Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: No Wayman writes: See the attached patch for a first draft implementation. Attached is a second draft which compiles cleanly and makes use of mapconcat where appropriate. [2. org-tags-crm-separators-2 --- text/x-patch; 0001-Add-org-tags-crm-separators.patch]... See

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: See the attached patch for a first draft implementation. Attached is a second draft which compiles cleanly and makes use of mapconcat where appropriate. >From 079f116f6bedcf2c2b1d08c18d71d8e432d94d38 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Fri, 3 Sep 2021

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Timothy writes: Reading your thoughts I’m inclined to agree, perhaps it’s best if we settle on a set of “sensible” separation characters, document them, and leave it at that. NoWayman, what do you think of that? I disagree with the idea that it shouldn't be customizable. See the second

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Allen Li writes: Sorry about that (I wrote the crm patch). I did not consider people deliberately using invalid tag characters to separate tags. It's an (un?)happy coincidence that org-set-tags-commands retains this behavior, because the fast tags selection logic gets in the way. The inco

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Timothy writes: Ah, right — that looks sensible. I think we should probably note that in a comment somewhere, Yes, a comment is warranted. I'll address minor issues like this once a solution is agreed upon. or perhaps construct the regexp with `rx' so it’s actually using `org-tag-re'?

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

My previous solution seems like it stopped working for some reason. Here is a new version that "should" only change syntax inside src-blocks, but not inside strings. It looks like this does not impact html blocks, or xml blocks. It is probably possible to make it mode specific if needed. (defun

Re: Bug: PDF Export of Link fails (emphasis ends inside link target)

On 03/09/2021 21:33, Timothy wrote: Perhaps a “fix” could be auto-escaping problematic characters in urls when entering links via `org-insert-link'. [/query/] Just to be clear: while comma may be percent-escaped (`org-lint' perhaps would not be happy), "/?" are

Re: Bug: PDF Export of Link fails (emphasis ends inside link target)

Hi Maxim, > In your particular case it is possible to use “%2C” instead of comma: > > /Link [kontakt] link/ > > As a more general approach, additional emphasis marks can be added around link > borders > > /Test/ [/query/] /test/ > > While I believe that during parsing of link target lookup

Re: Bug: PDF Export of Link fails (emphasis ends inside link target)

On 03/09/2021 12:17, Dr. Arne Babenhauserheide wrote: Using the following text I get failing pdf export: The link is not recognized correctly but ends after the comma and the markup persists in the PDF. /Diesen Text habe ich leicht abgewandelt schon am Montag per E-Mail ans [[https://km-bw.de/,

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

I think what is happening here is that org is bumping up against fundamental design limitations of Emacs. In basic terms, much of Emacs' underlying design is based on an assumption that a file only has a single major mode. Org works hard to get around this limitation, but it comes with cost - usu

[FR] Remove blank :effort:s from taskjuggler export

Dear wonderful Orgers, Something I think would make the taskjuggler export even smoother would be if empty :effort:'s were simply skipped over, rather than exported to the tjp without a value and triggering a tj3 error. Let me explain. Say we had the following org file, with one big feature: -

Re: Bug: Percentage in caption (even escaped) does not work in LaTeX export

On 30/07/2021 22:00, Charest, Luc wrote:    I simplified the problem down to : #+CAPTION: Org Mode works 99.99\% of the time. #+BEGIN_SRC -n // this is only a proof of concept #+END_SRC As soon as I put the percentage sign in the caption, the LaTeX export backend fails with this message : o

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

That is probably a matter of opinion. If you use angle brackets as delimiters, e.g. in html, xml in src-blocks, then the current syntax definition makes sense because you can use them to find open and closing brackets, navigate them, etc.. If you don't use those, it makes less sense, and maybe isn

Fwd: Greater than, less than bug in emacs-lisp source block

Thank you, Arthur. Forwarded Message Subject: Re: Greater than, less than bug in emacs-lisp source block Date: Fri, 03 Sep 2021 00:36:23 +0200 From: Arthur Miller To: John Kitchin CC: Charles Millar , emacs-orgmode@gnu.org John Kitchin writes: I think this issue is des

re: Bug Re: Greater than, less than bug in emacs-lisp source block

Thank you, John. I will give it a try. However, is this a bug that should be fixed within org source code? Charlie Millar On 9/2/21 2:24 PM, John Kitchin wrote: I think this issue is described in https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch. There

Re: Bug: PDF Export of Link fails [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]

Timothy writes: > Causes issues. I also note that in the Org-mode buffer the comma seems to > cause > issues. I’ve attached a screenshot, in which you can see in the “comma, > italics” > situation: > ⁃ The second line is not italic > ⁃ The second `/' of the pair is shown (and I have Org’s entity

Re: Bug: PDF Export of Link fails [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]

Ooops, I forgot to mark this as a bug on updates.orgmode.org in my last email. Let’s fix that.

Re: Bug: PDF Export of Link fails [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]

Hi Arne, > Using the following text I get failing pdf export: The link is not > recognized correctly but ends after the comma and the markup persists in > the PDF. Thanks for reporting this. I’ve managed to reproduce the behaviour. I also note that this doesn’t happen without the italic markers,

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Hi Allen, > The question here is, which behavior do we want? My philosphy is that > programs shouldn’t try to silently re-interpret the user’s intentions. > For example, if I accidentally mistyped the tag “green_blue” as > “green-blue”, I don’t want Org to “helpfully” split one tag into two > tag

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Hi NoWayman, >> would you be able to explain the default value you’ve set? It isn’t obvious >> to me how you > I was aiming for the inverse of `org-tag-re’ which is: > > “[[:alnum:]_@#%]+” > > The idea being we treat any character which is not a valid tag character as > the > crm separator. Ah,