Re: [O] Bug: org-clock-total-time is calculated from midnight in UTC (not in current time zone) [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]

[Samuel Wales]

in friendly jest:

On 12/21/17, Ihor Radchenko  wrote:
> intended recipient, you are hereby notified that any use, dissemination,
> distribution, or copying of this message, or any attachment, is strictly
> prohibited. If you have received this email in error, please inform the

all those people who read the archives have to send you email and
delete the archives!

that poor bot!  it is being told to send you email for each message!
it is disseminating!  or maybe distributing!

i'm gonna prohibit you from combing your hair for the next week!
because you received this email!  i'll bet you think this email is
about you!  don't you!  don't you!

-- 
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] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

[Nicolas Goaziou]

Hello,

Nathan Aclander  writes:

> Now I'm curious, do you have an example list where this would be
> obviously confusing and ambiguous?

* Headline 1

** Sub-headline

- Plain list

  - Sub-list

  - Sub-item

[X]


If the point is at [X], any headline, plain-list or item could claim
`M-S-'. This can be confusing if the surrounding structure is not
visible around point.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] Bug: org-clock-total-time is calculated from midnight in UTC (not in current time zone) [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]

[Nicolas Goaziou]

Hello,

Allen Li  writes:

> On Thu, Dec 21, 2017 at 5:55 PM, Ihor Radchenko
>  wrote:
>>
>> org-clock-in in org-clock.el calculates org-clock-total-time via calling
>> (org-clock-sum-current-item (org-clock-get-sum-start)).
>> However, org-clock-get-sum-start returns the time in UTC, which is not
>> considered by org-clock-sum-current-time.
>>
>> My time zone if UTC+8 and org-clock-mode-line-total is 'today. Hence
>> org-clock-total-time is gives total time starting from 8am today (which
>> is midnight in UTC) instead of midnight in UTC+8.
>
> This sounds like a continuation of Org mode’s timezone issues.

Indeed. This is a leftover from timezone issues. I removed it.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Editing src blocks: user-error: Cannot modify an area being edited in a dedicated buffer [9.1.4 (9.1.4-2-g118753-elpaplus @ /home/paul/.emacs.d/elpa/org-plus-contrib-20171211/)]

[stardiviner]

@Paul Do you have similar config? I use it to enable flycheck in editing 
temp src buffer.



   (defadvice org-edit-src-code (around set-buffer-file-name activate
   compile)
  (let ((file-name (buffer-file-name)))
    ad-do-it
    (setq buffer-file-name file-name)))


On 12/22/2017 06:39 AM, Paul Davis wrote:


Turns out that the issue was caused by trying to disable a flycheck 
checker using the org edit src hook



On Mon, Dec 18, 2017, 6:30 AM Nicolas Goaziou > wrote:


Hello,

Paul Davis > writes:

> Using ~C-c '~ to edit a src block works as expected, but if I make
> changes and use ~C-c '~ again, I get the error ~Cannot modify an
area
> being edited in a dedicated buffer~

I need more information. Where do you make changes? In the newly
created
buffer? Where do you call ~C-c '~?

For example, I created the following buffer

    #+begin_src emacs-lisp
      (+ 1 2)
    #+end_src

moved on the source block, used C-c '. Then, in the new buffer,
I replaced 2 with 3 and pressed C-c ' again, without any error?

IOW, could you provide a precise recipe demonstrating the issue?

Thank you.

Regards,

--
Nicolas Goaziou

Re: [O] Bug: List does not fold correctly with inline tasks in the middle [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]

[Ihor Radchenko]

I am dumb...
Forgot to load 'org-inlinetask


'Ihor Radchenko'  writes:

> 1. Create the following same org file:
> * Test
>   - blah
> - a
> - b
> - c
> *** List folding stops here
>  :PROPERTIES:
>  :ID:   27eb85b6-114f-437f-9424-b28d400f6aa9
>  :END:
> *** END
> - everything here and below folds on tab at =**...END=
> - f
>
> 2. Try to fold at =-blah=. Everything started from inline task is not
> folded, while should.
>
> 3. Try to fold at =*... END=. Everything below *is* folded, while should
> not.
>
> Regards,
> Ihor
>
>
> Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, X toolkit)
>  of 2017-12-06
> Package: Org mode version 9.1.4 (9.1.4-13-g84cb63-elpa @ 
> /home/yantar92/.emacs.d/elpa/org-20171218/)
> -- 
> Ihor Radchenko,
> PhD Student
> Singapore University of Technology and Design,
> 8 Somapah Road Singapore 487372
> Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg
> Tel: +6584017977

-- 
Ihor Radchenko,
PhD Student
Singapore University of Technology and Design,
8 Somapah Road Singapore 487372
Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg
Tel: +6584017977


signature.asc
Description: PGP signature

[O] Bug: List does not fold correctly with inline tasks in the middle [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]

['Ihor Radchenko']

1. Create the following same org file:
* Test
  - blah
- a
- b
- c
*** List folding stops here
 :PROPERTIES:
 :ID:   27eb85b6-114f-437f-9424-b28d400f6aa9
 :END:
*** END
- everything here and below folds on tab at =**...END=
- f

2. Try to fold at =-blah=. Everything started from inline task is not
folded, while should.

3. Try to fold at =*... END=. Everything below *is* folded, while should
not.

Regards,
Ihor


Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, X toolkit)
 of 2017-12-06
Package: Org mode version 9.1.4 (9.1.4-13-g84cb63-elpa @ 
/home/yantar92/.emacs.d/elpa/org-20171218/)
-- 
Ihor Radchenko,
PhD Student
Singapore University of Technology and Design,
8 Somapah Road Singapore 487372
Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg
Tel: +6584017977


signature.asc
Description: PGP signature

Re: [O] Bug: org-clock-total-time is calculated from midnight in UTC (not in current time zone) [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]

[Allen Li]

On Thu, Dec 21, 2017 at 5:55 PM, Ihor Radchenko
 wrote:
>
> org-clock-in in org-clock.el calculates org-clock-total-time via calling
> (org-clock-sum-current-item (org-clock-get-sum-start)).
> However, org-clock-get-sum-start returns the time in UTC, which is not
> considered by org-clock-sum-current-time.
>
> My time zone if UTC+8 and org-clock-mode-line-total is 'today. Hence
> org-clock-total-time is gives total time starting from 8am today (which
> is midnight in UTC) instead of midnight in UTC+8.

This sounds like a continuation of Org mode’s timezone issues.

The original thread (which is long-winded):

http://lists.gnu.org/archive/html/emacs-orgmode/2017-11/msg0.html
http://lists.gnu.org/archive/html/emacs-orgmode/2017-11/msg00027.html

The second bug, also timezone issues:

http://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00039.html

[O] Bug: org-clock-total-time is calculated from midnight in UTC (not in current time zone) [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]

[Ihor Radchenko]

This email may contain confidential and/or proprietary information that is 
exempt from disclosure under applicable law and is intended for receipt and use 
solely by the addressee(s) named above. If you are not the intended recipient, 
you are notified that any use, dissemination, distribution, or copying of this 
email, or any attachment, is strictly prohibited. Please delete the email 
immediately and inform the sender. Thank You
The above message may contain confidential and/or proprietary information that 
is exempt from disclosure under applicable law and is intended for receipt and 
use solely by the addressee(s) named above. If you are not the intended 
recipient, you are hereby notified that any use, dissemination, distribution, 
or copying of this message, or any attachment, is strictly prohibited. If you 
have received this email in error, please inform the sender immediately by 
reply e-mail or telephone, reversing the charge if necessary. Please delete the 
message thereafter. Thank you.
--- Begin Message ---


Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


org-clock-in in org-clock.el calculates org-clock-total-time via calling
(org-clock-sum-current-item (org-clock-get-sum-start)).
However, org-clock-get-sum-start returns the time in UTC, which is not
considered by org-clock-sum-current-time.

My time zone if UTC+8 and org-clock-mode-line-total is 'today. Hence
org-clock-total-time is gives total time starting from 8am today (which
is midnight in UTC) instead of midnight in UTC+8.

Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, X toolkit)
 of 2017-12-06
Package: Org mode version 9.1.4 (9.1.4-13-g84cb63-elpa @ 
/home/yantar92/.emacs.d/elpa/org-20171218/)

-- 
Ihor Radchenko,
PhD Student
Singapore University of Technology and Design,
8 Somapah Road Singapore 487372
Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg
Tel: +6584017977


signature.asc
Description: PGP signature
--- End Message ---

Re: [O] Bug: Editing src blocks: user-error: Cannot modify an area being edited in a dedicated buffer [9.1.4 (9.1.4-2-g118753-elpaplus @ /home/paul/.emacs.d/elpa/org-plus-contrib-20171211/)]

[Paul Davis]

Turns out that the issue was caused by trying to disable a flycheck checker
using the org edit src hook

On Mon, Dec 18, 2017, 6:30 AM Nicolas Goaziou 
wrote:

> Hello,
>
> Paul Davis  writes:
>
> > Using ~C-c '~ to edit a src block works as expected, but if I make
> > changes and use ~C-c '~ again, I get the error ~Cannot modify an area
> > being edited in a dedicated buffer~
>
> I need more information. Where do you make changes? In the newly created
> buffer? Where do you call ~C-c '~?
>
> For example, I created the following buffer
>
> #+begin_src emacs-lisp
>   (+ 1 2)
> #+end_src
>
> moved on the source block, used C-c '. Then, in the new buffer,
> I replaced 2 with 3 and pressed C-c ' again, without any error?
>
> IOW, could you provide a precise recipe demonstrating the issue?
>
> Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Bug: Tangling python code results in mixed tabs and spaces, incomaptible with python3 [9.1.4 (9.1.4-dist @ /home/ehere/emacs-scripts/org-9.1.4/lisp/)]

[Nicolas Goaziou]

Hello,

Edmund Christian Herenz  writes:

> The following python code uses only whitespaces for the different
> indentdation levels:
>
> a_list = ['elem1',
>   'elem2',
>   'elem3']
>
> for elem in a_list:
> print(elem)
> for char in elem:
> print char
>
> I enter this code into a SRC block with
>
> #+BEGIN_SRC python :tangle blank_test.py
>
> #+END_SRC
>
> by pressing C-' inside the block (which opens the editing buffer
> python-mode).  Then I press C-' again, after which I tangle the code
> to blank_test.py by pressing C-u C-c C-v C-t.  The resulting file
> blank_test.py will contain a mix of tabs and spaces for the different
> intendation levels.  (I checked this with whitespace.el).
>
> Above behaviour is a bug, since Python3 forbids mixing of spaces and
> tabs. (Python2 is more relaxed about mixing of tabs and spaces). Thus,
> the above code, syntactical correctly entered into an OrgSrc buffer,
> will result in code that can not be run in python3 when tangled from
> an org-mode file.

Have you tried "-i" switch for the block, i.e.,

  #+BEGIN_SRC python -i :tangle blank_test.py


Regards, 

-- 
Nicolas Goaziou

[O] Bug: Tangling python code results in mixed tabs and spaces, incomaptible with python3 [9.1.4 (9.1.4-dist @ /home/ehere/emacs-scripts/org-9.1.4/lisp/)]

[Edmund Christian Herenz]

The following python code uses only whitespaces for the different
indentdation levels:

a_list = ['elem1',
  'elem2',
  'elem3']

for elem in a_list:
print(elem)
for char in elem:
print char

I enter this code into a SRC block with

#+BEGIN_SRC python :tangle blank_test.py

#+END_SRC

by pressing C-' inside the block (which opens the editing buffer
python-mode).  Then I press C-' again, after which I tangle the code
to blank_test.py by pressing C-u C-c C-v C-t.  The resulting file
blank_test.py will contain a mix of tabs and spaces for the different
intendation levels.  (I checked this with whitespace.el).

Above behaviour is a bug, since Python3 forbids mixing of spaces and
tabs. (Python2 is more relaxed about mixing of tabs and spaces). Thus,
the above code, syntactical correctly entered into an OrgSrc buffer,
will result in code that can not be run in python3 when tangled from
an org-mode file.

Emacs  : GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2017-09-12 on hullmann, modified by Debian
Package: Org mode version 9.1.4 (9.1.4-dist @ 
/home/ehere/emacs-scripts/org-9.1.4/lisp/)

Re: [O] [BUG] Re: header argument :noweb-ref seems can't be resolved

[numbch...@gmail.com]

 problem solved, Thanks very much. @Nicolas and @Berry.

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Wed, Dec 20, 2017 at 8:23 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> "Berry, Charles"  writes:
>
> > Looks pretty clean. I've not had time to try it out, however.
>
> Thank you.
>
> OK. I applied it on master. Since there was some differences with maint,
> I didn't backport it there, though. Instead, I bound
> `org-babel-current-sourced-block-location' to the current block.
>
> Hopefully, the problem is now solved.
>
> Regards,
>
> --
> Nicolas Goaziou
>
>

Re: [O] [BUG] Re: header argument :noweb-ref seems can't be resolved

[Nicolas Goaziou]

Hello,

"Berry, Charles"  writes:

> Looks pretty clean. I've not had time to try it out, however.

Thank you.

OK. I applied it on master. Since there was some differences with maint,
I didn't backport it there, though. Instead, I bound
`org-babel-current-sourced-block-location' to the current block.

Hopefully, the problem is now solved.

Regards,

-- 
Nicolas Goaziou

Re: [O] [BUG] Re: header argument :noweb-ref seems can't be resolved

[Berry, Charles]

> On Dec 19, 2017, at 11:00 AM, Nicolas Goaziou  wrote:
> 
> Since :noweb-ref is the only property that absolutely needs to be
> retrieved from definition, another option would be to write a specific
> function for that.
> 
> It implies some duplicated efforts with `org-babel-get-src-block-info',
> but it is faster when the source name doesn't match, which is the most
> common case, and avoids all side-effects from
> `org-babel-get-src-block-info'.
> 
> WDYT?

Looks pretty clean. I've not had time to try it out, however.

Chuck

Re: [O] [BUG] Re: header argument :noweb-ref seems can't be resolved

[Nicolas Goaziou]

Hello,

"Berry, Charles"  writes:

> I guess I was unclear. There are two ways to fix this.
>
> 1) let bind org-babel-current-src-block-location in
> org-babel-expand-noweb-references in the loop that scans for
> noweb-ref'ed src blocks. This fixes the bug, but contradicts the
> docstring for o-b-c-s-b-l, which says it is the location of the
> currently executing src block. Maybe not a big deal, since
> `org-babel-exp-src-block' can export blocks that are not actually
> executed which is another contradiction of the docstring. Maybe change
> the docstring.
>
> 2) rewrite org-babel-params-from-properties to add an optional arg
> `src-block-location' and use it when provided to govern where to look
> up properties. Modify `org-babel-get-src-block-info' accordingly to
> add that arg when calling o-b-p-f-p. This honors the use of
> o-b-c-s-b-l as the location of the executing src block, but inflates
> the code to accommodate just the `noweb-ref' case.
>
> I think `2' is better as it makes clearer where o-b-p-f-p is looking
> for properties when reading the code of org-babel-get-src-block-info.

Since :noweb-ref is the only property that absolutely needs to be
retrieved from definition, another option would be to write a specific
function for that.

It implies some duplicated efforts with `org-babel-get-src-block-info',
but it is faster when the source name doesn't match, which is the most
common case, and avoids all side-effects from
`org-babel-get-src-block-info'.

WDYT?

Regards,

-- 
Nicolas Goaziou
>From ea24f751fd4ec91857d59e2c287754d3d6dc33f1 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Tue, 19 Dec 2017 19:55:51 +0100
Subject: [PATCH] ob-core: Correctly find  Noweb reference

* lisp/ob-core.el (org-babel--noweb-reference): New function.
(org-babel-expand-noweb-references): Use new function.
---
 lisp/ob-core.el | 41 +
 1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index ade39ec67..bc3c255f5 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2662,6 +2662,36 @@ CONTEXT may be one of :tangle, :export or :eval."
 (cl-some (lambda (v) (member v allowed-values))
 	 (split-string (or (cdr (assq :noweb params)) "")
 
+(defun org-babel--noweb-reference (element)
+  "Return Noweb reference for ELEMENT.
+ELEMENT is a source block.  Return value from `:noweb-ref',
+possibly inherited from properties, or nil."
+  (let ((language (org-element-property :language element)))
+(cdr
+ (or (assq :noweb-ref		;from block itself
+	   (org-babel-parse-header-arguments
+		(mapconcat #'identity
+			   (cons (org-element-property :parameters element)
+ (org-element-property :header element))
+			   " ")))
+	 (assq :noweb-ref		;from properties
+	   (org-babel-parse-header-arguments
+		(org-trim
+		 (concat
+		  (and language
+		   (org-entry-get (point)
+  (concat "header-args:" language)
+  'inherit))
+		  " "
+		  (org-entry-get (point) "header-args" 'inherit)
+	 (and language
+	  (let ((lang-headers
+		 (intern (concat "org-babel-default-header-args:"
+ language
+		(and (boundp lang-headers)
+		 (assq :noweb-ref (symbol-value lang-headers)
+	 (assq :noweb-ref org-babel-default-header-args)
+
 (defun org-babel-expand-noweb-references ( info parent-buffer)
   "Expand Noweb references in the body of the current source code block.
 
@@ -2777,11 +2807,14 @@ block but are passed literally to the \"example-block\"."
 			;; those with a matching Noweb reference.
 			(let ((expansion nil))
 			  (org-babel-map-src-blocks nil
-			(let ((i (org-babel-get-src-block-info 'light)))
+			(let ((element (org-element-at-point)))
 			  (when (equal source-name
-	   (cdr (assq :noweb-ref (nth 2 i
-(let ((sep (or (cdr (assq :noweb-sep (nth 2 i)))
-	   "\n")))
+	   (org-babel--noweb-reference element))
+(let* ((i (org-babel-get-src-block-info
+	   'light element))
+   (sep
+	(or (cdr (assq :noweb-sep (nth 2 i)))
+	"\n")))
   (setq expansion
 	(cons sep
 	  (cons (funcall expand-body i)
-- 
2.15.1

Re: [O] [BUG] Re: header argument :noweb-ref seems can't be resolved

[Berry, Charles]

> On Dec 18, 2017, at 11:31 PM, stardiviner  wrote:
> 
> Confirmed. I don't know how to fix this problem, so maybe report to Org-mode 
> ML is the better way. (I changed the message title by prepend [BUG])

I guess I was unclear. There are two ways to fix this.

1) let bind org-babel-current-src-block-location in 
org-babel-expand-noweb-references in the loop that scans for noweb-ref'ed src 
blocks.  This fixes the bug, but contradicts the docstring for o-b-c-s-b-l, 
which says it is the location of the currently executing src block. Maybe not a 
big deal, since `org-babel-exp-src-block' can export blocks that are not 
actually executed which is another contradiction of the docstring. Maybe change 
the docstring. 

2) rewrite org-babel-params-from-properties to add an optional arg 
`src-block-location' and use it when provided to govern where to look up 
properties.  Modify `org-babel-get-src-block-info' accordingly to add that arg 
when calling o-b-p-f-p.  This honors the use of o-b-c-s-b-l as the location of 
the executing src block, but inflates the code to accommodate just the 
`noweb-ref' case.  

I think `2' is better as it makes clearer where o-b-p-f-p is looking for 
properties when reading the code of org-babel-get-src-block-info.

Chuck

[O] [BUG] Re: header argument :noweb-ref seems can't be resolved

[stardiviner]

Confirmed. I don't know how to fix this problem, so maybe report to 
Org-mode ML is the better way. (I changed the message title by prepend 
[BUG])



On 12/19/2017 12:59 PM, Berry, Charles wrote:



On Dec 18, 2017, at 9:28 AM, numbch...@gmail.com wrote:

Hope someone can help here.


OK. I think I have it. `org-babel-params-from-properties' uses 
`org-babel-current-src-block' to figure out where to look for properties. And o-b-c-s-b-l 
is let bound in `org-babel-noweb-expand-references' to the src block location with the 
noweb reference, e.g. `<>'.


The problem can be illustrated like so. Put this in a buffer:

#+begin_src org

   ,* abc
 :PROPERTIES:
 :header-args: :noweb-ref abcblocks
 :END:

   ,#+name: got-abc
   ,#+begin_src R
   1+2
   ,#+end_src


   ,* def

#+end_src

execute this:

#+begin_src emacs-lisp
   (defun show-prob (obcsbl)
 (let
((org-babel-current-src-block-location obcsbl))
  (assq :noweb-ref (nth 2 (org-babel-get-src-block-info)
#+end_src

Then put point in the got-abc src block and type

 M-: (show-prob (point)) RET

and you will see `(:noweb-ref . "abcblocks")' in the minibuffer.

Now try

M-:  (show-prob 1000) RET

and the result is `nil'.

The problem can be fixed by let-binding `org-babel-current-src-block-location' 
to `beg-body' in `org-babel-noweb-expand-references' like this

  (org-babel-map-src-blocks nil
(let*
((org-babel-current-src-block-location beg-body)
 (i (org-babel-get-src-block-info 'light)))

but maybe it is better to change  `org-babel-params-from-properties'.

WDYT?

Chuck

Re: [O] Bug: Editing src blocks: user-error: Cannot modify an area being edited in a dedicated buffer [9.1.4 (9.1.4-2-g118753-elpaplus @ /home/paul/.emacs.d/elpa/org-plus-contrib-20171211/)]

[Nicolas Goaziou]

Hello,

Paul Davis  writes:

> Using ~C-c '~ to edit a src block works as expected, but if I make
> changes and use ~C-c '~ again, I get the error ~Cannot modify an area
> being edited in a dedicated buffer~

I need more information. Where do you make changes? In the newly created
buffer? Where do you call ~C-c '~?

For example, I created the following buffer

#+begin_src emacs-lisp
  (+ 1 2)
#+end_src

moved on the source block, used C-c '. Then, in the new buffer,
I replaced 2 with 3 and pressed C-c ' again, without any error?

IOW, could you provide a precise recipe demonstrating the issue?

Thank you.

Regards,

-- 
Nicolas Goaziou

[O] Bug: Editing src blocks: user-error: Cannot modify an area being edited in a dedicated buffer [9.1.4 (9.1.4-2-g118753-elpaplus @ /home/paul/.emacs.d/elpa/org-plus-contrib-20171211/)]

[Paul Davis]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Using ~C-c '~ to edit a src block works as expected, but if I make
changes and use ~C-c '~ again, I get the error ~Cannot modify an area
being edited in a dedicated buffer~

It happens with the default setting for ~org-src-window-setup~ as well.

I was not experiencing this issue with version 20171127, which was the
last I had befire upgrading to this version. Tested on 20171205 and it
also presented this bug.


Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2017-12-04
Package: Org mode version 9.1.4 (9.1.4-2-g118753-elpaplus @
/home/paul/.emacs.d/elpa/org-plus-contrib-20171211/)

current state:
==
(setq
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 outline-minor-mode-hook '((lambda nil (make-local-variable (quote
smart-outline-cut)) (setq smart-outline-cut nil)))
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function '(closure
   (htmlize-buffer-places
org-html-format-table-no-css htmlize-css-name-prefix htmlize-output-type
htmlize-output-type htmlize-css-name-prefix t)
   (_name contents) contents)
 org-clock-into-drawer "LOGBOOK"
 org-log-done 'time
 org-src-window-setup 'other-frame
 org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
 org-clock-mode-line-total 'today
 org-confirm-shell-link-function 'yes-or-no-p
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-clock-idle-time 15
 org-pretty-entities t
 org-latex-format-headline-function
'org-latex-format-headline-default-function
 org-default-notes-file "~/org/todo.org"
 org-clock-in-resume t
 org-capture-templates '(("t" "Todo" entry (file+headline (concat
org-directory "/todo.org") "Todo") "* TODO %?\n  SCHEDULED:
%^{Schedule}t\n  %A")
 ("n" "Note" entry (file+headline (concat
org-directory "/notes.org") "Notes") "* %? %U\n  %i"))
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function '(closure (t) (_ contents) contents)
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-from-is-user-regexp nil
 org-src-mode-hook '(#[nil "\301 \302\"\207" [flycheck-disabled-checkers
add-to-list emacs-lisp-checkdoc] 3] org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-block-all append local] 5]
 #[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
 (closure
  (org-inlinetask-min-level org-struct-menu org-last-state
org-id-track-globally texmathp-why remember-data-file
org-agenda-tags-todo-honor-ignore-options
   iswitchb-temp-buflist calc-embedded-open-mode
calc-embedded-open-formula calc-embedded-close-formula
align-mode-rules-list org-export-registered-backends t)
  nil (add-hook (quote change-major-mode-hook) (quote
org-show-block-all) (quote append) (quote local)))
 (closure (*this* org-babel-confirm-evaluate-answer-no t)
nil
  (add-hook (quote change-major-mode-hook) (quote
org-babel-show-result-all) (quote append) (quote local)))
 #[nil "\300\301!\207" [org-bullets-mode 1] 2] #[nil
"\300\301\302\303\304$\207" [add-hook after-save-hook org-babel-tangle nil
local-please] 5] org-clock-load
 (closure
  (org-inlinetask-min-level org-mode-map org-tbl-menu
org-org-menu org-struct-menu org-entities org-last-state
org-id-track-globally org-clock-start-time
   texmathp-why remember-data-file
org-agenda-tags-todo-honor-ignore-options iswitchb-temp-buflist
calc-embedded-open-mode calc-embedded-open-formula
   calc-embedded-close-formula align-mode-rules-list
org-emphasis-alist org-emphasis-regexp-components
org-export-registered-backends org-modules
   org-babel-load-languages org-element-paragraph-separate
ffap-url-regexp t)
  nil (add-hook (quote change-major-mode-hook) (quote
org-show-block-all) (quote append) (quote local)))
 (closure
  (org-bracket-link-regexp org-src-window-setup *this*
org-babel-confirm-evaluate-answer-no org-src-preserve-indentation

[O] bug#24791: bug#24791: org-todo-yesterday behaves like plain org-todo (incorrect timestamp)

[Jan Böhm]

Hi,

interestingly, it hasn't happend to me for a long time now – I assumed
that it had already been fixed. I tried again just now and I can no
longer reproduce it with Org 9.0.9. / Emacs 27.0.50.

Cheers,
Jan


Am 04.12.2017 um 20:59 schrieb Nicolas Goaziou:
> Hello,
> 
> Allen Li  writes:
> 
>> On Fri, Dec 1, 2017 at 1:53 PM, Nicolas Goaziou  
>> wrote:
>>> Hello,
>>>
>>> Jan Böhm  writes:
>>>
 Symptoms: both org-todo-yesterday and org-agenda-todo-yesterday behave
 just like normally setting todo state to "DONE" with org-todo.
 Specifically, the timestamp
 added in the log takes the current time instead of 23:59 of the previous
 day, as would be expected.

 Replicate behaviour:
 start emacs -Q
 set org-log-done to "time"
 visit new file and switch to org mode
 create TODO headline and set TODO state to "DONE" by calling
 "org-todo-yesterday"
 ⇒ todo state is set to DONE correctly, but the timestamp inserted in
 the log drawer is the current time.
>>>
>>> I cannot reproduce it in a recent Org release. Could you double-check
>>> with a newer Org?
>>
>> I am going to blindly wager that this is yet another bug caused by Org
>> mode's subtle timezone issues.
>>
>> I can reproduce it (and crucially, I am not in the GMT time zone),
>> although the repro recipe produces a CLOSED timestamp and not a log
>> drawer timestamp.
> 
> I removed timezone references from maint. Can you still reproduce the
> issue?
> 
> Regards,
> 

[O] bug#28072: Org Mode Drawer Folds Unexpectedly

[Mitch Norcross]

Hello Nicolas,
Thanks you so much for trying to reproduce my observation.
I see the discrepancy that you have uncovered...
It seems that to reproduce the problem, the drawer must be
inside the body of a headlined section.

So, simply adding a headline above the drawer should allow
you to reproduce the problem.  For example:

* Testing drawer that closes unexpectedly

:mydrawer:
  - Plain list item with children
  + some notes here
  + and here
  + some more here
:end:

Looking forward to hearing again from you.

Kind Regards,
/Mitch




On Mon, Dec 4, 2017 at 3:32 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Mitch Norcross  writes:
>
> > * ISSUE: Org Mode Drawer Folds Unexpectedly
> >
> > ** Issue Description
> >
> >   - Org Mode Drawers fold (unexpected) when user attempts to unfold a
> plain
> > list item within the drawer after having folded it.
> >
> > ** Steps To Reproduce the Bug
> >
> >   - Steps
> >   1) Create a plain list with some hierarchy in it
> >   2) Put the list in a drawer
> >   3) Unfold the drawer
> >   4) Fold a list item that has children
> >   5) Try to unfold the list item that that you folded
> >   - Notice that the drawer then folds, unexpectedly
> >
> > :mydrawer:
> >   - Plain list item with children
> >   + some notes here
> >   + and here
> >   + some more here
> > :end:
>
> I cannot reproduce it.
>
> More explicitly, I copied the drawer above in a new file. I folded the
> top item, then immediately unfolded it. The drawer didn't move.
>
> Am I missing something?
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738
>

[O] bug#29722: issues with some function declarations

[Nicolas Goaziou]

Glenn Morris  writes:

> Thanks. I think that will have introduced a compilation warning:
>
>  In end of data:
>  org-duration.el:448:1:Warning: the function 'org-trim' is not known to
>  be defined.

Indeed! Also fixed. Thank you.

Regards,

[O] bug#29722: issues with some function declarations

[Glenn Morris]

Thanks. I think that will have introduced a compilation warning:

 In end of data:
 org-duration.el:448:1:Warning: the function 'org-trim' is not known to
 be defined.

[O] bug#29722: issues with some function declarations

[Nicolas Goaziou]

Hello,

Glenn Morris  writes:

> Package: org-mode
> Severity: minor
>
> "make check-declare" reports the following issues:
>
> org/org-compat.el:40:Warning (check-declare): said 'org-table-end' was defined
> in unknown file: Malformed declaration
> org/org-footnote.el:48:Warning (check-declare): said 'org-fill-paragraph' was
> defined in org/org.el: arglist mismatch
> org/org-compat.el:35:Warning (check-declare): said 'org-at-table.el-p' was
> defined in org/org.el: arglist mismatch
> org/ob-core.el:77:Warning (check-declare): said 'org-number-sequence' was
> defined in org/org-compat.el: obsolete alias
> org/ob-core.el:85:Warning (check-declare): said 'org-src-coderef-format' was
> defined in org/org-src.el: arglist mismatch
> org/org-duration.el:54:Warning (check-declare): said 'org-trim' was defined in
> org/org-trim.el: file not found

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] bug#29722: issues with some function declarations

[Glenn Morris]

Package: org-mode
Severity: minor

"make check-declare" reports the following issues:

org/org-compat.el:40:Warning (check-declare): said 'org-table-end' was defined
in unknown file: Malformed declaration
org/org-footnote.el:48:Warning (check-declare): said 'org-fill-paragraph' was
defined in org/org.el: arglist mismatch
org/org-compat.el:35:Warning (check-declare): said 'org-at-table.el-p' was
defined in org/org.el: arglist mismatch
org/ob-core.el:77:Warning (check-declare): said 'org-number-sequence' was
defined in org/org-compat.el: obsolete alias
org/ob-core.el:85:Warning (check-declare): said 'org-src-coderef-format' was
defined in org/org-src.el: arglist mismatch
org/org-duration.el:54:Warning (check-declare): said 'org-trim' was defined in
org/org-trim.el: file not found

[O] bug#29694: Quoting of consts in org-agenda-custom-commands-local-options

[Nicolas Goaziou]

Hello,

Glenn Morris  writes:

> Package: org-mode
>
> In code like
>
> (defcustom ...
>   :type '(const some-constant))
>
> it's a mistake to write 'some-constant.
>
> So I'm guessing that various instances of quoted consts in
> org-agenda-custom-commands-local-options are a mistake. Eg
>
> (const :tag "scheduled" 'scheduled)

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] bug#29698: missing/empty custom groups

[Nicolas Goaziou]

Hello,

Glenn Morris  writes:

> Package: org-mode
> Severity: minor
>
> ox-publish.el defines an "org-publish" group, but nothing uses it.
>
> org-pcomplete.el defines an "org-complete" group, but nothing uses it.
>
> org-structure-template-alist uses an "org-completion" group, but
> nothing defines it.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] bug#29695: Mistakes in custom :types

[Nicolas Goaziou]

Hello,

Glenn Morris  writes:

> Package: org-mode
>
> The following user options have :types that do not match their defaults:
>
> org-babel-stan-cmdstan-directory
> org-latex-default-packages-alist
> org-odt-with-latex
>
> As a result, customizing them displays "mismatch".

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] bug#29698: missing/empty custom groups

[Glenn Morris]

Package: org-mode
Severity: minor

ox-publish.el defines an "org-publish" group, but nothing uses it.

org-pcomplete.el defines an "org-complete" group, but nothing uses it.

org-structure-template-alist uses an "org-completion" group, but
nothing defines it.

[O] bug#29695: Mistakes in custom :types

[Glenn Morris]

Package: org-mode

The following user options have :types that do not match their defaults:

org-babel-stan-cmdstan-directory
org-latex-default-packages-alist
org-odt-with-latex

As a result, customizing them displays "mismatch".

[O] bug#29694: Quoting of consts in org-agenda-custom-commands-local-options

[Glenn Morris]

Package: org-mode

In code like

(defcustom ...
  :type '(const some-constant))

it's a mistake to write 'some-constant.

So I'm guessing that various instances of quoted consts in
org-agenda-custom-commands-local-options are a mistake. Eg

(const :tag "scheduled" 'scheduled)

etc

Re: [O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

[Nicolas Goaziou]

Allen Li  writes:

> Archiving DOES move point, it's just a question of where it moves
> point to.  It should not be moving point to the archived heading.
> Examples (^ is point):
>
>   * Foo
>   ** A
>   ** ^B
>   ** C
>   ** Archive :ARCHIVE:...
>
> Archiving to a separate file yields:
>
>   * Foo
>   ** A
>   ^** C
>   ** Archive :ARCHIVE:...
>
> Archiving to a subtree yields:
>
>   * Foo
>   ** A
>   ^** C
>   ** Archive :ARCHIVE:...
>
> BUT if the Archive heading isn’t last:
>
>   * Foo
>   ** Archive :ARCHIVE:...
>   ** A
>   ** ^B
>   ** C
>
> Archiving to a separate file yields:
>
>   * Foo
>   ** Archive :ARCHIVE:...
>   ** A
>   ^** C
>
> Archiving to a subtree yields:
>
>   * Foo
>   ** Archive :ARCHIVE:
>   *** B^...
>   ** A
>   ** C

I see. Fixed. Thank you.

Regards,

Re: [O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

[Allen Li]

On Mon, Dec 11, 2017 at 6:10 AM, Nicolas Goaziou  wrote:
> Hello,
>
> Allen Li  writes:
>
>> On Wed, Dec 6, 2017 at 12:19 PM, Allen Li  wrote:
>>> (Can reproduce with Org 9.1.3, submitting with emacs -Q)
>>>
>>> Using a file tmp.org:
>>>
>>>   * Foo
>>>   ** Archive :ARCHIVE:
>>>   *** Test
>>>   :PROPERTIES:
>>>   :ARCHIVE_TIME: 2017-12-06 Wed 12:13
>>>   :END:
>>>   ** Bar
>>>
>>> This appears like so with default visibility:
>>>
>>>   * Foo
>>>   ** Archive :ARCHIVE:...
>>>   ** Bar
>>>
>>> Archiving Bar with C-c C-x A yields:
>>>
>>>   * Foo
>>>   ** Archive :ARCHIVE:...
>>>   *** Bar...
>>>
>>> Expected visibility:
>>>
>>>   * Foo
>>>   ** Archive :ARCHIVE:...
>
> AFAICT, the action leaves point on the just archived sub-heading. As
> a consequence, it has to visible.
>
> Your expected visibility means the function should move point. Why would
> that be better than letting it on the headline you just operated on?

Archiving DOES move point, it's just a question of where it moves
point to.  It should not be moving point to the archived heading.
Examples (^ is point):

  * Foo
  ** A
  ** ^B
  ** C
  ** Archive :ARCHIVE:...

Archiving to a separate file yields:

  * Foo
  ** A
  ^** C
  ** Archive :ARCHIVE:...

Archiving to a subtree yields:

  * Foo
  ** A
  ^** C
  ** Archive :ARCHIVE:...

BUT if the Archive heading isn’t last:

  * Foo
  ** Archive :ARCHIVE:...
  ** A
  ** ^B
  ** C

Archiving to a separate file yields:

  * Foo
  ** Archive :ARCHIVE:...
  ** A
  ^** C

Archiving to a subtree yields:

  * Foo
  ** Archive :ARCHIVE:
  *** B^...
  ** A
  ** C

The implementation is painfully inconsistent.

Re: [O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

[Nicolas Goaziou]

Hello,

Allen Li  writes:

> On Wed, Dec 6, 2017 at 12:19 PM, Allen Li  wrote:
>> (Can reproduce with Org 9.1.3, submitting with emacs -Q)
>>
>> Using a file tmp.org:
>>
>>   * Foo
>>   ** Archive :ARCHIVE:
>>   *** Test
>>   :PROPERTIES:
>>   :ARCHIVE_TIME: 2017-12-06 Wed 12:13
>>   :END:
>>   ** Bar
>>
>> This appears like so with default visibility:
>>
>>   * Foo
>>   ** Archive :ARCHIVE:...
>>   ** Bar
>>
>> Archiving Bar with C-c C-x A yields:
>>
>>   * Foo
>>   ** Archive :ARCHIVE:...
>>   *** Bar...
>>
>> Expected visibility:
>>
>>   * Foo
>>   ** Archive :ARCHIVE:...

AFAICT, the action leaves point on the just archived sub-heading. As
a consequence, it has to visible.

Your expected visibility means the function should move point. Why would
that be better than letting it on the headline you just operated on?

>> AFAIK, there is no special location in the file for archived subtrees,
>> i.e., there is nothing wrong with
>>
>>   * Some projects
>>   ** Some item...
>>   ** Archive :ARCHIVE:...
>>   ** New entry...
>
> This bug means that the Archive headline's position is significant.

I fail to see how you draw such a conclusion.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Inline src block results no longer exported

[Nicolas Goaziou]

Hello,

"Berry, Charles"  writes:

> This commit
>
> ---
>   commit 5f5d82ed516b7b385a9258271becbfa247e94af3
>   Author: Nicolas Goaziou 
>   Date:   Tue Nov 21 22:25:17 2017 +0100
>
>   Remove second pass for macro expansion
> ---
>
> breaks the processing of inline src block results wrapped as {{{results(=my 
> result=)}}}.
>
> ECM:
>
> Copy the follow org block to a buffer and run `C-c C-e l L y y'
>
> #+begin_src org
>   See nothing: src_emacs-lisp{"Hello World"}
>
>   See something: src_emacs-lisp[:results raw]{ "Raw Results" }
> #+end_src
>
>
> The result will be
>
> #+begin_example 
> See nothing: 
>
> See something: Raw Results
> #+end_example
>
> missing the Hello World.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] bug report: + is not escaped in org-link-escape

[D M German]

Nicolas Goaziou twisted the bytes to say:

 Nicolas> Hello,
 Nicolas> dmg  writes:

 >> org-link-escape only replaces space, [, ], and %
 >> 
 >> but search in google/gmail is replacing + also.
 >> 
 >> The simplest solution is to add 43 to org-link-escape-chars:
 >> 
 >> org-link-escape-chars is a variable defined in ‘org.el’.
 >> Its value is (32 91 93 37)
 >> 
 >> This variable may be risky if used as a file-local variable.

 Nicolas> `org-link-escape' is for internal links, not for general URL-encoding.
 Nicolas> You may want to use `url-encode-url' instead.

this indeed addresses the issue I was having.

thank you very much for your response.


--daniel



--
Daniel M. German  "It is useless to punish a man
   unless he knows why he is punished...
   Punishment must be unusual
   R. Heinlein ->  or it serves no purpose."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

[O] Bug: Inline src block results no longer exported

[Berry, Charles]

This commit

---
  commit 5f5d82ed516b7b385a9258271becbfa247e94af3
  Author: Nicolas Goaziou 
  Date:   Tue Nov 21 22:25:17 2017 +0100

  Remove second pass for macro expansion
---

breaks the processing of inline src block results wrapped as {{{results(=my 
result=)}}}.

ECM:

Copy the follow org block to a buffer and run `C-c C-e l L y y'

#+begin_src org
  See nothing: src_emacs-lisp{"Hello World"}

  See something: src_emacs-lisp[:results raw]{ "Raw Results" }
#+end_src

The result will be 

#+begin_example 
See nothing: 

See something: Raw Results
#+end_example

missing the Hello World.

Chuck

Re: [O] BUG: TODO statistics in parent heading prevent evaluation of TODOs with TRIGGER property

[Adrian Bradd]

I should probably add that this will require org-depend.el to be loaded.

On 10 December 2017 at 17:50, Adrian Bradd  wrote:

> Hello,
>
> ECM:
>
> * Top-Heading with process indicator [/]
>
> ** TODO Here I invoke org-todo to DONE
> :PROPERTIES:
> :TRIGGER:  2021-12-03-target(TODO)
> :END:
>
> ** This should be changed to TODO
> :PROPERTIES:
> :ID: 2021-12-03-target
> :END:
>
> If you run org-todo on the "Here I invoke org-todo to DONE" headline the
> headline will change to DONE, but the trigger will not update the "This
> should be changed to TODO" headline. There is further discussion in another
> thread where the user reported the issue [1].
>
> The issue is Line 12534 in org.el:
>
> (when org-provide-todo-statistics
>   (org-update-parent-todo-statistics))
>
> which traverses the tree and updates the todo progress statistics. If the
> statistic is [/], as in the ECM above, or [%] it will add 1 or more
> characters which is enough to push the :position property up to the line
> above. I wasn't sure how to deal with this as it seems
> `org-update-parent-todo-statistics' could update more than one parent
> heading and the number of additional characters isn't clear without some
> feedback from `org-update-parent-todo-statistics'.
>
> Cheers,
>
> Adrian
>
> [1] https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00058.html
>
> On 10 December 2017 at 16:53, Nicolas Goaziou 
> wrote:
>
>> Hello,
>>
>> Adrian Bradd  writes:
>>
>> > Please see the patch attached.
>> >
>> > When completing a TODO with a TRIGGER property that has statistics in
>> the
>> > parent headline the trigger would not evaluate because the :position
>> > property in `change-plist' may now refer to the line above the original
>> > TODO.
>> >
>> > I have used a marker to avoid the issue with the point moving due to the
>> > addition of characters
>> > ​ in the parent headline​
>> > . Not sure if this is the best way to solve the problem.
>>
>> IIUC, point is moved between `startpos' and `change-plist' bindings? Do
>> you know when that happens? Would you have an ECM for the issue?
>>
>> Thank you.
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
>

Re: [O] BUG: TODO statistics in parent heading prevent evaluation of TODOs with TRIGGER property

[Adrian Bradd]

Hello,

ECM:

* Top-Heading with process indicator [/]

** TODO Here I invoke org-todo to DONE
:PROPERTIES:
:TRIGGER:  2021-12-03-target(TODO)
:END:

** This should be changed to TODO
:PROPERTIES:
:ID: 2021-12-03-target
:END:

If you run org-todo on the "Here I invoke org-todo to DONE" headline the
headline will change to DONE, but the trigger will not update the "This
should be changed to TODO" headline. There is further discussion in another
thread where the user reported the issue [1].

The issue is Line 12534 in org.el:

(when org-provide-todo-statistics
  (org-update-parent-todo-statistics))

which traverses the tree and updates the todo progress statistics. If the
statistic is [/], as in the ECM above, or [%] it will add 1 or more
characters which is enough to push the :position property up to the line
above. I wasn't sure how to deal with this as it seems
`org-update-parent-todo-statistics' could update more than one parent
heading and the number of additional characters isn't clear without some
feedback from `org-update-parent-todo-statistics'.

Cheers,

Adrian

[1] https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00058.html

On 10 December 2017 at 16:53, Nicolas Goaziou 
wrote:

> Hello,
>
> Adrian Bradd  writes:
>
> > Please see the patch attached.
> >
> > When completing a TODO with a TRIGGER property that has statistics in the
> > parent headline the trigger would not evaluate because the :position
> > property in `change-plist' may now refer to the line above the original
> > TODO.
> >
> > I have used a marker to avoid the issue with the point moving due to the
> > addition of characters
> > ​ in the parent headline​
> > . Not sure if this is the best way to solve the problem.
>
> IIUC, point is moved between `startpos' and `change-plist' bindings? Do
> you know when that happens? Would you have an ECM for the issue?
>
> Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] bug report: + is not escaped in org-link-escape

[Nicolas Goaziou]

Hello,

dmg  writes:

> org-link-escape only replaces space, [, ], and %
>
> but search in google/gmail is replacing + also.
>
> The simplest solution is to add 43 to org-link-escape-chars:
>
>org-link-escape-chars is a variable defined in ‘org.el’.
>Its value is (32 91 93 37)
>
>   This variable may be risky if used as a file-local variable.

`org-link-escape' is for internal links, not for general URL-encoding.
You may want to use `url-encode-url' instead.

> I use org-link-escape to jump from an email in gnus to gmail by searching
> the message-id. But if when the message-id contains +, this character
> must be escaped.

See above.

Regards,

-- 
Nicolas Goaziou

Re: [O] BUG: TODO statistics in parent heading prevent evaluation of TODOs with TRIGGER property

[Nicolas Goaziou]

Hello,

Adrian Bradd  writes:

> Please see the patch attached.
>
> When completing a TODO with a TRIGGER property that has statistics in the
> parent headline the trigger would not evaluate because the :position
> property in `change-plist' may now refer to the line above the original
> TODO.
>
> I have used a marker to avoid the issue with the point moving due to the
> addition of characters
> ​ in the parent headline​
> . Not sure if this is the best way to solve the problem.

IIUC, point is moved between `startpos' and `change-plist' bindings? Do
you know when that happens? Would you have an ECM for the issue?

Thank you.

Regards,

-- 
Nicolas Goaziou

[O] BUG: TODO statistics in parent heading prevent evaluation of TODOs with TRIGGER property

[Adrian Bradd]

Hi,

Please see the patch attached.

When completing a TODO with a TRIGGER property that has statistics in the
parent headline the trigger would not evaluate because the :position
property in `change-plist' may now refer to the line above the original
TODO.

I have used a marker to avoid the issue with the point moving due to the
addition of characters
​ in the parent headline​
. Not sure if this is the best way to solve the problem.

Cheers,

Adrian


0001-lisp-org.el-Use-marker-for-change-plist-position-pro.patch
Description: Binary data

Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

[Nathan Aclander]

Nicolas Goaziou  writes:
> This is confusing because it is ambiguous. The same point could
> correspond to a table, multiple lists, and multiple headings, all
> reclaiming S-M-left binding.

I think I agree with your point that having the S-M-left bindings
overloaded by other modes reclaiming S-M-left will get confusing.

However, I don't use the S-M-left binding, but rather call
org-shiftmetaleft or org-shiftmetaright, I've never used other minor
modes in sublist so I'm not sure if there are any that also re-purpose
the org-shiftmetaleft/right commands.

Now I'm curious, do you have an example list where this would be
obviously confusing and ambiguous?

> You can also define a function that does this and add it to
> `org-shiftmetaleft-hook' or `org-shiftmetaright-hook'.

Yup, I wrote a function that ends up doing this for me.

Nathan


signature.asc
Description: PGP signature

Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

[Nicolas Goaziou]

Hello,

Nathan Aclander  writes:

> Using ^ as point like you did, what I am expecting to happen is:
>
> Case 1:
>  
> * Heading
>
> - foo
>   - ^bar
> second bar line
>
> M-S-left/right moves
>
> - bar
>   second bar line 
>
> left and right.
>
> Case 2:
>
> - foo
>   - bar
> ^second bar line
>
> M-S-left/right moves
>
> - bar
>   second bar line 
>
> left and right.
>
> Case 3:
>   ...
>   some very long text
>   ^some very long text
>   some very long text
>   ...
>
> Whatever sub list that "some very long text" is part of should be moved
> left and right.
>
> None of these scenarios seem very confusing, and ( at least to me ) seem
> more consistent than the current behavior. Could you explain why you
> find adding this behavior would make this confusing?

This is confusing because it is ambiguous. The same point could
correspond to a table, multiple lists, and multiple headings, all
reclaiming S-M-left binding.

Of course, we could apply the change to the closest, i.e., the inner,
structure, but, in some cases, e.g. the third one, the context is not
obvious. You may end up ignoring if the whole section was shifted, or
just some random sub-list. 

I don't find this behaviour particularly satisfactory. OTOH, only
reacting when point is on item bullet's line is totally unambiguous.

> As a current workaround, what I have to do is:
>
> 1. save point
> 2. Go to the parent sub-list
> 3. Shift left or right
> 4. move point back to its previous location. 

You can also define a function that does this and add it to
`org-shiftmetaleft-hook' or `org-shiftmetaright-hook'.

I suggest to do that if you think that's better.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

[Nathan Aclander]

Allen Li  writes:
> I think what Nicolas is saying is this (^ is point):
>
> * ^Heading
>
> M-S-left/right works here.
>
> * Heading
> ^content text
>
> M-S-left/right does not work here.  Let’s assume that it does work
> here to be consistent with the feature/bug you are requesting.
>
> * Heading
>
> - foo
>   - bar
> ^second bar line
>
> M-S-left/right does not work here.  Let’s assume that it does work
> here per the feature/bug you are requesting.  Does it move bar, foo,
> or Heading?  What if the text is very long and you cannot see where
> you are?
>
>   ...
>   some very long text
>   ^some very long text
>   some very long text
>   ...
>
> What M-S-left/right does would be very confusing.

Using ^ as point like you did, what I am expecting to happen is:

Case 1:
 
* Heading

- foo
  - ^bar
second bar line

M-S-left/right moves

- bar
  second bar line 

left and right.

Case 2:

- foo
  - bar
^second bar line

M-S-left/right moves

- bar
  second bar line 

left and right.

Case 3:
  ...
  some very long text
  ^some very long text
  some very long text
  ...

Whatever sub list that "some very long text" is part of should be moved
left and right.

None of these scenarios seem very confusing, and ( at least to me ) seem
more consistent than the current behavior. Could you explain why you
find adding this behavior would make this confusing?

As a current workaround, what I have to do is:

1. save point
2. Go to the parent sub-list
3. Shift left or right
4. move point back to its previous location. 

Nathan


signature.asc
Description: PGP signature

Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

[Allen Li]

On Sat, Dec 9, 2017 at 4:41 PM, Nathan Aclander
 wrote:
>
> Nicolas Goaziou  writes:
>
>> I don't qualify this as a bug. These commands explicitly work when point
>> is at the beginning of an item. Indeed, the sub-item may be arbitrarily
>> large, contain tables... it would be confusing to move the whole
>> sub-list when its structure is out of sight.
>
> Why do you think it would be confusing to move the whole sub-list? Why
> would it be move confusing when the point is on the sub-item vs. when
> the point is on the parent item?
>
> I think the inconsistency is unintuitive here, and causes confusion. And
> I think since large sub-items already get moved when the point is
> at the beginning, it would make sense to also move them when the point
> is on the sub item.
>
> Nathan

I think what Nicolas is saying is this (^ is point):

* ^Heading

M-S-left/right works here.

* Heading
^content text

M-S-left/right does not work here.  Let’s assume that it does work
here to be consistent with the feature/bug you are requesting.

* Heading

- foo
  - bar
^second bar line

M-S-left/right does not work here.  Let’s assume that it does work
here per the feature/bug you are requesting.  Does it move bar, foo,
or Heading?  What if the text is very long and you cannot see where
you are?

  ...
  some very long text
  ^some very long text
  some very long text
  ...

What M-S-left/right does would be very confusing.

Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

[Nathan Aclander]

Nicolas Goaziou  writes:

> I don't qualify this as a bug. These commands explicitly work when point
> is at the beginning of an item. Indeed, the sub-item may be arbitrarily
> large, contain tables... it would be confusing to move the whole
> sub-list when its structure is out of sight.

Why do you think it would be confusing to move the whole sub-list? Why
would it be move confusing when the point is on the sub-item vs. when
the point is on the parent item?

I think the inconsistency is unintuitive here, and causes confusion. And
I think since large sub-items already get moved when the point is
at the beginning, it would make sense to also move them when the point
is on the sub item.

Nathan


signature.asc
Description: PGP signature

[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

[Nicolas Goaziou]

Hello,

Eli Zaretskii  writes:

> Can one of you please provide a short Lisp snippet that generates a
> 2x2 Org table and inserts it in a buffer, which I could use as the
> basis for the test?  That would get me off the ground quicker, since
> I'm a very infrequent user of Org tables.

For tests, we use `org-test-with-temp-text' macro, e.g.,

  (org-test-with-temp-text "| a | b |\n| c | d |"
... do something in that buffer ...)

> I will experiment with both and see which one is better.

OK. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

[Eli Zaretskii]

> From: Nicolas Goaziou 
> Cc: dov.grobg...@gmail.com,  11...@debbugs.gnu.org
> Date: Mon, 04 Dec 2017 22:02:00 +0100
> 
> Eli Zaretskii  writes:
> 
> > Such tests can only be run interactively, because bidi reordering is a
> > display-time feature in Emacs.  Is that OK with you?
> 
> That's better than no test at all in my book, so I'm fine with it, yes.

OK.

Can one of you please provide a short Lisp snippet that generates a
2x2 Org table and inserts it in a buffer, which I could use as the
basis for the test?  That would get me off the ground quicker, since
I'm a very infrequent user of Org tables.

> I can use isolation characters instead (if anyone cares to point me to
> what those are), if you think that's better.

I will experiment with both and see which one is better.

[O] bug#24791: bug#24791: org-todo-yesterday behaves like plain org-todo (incorrect timestamp)

[Allen Li]

On Mon, Dec 4, 2017 at 11:59 AM, Nicolas Goaziou  wrote:
> Hello,
>
> Allen Li  writes:
>
>> On Fri, Dec 1, 2017 at 1:53 PM, Nicolas Goaziou  
>> wrote:
>>> Hello,
>>>
>>> Jan Böhm  writes:
>>>
 Symptoms: both org-todo-yesterday and org-agenda-todo-yesterday behave
 just like normally setting todo state to "DONE" with org-todo.
 Specifically, the timestamp
 added in the log takes the current time instead of 23:59 of the previous
 day, as would be expected.

 Replicate behaviour:
 start emacs -Q
 set org-log-done to "time"
 visit new file and switch to org mode
 create TODO headline and set TODO state to "DONE" by calling
 "org-todo-yesterday"
 ⇒ todo state is set to DONE correctly, but the timestamp inserted in
 the log drawer is the current time.
>>>
>>> I cannot reproduce it in a recent Org release. Could you double-check
>>> with a newer Org?
>>
>> I am going to blindly wager that this is yet another bug caused by Org
>> mode's subtle timezone issues.
>>
>> I can reproduce it (and crucially, I am not in the GMT time zone),
>> although the repro recipe produces a CLOSED timestamp and not a log
>> drawer timestamp.
>
> I removed timezone references from maint. Can you still reproduce the
> issue?

I can confirm that it's fixed on 9.1.4 (org-plus-contrib-20171205)

Re: [O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

[Allen Li]

On Wed, Dec 6, 2017 at 12:19 PM, Allen Li  wrote:
> (Can reproduce with Org 9.1.3, submitting with emacs -Q)
>
> Using a file tmp.org:
>
>   * Foo
>   ** Archive :ARCHIVE:
>   *** Test
>   :PROPERTIES:
>   :ARCHIVE_TIME: 2017-12-06 Wed 12:13
>   :END:
>   ** Bar
>
> This appears like so with default visibility:
>
>   * Foo
>   ** Archive :ARCHIVE:...
>   ** Bar
>
> Archiving Bar with C-c C-x A yields:
>
>   * Foo
>   ** Archive :ARCHIVE:...
>   *** Bar...
>
> Expected visibility:
>
>   * Foo
>   ** Archive :ARCHIVE:...

Actually, this issue is a bit more severe.  point does not get left on
the next headline, which breaks my workflow of recording a macro for
C-c C-x A and tapping F4 many times.

According to 
http://lists.gnu.org/archive/html/emacs-orgmode/2017-10/msg00286.html

> AFAIK, there is no special location in the file for archived subtrees,
> i.e., there is nothing wrong with
>
>   * Some projects
>   ** Some item...
>   ** Archive :ARCHIVE:...
>   ** New entry...

This bug means that the Archive headline's position is significant.

[O] bug report: + is not escaped in org-link-escape

[dmg]

hi everybody,

I am running 9.0.10.

org-link-escape only replaces space, [, ], and %

but search in google/gmail is replacing + also.

The simplest solution is to add 43 to org-link-escape-chars:

   org-link-escape-chars is a variable defined in ‘org.el’.
   Its value is (32 91 93 37)

  This variable may be risky if used as a file-local variable.


I use org-link-escape to jump from an email in gnus to gmail by searching
the message-id. But if when the message-id contains +, this character
must be escaped.

thank you,

-- 
--dmg

---
Daniel M. German
http://turingmachine.org

Re: [O] Bug: org-files-list duplicate files [9.1.3 (9.1.3-29-g037db0-elpa @ ~/.emacs.d/elpa/org-20171204/)]

[Nicolas Goaziou]

Hello,

Renato Ferreira  writes:

> Investigating an issue I was having with (org-resolve-clocks) that i would
> need to resolve the same clock twice, i believe i stumbled upon the
> following bug on (org-files-list) (used by (org-resolve-clocks)):
>
> It gets a list from (org-agenda-files) and pushes the open org
> buffers found through (buffer-list), but i believe it _incorrectly_ uses
> (cl-pushnew) since it ultimately uses memql (which compares with eql) to
> check existence of the buffer file name (a string) with the
> (org-agenda-files) list (of strings), returning duplicate items on lists
> since compared strings are not the same lisp objects.
>
> Advising (org-files-list) with (delete-dups) is a workaround i'm using but
> (org-files-list) needs to be changed to use member instead of memql.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] bug#28263: bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys

[Allen Li]

On Wed, Dec 6, 2017 at 7:23 AM, Drew Adams  wrote:
> [paraphrased] Org should not suggest user reserved key bindings

I agree with you in general.  However, when I first started using
Emacs for Org mode years ago, I found the documentation very helpful.
Furthermore, I did not find the documentation misleading about the
fact that these keys are not standard.

For users that are not accustomed to Emacs, the ability to bind keys
freely is paralyzing.  I had no idea what keys would be okay or not
okay to bind.

This could be solved by instead linking to the Emacs key binding
guidelines and pointing out ranges of keys or example keys that would
be safe to bind. I interpret the current documentation as suggesting
such example keys.

For comparison, calendar.el et al do not suggest global key bindings
for their commands.  However, Org mode is different because it is one
of Emacs’s "killer apps".  It is something that a non-Emacs user would
start using Emacs for.  No one is going to switch to Emacs to use
calendar.el, but there are many people that switch to Emacs to use Org
mode.  Therefore, there is a benefit in adding some tips for very new
users.

As a matter of practicality, I suspect many users are just blindly
copying Emacs Lisp code from various guides online, so there is no
good way to fight de facto standards from emerging.  Projectile is a
particularly blatant offender, a popular package that reserves the C-c
p key for its minor mode.

However, the Emacs documentation is quite clear about key binding
rules.  All built in libraries follow it, including Org mode.  I do
not interpret the Org documentation as implying otherwise.

[O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

[Allen Li]

(Can reproduce with Org 9.1.3, submitting with emacs -Q)

Using a file tmp.org:

  * Foo
  ** Archive :ARCHIVE:
  *** Test
  :PROPERTIES:
  :ARCHIVE_TIME: 2017-12-06 Wed 12:13
  :END:
  ** Bar

This appears like so with default visibility:

  * Foo
  ** Archive :ARCHIVE:...
  ** Bar

Archiving Bar with C-c C-x A yields:

  * Foo
  ** Archive :ARCHIVE:...
  *** Bar...

Expected visibility:

  * Foo
  ** Archive :ARCHIVE:...

Emacs  : GNU Emacs 25.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version
3.22.11), modified by Debian
Package: Org-mode version 8.2.10 (release_8.2.10 @
/usr/share/emacs/25.2+gg1+12/lisp/org/)

[O] bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys

[Drew Adams]

> Could you summarize how you think the situation could be improved in
> one or two sentences?
> 
> I think what you are trying to say is, Org mode should make global
> key bindings for some commands.

No.  I'm saying that Org should not suggest that users bind
keys that are reserved for use by users to Org commands.

And it should not then present those keys in the doc.

And it should not say anything about the doc using those
keys for illustrative purposes or assuming that users
have bound those keys.

Org should do _nothing_ with such reserved keys.  It
should not mention them at all in its doc.

If Org wants to recommend or suggest that users bind some
particular commands to keys, including to prefix keys, it
can do that.  But don't mention any particular keys
(preferably), and certainly do not suggest using any
particular keys.

*IF* Org feels that certain commands should definitely be
bound globally *THEN* (1) it should present that as a
concrete proposal to emacs-devel for consideration and
(2) if agreed on, Org should just bind those keys globally.

That's Org's decision.  I'm not in any way suggesting
that Org should bind global keys.  In fact, I hope it
does not do so.  But I can't decide what's best for
everyone here.  Maybe some global keys should be
sacrificed for Org.  I doubt it, but maybe Emacs Dev
would decide that that's appropriate.

What Org does now is, IMO, a shame-faced way of getting
a bunch of keys bound globally for its purposes, without
actually binding them.  And what's more, the keys in
question are keys that are always reserved for users.
That's not right.

> However, this is problematic because there are pretty much no global
> keys available that are not reserved for major modes, minor modes, or
> the user,

Tough.  We're all in that boat.  (And anyway, it's not true
in such absolute terms.)  That's the whole point of
reserving keys - to prevent things like Org from gobbling
them all up.

And nothing prevents Org from defining a minor mode that
it intends all Org users to use all the time - in effect
providing a whole new space for its "global" key bindings.

(Not `org-mode', of course, if you want the keys available
even when Org mode is turned off.)

> and at any rate I don’t think we could justify binding
> global keys by default since Org mode is a pretty small application
> within Emacs.  calendar.el does not have a global key.  remember.el
> does not have a global key.  et cetera.  Org mode is no different.

Exactly.  Please follow their example: Don't suggest to
users to bind keys reserved to them to Org commands.

> If we make an Org minor mode, that’s really no better than the user
> just binding his own keys vs turning on the minor mode.

Defining such a minor mode is exactly the way to go, to
get pretty much global behavior without locking in keys
to the absolutely global `global-map'.

Turning on a minor mode that binds keys in its keymap
_is_ a bit like binding your own keys globally.  The
difference is that they are not bound globally.  In
both cases the user makes the choice.  But in one
case the user does not (and ALL users do not) sacrifice
the global keys reserved for users.

Turn the mode on to get its bindings.  Turn it off
to be rid of its bindings.  That's the clean Emacs
way to handle such things. Sneakily recommending to
users that they bind keys reserved for users to Org
commands is not right.  It's not fair to users, most
of all.  And it's not fair to other modes and the
rest of Emacs.  You might say it's "orgocentric".


> Also, the
> reserved minor mode keys are not very good (hard to press), and they
> can conflict with other minor modes, which is probably undesirable for
> Org users.

Tough.  We all live with it.  Emacs is not only for Org.

And in any case, you can put any number of keys on a
prefix key.  And there are plenty of prefix keys that
are not reserved for users.

> Is your complaint simply that we suggest a key for the user to bind?

See above.  If you take the approach of suggesting a key
to bind, it should not be a key that is reserved for users.

This really shouldn't be hard to understand.  Please see
how other packages/modes deal with it.

Yes, key sequences are a limited resource.  For _all_ of us.
For all of Emacs and for all users.  If Org is just starting
to realize this and play fair then it's about time.

[O] bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys

[Allen Li]

On Tue, Dec 5, 2017 at 7:15 AM, Drew Adams  wrote:
>
> That's even worse, IMHO.  And hardly "as neutral as possible".
>
> 
>
> Just one opinion.

Could you summarize how you think the situation could be improved in
one or two sentences?

I think what you are trying to say is, Org mode should make global
key bindings for some commands.

However, this is problematic because there are pretty much no global
keys available that are not reserved for major modes, minor modes, or
the user, and at any rate I don’t think we could justify binding
global keys by default since Org mode is a pretty small application
within Emacs.  calendar.el does not have a global key.  remember.el
does not have a global key.  et cetera.  Org mode is no different.

If we make an Org minor mode, that’s really no better than the user
just binding his own keys vs turning on the minor mode.  Also, the
reserved minor mode keys are not very good (hard to press), and they
can conflict with other minor modes, which is probably undesirable for
Org users.

Is your complaint simply that we suggest a key for the user to bind?

[O] bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys

[Allen Li]

[O] Bug: org-files-list duplicate files [9.1.3 (9.1.3-29-g037db0-elpa @ ~/.emacs.d/elpa/org-20171204/)]

[Renato Ferreira]

Hello,

Investigating an issue I was having with (org-resolve-clocks) that i would
need to resolve the same clock twice, i believe i stumbled upon the
following bug on (org-files-list) (used by (org-resolve-clocks)):

It gets a list from (org-agenda-files) and pushes the open org
buffers found through (buffer-list), but i believe it _incorrectly_ uses
(cl-pushnew) since it ultimately uses memql (which compares with eql) to
check existence of the buffer file name (a string) with the
(org-agenda-files) list (of strings), returning duplicate items on lists
since compared strings are not the same lisp objects.

Advising (org-files-list) with (delete-dups) is a workaround i'm using but
(org-files-list) needs to be changed to use member instead of memql.

Thank you very much.

Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.19)
 of 2017-09-16
Package: Org mode version 9.1.3 (9.1.3-29-g037db0-elpa @ 
~/.emacs.d/elpa/org-20171204/)

-- 
Att.,
Renato Ferreira

[O] bug#28263: 24.5; Org: `C-c LETTER' keys

[Drew Adams]

> >> Org's manual suggests to bind `org-agenda' to `C-c a', 
> >> but doesn't bind it by default.
> >
> > I'm not even sure that's a great idea.  I think not.
> >
> > I suppose it's "legit", as the user, not the Org code,
> > would be making the binding.  But in my libraries I 
> > provide binding suggestions only for keys that are not 
> > reserved for use by users.
> >
> > If a commonly used Emacs library (Org is the best example
> > of that) suggests to users that they bind `C-c a' to 
> > something then that key becomes pretty much, in effect,
> > lost as a key reserved for user customization.
> >
> > IOW, if 90% of Emacs users follow that suggestion then there 
> > is little difference between that situation and the situation 
> > of Org binding `C-c a' by default.
> >
> > My vote would be that Org should not do this.  Just one 
> > opinion.
> 
> I understand your concern. However, Org tries to be as neutral
> as possible with this. Quoting the manual:
> 
>  The manual suggests a few global key bindings, in particular 
>  @kbd{C-c a} for @code{org-agenda} and @kbd{C-c c} for 
>  @code{org-capture}.  These are only suggestions, but the rest 
>  of the manual assumes that these key bindings are in place in 
>  order to list commands by key access.

That's even worse, IMHO.  And hardly "as neutral as possible".

Why should the manual list commands by key access that Org
does _not_ bind to keys?  What's wrong with listing the
commands by name?  That's what Emacs does in its doc.

My suggestion would be to bind keys in Org keymaps only,
and leave it at that.

The manual should definitely not present key bindings that
are  not made by Org, tossing out an introductory comment
that they are shown only to "clarify bindings shown" or to
prevent having to show command names or whatever.

That approach is a bit backhanded, and it really flies
against the spirit of (really!) reserving C-c LETTER keys
for users.

> As explained here, this "suggestion" is only necessary
> to clarify key bindings in the manual.

Clarify key bindings in the manual?  Why are those key
bindings in the manual?  Describe the commands, not
(formally, supposedly) fictitious key bindings for them.

Either it is _important_ for Org to bind those commands
to keys or it's not.  If it is, then Org should find keys
that are not reserved for users.

As I said:

 > > provide binding suggestions only for keys that are
 > > not reserved for use by users

If it is not important for Org itself to bind such keys,
then no such "fictitious" global keys should be presented
in the manual.

> `org-agenda' and `org-capture' bindings are
> really prefixes for many other commands. Having to write, e.g.,
> "the prefix you chose for `org-agenda' then #" instead of
> "C-c a #" would be a lot more verbose, and ultimately, cripple 
> documentation.

My response to that: suck it up, or find a better way
to describe it.

You can perfectly well say "PK #", where PK is a
prefix key bound to `org-agenda'.  Or you can use,
for illustration purposes, a key such as .
(But using  or C-c a is no better than using
PK or whatever - you still need to say something like
"Supposing that  is a prefix key bound to
`org-agenda'...").

And why do you need to refer to a key at all, instead
of referring to the command?  As I say, if it is so
important that the command be bound to a key then
bind it - but to a key that is not reserved for users.

Don't ask users to bind their keys to provide something
that you think Org really needs.  If it needs keys for
this then bind keys for it.  If it does not then
hands-off, and just speak about the commands.  That's
what other Emacs doc does.

This is the wrong thing to do, IMO:

 The four Org commands 'org-store-link', 'org-capture',
 'org-agenda', and 'org-iswitchb' should be accessible 
 through global keys (i.e., anywhere in Emacs, not just
 in Org buffers).  Here are suggested bindings for these 
 keys, please modify the keys to your own liking.

 (global-set-key "\C-cl" 'org-store-link)
 (global-set-key "\C-ca" 'org-agenda)
 (global-set-key "\C-cc" 'org-capture)
 (global-set-key "\C-cb" 'org-iswitchb)

If those commands "should" be on global keys then
_Org should bind them to global keys_.  And those
global keys should _not_ be keys reserved for users.

This looks like a shame-faced way of getting around
the prohibition of libraries binding such keys
globally.  Especially for a library such as Org,
which is very widely used.

My suggestion would be to propose, to emacs-devel,
to bind 4 keys globally for those Org commands -
if you really feel they "should" be bound globally.
IOW, stick up for what you believe.  And if it is
decided to bind those commands you can be sure that
the keys decided on then will not be keys reserved
for users.

> I think the current state is quite fair.

I disagree.  It's a shame.  (FWIW.)  Emacs "should"
do better.

Just one opinion.

[O] bug#27711: bug#27711: 25.2; org-feed gets old news as new from some feeds

[Adonay Felipe Nogueira]

Thank you very much for the fix. ;)

I can't test it right now, but I will do so in the future.

Have a nice day! ;)

2017-12-04T22:22:13+0100 Nicolas Goaziou wrote:
> Hello,
>
>
> Fixed. Thank you.
>
> Regards,

[O] bug#28263: 24.5; Org: `C-c LETTER' keys

[Nicolas Goaziou]

Hello,

Drew Adams  writes:

>> > Dunno whether there are actual bindings in Org that correspond to these
>> > occurrences in the source code of `C-c' followed by a letter.  Might be
>> > worth checking.  (Bindings of `C-c' followed by a letter are reserved
>> > for users.)  Possibly these are just vestigial doc indications, which
>> > could be corrected/updated.
>> 
>> Org's manual suggests to bind `org-agenda' to `C-c a', but doesn't bind
>> it by default.
>
> I'm not even sure that's a great idea.  I think not.
>
> I suppose it's "legit", as the user, not the Org code, would be
> making the binding.  But in my libraries I provide binding
> suggestions only for keys that are not reserved for use by users.
>
> If a commonly used Emacs library (Org is the best example of that)
> suggests to users that they bind `C-c a' to something then that
> key becomes pretty much, in effect, lost as a key reserved for
> user customization.
>
> IOW, if 90% of Emacs users follow that suggestion then there is
> little difference between that situation and the situation of
> Org binding `C-c a' by default.
>
> My vote would be that Org should not do this.  Just one opinion.

I understand your concern. However, Org tries to be as neutral as
possible with this. Quoting the manual:

The manual suggests a few global key bindings, in particular @kbd{C-c a} for
@code{org-agenda} and @kbd{C-c c} for @code{org-capture}.  These are only
suggestions, but the rest of the manual assumes that these key bindings are 
in
place in order to list commands by key access.

As explained here, this "suggestion" is only necessary to clarify key
bindings in the manual. `org-agenda' and `org-capture' bindings are
really prefixes for many other commands. Having to write, e.g., "the
prefix you chose for `org-agenda' then #" instead of "C-c a #" would be
a lot more verbose, and ultimately, cripple documentation.

I think the current state is quite fair.

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#28263: 24.5; Org: `C-c LETTER' keys

[Drew Adams]

> > Dunno whether there are actual bindings in Org that correspond to these
> > occurrences in the source code of `C-c' followed by a letter.  Might be
> > worth checking.  (Bindings of `C-c' followed by a letter are reserved
> > for users.)  Possibly these are just vestigial doc indications, which
> > could be corrected/updated.
> 
> Org's manual suggests to bind `org-agenda' to `C-c a', but doesn't bind
> it by default.

I'm not even sure that's a great idea.  I think not.

I suppose it's "legit", as the user, not the Org code, would be
making the binding.  But in my libraries I provide binding
suggestions only for keys that are not reserved for use by users.

If a commonly used Emacs library (Org is the best example of that)
suggests to users that they bind `C-c a' to something then that
key becomes pretty much, in effect, lost as a key reserved for
user customization.

IOW, if 90% of Emacs users follow that suggestion then there is
little difference between that situation and the situation of
Org binding `C-c a' by default.

My vote would be that Org should not do this.  Just one opinion.

> Fixed (I used \\[org-agenda] instead of C-c a). Thank you.

Thanks for doing that.

[O] bug#7980: Org links does not allow () - at least http links can contain that

[Nicolas Goaziou]

Hello,

Lennart Borgman  writes:

> In `org-make-link-regexps' the characters "()" are excluded in
> `org-plain-link-re'. Is not that wrong at least for http links?

This is not accurate, but usually Org plain links are used when jolting
down notes, as in the following example:

  Visit the Org mode site (http://orgmode.org)

Including "()" in the link could get in the way. IMO, the trade-off is
acceptable. 

Besides, you can use other link types (angle and brackets) for URL with
parenthesis.

WDYT?

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#14910: org-mode `org-open-at-point' doesn't follow id links

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Hi Oleh,
>
> Oleh  writes:
>
>> As the subject says.
>
> This bug is fixed in upstream Org.  You can either install Org
> separately or wait for the next stable version to be merged in
> Emacs.

I'm closing this bug, per the last comment.

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#28263: 24.5; Org: `C-c LETTER' keys

[Nicolas Goaziou]

Hello,

Drew Adams  writes:

> Dunno whether there are actual bindings in Org that correspond to these
> occurrences in the source code of `C-c' followed by a letter.  Might be
> worth checking.  (Bindings of `C-c' followed by a letter are reserved
> for users.)  Possibly these are just vestigial doc indications, which
> could be corrected/updated.

Org's manual suggests to bind `org-agenda' to `C-c a', but doesn't bind
it by default.

> In org-agenda.el:
>
>   ["Find FLAGGED Tasks" (org-agenda nil "?") :active t :keys "C-c a ?"]
>
>   (defun org-agenda-kill-all-agenda-buffers ()
> "Kill all buffers in `org-agenda-mode'.
>   This is used when toggling sticky agendas.
>   You can also explicitly invoke it with `C-c a C-k'."...
>
> In org.el:
>
>   commands `org-search-view' (`C-c a s') and `org-occur-in-agenda-files'.
>   ["Global TODO list" org-todo-list :active t :keys "C-c a t"]
>   ["Find FLAGGED Tasks" (org-agenda nil "?") :active t :keys "C-c
>   a ?"]

Fixed (I used \\[org-agenda] instead of C-c a). Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#24814: Doc Typo in org-insert-heading

[Nicolas Goaziou]

Hello,

Benjamin Wiese  writes:

> The documentation of the function org-insert-heading contains a typo on
> line 21 ('ways' instead of 'way'). This documentation can be viewed by
> typing: C-h f org-insert-heading.

Apparently, the docstring no longer contains the typo.

I'm closing this bug report. Thank you!

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#27711: 25.2; org-feed gets old news as new from some feeds

[Nicolas Goaziou]

Hello,

Adonay Felipe Nogueira  writes:

> This was tested with `emacs -Q`.
>
> 1. In the Lisp Interaction buffer, evaluate:
>
> (require 'org-feed)
> (setq org-feed-alist '(("Blog de Bradley Kuhn"
>   "http://ebb.org/bkuhn/rss.xml;
>   "~/Documentos/Notícias.org"
>   "Blog de Bradley Kuhn")))
>
> 2. Then do M-x org-feed-update-all RET. Wait for the entries to be add
>to "~/Documentos/Notícias.org", inside "Blog de Bradley Kuhn".
>
> 3. Delete the entries inside "Blog de Bradley Kuhn", keep the FEEDSTATUS
>drawer.
>
> 4. Do (2) again.
>
> Notice that the old news are fetched as if they were new. In other
> feeds, this doesn't happen (that is: old news isn't fetched again).

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

[Nicolas Goaziou]

Eli Zaretskii  writes:

> Such tests can only be run interactively, because bidi reordering is a
> display-time feature in Emacs.  Is that OK with you?

That's better than no test at all in my book, so I'm fine with it, yes.

I can use isolation characters instead (if anyone cares to point me to
what those are), if you think that's better.

Regards,

[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

[Eli Zaretskii]

> Date: Mon, 04 Dec 2017 22:43:12 +0200
> From: Eli Zaretskii 
> Cc: m...@nicolasgoaziou.fr, 11...@debbugs.gnu.org
> 
> Yes, Emacs implements Unicode 9.0, including the UBA with isolates.

Actually, the current development sources and the upcoming Emacs 26.1
already support Unicode 10.0.

[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

[Eli Zaretskii]

> From: Nicolas Goaziou 
> Cc: Dov Grobgeld ,  11...@debbugs.gnu.org
> Date: Mon, 04 Dec 2017 21:27:53 +0100
> 
> I'd rather preserve structure of Org documents outside of Emacs. So,
> `:align-to' is not an option. 
> 
> IIUC, I need to replace the closest space from vertical bars with 
> 
>   #(" " 0 1 (space :width 1))
> 
> This doesn't sound too difficult.
> 
> However, could someone provide tests cases so we get it right once and
> for all?

Such tests can only be run interactively, because bidi reordering is a
display-time feature in Emacs.  Is that OK with you?

[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

[Eli Zaretskii]

> From: Dov Grobgeld 
> Date: Mon, 4 Dec 2017 21:35:40 +0100
> Cc: Eli Zaretskii , 11...@debbugs.gnu.org
> 
> The correct Unicode≥6.3 way to do this would be with the unicode isolation 
> characters. I.e. you would wrap
> each of the columns with column contents. Does emacs honor these?

Yes, Emacs implements Unicode 9.0, including the UBA with isolates.

However, I suspect that the results of wrapping with isolates will be
different from using the original proposal of using segment separators.

[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

[Dov Grobgeld]

The correct Unicode≥6.3 way to do this would be with the unicode isolation
characters. I.e. you would wrap each of the columns with column
contents. Does emacs honor these? Should be easy to test.

Regards,
Dov

On Mon, Dec 4, 2017 at 9:27 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Eli Zaretskii  writes:
>
> >> Date: Wed, 13 Jun 2012 22:26:35 +0300
> >> From: Dov Grobgeld 
> >>
> >> Imagine you have a buffer with the following logical contents (using the
> >> convention that capitals are RTL characters).
> >>
> >> | abcdef | abc |
> >> | ABCDEF | ABC |
> >>
> >> I would like this to be displayed as:
> >>
> >> | abcdef | abc |
> >> | FEDCBA | CBA |
> >>
> >> The problem is that I want to each column of the table to be isolated
> >> (with regards to bidi influence) from other columns in the table. (Of
> >> course we also want to choose the table direction, but that is a
> >> different and solvable issue.) If there is no such separation, which
> >> is the behaviour currently get in emacs HEAD, then the resulting
> >> rendered buffer is:
> >>
> >> | abcdef | abc |
> >> | CBA | FEDCBA |
> >>
> >> Is this even solvable in the current emacs bidi model?
> >
> > Yes, it is.  The solution involves putting segment separators between
> > the table columns.  These could be TAB characters or a display
> > property whose value is (space . :width N) or (space . :align-to COL).
> >
> > Org maintainers, please ask if you need help in fixing this.
>
> *raises a hand*
>
> I'd rather preserve structure of Org documents outside of Emacs. So,
> `:align-to' is not an option.
>
> IIUC, I need to replace the closest space from vertical bars with
>
>   #(" " 0 1 (space :width 1))
>
> This doesn't sound too difficult.
>
> However, could someone provide tests cases so we get it right once and
> for all?
>
> Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738
>

[O] bug#28072: Org Mode Drawer Folds Unexpectedly

[Nicolas Goaziou]

Hello,

Mitch Norcross  writes:

> * ISSUE: Org Mode Drawer Folds Unexpectedly
>
> ** Issue Description
>
>   - Org Mode Drawers fold (unexpected) when user attempts to unfold a plain
> list item within the drawer after having folded it.
>
> ** Steps To Reproduce the Bug
>
>   - Steps
>   1) Create a plain list with some hierarchy in it
>   2) Put the list in a drawer
>   3) Unfold the drawer
>   4) Fold a list item that has children
>   5) Try to unfold the list item that that you folded
>   - Notice that the drawer then folds, unexpectedly
>
> :mydrawer:
>   - Plain list item with children
>   + some notes here
>   + and here
>   + some more here
> :end:

I cannot reproduce it.

More explicitly, I copied the drawer above in a new file. I folded the
top item, then immediately unfolded it. The drawer didn't move.

Am I missing something?

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

[Nicolas Goaziou]

Hello,

Eli Zaretskii  writes:

>> Date: Wed, 13 Jun 2012 22:26:35 +0300
>> From: Dov Grobgeld 
>> 
>> Imagine you have a buffer with the following logical contents (using the
>> convention that capitals are RTL characters).
>> 
>> | abcdef | abc |
>> | ABCDEF | ABC |
>> 
>> I would like this to be displayed as:
>> 
>> | abcdef | abc |
>> | FEDCBA | CBA |
>> 
>> The problem is that I want to each column of the table to be isolated
>> (with regards to bidi influence) from other columns in the table. (Of
>> course we also want to choose the table direction, but that is a
>> different and solvable issue.) If there is no such separation, which
>> is the behaviour currently get in emacs HEAD, then the resulting
>> rendered buffer is:
>> 
>> | abcdef | abc |
>> | CBA | FEDCBA |
>> 
>> Is this even solvable in the current emacs bidi model?
>
> Yes, it is.  The solution involves putting segment separators between
> the table columns.  These could be TAB characters or a display
> property whose value is (space . :width N) or (space . :align-to COL).
>
> Org maintainers, please ask if you need help in fixing this.

*raises a hand*

I'd rather preserve structure of Org documents outside of Emacs. So,
`:align-to' is not an option. 

IIUC, I need to replace the closest space from vertical bars with 

  #(" " 0 1 (space :width 1))

This doesn't sound too difficult.

However, could someone provide tests cases so we get it right once and
for all?

Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#24791: bug#24791: org-todo-yesterday behaves like plain org-todo (incorrect timestamp)

[Nicolas Goaziou]

Hello,

Allen Li  writes:

> On Fri, Dec 1, 2017 at 1:53 PM, Nicolas Goaziou  
> wrote:
>> Hello,
>>
>> Jan Böhm  writes:
>>
>>> Symptoms: both org-todo-yesterday and org-agenda-todo-yesterday behave
>>> just like normally setting todo state to "DONE" with org-todo.
>>> Specifically, the timestamp
>>> added in the log takes the current time instead of 23:59 of the previous
>>> day, as would be expected.
>>>
>>> Replicate behaviour:
>>> start emacs -Q
>>> set org-log-done to "time"
>>> visit new file and switch to org mode
>>> create TODO headline and set TODO state to "DONE" by calling
>>> "org-todo-yesterday"
>>> ⇒ todo state is set to DONE correctly, but the timestamp inserted in
>>> the log drawer is the current time.
>>
>> I cannot reproduce it in a recent Org release. Could you double-check
>> with a newer Org?
>
> I am going to blindly wager that this is yet another bug caused by Org
> mode's subtle timezone issues.
>
> I can reproduce it (and crucially, I am not in the GMT time zone),
> although the repro recipe produces a CLOSED timestamp and not a log
> drawer timestamp.

I removed timezone references from maint. Can you still reproduce the
issue?

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#18870: bug#18870: \emsp and alignment in org clock report

[Ben Finney]

On 04-Dec-2017, Nicolas Goaziou wrote:
> Any 9.X version certainly contains the fix.

Using this version of ‘org-mode’:

Org mode version 9.1.2 (9.1.2-dist @ 
/usr/share/emacs/25.2/site-lisp/elpa/org-9.0.9/)

I confirm that the display of the report is much better:

| Headline| Time   |  |  |
|-++--+--|
| *Total time*| *0:20* |  |  |
|-++--+--|
| Lorem ipsum, dolor sit amet | 0:20   |  |  |
| \_  Suscipit sint quod  || 0:13 |  |
| \_  Ab facilis nulla|| 0:07 |  |
| \_Dolore laborum||  | 0:07 |

Thank you to the Org developers for resolving this bug.

-- 
 \  “A thing moderately good is not so good as it ought to be. |
  `\Moderation in temper is always a virtue; but moderation in |
_o__)   principle is always a vice.” —Thomas Paine |
Ben Finney 


signature.asc
Description: PGP signature

[O] bug#29329: 27.0.50; Missing requirement in org-gnus.el

[Nicolas Goaziou]

Hello,

Glenn Morris  writes:

> Speaking for the version in Emacs, apart from org-gnus the warnings are:
>
> In end of data:
> org-irc.el:255:1:Warning: the following functions are not known to be defined:
> erc-save-buffer-in-logs, erc-logging-enabled

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#29329: 27.0.50; Missing requirement in org-gnus.el

[Glenn Morris]

Speaking for the version in Emacs, apart from org-gnus the warnings are:

In end of data:
org-irc.el:255:1:Warning: the following functions are not known to be defined:
erc-save-buffer-in-logs, erc-logging-enabled

(I haven't looked at the code.)

Re: [O] Bug in emphasis fontification

[Kaushal Modi]

On Sat, Dec 2, 2017 at 5:30 PM Nicolas Goaziou 
wrote:

> Hopefully fixed. Thank you.
>

Yes, I confirm the fix. Thank you!
-- 

Kaushal Modi

Re: [O] Bug: org-attach-directory should be safe [9.1.3 (9.1.3-10-gadfbfd-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171127/)]

[Nicolas Goaziou]

Hello,

Allen Li  writes:

> org-attach-directory should be safe to set as a file local or
> directory local string.
>
> This allows the user to set a directory local attachment directory for
> all Org files in a directory tree recursively.
>
> I do not believe there are any security issues to enable arbitrary Org
> files to set org-attach-directory to a string value as the user would
> have to explicitly initiate any attach operations.  The most dangerous
> thing I can think of is an Org file setting the attachment directory
> to the user's home directory and the user running the command to
> delete all attachments.

Fair enough. I added a :safe keyword to the defcustom.

Regards,

-- 
Nicolas Goaziou

[O] bug#18870: bug#18870: \emsp and alignment in org clock report

[Nicolas Goaziou]

Hello,

Ben Finney  writes:

> On 04-Dec-2017, Nicolas Goaziou wrote:
>> Ben Finney  writes:
>> > How can we test the change, to know whether this bug is resolved?
>> 
>> You can test the latest ELPA release, scheduled for today
>
> Please state the exact version string, so that we can compare to see
> whether we're using one that meets your description.

We are talking about a 2 years old fix, so exact release doesn't really
matter, really. Any 9.X version certainly contains the fix.

Regards,

-- 
Nicolas Goaziou

[O] bug#18870: bug#18870: \emsp and alignment in org clock report

[Ben Finney]

On 04-Dec-2017, Nicolas Goaziou wrote:
> Ben Finney  writes:
> > How can we test the change, to know whether this bug is resolved?
> 
> You can test the latest ELPA release, scheduled for today

Please state the exact version string, so that we can compare to see
whether we're using one that meets your description.

-- 
 \   “We must find our way to a time when faith, without evidence, |
  `\disgraces anyone who would claim it.” —Sam Harris, _The End of |
_o__) Faith_, 2004 |
Ben Finney 


signature.asc
Description: PGP signature

[O] bug#18870: bug#18870: \emsp and alignment in org clock report

[Nicolas Goaziou]

Hello,

Ben Finney  writes:

> On 22-Aug-2016, Nicolas Goaziou wrote:
>> The display for clock reports has been changed some months ago in
>> development version.
>
> Which version contains this change?
>
>> I think this bug can be closed.
>
> How can we test the change, to know whether this bug is resolved?

You can test the latest ELPA release, scheduled for today (the current
ELPA release also contains the bug but has a nasty fontification bug
too).

You can also test Org bundled with Emacs 26.0.50.

Regards,

-- 
Nicolas Goaziou

[O] bug#18870: bug#18870: \emsp and alignment in org clock report

[Ben Finney]

On 22-Aug-2016, Nicolas Goaziou wrote:
> The display for clock reports has been changed some months ago in
> development version.

Which version contains this change?

> I think this bug can be closed.

How can we test the change, to know whether this bug is resolved?

-- 
 \   “Instead of having ‘answers’ on a math test, they should just |
  `\   call them ‘impressions’, and if you got a different |
_o__)   ‘impression’, so what, can't we all be brothers?” —Jack Handey |
Ben Finney 


signature.asc
Description: PGP signature

[O] Bug: org-attach-directory should be safe [9.1.3 (9.1.3-10-gadfbfd-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171127/)]

[Allen Li]

org-attach-directory should be safe to set as a file local or
directory local string.

This allows the user to set a directory local attachment directory for
all Org files in a directory tree recursively.

I do not believe there are any security issues to enable arbitrary Org
files to set org-attach-directory to a string value as the user would
have to explicitly initiate any attach operations.  The most dangerous
thing I can think of is an Org file setting the attachment directory
to the user's home directory and the user running the command to
delete all attachments.

Note that org-attach already allows setting the attachment directory
on a headline basis, this would just allow setting the attachment
directory on a file or directory basis.  It can be argued that the
existing functionality makes it more visible if a malicious Org file
sets a dangerous attachment path (a property on the headline vs a file
local variable or dir-locals file).  org-attach already mentions that
deleting all attachments is potentially dangerous and recommends
deleting through Dired.  Deleting through Dired would make it
impossible for a user to not notice that a malicious Org file has set
the attachment directory to something undesirable.

Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.19)
 of 2017-09-16
Package: Org mode version 9.1.3 (9.1.3-10-gadfbfd-elpaplus @
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20171127/)

[O] bug#20090: improperly closed

[Nicolas Goaziou]

Boruch Baum  writes:

> Bug report 20090 was perfunctorily closed today:

> 1] without the person who performed the action consulting with the bug
> reporter;

You're free to re-open the bug or create another one if you disagree.
For the record, I don't consider this to be a bug, but a feature
request.

> 2] without any discussion for over 2.5 years;

I hope you are not blaming me for that.

> 3] with a reason given that demonstrates that the person who performed
> the action didn't give the action much of any thought;

Yet, I gave it more thought than anyone in 2.5 years!

> In this particular case, the person who closed the bug apparently looked
> at the sentence fragment 'does not work for positions within an info node (eg.
>  line 85 of node x)', and confused the term `eg' with the term 'ie'.

How nice.

> At this point, emacs is uniquely inferior to all major 'word processors'
> in that it does not support the feature described in the bug, ie. the
> ability to link to a specific position within a document.
>
> Pretty basic, no?

Pretty inaccurate, actually. Org is able to link to a specific position
within an Org document, and to a specific line in any plain text
document.

Your feature request is to link to a specific position in a document
written in a foreign, processed format, namely Info. I cannot think of
any reliable way to do so (e.g., "going to the node, and searching for
a string" doesn't qualify as "reliable"). If you have an idea about it,
I suggest to first implement it as a custom link type, and open a proper
feature request, or report it on the Org mailing list.

Another option is to wait for 2.5 years again and despise the next
person to close this report.

Regards,

[O] bug#20090: improperly closed

[Boruch Baum]

Bug report 20090 was perfunctorily closed today:

1] without the person who performed the action consulting with the bug
reporter;

2] without any discussion for over 2.5 years;

3] with a reason given that demonstrates that the person who performed
the action didn't give the action much of any thought;

In this particular case, the person who closed the bug apparently looked
at the sentence fragment 'does not work for positions within an info node (eg.
 line 85 of node x)', and confused the term `eg' with the term 'ie'.

At this point, emacs is uniquely inferior to all major 'word processors'
in that it does not support the feature described in the bug, ie. the
ability to link to a specific position within a document.

Pretty basic, no?

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

[O] bug#20090: 24.4: linking to a position within an info node

[Nicolas Goaziou]

Closing the bug report.

[O] bug#20090: 24.4: linking to a position within an info node

[Nicolas Goaziou]

Hello,

Boruch Baum  writes:

> On 03/12/2015 03:50 PM, Juri Linkov wrote:
>>> When the org mode manual discusses creating links, it gives an example
>>> of linking to an info node (the self-referencing example is
>>> `info:org#External' links). The manual continues, at node
>>> `info:org#Search options', to describe how specific positions within
>>> file links can be directly specified. This does work for links to
>>> regular files, but does not work for positions within an info node (eg.
>>> line 85 of node x).
>> 
>> Is there an official format for the line numbers in Info cross-references?
> I don't know - my assumption was that within emacs, it would be
> basically just another type of emacs buffer, and be a legitimate subject
> for all elisp commands.
>
> Your question got me thinking, that emacs may have subtle rendering
> quirks, so just now, I opened fresh instances of info buffers in both
> very wide and very narrow windows, and they both `fill' to the same line
> length, ie the wide window has a lot of right-side white-space, and the
> narrow window has lines wrapped.
>
> Since I submitted the bug report, I've continued trying to get the
> feature working, and have been experimenting with the org-mode hooks
> `org-create-file-search-functions' and
> `org-execute-file-search-functions' to no success. The only, supposedly
> working examples I've come across for these functions are [1] and [2].
> If you know of other resources, that could be helpful.

Info links are also meant to be exported. Linking to a line number
doesn't sound portable. I don't think it should be supported out of the
box.

In any case, you can implement your own link types, if you need this
specific feature. See `org-link-parameters' for details.

> One other possible related bug I've found is that when trying to use
> org-store-link for a particular line number within an org-file, the link
> is created to the most recent header. One can successfully, manually,
> hack the created link, replacing the reference to the header with a line
> number, in order to be able to navigate directly to the desired line
> (all this, for a link target in an org mode file - this was done as a
> test, once I came across the original bug) [3].

Please open a new bug report if you think you found a bug. I'm closing
this one.

Thank you!

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#4068: 23.1; M-x org-cdlatex-mode: cdlatex not found

[Nicolas Goaziou]

Hello,

David Reitter  writes:

> Selecting M-x org-cdlatex-mode brings up the error message shown below.
> This command is also available via a menu, so it should really work
> out-of-the-box.

As specified in the manual, you need to install cdlatex from
.

In any case, the menu no longer allows to activate Org CDLatex mode if
`cdlatex' cannot be found in the load path.

I'm closing this bug report. Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#7528: 24.0.50; (org) Visibility Cycling

[Nicolas Goaziou]

Hello,

"Drew Adams"  writes:

> The node says:
>  
>  `C-c C-k' (`show-branches')
>  Expose all the headings of the subtree, CONTENT view for just one
>  subtree.  
>  
> But both `C-c C-k' and `show-branches' seem to be undefined in Org mode.
>  
> The doc does say specifically that this is for a CONTENT view, but at
> this point in the manual I have no idea what that is.  So maybe this
> key and command are defined only for some other (e.g. minor) mode?

`show-branches' is `outline-show-branches'. CONTENT view refers to
CONTENTS view, explained at the beginning of the node. I fixed the
"CONTENT" typo in the manual.

Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#21818: 24.5; org-set-tags-to indentation problems when called programmatically

[Nicolas Goaziou]

Nicolas Goaziou  writes:

> Nicolas Goaziou  writes:
>
>> After a quick glance, I think you are right: invisible characters are
>> not treated the same way in both cases. I'll investigate deeper soon.
>
> Fixed in d5767ad.

Closing this bug report, since my past self apparently fixed it.

Regards,

[O] bug#18877: 25.0.50; org-mode fontification error

[Nicolas Goaziou]

Hello,

Davor Rotim  writes:

> GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.4) of 2014-10-26
>
> emacs -Q, then (setq org-src-fontify-natively t) and try visiting an org
> file with source code blocks, the message "org-mode fontification error"
> will appear and no source code will be highlighted. The issue seems to go
> away if I install Org-mode from ELPA afterwards.

I'm closing this report as the issue is fixed in the code base.

Thank you!

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#28999: 25.3.50; org export : exclude-tags not working with org-export-filter-options-functions

[Nicolas Goaziou]

Hello,

Kyle Meyer  writes:

> Michel Damiens  writes:
>
>> Adding :
>>
>> (defun my-org-export-change-options (plist backend)
>> (cond 
>>   ((equal backend 'html)
>>(plist-put plist :exclude-tags "NOHTML")
>>(plist-put plist :select-tags "HTML"))
>>   ((equal backend 'latex)
>>(plist-put plist :exclude-tags "NOLATEX")
>>(plist-put plist :select-tags "LATEX")))
>> plist)
>>
>> (add-to-list 'org-export-filter-options-functions
>> 'my-org-export-change-options)
>>
>> to my init.el file doesn't work : headers with NOHTML tag are exported
>> to html, using the export dispatcher (C-c C-e h H)
>
> Shouldn't the values should be a list of strings rather than a single
> string?  (Is this something that used to work for you?)

I agree. This looks like a user error.

I'm closing this bug report.

Michel, do not hesitate to open a new one if you think the issue is
still there. Thank you!

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#27068: 25.2; org-odt-export-to-odt error when filename contains Chinese chars

[Nicolas Goaziou]

Hello,

"steven.y...@china-hicloud.com"  writes:

> When execute `org-odt-export-to-odt` command, if the org filename
> contains Chinese, and under Windows 7 OS default encoding GBK. An error
> occurs that the zipped obt file's name is not correct. I think we
> can change the following codes:
> ox-odt.el  line: 4067
> (target-name (file-name-nondirectory target)) ->
> (target-name "temp.odt")

I cannot reproduce it. More specifically, I created a file named "童.org",
added "* Headline" in it and exported it to ODT without problem.

Could you provide a recipe for the issue you are encountering? If you
are not able to reproduce it anymore, could you tell me so I can close
this bug?

Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#22635: 25.1.50; wrong-type-argument when using org-beamer-select-environment

[Nicolas Goaziou]

Hello,

Kyle Meyer  writes:

> Derek Feichtinger  writes:
>
>> When executing C-c C-b (org-beamer-select-environment) in an org beamer
>> using the current emacs head (git hash ae928ae), I reproducibly get
>> the following
>> error and backtrace, independent of the org beamer file used:
>>
>> ###
>> Debugger entered--Lisp error: (wrong-type-argument listp t)
>>   delete((org-filtered) t)
>>   remove((org-filtered) t)
>>   org-move-to-column(79 t)
>>   org-fast-tag-show-exit(t)
>>   org-fast-tag-selection(("B_note") nil ((:startgroup) ("B_againframe"
>> . 65) ("B_appendix" . 120) ("B_column" . 99) ("B_columns" . 67)
>> ("B_frame" . 102) ("B_fullframe" . 70) ("B_ignoreheading" . 105)
>> ("B_note" . 110) ("B_noteNH" . 78) ("B_block" . 98) ("B_alertblock"
>> . 97) ("B_verse" . 118) ("B_quotation" . 113) ("B_quote" . 81)
>> ("B_structureenv" . 115) ("B_theorem" . 116) ("B_definition" . 100)
>> ("B_example" . 101) ("B_exampleblock" . 69) ("B_proof" . 112)
>> ("B_beamercolorbox" . 111) (:endgroup) ("BMCOL" . 124)) nil)
>>   org-set-tags()
>>   org-beamer-select-environment()
>
> This was reported on the Org list and fixed in commit 34f3260 of the Org
> repo.
>
>   http://permalink.gmane.org/gmane.emacs.orgmode/104703

I'm therefore closing this bug report.

Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#26765: 25.2; org-babel: Inserting list of cons cells fails

[Nicolas Goaziou]

Hello,

Lucas Groenendaal  writes:

> Please describe exactly what actions triggered the bug, and
> the precise symptoms of the bug.  If you can, give a recipe
> starting from 'emacs -Q':
>
> First off, I found a fix for this problem.  I wasn't sure how to best
> submit that change but a bug report seemed appropriate so I went with
> that.  After a short demonstration of the problem comes my diff.
> Apologies if anything is missing or confusing, I've never done this
> before.
>
> - Start up emacs: emacs -Q
> - Put this code into an org mode file:
>
> #+BEGIN_SRC elisp
>   (print '((1 . 2)))
> #+END_SRC

I cannot reproduce it, so I guess it was fixed some time ago.

I'm closing this bug report. Please re-open one if you can reproduce it.

Thank you!

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] bug#29329: 27.0.50; Missing requirement in org-gnus.el

[Nicolas Goaziou]

Hello,

Glenn Morris  writes:

> In org-gnus-store-link:
> org-gnus.el:121:49:Warning: reference to free variable ‘gnus-newsgroup-name’
> org-gnus.el:127:42:Warning: reference to free variable ‘gnus-summary-buffer’
>
> In org-gnus-follow-link:
> org-gnus.el:203:9:Warning: reference to free variable 
> ‘gnus-other-frame-object’
>
> In end of data:
> org-gnus.el:243:1:Warning: the following functions are not known to be
> defined: gnus-group-group-name, gnus-find-method-for-group,
> gnus-summary-article-number, nnir-article-group,
> gnus-summary-article-header, mail-header-from, mail-header-id,
> mail-header-date, mail-header-subject, mail-header-extra,
> gnus-summary-select-article, message-narrow-to-headers,
> message-generate-headers, message-unquote-tokens,
> message-tokenize-header,
> gnus-activate-group, gnus-group-read-group,
> gnus-summary-goto-article,
> gnus-group-jump-to-group
>
>
> (These issues are all hidden if org-gnus.elc is created before
> org.elc.)

I think I fixed those. Is there any left?

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug in emphasis fontification

[Nicolas Goaziou]

Hello,

Kaushal Modi  writes:

> I believe that the recent fontification rules still need tweaking.
>
> Here's a MWE:
>
> =
> *bold*
> =
>
> Here's a more detailed version:
>
> =
> *bold*
> ^ above does not work
> *bold* this works at the time of typing.
> But on saving and doing =revert-buffer=, the fontification goes away.
> This *bold* fontification stays (starting emph char *and* ending emph char
> not at BOL/EOL).
>
> Looks like fontification is lost if emphasis chars are at BOL or EOL.

Hopefully fixed. Thank you.

Regards,

-- 
Nicolas Goaziou