Re: [O] Possible bug with coderef highlighting in HTML export

[Nicolas Goaziou]

Hello,

Thibault Marin  writes:

> Hi the attach patch fixes the issue for me.  Please let me know if you
> have any suggestions.

It looks good. Applied. Thank you.

Regards,

-- 
Nicolas Goaziou

[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] How can I obtain Org via HTTPS?

[Radon Rosborough]

Hello all,

It does not appear to be possible to obtain the Git repository for Org
via HTTPS or SSH, only via HTTP. I have checked the manual and
searched the Internet to see if there is a way, but no luck. I only
found an unanswered inquiry from earlier this year [1].

—Why is HTTPS/SSH necessary when Org releases are signed with GPG?
Well, only releases are signed. If you want to clone the development
version of Org, there appears to be no way to verify that it has not
been tampered with, since the clone was using an insecure protocol.

—Why do I care about this?
I maintain the package manager straight.el [2], which installs
packages by cloning their Git repositories. By default, the
development version of a package is installed. It would be
irresponsible to install packages via HTTP, so straight.el is forced
to install Org from the EmacsMirror [3] instead. This makes me
uncomfortable, since I would prefer to install packages from their
authoritative upstream sources—this makes contributing back to those
packages easier.

Have I missed something? Is it already possible to obtain Org
securely? If not, is making that possible a current goal of the
project? If not, what is the difficulty and can I help?

Best regards,
Radon Rosborough

[1]: http://lists.gnu.org/archive/html/emacs-orgmode/2017-03/msg00335.html
[2]: https://github.com/raxod502/straight.el
[3]: https://github.com/emacsmirror/org

[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

Re: [O] org-depend: TRIGGER XYZ(KEYWORD) not working

[Adrian Bradd]

Hi Karl,


> Examples:
>
>  * Top-Heading
>
>  ** TODO Here I invoke org-todo to DONE
>  :PROPERTIES:
>  :TRIGGER: 2017-12-03-target(TODO)
>  :END:
>
>  ** This should be changed to TODO
>  :PROPERTIES:
>  :ID: 2017-12-03-target
>  :END:
>
> ... this is working (i.e., "This should be changed to TODO" gets its
> TODO keyword).
>
>  * Top-Heading with process indicator [0/2]
>
>  ** TODO Here I invoke org-todo to DONE
>  :PROPERTIES:
>  :TRIGGER: 2017-12-03-target(TODO)
>  :END:
>
>  ** This should be changed to TODO
>  :PROPERTIES:
>  :ID: 2017-12-03-target
>  :END:
>
> ... this is *not* working.
>
> However, anticipating the wrong position:
>
>  * Top-Heading with process indicator [0/2]
>  :PROPERTIES:
>  :TRIGGER: 2017-12-03-target(TODO)
>  :END:
>
>  ** TODO Here I invoke org-todo to DONE
>  :PROPERTIES:
>  :TRIGGER: 2017-12-03-target(TODO)
>  :END:
>
>  ** This should be changed to TODO
>  :PROPERTIES:
>  :ID: 2017-12-03-target
>  :END:
>
> ... is working. And according to this:
>
>  * Top-Heading with process indicator [0/2]
>  :PROPERTIES:
>  :TRIGGER: 2017-12-03-target(TODO)
>  :END:
>
>  ** TODO Here I invoke org-todo to DONE
>
>  ** This should be changed to TODO
>  :PROPERTIES:
>  :ID: 2017-12-03-target
>  :END:
>
> ... this is also working. So the update of the process indicator
> causes the wrong property drawer to be parsed for the relevant
> TRIGGER property.
>
> Contrary to my previous assumption, this is issue is *not* related
> to big and small files. This is purely related to the existing or
> missing process indicator of the upper-level heading.
>
> I guess I have found the origin of the bug.


​I'm not able to reproduce what you are seeing above.​ Even instances with
a progress indicator correctly triggered if the TRIGGER property was set.
Your final example updates the "Here I invoke org-todo to DONE" entry to
DONE and doesn't touch any other heading for me.

I did see an issue with triggered headings not honouring note logging when
the todo was set to DONE, but I haven't looked any closer at it just yet.

What version of org-mode are you running? If you are using the git version
can you pull the latest on maint. I performed my testing on maint.


> Can you please do me the favor and fix it for me. I feel

extraordinary proud of me having dig into elisp (which I don't know
> how to code mostly) and found the bug ;-)
>
> However, I can't fix it on my own :-(
>

​Even just being able to dig through some code and debug can be a major
benefit. :-)


> Why did nobody tell me about org-edna yet? ;-)
>

​I found out on the mailing list as well. Doubt I would have even stumbled
upon it otherwise.
​
Cheers,

Adrian

Re: [O] Possible bug with coderef highlighting in HTML export

[Thibault Marin]

Hi,

Hi the attach patch fixes the issue for me.  Please let me know if you
have any suggestions.

As always, thanks for the guidance.

thibault


>From a78dc91c9fd1aacb2c65f66ae5afa9ee25f56e01 Mon Sep 17 00:00:00 2001
From: thibault 
Date: Sun, 3 Dec 2017 17:42:13 -0600
Subject: [PATCH] Fix bug in HTML export of code blocks with starting blank
 lines

* lisp/ox-html.el (org-html-do-format-code): Preverse starting blank
  lines when splitting code lines (use `split-string' instead of
  `org-split-string').

  (org-html-fontify-code): Preserve starting blank lines in returned
  code string.
---
 lisp/ox-html.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 0e22c1699..90a6cede0 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2202,7 +2202,7 @@ https://github.com/hniksic/emacs-htmlize;))
 		  (org-html-htmlize-region-for-paste
 		   (point-min) (point-max))
 	  ;; Strip any enclosing  tags.
-	  (let* ((beg (and (string-match "\\`]*>\n*" code) (match-end 0)))
+	  (let* ((beg (and (string-match "\\`]*>\n?" code) (match-end 0)))
 		 (end (and beg (string-match "\\'" code
 	(if (and beg end) (substring code beg end) code)
 
@@ -2215,7 +2215,7 @@ alist between line numbers and references (as returned by
 `org-export-unravel-code'), a boolean specifying if labels should
 appear in the source code, and the number associated to the first
 line of code."
-  (let* ((code-lines (org-split-string code "\n"))
+  (let* ((code-lines (split-string code "\n"))
 	 (code-length (length code-lines))
 	 (num-fmt
 	  (and num-start
-- 
2.14.1

[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

Re: [O] org-depend: TRIGGER XYZ(KEYWORD) not working

[Karl Voit]

Hi Adrian,

Glad that you replied - I was worrying that this thread is going to
die before any improvement can be developed ...

* Adrian Bradd  wrote:
>
> First observation:
>>
>> When I set the heading 1 to DONE (without assigning it any other
>> keyword), the TRIGGER events are ignored totally.  I guess this is
>> an edge-case that may be considered as a bug.
>>
>
> This is the result of Line 219 in org-depend.el:
>
> (unless (and (member from org-not-done-keywords)
> (member to org-done-keywords))
>
> In this instance 'from' is set to nil so the 'and' returns nil and
> org-depend doesn't process the change of TODO to look for dependents. I
> don't know why it was defined this way as org-todo.el accepts headings with
> no TODO entry. I can't think of any reason other than explicitly blocking a
> user from processing a heading without a TODO entry, but it seems that if
> the user went to the effort of populating a TRIGGER property that they
> probably want this to be acted upon by org-depend.el.

I totally agree: there should not be any reason to accept missing
TODO keywords in this case as well.

> If there are no concerns raised in this thread I'll push a patch to all
> have org-depend process the example you listed.

Cool ;-)

>> Second observation:
>>
>> However, what is bugging me even more is that even when "heading 1"
>> has a TODO keyword assigned, in *some* cases, the TRIGGER event does
>> not get executed when I do it in my large Org-mode file.
>>
>> Copying the corresponding headings (the one with the TRIGGER prop
>> and the headings containing the "target" IDs) from my real-world
>> Org-mode file to my small test.org from above and marking the
>> heading that contains the TRIGGER properties to DONE, it then works
>> as expected.
>>
>> I then took the simple example from above, added a TODO keyword to
>> the heading 1, copied it to my real-world Org-mode file and even
>> this did not work: Heading 2 and 3 don't get their "NEXT" keyword
>> assigned.
>>
>> So the behavior changes within different Org-file contexts.
>> Therefore, I do have an issue creating a minimal example to
>> demonstrate the bug.
>>
>> Can somebody give me an advice how to debug this behavior?
>
> My only thought is that there is an ID clashing with your sample I=
> D and it
> is being updated instead of the heading you are interested in.
> org-depend.el looks at the local file for an ID and then looks globally for
> an ID match.

Well, the IDs I was using were unique over all of my files.
Valid guess but not the case at my setup.

> You could instrument 'org-depend-trigger-todo' to trace the behaviour while
> processing the TODO update.

I found out that following part does not return any TRIGGER line:

: ;; OK, we just switched from a TODO state to a DONE state
: ;; Lets see if this entry has a TRIGGER property.
: ;; If yes, split it up on whitespace.
: (setq trigger (org-entry-get pos "TRIGGER");; <-- no result here!
:   triggers (and trigger (split-string trigger)))

So the whole procedure of looking for the IDs to trigger is not
reached at all. 

After that I edebug-defun org-entry-get and the difference between
working and non-working TRIGGER (non-nil list of property values
versus nil) can be found at:

: (let* ((local (org--property-local-values property literal-nil))

... within org.el (git maint 946f76d70)

Another edebug-defun of org--property-local-values shows that this
code does not return the list of values in the big file where it is
working with my working minimal file:

: (let ((v (and (re-search-forward
:(org-re-property property nil t) end t)
:   (match-string-no-properties 3

I could not jump into re-search-forward (built-in function) but I
found out something fishy: The value for "end" held a position which
is *not* the correct one.

Instead of holding the end position of the property drawer of the
heading I invoked org-todo on, it held the end of the properties
drawer of the next higher heading which has a progress indicator in
it.

Examples:

 * Top-Heading
 
 ** TODO Here I invoke org-todo to DONE
 :PROPERTIES:
 :TRIGGER: 2017-12-03-target(TODO)
 :END:
 
 ** This should be changed to TODO
 :PROPERTIES:
 :ID: 2017-12-03-target
 :END:

... this is working (i.e., "This should be changed to TODO" gets its
TODO keyword).

 * Top-Heading with process indicator [0/2]
 
 ** TODO Here I invoke org-todo to DONE
 :PROPERTIES:
 :TRIGGER: 2017-12-03-target(TODO)
 :END:
 
 ** This should be changed to TODO
 :PROPERTIES:
 :ID: 2017-12-03-target
 :END:

... this is *not* working.

However, anticipating the wrong position:

 * Top-Heading with process indicator [0/2]
 :PROPERTIES:
 :TRIGGER: 2017-12-03-target(TODO)
 :END:
 
 ** TODO Here I invoke org-todo to DONE
 :PROPERTIES:
 :TRIGGER: 2017-12-03-target(TODO)
 :END:
 
 ** 

[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] org-depend: TRIGGER XYZ(KEYWORD) not working

[Adrian Bradd]

Hi,

First observation:
>
> When I set the heading 1 to DONE (without assigning it any other
> keyword), the TRIGGER events are ignored totally.  I guess this is
> an edge-case that may be considered as a bug.
>

​This is the result of Line 219 in org-depend.el:

(unless (and (member from org-not-done-keywords)
(member to org-done-keywords))

In this instance 'from' is set to nil so the 'and' returns nil and
org-depend doesn't process the change of TODO to look for dependents. I
don't know why it was defined this way as org-todo.el accepts headings with
no TODO entry. I can't think of any reason other than explicitly blocking a
user from processing a heading without a TODO entry, but it seems that if
the user went to the effort of populating a TRIGGER property that they
probably want this to be acted upon by org-depend.el.

If there are no concerns raised in this thread I'll push a patch to all
have org-depend process the example you listed.


> Second observation:
>
> However, what is bugging me even more is that even when "heading 1"
> has a TODO keyword assigned, in *some* cases, the TRIGGER event does
> not get executed when I do it in my large Org-mode file.
>
> Copying the corresponding headings (the one with the TRIGGER prop
> and the headings containing the "target" IDs) from my real-world
> Org-mode file to my small test.org from above and marking the
> heading that contains the TRIGGER properties to DONE, it then works
> as expected.
>
> I then took the simple example from above, added a TODO keyword to
> the heading 1, copied it to my real-world Org-mode file and even
> this did not work: Heading 2 and 3 don't get their "NEXT" keyword
> assigned.
>
> So the behavior changes within different Org-file contexts.
> Therefore, I do have an issue creating a minimal example to
> demonstrate the bug.
>
> Can somebody give me an advice how to debug this behavior?
>

​My only thought is that there is an ID clashing with your sample ID and it
is being updated instead of the heading you are interested in.
org-depend.el looks at the local file for an ID and then looks globally for
an ID match.

You could instrument 'org-depend-trigger-todo' to trace the behaviour while
processing the TODO update.

Otherwise, you could use a process of elimination in a copy of your
existing file to find the MWE that causes the issue and post it here. You
could successively delete headings or other entries until the issue stops
occurring.​

I have read your post on org-depend and found it insightful so thanks for
that. When I was looking around at patching some new functionality into
org-depend I was put onto org-edna[1] which was built as an alternative to
org-depend. The syntax isn't compatible with org-depend, but org-edna is
more powerful than org-depend. I am now using org-edna and am quite happy
with it.

[1] https://elpa.gnu.org/packages/org-edna.html

Re: [O] Possible bug with coderef highlighting in HTML export

[Nicolas Goaziou]

Hello,

Thibault Marin  writes:

> I am using Org mode version 9.1.3 (release_9.1.3-216-g259656 @
> /.../org-mode/lisp/) and I am experiencing an issue with the exported
> HTML of the following org file:
>
> ,
> | this links get highlighted [[(link0)]].
> | 
> | this link does not get highlighted [[(link1)]].
> | 
> | #+begin_src emacs-lisp -r
> | 0(ref:link0)
> | #+end_src
> | 
> | #+begin_src emacs-lisp -r
> | 
> | 1(ref:link1)
> | #+end_src
> `
>
> The relevant HTML output is:
>
> ,
> | 
> | this links get highlighted  onmouseover="CodeHighlightOn(this, 'coderef-link0');" 
> onmouseout="CodeHighlightOff(this, 'coderef-link0');">1.
> | 
> | 
> | 
> | this link does not get highlighted  onmouseover="CodeHighlightOn(this, 'coderef-link1');" 
> onmouseout="CodeHighlightOff(this, 'coderef-link1');">1.
> | 
> | 
> | 
> |  class="coderef-off">0
> | 
> | 
> | 
> | 
> | 1
> | 
> | 
> `
>
> The issue is that the link to the line in the second source block is not
> highlighted (it does not get the "coderef-off" span markup).

Indeed.

> I tried to dig a little and it appears that `org-html-do-format-code'
> does not handle empty lines at the beginning of a block.
> `(org-split-string "\n1")' returns '("1") which looses the first empty
> line. The line reference received via the `refs' variable (which has
> value ((2 . link1))) then becomes out of sync with the `code' variable
> (split by lines) used for formatting of the code block.
>
> I am not sure what is the best way to handle this:
>
> 1. Should the `refs' variable be built accounting for the top empty lines?
> 2. Alternatively, should the `org-html-do-format-code' and
>`org-export-format-code' functions count the number of top empty lines and
>adjust the line number accordingly?
> 3. Should top empty lines be completely deleted, before the `refs' array is
>built?
>
> I can try to propose a patch if the best option can be decided.  Option 2 
> seems
> relatively simple but feels like a hack.
>
> I would appreciate any suggestions on how to best fix this.

Option 1 seems the best way to go. Replacing `org-split-string' with
`split-string' is straightforward in this case. However, some issues
remain in `org-html-fontify-code'.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] using org-global-properties in capture templates

[Xebar Saram]

Hi

thank you Adrian so so much, i hugely appreciate this!

this works perfectly now, thx for pointing me in the right direction

have a great week!

Z

On Sun, Dec 3, 2017 at 3:28 AM, Adrian Bradd  wrote:

> Hello,
>
> It looks like you have one too many parenthesis around the Rating entry.
> org-global properties is supposed to be a list of cons cells. The below
> should work:
>
> #+BEGIN_SRC elisp
> (setq org-global-properties '(("Cuisine_ALL". "- Indian Thai Vietnamese
> Asian Chinese Israeli Italian American EastEuro Mexican French Persian
> Austrian Greek Fusion")))
> (add-to-list 'org-global-properties '("Rating_ALL". "- 1 2 3 4 5"))
> #+END_SRC
>
> Below is a version that worked for me with all three properties. I declare
> the properties all in one list instead of adding them.
>
> #+BEGIN_SRC elisp
> (setq org-global-properties '(("Cuisine_ALL". "- Indian Thai Vietnamese
> Asian Chinese Israeli Italian American EastEuro Mexican French Persian
> Austrian Greek Fusion") ("Effort_ALL" . "0 0:10 0:20 0:30 1:00 2:00 3:00
> 4:00 6:00 8:00") ("Rating_ALL" . "- 1 2 3 4 5")))
>
>  (setq org-capture-templates
>   '(("f" "Food"
> entry
> (file+headline  "~/tmp/tmp.org" "Inbox")
> "* COOK %^{Recipe Name}
> :PROPERTIES:
> :ID: %(org-id-uuid)
> :Time: %^{minutes|-|10|15|30|60}
> :Effort: %^{Effort}p
> :Rating: %^{Rating}p
> :Cuisine: %^{Cuisine}p
> :END:
> "
> "Capture Template for food recipe")))
> #+END_SRC
>
> HTH,
>
> Adrian
>
> On 22 November 2017 at 04:52, Xebar Saram  wrote:
>
>> Hi all
>>
>> sorry to nudge but after spending alot of time on this , googling etc
>> cant seem to get it to work. any help, tips or pointing me in the right
>> direction would really be appreciated!
>>
>> Z
>>
>> On Sat, Nov 4, 2017 at 5:31 PM, Xebar Saram  wrote:
>>
>>> sorry to bother again but still stuck with this
>>>
>>> i tried to add another org-global-property entry (i assume thats
>>> possible) but then i didnt get completion for the second one.
>>> this is what i used
>>>
>>> (setq org-global-properties '(("Cuisine_ALL". "- Indian Thai Vietnamese
>>> Asian Chinese Israeli Italian American EastEuro Mexican French Persian
>>> Austrian Greek Fusion")))
>>> (add-to-list 'org-global-properties '(("Rating_ALL". "- 1 2 3 4 5")))
>>>
>>> can anyone point me to the correct syntax for adding additional
>>> org-global-properties?
>>>
>>> thx alot in advance
>>>
>>> Z
>>>
>>>
>>> On Sat, Oct 28, 2017 at 9:44 PM, Xebar Saram  wrote:
>>>
 thx so much

 that works well. i tried to add another org-global-property entry (i
 assume thats possible) but then i didnt get completion for the second one.
 this is what i used

 (setq org-global-properties '(("Cuisine_ALL". "- Indian Thai Vietnamese
 Asian Chinese Israeli Italian American EastEuro Mexican French Persian
 Austrian Greek Fusion")))
 (add-to-list 'org-global-properties '(("Rating_ALL". "- 1 2 3 4 5")))

 i assume my syntax is wrong?

 thx!

 Z

 On Sat, Oct 28, 2017 at 12:37 PM, Nicolas Goaziou <
 m...@nicolasgoaziou.fr> wrote:

> Hello,
>
> Xebar Saram  writes:
>
> > ;; Effort and global properties
> > (setq org-global-properties '(("Effort_ALL". "0 0:10 0:20 0:30 1:00
> 2:00
> > 3:00 4:00 6:00 8:00")))
> >
> >
> >
> > (add-to-list 'org-capture-templates
> > '("f" "Food"
> > entry
> > (file+headline (lambda () (concat pmm "/org/files/agenda/food.org"))
> > "Inbox")
> > "* COOK %^{Recipe Name}
> > :PROPERTIES:
> > :ID: %(org-id-uuid)
> > :Effort_ALL: %^{Effort_ALL}p
> > :END:
> > "
> > "Capture Template for food recipe"
> > ))
>
> "XYZ_ALL" is a special property defining allowed values for "XYZ". In
> you case, you will get completion for "Effort" with:
>
>   :Effort: %^{Effort}p
>
>
> Regards,
>
> --
> Nicolas Goaziou
>


>>>
>>
>

[O] Possible bug with coderef highlighting in HTML export

[Thibault Marin]

Hi all,

I am using Org mode version 9.1.3 (release_9.1.3-216-g259656 @
/.../org-mode/lisp/) and I am experiencing an issue with the exported
HTML of the following org file:

,
| this links get highlighted [[(link0)]].
| 
| this link does not get highlighted [[(link1)]].
| 
| #+begin_src emacs-lisp -r
| 0(ref:link0)
| #+end_src
| 
| #+begin_src emacs-lisp -r
| 
| 1(ref:link1)
| #+end_src
`

The relevant HTML output is:

,
| 
| this links get highlighted 1.
| 
| 
| 
| this link does not get highlighted 1.
| 
| 
| 
| 0
| 
| 
| 
| 
| 1
| 
| 
`

The issue is that the link to the line in the second source block is not
highlighted (it does not get the "coderef-off" span markup).

I tried to dig a little and it appears that `org-html-do-format-code' does not
handle empty lines at the beginning of a block.  `(org-split-string "\n1")'
returns '("1") which looses the first empty line.  The line reference received
via the `refs' variable (which has value ((2 . link1))) then becomes out of sync
with the `code' variable (split by lines) used for formatting of the code block.

I am not sure what is the best way to handle this:

1. Should the `refs' variable be built accounting for the top empty lines?
2. Alternatively, should the `org-html-do-format-code' and
   `org-export-format-code' functions count the number of top empty lines and
   adjust the line number accordingly?
3. Should top empty lines be completely deleted, before the `refs' array is
   built?

I can try to propose a patch if the best option can be decided.  Option 2 seems
relatively simple but feels like a hack.

I would appreciate any suggestions on how to best fix this.

Thanks in advance.

thibault