[O] [fr] separate agenda buffers for different types of agenda

[Samuel Wales]

this is a separate report from my previous report about keeping point
when refreshing.
i think it is unrelated.

i find myself doing a daily/weekly agenda, and often running an agenda
text search, and thus losing my place in the daily/weekly.

i am aware of c-c a *, but that also has the feature of turning off
refresh when i call the agenda.  all i want is two separate buffers,
so that if i call daily/weekly, i get that in the daily/weekly agenda
and it refreshes [and keeps point], but if i call text search, i get
that in the text search agenda buffer and it refreshes.

===

is this possible?

thanks.

-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

Re: [O] Problem with completion and case in tag search

[Alain . Cochard]

Nicolas Goaziou writes on Sun 27 May 2018 22:14:

> > The file ~/tmp/bug-agenda.org contains
 > >
 > >* foo :bar:baR:Bar:BAR:
 > >
 > > When in the empty document ~/tmp/bug-agenda2.org,
 > >
 > > if I type
 > >
 > >C-a m 
 > >
 > > it gives "BAR" in the minibuffer.
 > >
 > > If I type
 > >
 > >C-a m B
 > >
 > > it also gives "BAR".
 > >
 > > If I type
 > >
 > >C-a m b
 > >
 > > it gives "baR".
 > >
 > > Is it normal?  Am I doing something wrong?  Thank you.  Regards.
 > 
 > I pushed a fix in master. Could you confirm it fixes your issue?

Yes it does: everything works as expected now.  Thank you very much.

I can't help being surprised though: this problem is likely to affect
any user using both upper and lower case for tags, and it has been
around for a while now (it is also there for version 8.2) -- how come
nobody reported it?  Well, it is just curiosity...

Regards

-- 
EOST (École et Observatoire des Sciences de la Terre) 
IPG (Institut de Physique du Globe) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 106] | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France| Fax:   +33 (0)3 68 85 01 25 

Re: [O] point moves and zoom level reverts when refreshing agenda

[Samuel Wales]

On 5/27/18, Samuel Wales  wrote:
> 2] i also find that refreshing resets the zoom level created using
> text-scale-increase.  i wonder if this can also be preserved.  to me,
> refreshing refers to updating the contents of the agenda view, not
> things like text scale.

[O] point moves and zoom level reverts when refreshing agenda

[Samuel Wales]

recent maint, have not tried in -Q.

summary: point moves and zoom level reverts when refreshing agenda

1]

i find that,

when i do an agenda agenda [daily/weekly] and i have point on a task,

and i go do something in the task and nearby nodes, and a bunch of
other things, and return to the agenda,

and refresh agenda view [and also just in case any of the markers god
out of date and could cause corruption if i operated on a task from
the agenda],

that point moves from the task.  i wonder if it makes sense to try to
keep point on the task that it was on?

2] i also find that refreshing resets the zoom level created using
text-scale-increase.  i wonder if this can also be preserved.  to me,
refreshing refers to updating the contents of the agenda view, not
things like text scale.

thanks.

-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

Re: [O] C++ is not accepted for SRC block evaluation

[Nicolas Goaziou]

Aaron Ecay  writes:

> Is this right?  Even if the feature is provide-d by the file, the require
> in org-babel-do-load-languages will not find it (because the file name
> does not match).  C++ is not a valid choice for the variable AFAICT.  The
> customize interface makes that clear by not offering it as an option, but
> if the variable is customized outside of customize (so to speak...) chaos
> reigns...

You are right, the change is not sufficient, although it doesn't make
things worse. We could modify `org-babel-load-languages' defcustom and
add lines:

   (const :tag "C++" C)
   (const :tag "D" C)

which would do the job from Customize, but not for a user changing the
variable outside it, as you point out.

We probably need to implement a mapping between languages symbols and
files and use it in `org-babel-do-load-languages'. The implicit mapping
it uses currently has shortcomings.

We could also leave it like this (even with my patch reverted), and
document it somehow. Maybe a third column per language in (info "(org)
Languages") to hold the file name.

WDYT?

Re: [O] unable to edit indirect-buffer in fundamental mode without losing pretty printing in base buffer org mode

[Nicolas Goaziou]

Aaron Ecay  writes:

> Of course, done in c32938b7f.  I did not realize how the freeze for 9.2
> was working.

Thank you.

BTW, I'm considering creating a "next" branch for pending patches that
I'm refraining to push to master. It could help moving forward.

>> However, your fix is not great at all. It was discussed on this ML,
>> about square brackets in links: it causes "jumpings" during editing,
>> which some users, including me, find annoying. Even if it was optional,
>> it would need to be discussed beforehand.
>
> I must have missed that discussion.  I would say that the “jump” in
> this case is only three characters,

Not at all. If you're fontifying sub/superscripts, it changes size of
the whole script (e.g., a_{0123456789}), so it can be obnoxious.

Besides, even if a single character changes its size, the whole line
"jumps". This is distracting.

> whereas for links it is much more (as the whole link becomes un- and
> re-hidden).

Actually, that was only square brackets around the link, not the link
itself, so there was really 2 characters involved. But, see above.

> I would not like links to work this way, but for foo-scripts I found
> it to be quite natural in my testing. So I hope that we can discuss it
> (as an optional feature, certainly) once 9.2 is out.

We can of course discuss it on the ML, but it would be nice to make
clear what is the problem to solve first.

Re: [O] Babel - :export-dir and :file-ext arguments cause all blocks to emit files

[Nicolas Goaziou]

Aaron Ecay  writes:

> (As an aside: is org-footnote-auto-adjust TRT for the manual?  It seems
> like it will lead to lots of churn every time a footnote is added or
> removed...)

This is a trade-off, indeed. It adds churn in diffs, but it's more
natural to follow when editing or simply reading the Org file.

Re: [O] C++ is not accepted for SRC block evaluation

[Aaron Ecay]

Hi Nicolas,

2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen:

[...]

> No, that's not correct. It should be (C++ . t), but "ob-C.el" should
> provide "ob-C++" feature, too.

Is this right?  Even if the feature is provide-d by the file, the require
in org-babel-do-load-languages will not find it (because the file name
does not match).  C++ is not a valid choice for the variable AFAICT.  The
customize interface makes that clear by not offering it as an option, but
if the variable is customized outside of customize (so to speak...) chaos
reigns...

-- 
Aaron Ecay

Re: [O] Babel - :export-dir and :file-ext arguments cause all blocks to emit files

[Aaron Ecay]

Hi Nicolas,

2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay  writes:
> 
>> Iʼve pushed commit 1643f70d3 to master which documents this behavior.
> 
> Thank you. Please have a look at the consistency edits I made to it.

Thanks very much.

(As an aside: is org-footnote-auto-adjust TRT for the manual?  It seems
like it will lead to lots of churn every time a footnote is added or
removed...)

-- 
Aaron Ecay

Re: [O] unable to edit indirect-buffer in fundamental mode without losing pretty printing in base buffer org mode

[Aaron Ecay]

Hi Nicolas,

2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen:

[...]

> 
> Also, we are in feature freeze for Org 9.2, so this would need, in any
> case, to wait for the release.
> 
> As a consequence, would you mind reverting the patches related to this
> feature?

Of course, done in c32938b7f.  I did not realize how the freeze for 9.2
was working.

> 
> However, your fix is not great at all. It was discussed on this ML,
> about square brackets in links: it causes "jumpings" during editing,
> which some users, including me, find annoying. Even if it was optional,
> it would need to be discussed beforehand.

I must have missed that discussion.  I would say that the “jump” in
this case is only three characters, whereas for links it is much more
(as the whole link becomes un- and re-hidden).  I would not like links
to work this way, but for foo-scripts I found it to be quite natural in
my testing.  So I hope that we can discuss it (as an optional feature,
certainly) once 9.2 is out.

-- 
Aaron Ecay

Re: [O] C++ is not accepted for SRC block evaluation

[Nicolas Goaziou]

Hello,

Van L  writes:

>> John Kitchin writes:
>> 
>> It should be (C . t)
>> 
>> it looks like ob-C also handles C++.
>
> How about the following to update the documentation:
>
> #+BEGIN_EXAMPLE
>   diff --git a/doc/misc/org.texi b/doc/misc/org.texi
>   index cf1c037..7b00f0a 100644
>   --- a/doc/misc/org.texi
>   +++ b/doc/misc/org.texi
>   @@ -15522,7 +15522,8 @@ Languages
>@multitable @columnfractions 0.25 0.25 0.25 0.25
>@headitem @b{Language} @tab @b{Identifier} @tab @b{Language} @tab 
> @b{Identifier}
>@item Asymptote @tab asymptote @tab Awk @tab awk
>   -@item C @tab C @tab C++ @tab C++
>   +@c @item C @tab C @tab C++ @tab C++
>   +@item C++ @tab C @tab C @tab C
>@item Clojure @tab clojure @tab CSS @tab css
>@item D @tab d @tab ditaa @tab ditaa
>@item Graphviz @tab dot @tab Emacs Calc @tab calc
> #+END_EXAMPLE

No, that's not correct. It should be (C++ . t), but "ob-C.el" should
provide "ob-C++" feature, too.

I pushed a fix along those lines in master.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Problem with completion and case in tag search

[Nicolas Goaziou]

Hello,

alain.coch...@unistra.fr writes:

> I run 
>
>emacs -Q -l ~/tmp/scr.emacs 
>
> The file ~/tmp/scr.emacs contains
>
>(add-to-list 'load-path "~/.emacs.d/elpa/org-20180521/")
>(setq org-agenda-files '("~/tmp/bug-agenda.org"))
>(global-set-key "\C-ca" 'org-agenda)
>(find-file "~/tmp/bug-agenda2.org") ;; <- empty file
>
> The file ~/tmp/bug-agenda.org contains
>
>* foo :bar:baR:Bar:BAR:
>
> When in the empty document ~/tmp/bug-agenda2.org,
>
> if I type
>
>C-a m 
>
> it gives "BAR" in the minibuffer.
>
> If I type
>
>C-a m B
>
> it also gives "BAR".
>
> If I type
>
>C-a m b
>
> it gives "baR".
>
> Is it normal?  Am I doing something wrong?  Thank you.  Regards.

I pushed a fix in master. Could you confirm it fixes your issue?

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Babel - :export-dir and :file-ext arguments cause all blocks to emit files

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> Iʼve pushed commit 1643f70d3 to master which documents this behavior.

Thank you. Please have a look at the consistency edits I made to it.

> Iʼm inclined not to make the change now, but (hopefully remember to)
> revisit it when Org 10 is imminent.

I agree now is clearly not the time for such a change. We could however
try to make that right as soon as Org 9.2 is released.

Regards,

-- 
Nicolas Goaziou

Re: [O] unable to edit indirect-buffer in fundamental mode without losing pretty printing in base buffer org mode

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> OTOH, we need to provide a way to edit those curly braces.  I have just
> pushed commit 102832e66 to the master branch.  That will cause any
> sub/superscript under the point to have its font lock properties
> removed, so that the braces will become visible for editing.  It is
> modeled after a similar feature in emacs built-in
> prettify-symbols-mode.
>
> So, I think that should address your usecase.

As far as the initial problem is concerned, this is an issue with
indirect buffers, a feature that is not well considered even by Emacs
developers. It has clear limitations.

On the other hand, I agree that editing sub/superscripts is not optimal.
In particular, hiding braces and using skeleton pairs for curly brackets
is not a nice editing experience. It would be nice if we could make it
smoother.

However, your fix is not great at all. It was discussed on this ML,
about square brackets in links: it causes "jumpings" during editing,
which some users, including me, find annoying. Even if it was optional,
it would need to be discussed beforehand.

Also, we are in feature freeze for Org 9.2, so this would need, in any
case, to wait for the release.

As a consequence, would you mind reverting the patches related to this
feature?

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] extract a column from a table but but an name on the new table

[Uwe Brauer]

   > On 26/05/2018 10:32, Uwe Brauer wrote:
   > You may like the out-of-the-boxtable remote references:

   > | 3 |
   > | 4 |
   > | 6 |
   > | 7 |
   > |   |
   > |   |

   > #+TBLFM: $1=remote(raw-data,@@#$3)

   > The downside is that you need to create an empty table with the right 
   > size before filling it with C-u C-c *


   > I get a result. Maybe you used downcase "notasA" where uppercase 
   > "NotasA" was expected?

You are right!! I did not pay attention!

Now it works, thanks very very much, that simplifies my workflow.

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] Babel - :export-dir and :file-ext arguments cause all blocks to emit files

[Aaron Ecay]

Hi Alex,

2018ko maiatzak 25an, Alex Fenton-ek idatzi zuen:

[...]


> Now I understand how it was intended (a shortcut for people who are 
> scrupulous about using #+NAME) it makes sense. 

Iʼve pushed commit 1643f70d3 to master which documents this behavior.

> I was thinking it was meant as an easy way to switch globally between
> different formats (sometimes I want PDF for ease, sometimes I want
> Tikz for publication-quality, sometimes I want SVG for online etc.).

I agree it would be nice.  You can have executable elisp in header
arguments, so it is possible to do something like this (though ugly,
since the same snippet has to be duplicated across every src block).

One example of what I mean is at
;
search for “by-backend” in the page.


[...]

> 
> You (all) are a better judge of what is a reasonable non-back-compatible 
> change.

Iʼm inclined not to make the change now, but (hopefully remember to)
revisit it when Org 10 is imminent.

Thanks for raising the issue,

-- 
Aaron Ecay

Re: [O] unable to edit indirect-buffer in fundamental mode without losing pretty printing in base buffer org mode

[Aaron Ecay]

Hi Van,

What you describe is fragile and should not work.

OTOH, we need to provide a way to edit those curly braces.  I have just
pushed commit 102832e66 to the master branch.  That will cause any
sub/superscript under the point to have its font lock properties
removed, so that the braces will become visible for editing.  It is
modeled after a similar feature in emacs built-in
prettify-symbols-mode.

So, I think that should address your usecase.

Thanks for raising the issue.

-- 
Aaron Ecay

Re: [O] RFC: Proposal for an Org Special Block for ox-html

[Aaron Ecay]

Hi Kaushal,

[...]

> But then I also wanted to mask all the shortcoming of Markdown. So ox-hugo
> helps bridge that gap by filling in HTML snippets only where needed. I hope
> that makes sense.

It does indeed make sense, thanks for the explanation.  Now I understand
the context a bit better.

I added “summary” to ‘org-html-html5-elements’ in commit 5192e810a.  It
seems obviously correct (in fact, “details” was already included in that
variable).  So now summary/details should work for HTML5 export.  Thank
you for raising this issue.

It sounds like you have things well in hand for ox-{hugo,blackfriday}.
And I do not think there are any other shortcomings in org core that are
left outstanding from this discussion.

Thanks again,

-- 
Aaron Ecay

Re: [O] [patch] Check org-structure-template-alist

[Aaron Ecay]

Hi Rasmus,

2018ko maiatzak 27an, Rasmus-ek idatzi zuen:

[...]

> If there’s any better way to display the error 

org-display-warning?

[...]

> +   (mapconcat 'identity
> +   '("Please update the entries of `%s'."
> + ""
> + "In Org 9.2 the format was changed from something akin to"
> + "   (\"s\" \"#+BEGIN_SRC ?\\n#+END_SRC\" "
> + "to something akin to"
> + "(\"s\" . \"src\")"
> + "See (info \"(org)org-structure-template-alist\")"
> + ""
> + "The following entries must be updated:"
> + ""
> + "%s"
> + "%s")
> +   "\n")

You could use a multiline string literal.  IMO itʼs less ugly (but
still ugly...)
-- 
Aaron Ecay

Re: [O] extract a column from a table but but an name on the new table

[Thierry Banel]

On 26/05/2018 10:32, Uwe Brauer wrote:



> You may name the Lisp block like that:

> --

> #+TBLNAME: raw-data
> | 1 | a | 3 |
> | 2 | b | 4 |
> | 3 | c | 6 |
> | 4 | d | 7 |


Thank you!

BTW I found it strange that the extracting function does not exist in
vanilla org.

You may like the out-of-the-boxtable remote references:

| 3 |
| 4 |
| 6 |
| 7 |
|   |
|   |
#+TBLFM: $1=remote(raw-data,@@#$3)

The downside is that you need to create an empty table with the right 
size before filling it with C-u C-c *




My situation is a bit different, since I later want to use R.

So I have


#+TBLNAME: raw-data
| 1 | a | 3 |
| 2 | b | 4 |
| 3 | c | 6 |
| 4 | d | 7 |

#+NAME: NotasA
#+BEGIN_SRC elisp :var data=raw-data
(mapcar (lambda (line)
 (list (nth 2 line)))
  data)
#+END_SRC

#+RESULTS: NotasA
| 3 |
| 4 |
| 6 |
| 7 |



#+begin_src R  :var notasA=notasA
summary(notasA)
#+end_src

And the last call does not work. It seems that R needs a table name.

Uwe



I get a result. Maybe you used downcase "notasA" where uppercase 
"NotasA" was expected?


#+begin_src R  :var notasA=NotasA
summary(notasA)
#+end_src

#+RESULTS:
| Min.   :3.00 |
| 1st Qu.:3.75 |
| Median :5.00 |
| Mean   :5.00 |
| 3rd Qu.:6.25 |
| Max.   :7.00 |

[O] [patch] Check org-structure-template-alist

[Rasmus]

Hi,

Here’s a patch that would check org-structure-template-alist for the "old"
format.

It just pops a user-error if the old format is detected (it checks if the
cdr of org-structure-template-alist entries is a list).

On my system, binding max-mini-window-height seems to have no effect.  My
test window-total-height is 35.

(let ((max-mini-window-height 15))
  (message (mapconcat 'number-to-string (number-sequence 1 15) "\n")))

If there’s any better way to display the error or check if
org-structure-template-alist is in the "old" format let me know.

Rasmus 

-- 
Slowly unravels in a ball of yarn and the devil collects it
>From 7ae2fd392aaa5f76f65f4c88a0b1286167d6732a Mon Sep 17 00:00:00 2001
From: Rasmus 
Date: Sun, 27 May 2018 14:44:49 +0200
Subject: [PATCH] Check format of org-structure-template-alist

* org.el (org--check-org-structure-template-alist): New function
  yielding user-error if using old org-structure-template-alist
  format.
  (org--insert-structure-template-mks):
* org-tempo.el (org-tempo-add-templates): Use new function
---
 lisp/org-tempo.el |  2 ++
 lisp/org.el   | 36 
 2 files changed, 38 insertions(+)

diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index b9a554ff7..a651c7b37 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -102,6 +102,8 @@ Tempo templates will be added."
 
 Go through `org-structure-template-alist' and
 `org-tempo-keywords-alist' and update tempo templates."
+  (mapc 'org--check-org-structure-template-alist '(org-structure-template-alist
+		   org-tempo-keywords-alist))
   (let ((keys (org-tempo--keys)))
 ;; Check for duplicated snippet keys and warn if any are found.
 (when (> (length keys) (length (delete-dups keys)))
diff --git a/lisp/org.el b/lisp/org.el
index b05acd78a..c67e91489 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11727,6 +11727,41 @@ block can be inserted by pressing TAB after the string \" len maxlen)
+	   (format "... And %s other entries" (- len maxlen))
+	 "")
+
 (defun org--insert-structure-template-mks ()
   "Present `org-structure-template-alist' with `org-mks'.
 
@@ -11734,6 +11769,7 @@ Menus are added if keys require more than one keystroke.  Tabs
 are added to single key entries when more than one stroke is
 needed.  Keys longer than two characters are reduced to two
 characters."
+  (org--check-org-structure-template-alist)
   (let* (case-fold-search
 	 (templates (append org-structure-template-alist
 			'(("\t" . "Press TAB, RET or SPC to write block name"
-- 
2.17.0

[O] unable to edit indirect-buffer in fundamental mode without losing pretty printing in base buffer org mode

[Van L]

Hello.

Is it possible to edit a buffer in org mode 
and its indirect-buffer in fundamental mode 
without losing pretty printing in the org mode base buffer?

At the indirect-buffer, I switch to fundamental mode and 
that causes the base buffer in org mode to 
lose the pretty printing for superscript, subscript. 

The two mode lines are set: org mode and fundamental mode. 

I drop into fundamental mode to adjust the curly braces for 
super/subscripting and want to see the changes in the base buffer
in org mode.

I use the following to create the indirect buffer.

  clone-indirect-buffer-other-window

Org mode version 9.1.9
GNU Emacs 26.1-rc1