[BUG] Org export fails on $k$-ary
Dear all, I would expect this to be exported to HTML and LaTeX correctly: "A $k$-ary function has $k$ arguments" In 12.5.1 LaTeX fragments, this use of a hyphen is documented: "To avoid conflicts with currency specifications, single ‘$’ characters are only recognized as math delimiters if the enclosed text contains at most two line breaks, is directly attached to the ‘$’ characters with no whitespace in between, and if the closing ‘$’ is followed by whitespace, punctuation or a dash." However, the HTML export result contains "A $k$-ary function has \(k\) arguments", which is not rendered correctly. The first two dollar signs should be replaced as well. The LaTeX result contains "A \$k\$-ary ...", which produces literal dollar signs, not math mode. In contrast, "A \(k\)-ary..." works. This happens with Org mode version 9.6.15 and with 9.7-pre (release_9.6.24-1336-gc8d133 @ ...). Recipe: emacs -Q (add-to-list 'load-path "~/src/org-mode/lisp") Then export an Org buffer/file with the above line: C-c C-e h h C-c C-e l l Best wishes, Jens smime.p7s Description: S/MIME cryptographic signature
Re: [Bug] org-in-src-block-p returns t when not in source block
On 2023-11-27 21:30, Ihor Radchenko wrote: > Fixed, on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6d7c7917a Which is currently my HEAD, and there are still edge cases that do not seem to be handled well. Start off from "make vanilla" and the following buffer - test.org - #+begin_src shell foo #+end_src bar - test.org - Navigate to BOL of the "#+end_src" line and M-: (org-in-src-block-p t) => nil As expected. Now add a space on the empty line *after* the "#+end_src" line, navigate back to BOL of the "#+end_src" line and M-: (org-in-src-block-p t) => t When I wrote my own inner-boundary function, I looked with envy at the elegance of the arithmetic done in `org-in-src-block-p' but thought that this probably would not always work ... or did I misunderstand something here? Thanks Jens Here is the lossage corresponding to my test case, just in case: C-s ;; isearch-forward #;; isearch-printing-char +;; isearch-printing-char e;; isearch-printing-char n;; isearch-printing-char d;; isearch-printing-char C-a ;; org-beginning-of-line M-: (org-in-src-block-p t) ;; read--expression-try-read C-n ;; next-line SPC ;; org-self-insert-command C-a ;; org-beginning-of-line C-p ;; previous-line M-: (org-in-src-block-p t) ;; read--expression-try-read
How to get the inner boundaries of a block
Triggered by a recent question here on `org-in-src-block-p' and a current need: Is there a function already available that returns the *inner* boundaries of an arbitrary block element? For the element corresponding to the block below: #+begin_verse ^A foo bar baz^B #+end_verse that function would return, for example, the pair of positions (A . B). Currently, I use org element properties and some combination of save-excursion, forward-line, and skip-syntax-*, but I thought this could be something which is available already. A cursory search hasn't brought up anything, though. Thanks Jens
Re: Gantt Chart with org-mode
Maybe a bit more than just gant: https://taskjuggler.org/ and https://orgmode.org/worg/exporters/taskjuggler/ox-taskjuggler.html > On 4. Nov 2023, at 13:33, Heime wrote: > > > Can one construct a Gantt Chart with org-mode ? >
[BUG] org-comment-dwim does not work with temporary Transient Mark mode [9.7-pre (release_9.6.10-902-g41ff56 @ /home/jschmidt/work/org-mode/lisp/)]
* Reproducer Save the following files: - /tmp/test.org - #+begin_src bash foo bar baz #+end_src - /tmp/test.org - - /tmp/test.el - (transient-mark-mode -1) (setq org-support-shift-select t) - /tmp/test.el - Then start Emacs as emacs -Q -l /tmp/test.el +2 /tmp/test.org Select the three lines of the source block with `C-3 S-', then press `M-;'. For me the resulting buffer looks like: - /tmp/test.org - #+begin_src bash foo bar baz # (point) #+end_src - /tmp/test.org - where I would have expected: - /tmp/test.org - #+begin_src bash # foo # bar # baz(point) #+end_src - /tmp/test.org - The latter result you get when Transient Mark mode is permanently on. * My Educated Guess In the following snippet from `org-comment-dwim' (org-babel-do-in-edit-buffer (call-interactively #'comment-dwim))) the buffer-local setting of `transient-mark-mode' (having value `(only)' when a region is shift-selected) from buffer test.org does not get transferred to the intermediate source buffer. However, function `comment-dwim' relies on that to decide whether to operate on point or on region: comment-dwim is an interactive native-compiled Lisp function in ‘newcomment.el’. Call the comment command you want (Do What I Mean). If the region is active and ‘transient-mark-mode’ is on, call ‘comment-region’ (unless it only consists of comments, in which case it calls ‘uncomment-region’); [...] So probably somewhere in `org-babel-do-in-edit-buffer' the value of `transient-mark-mode', if it is buffer-local and differs from the default value, should be transferred to the intermediate source buffer. Emacs : GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2023-10-26 Package: Org mode version 9.7-pre (release_9.6.10-902-g41ff56 @ /home/jschmidt/work/org-mode/lisp/)
Support for buffer-column-aligned tables in Org?
Is there any kind of support (also by non-core extensions) for tables in Org that are entirely organized along buffer columns? Some magic (= clever heuristics) that recognizes the following as a table with four columns, the first three left-aligned, the last right-aligned: <6> 1.0 1 one some 10.0 2 two boring 100.0 3 This is a long text column 1000.0 By "organized along buffer columns" I mean that basically any kind of white-space should be allowed to align the columns in the buffer. By "any kind of support" I mean: - one-time conversion support to an Org table along the lines of C-c | - or edit/export support of such tables w/o the need to convert them to an Org table first. I tried searching but failed to find search terms that are specific enough to find anything useful. Thanks.
Re: Suggestions for Text-To-Speech (TTS) from Org sources?
On 2023-09-28, Jude DaShiell wrote: > espeak-ng likes to have speechdispatcher on a system Does this improve the quality of the generated speech? > and festival likes to have language-specific voices on it to use. Indeed. Which one(s) do you recommend? I tried voice_cmu_us_slt_arctic_hts and the mbrola us voices. > fenrir which you didn't mention runs in user land and has no kernel > dependencies. I briefly tried that but failed. Also, I was under the impression that fenrir does produce speech by itself but relies on some TTS implementation like espeak. Is that wrong? Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: Suggestions for Text-To-Speech (TTS) from Org sources?
Dear all, some time ago I asked for suggestions concerning Text-To-Speech (TTS) from Org sources. Thank you to everyone who provided suggestions! In case you are interested, you can listen to sample results at [1]. Briefly, Emacspeak, espeak-ng, and festival are not good enough for my purposes. Maybe I'm missing relevant backend options. IMHO, Coqui-AI TTS [2] and Microsoft SpeechT5 [3] are far superior. Best wishes Jens [1] https://gitlab.com/oer/emacs-reveal/-/wikis/Sample-TTS-results [2] https://github.com/coqui-ai/TTS/ [3] https://huggingface.co/microsoft/speecht5_tts
Re: Suggestions for Text-To-Speech (TTS) from Org sources?
Thank you for the additional pointers! I still need to check out
promising combinations of those approaches, also options for MBROLA
(which is not free, but applies a custom AGPL-3.0-but-not-be-sold
license to the voices). ADRIANE is certainly fascinating.
Best wishes
Jens
On 2023-09-11, briangpowell wrote:
> * eSpeak seems to focus on small footprints & a "format synthesis" method
>
> * Suggest using Festival with MBrola:
>
> https://www.cstr.ed.ac.uk/projects/festival/mbrola.html
>
> https://www.cstr.ed.ac.uk/projects/festival/
>
> and/or just install FestivalLite:
>
> apt-get install -f -y --force-yes flite
>
> * Note EmacSpeak {mentioned in another email} is written by OrgMode user &
> programmer TV Raman--not sure EmacSpeak will help you at all; but it might
> be interesting for you
>
> ** Klaus Knopper distributes some very interesting free software that
> includes an audio-desktop called ADRIANE that maybe you can look at--I'd
> love to hear what you find out if you do:
>
> https://www.knopper.net/knoppix-adriane/index-en.html
>
> ** Knopper invented the "run Linux entirely from a cdrom" craze--which
> still is very useful in many ways--suggest you give Knoppix & Adriane a look
>
> On Mon, Sep 11, 2023 at 4:02 AM Christian Thäter wrote:
>
>> On Sun, 10 Sep 2023 16:39:26 +0200
>> Jens Lechtenboerger wrote:
>>
>> > On 2023-09-10, Ihor Radchenko wrote:
>> >
>> > > Jens Lechtenboerger writes:
>> > >
>> > >> does someone here produce audio via Text-To-Speech (TTS) from Org
>> > >> sources? I plan to do that in the context of emacs-reveal to
>> > >> generate voice-over for reveal.js presentations, with open
>> > >> questions [1] concerning my initial, experimental approach.
>> > >
>> > > Emacspeak is a mature Emacs solution for TTS. However, it aims blind
>> > > users, not presentations. Still,
>> > > http://tvraman.github.io/emacspeak/manual/Quick-Installation.html
>> > > might be a good starting point for TTS options.
>> >
>> > Thank you for the suggestion. With espeak this indeed pronounces
>> > numbers and abbreviations but its audio quality it not good enough
>> > for my purposes. I am looking for (near-) human voices...
>>
>> using mbrola is probably as good as possible with free software:
>> https://en.wikipedia.org/wiki/MBROLA
>>
>> still not perfect, but much better than the builtin voices of espeak or
>> festival (YYMV).
>>
>> >
>> > Best wishes
>> > Jens
>> >
>>
>>
>>
smime.p7s
Description: S/MIME cryptographic signature
Re: Suggestions for Text-To-Speech (TTS) from Org sources?
On 2023-09-10, Christian Thäter wrote: > On Sun, 10 Sep 2023 16:39:26 +0200 > Jens Lechtenboerger wrote: > >> On 2023-09-10, Ihor Radchenko wrote: >> >> > Jens Lechtenboerger writes: >> > >> >> does someone here produce audio via Text-To-Speech (TTS) from Org >> >> sources? I plan to do that in the context of emacs-reveal to >> >> generate voice-over for reveal.js presentations, with open >> >> questions [1] concerning my initial, experimental approach. >> > >> > Emacspeak is a mature Emacs solution for TTS. However, it aims blind >> > users, not presentations. Still, >> > http://tvraman.github.io/emacspeak/manual/Quick-Installation.html >> > might be a good starting point for TTS options. >> >> Thank you for the suggestion. With espeak this indeed pronounces >> numbers and abbreviations but its audio quality it not good enough >> for my purposes. I am looking for (near-) human voices... > > using mbrola is probably as good as possible with free software: > https://en.wikipedia.org/wiki/MBROLA > > still not perfect, but much better than the builtin voices of espeak or > festival (YYMV). This sounds promising. I’ll check it out. Many thanks Jens smime.p7s Description: S/MIME cryptographic signature
Re: Suggestions for Text-To-Speech (TTS) from Org sources?
On 2023-09-10, Ihor Radchenko wrote: > Jens Lechtenboerger writes: > >> does someone here produce audio via Text-To-Speech (TTS) from Org >> sources? I plan to do that in the context of emacs-reveal to >> generate voice-over for reveal.js presentations, with open questions >> [1] concerning my initial, experimental approach. > > Emacspeak is a mature Emacs solution for TTS. However, it aims blind > users, not presentations. Still, > http://tvraman.github.io/emacspeak/manual/Quick-Installation.html might > be a good starting point for TTS options. Thank you for the suggestion. With espeak this indeed pronounces numbers and abbreviations but its audio quality it not good enough for my purposes. I am looking for (near-) human voices... Best wishes Jens
Re: Suggestions for Text-To-Speech (TTS) from Org sources?
On 2023-09-09, briangpowell wrote: > I've turned OrgMode files into audio desktops > > It was pretty simple > > Just find the code that reveals what an icon is when you hover over it & > pipe it to some text-to-speech engine & then on to usual routes Thank you for the reply. In my case (GNU/Linux), I guess that the usual text-to-speech engine is espeak. I find its speech quality to be disappointing (much worse than the language models that I mentioned earlier). I am looking for (near-) human quality... Best wishes Jens
Suggestions for Text-To-Speech (TTS) from Org sources?
Dear all, does someone here produce audio via Text-To-Speech (TTS) from Org sources? I plan to do that in the context of emacs-reveal to generate voice-over for reveal.js presentations, with open questions [1] concerning my initial, experimental approach. Currently, I like the default model of Coqui-AI TTS [2] and Microsoft SpeechT5 [3] best. Any suggestions for free and open TTS implementations that produce even better results? Other models of Coqui-AI? The solution should work without GPU support, which seems to rule out Suno Bark [4]. The above models do not pronounce numbers/digits, and they fail to pronounce most acronyms. In a preprocessing step I could replace those. I use preprocessing anyways to get rid of Org markup that might confuse the language models. Anyone here who did that already? Maybe gruut [5] in conjunction with SSML [6] handling? Any other suggestions? Best wishes Jens [1] https://gitlab.com/oer/emacs-reveal/-/issues/20 [2] https://github.com/coqui-ai/TTS/ [3] https://huggingface.co/microsoft/speecht5_tts [4] https://github.com/suno-ai/bark [5] https://github.com/rhasspy/gruut [6] https://www.w3.org/TR/speech-synthesis11/
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
On 2023-09-03 08:53, Ihor Radchenko wrote: > Jens Schmidt writes: > >> Implemented in the next version of the patch, please check. >> > > Applied, onto main. Thanks!
Re: [RFC] Quoting property names in tag/property matches
On 2023-09-02 09:10, Ihor Radchenko wrote: > Jens Schmidt writes: >> - Even if we made "&" mandatory, it would not really solve the quoting >> problem, since the parser is rather hacky and other quoting and >> context issues would still be there. > > But at this point you are more familiar with that parser than I am, so > my idea does not seem to be viable. I think so, yes. That would mean that my pending patch could be merged, right? (Sorry for being impertinent here, but I'd like to get that thing off my stack.)
Re: Redoing the current tag/property parser in a real grammar [was: Re: [RFC] Quoting property names in tag/property matches]
On 2023-09-02 09:10, Ihor Radchenko wrote: > Jens Schmidt writes: >> This all calls for a proper parser, based on peg or bovine or whatever. >> Hopefully that parser would still keep backward compatibility, but >> that's probably wishful thinking. > > Backward compatibility will be easy - just leave the current code when > old query version is detected. We should better focus on the new syntax > in future and leave the current syntax as compatibility layer that will > be eventually deprecated. Agreed except for the deprecation part. I think Org should be big enough to have two parsers: One along the lines of the current one (infix, DWIM, easy to type) and one along the lines of org-ql (sexp, better extensible, more flexible, harder to type). Ideally, it should be even possible to embed the infix-one into the sexp-one. It should also be possible to put the current infix parser onto a more stable ground as well, based on a formal grammar, providing at least parentheses for grouping and negation, and that without breaking backward compatibility. Let's rephrase that way: If I were to redo the current parser as mentioned in the previous paragraph, would these changes "eventually be deprecated"? (Which doesn't necessarily mean that I promise to do so, of course.)
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
On 2023-08-27 09:43, Ihor Radchenko wrote:
> Samuel Loury writes:
>
>> IMHO, "-tag&-todo=TODO" is totally ok. I even imagine we could say that
>> & and | are forbidden to say anything else than AND and OR and people
>> would be ok with that.
>
> Actually, explicit & or | might be an easier way to not worry about
> escaping things. Except escaping & or | themselves.
> It might be the preferred way to put into the manual.
>
>> IOW, I wonder of the time and effort to deal with optional & is worth
>> it. WDYT?
>
> We cannot remove the optionality of &, because doing so will break
> existing user setups. But we can certainly change our recommendations in
> the manual.
>
> Though pure tag matcher makes more sense with implicit &:
> +tag1-tag2+tag3... vs +tag1&-tag2&+tag3
> Especially in the interactive agenda filters.
I feel it's a bit hard to reply to this message in the right places, so
I'll do a plain bottom post, sorry.
TL;DR:
- I think we cannot make "&" mandatory because of backward compatibility.
- Even if we made "&" mandatory, it would not really solve the quoting
problem, since the parser is rather hacky and other quoting and
context issues would still be there.
- But then I cannot see any real reason why we should recommend using
"&" in the manual.
- Finally, we should hope for and work towards a "real parser", as Ihor
has mentioned already in a previous post:
(beginning of thread)
https://list.orgmode.org/orgmode/9132e58f-d89e-f7df-bbe4-43d53a236...@vodafonemail.de/
(mentioning of peg)
https://list.orgmode.org/orgmode/87wmyendr7.fsf@localhost/
Details, as far as still required:
The whole tag/property query parser seems to have a long tradition. For
example, there is still that TODO-state special case that allows for
queries like this (example ripped from the manual):
work/WAITING
Same as work+TODO="WAITING"
So people *have* been worrying about a) query brevity and b) backward
compatibility, and I think we should do so as well.
Then the current parser is horribly ad-hoc-ish and, as a plain
regexp-based parser, context insensitive. For example, a tag regexp
match
{regexp}
is matched simply as
{[^}]+}
that is, you have no chance whatsoever to quote the closing curly
parenthesis. Likewise for double-quoted strings.
In other words, even if we make | or & mandatory, there will still
remain a lot of ambiguities stemming from the rest of the parser. And
I'm too lazy to think about how we could quote & in that whole picture.
(| is sort of handled already, but again in a completely
context-insensitive way.)
This all calls for a proper parser, based on peg or bovine or whatever.
Hopefully that parser would still keep backward compatibility, but
that's probably wishful thinking.
Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link?
On 2023-09-01, Ihor Radchenko wrote: > In theory, we might change the parser to treat anything like foo:bar or > or [[foo:bar]] as a link with "foo" protocol and "bar" URI. > And introduce [[::fig:something]] to allow explicit internal links. > But, despite simplifying the parser, it will certainly be a breaking > change. What would the implications be? FAQ 18.25 [1] contains a recipe to use colors on text like this: [[color:red][red]] Would that be a problem? Also, I use custom link types for additional markup like this: [[basic:https://en.wikipedia.org/wiki/Cache_(computing)][Caching]] In both cases, the part before the first colon is certainly no protocol. Besides, concerning wording in this discussion: A URIs may or may not embed a protocol. It contains a scheme, then a colon, then a scheme-specific part, see [2]. Best wishes Jens [1] https://orgmode.org/worg/org-faq.html [2] https://datatracker.ietf.org/doc/html/rfc3986
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
On 2023-08-31 10:08, Ihor Radchenko wrote: > Jens Schmidt writes: > >>> Implemented in the next version of the patch, please check. >> >> Gentle ping ... > > I was waiting for your comment on > https://list.orgmode.org/orgmode/874jklhqw2.fsf@localhost/ Ah, ok, sorry. I will give that branch a second thought and comment soon.
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
On 2023-08-26 14:54, Jens Schmidt wrote: > On 2023-08-26 14:22, Ihor Radchenko wrote: >> Looks good to me. > > Implemented in the next version of the patch, please check. Gentle ping ...
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
On 2023-08-26 14:22, Ihor Radchenko wrote:
> Jens Schmidt writes:
>> #+begin_example
>> boss\-prio="C"
>> boss\:prio="C"
>> boss\\prio="C"
>> #+end_example
>
> Looks good to me.
Implemented in the next version of the patch, please check.
From 11dc3ac4ff060f1ffb9dae7b35eabe526bbbc572 Mon Sep 17 00:00:00 2001
From: Jens Schmidt
Date: Thu, 24 Aug 2023 22:38:02 +0200
Subject: [PATCH] org-make-tags-matcher: Re-add quoting of property names
* lisp/org.el (org-make-tags-matcher):
* testing/lisp/test-org.el (test-org/map-entries): Move special cased
handling of LEVEL properties. Add tests for other special cased
properties TODO and CATEGORY.
* lisp/org.el (org-make-tags-matcher):
* doc/org-manual.org (Matching tags and properties):
* testing/lisp/test-org.el (test-org/map-entries): Re-add and extend
quoting of property names in search strings.
Link: https://orgmode.org/list/87h6oq2nu1@gmail.com
---
doc/org-manual.org | 22
lisp/org.el | 55
testing/lisp/test-org.el | 34 +
3 files changed, 68 insertions(+), 43 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 17b25fef4..249648566 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9320,21 +9320,21 @@ With the regular =<= operator, the search would handle entries without
an =EFFORT= property as having a zero effort and would include them in
the result as well.
-Currently, you can use only property names including alphanumeric
-characters, underscores, and minus characters in search strings. In
-addition, if you want to search for a property whose name starts with
-a minus character, you have to "quote" that leading minus character
-with an explicit positive selection plus character, like this:
+You can use all characters valid in property names when matching
+properties. However, you have to quote some characters in property
+names with backslashes when using them in search strings, namely all
+characters different from alphanumerics and underscores[fn:: If you
+quote alphanumeric characters or underscores with a backslash, that
+backslash is ignored.]. For example, to search for all entries having
+a property =boss-prio=, =boss:prio=, or =boss\prio=, respectively,
+with value =C=, use search strings
#+begin_example
-+-long-and-twisted-property-name-="foo"
+boss\-prio="C"
+boss\:prio="C"
+boss\\prio="C"
#+end_example
-#+texinfo: @noindent
-Without that extra plus character, the minus character would be taken
-to indicate a negative selection on search term
-=long-and-twisted-property-name-="foo"=.
-
You can configure Org mode to use property inheritance during
a search, but beware that this can slow down searches considerably.
See [[*Property Inheritance]], for details.
diff --git a/lisp/org.el b/lisp/org.el
index 50df1b2d9..78f8eb2e9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11328,15 +11328,14 @@ See also `org-scan-tags'."
"\\(?2:"
;; tag regexp match
"{[^}]+}\\|"
- ;; LEVEL property match. For sake of consistency,
- ;; recognize starred operators here as well. We do
- ;; not need to process them below, however, since
- ;; the LEVEL property is always present.
- "LEVEL\\(?3:" opre "\\)\\*?\\(?4:[0-9]+\\)\\|"
- ;; regular property match
+ ;; property match. Try to keep this subre generic
+ ;; and rather handle special properties like LEVEL
+ ;; and CATEGORY further below. This ensures that
+ ;; the same quoting mechanics can be used for all
+ ;; property names.
"\\(?:"
;; property name [1]
- "\\(?5:[[:alnum:]_-]+\\)"
+ "\\(?5:\\(?:[[:alnum:]_]+\\|[^[:space:]]\\)+\\)"
;; operator, optionally starred
"\\(?6:" opre "\\)\\(?7:\\*\\)?"
;; operand (regexp, double-quoted string,
@@ -11353,13 +11352,19 @@ See also `org-scan-tags'."
(start 0)
tagsmatch todomatch tagsmatcher todomatcher)
-;; [1] The minus characters in property names do *not* conflict
-;; with the exclusion operator above, since the mandatory
-;; following operator distinguishes these both cases.
-;; Accordingly, minus characters do not need any special quoting,
-;; even if https://orgmode.org/list/87jzv67k3p.fsf@localhost and
-;; commit 19b0e03f32c6032a60150fc6cb07c6f766cb3f6c suggest
-;; otherwise.
+;; [1] The history of this particular subre:
+;
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
On 2023-08-26 14:00, Ihor Radchenko wrote: > Jens Schmidt writes: >> On 2023-08-26 12:16, Ihor Radchenko wrote: >>> This actually feels rather cubersome. >> >> [...] I can >> provide a simpler example in the manual, but that's probably not >> what you meant :-) > > That's partially what I meant. > It would help to provide a simpler example first. How about a series of simpler examples then, like this: #+begin_example boss\-prio="C" boss\:prio="C" boss\\prio="C" #+end_example
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
On 2023-08-26 12:16, Ihor Radchenko wrote: > Jens Schmidt writes: >> #+begin_example >> -+-long-and-twisted-property-name-="foo" >> +\-long\=and\\twisted\:property\.name\*="foo" >> #+end_example > > This actually feels rather cubersome. That particular example looks awkward, but pls don't forget that users (mostly) have been happy without any option of quoting so far. IOW, there shouldn't be much to quote in real life. I can provide a simpler example in the manual, but that's probably not what you meant :-) > I am now wondering if we could instead do something like > "-long=and\twisted:property.name*"="foo" > Then, we will just have to quote the " itself, not all > non-alphanumerics. > > Although, using " might be tricky. Agreed. It introduces more context, and longer context, than a simple backslash. Plus double quotes are already used for other purposes in the larger regexp, which could introduce more ambiguities. Finally, a term "foo-bar"="foo-bar" looks, er, tautologically? at best.
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
On 2023-08-24 10:52, Jens Schmidt wrote:
> On 2023-08-24 09:32, Ihor Radchenko wrote:
>> I prefer (B). And we will need to allow escaping of the "\" itself. Like
>> \\.
>
> OK. Since backslash is not used yet in the rest of the regexp, (B)
> should be rather edge-case-free. So the corresponding subre to match
> property names would look like
>
> \(?5:\(?:[[:alnum:]]+\|\\[^[:space:]]\)+\)
>
> IOW, backslash quotes everything except whitespace, which by definition
> cannot be part of a property name.
>
> Will start on this, but with tests and documentation this might take
> some time.
Here comes a first patch ... please check.From 830750bfa10b52ac77abe8af1f2789057f9101c1 Mon Sep 17 00:00:00 2001
From: Jens Schmidt
Date: Thu, 24 Aug 2023 22:38:02 +0200
Subject: [PATCH] org-make-tags-matcher: Re-add quoting of property names
* lisp/org.el (org-make-tags-matcher):
* testing/lisp/test-org.el (test-org/map-entries): Move special cased
handling of LEVEL properties. Add tests for other special cased
properties TODO and CATEGORY.
* lisp/org.el (org-make-tags-matcher):
* doc/org-manual.org (Matching tags and properties):
* testing/lisp/test-org.el (test-org/map-entries): Re-add and extend
quoting of property names in search strings.
Link: https://orgmode.org/list/87h6oq2nu1@gmail.com
---
doc/org-manual.org | 20 +++
lisp/org.el | 55
testing/lisp/test-org.el | 34 +
3 files changed, 66 insertions(+), 43 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 17b25fef4..10a03b344 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9320,21 +9320,19 @@ With the regular =<= operator, the search would handle entries without
an =EFFORT= property as having a zero effort and would include them in
the result as well.
-Currently, you can use only property names including alphanumeric
-characters, underscores, and minus characters in search strings. In
-addition, if you want to search for a property whose name starts with
-a minus character, you have to "quote" that leading minus character
-with an explicit positive selection plus character, like this:
+You can use all characters valid in property names when matching
+properties. However, you have to quote some characters in property
+names with backslashes when using them in search strings, namely all
+characters different from alphanumerics and underscores[fn:: If you
+quote alphanumeric characters or underscores with a backslash, that
+backslash is ignored.]. For example, to search for all entries having
+a property =-long=and\twisted:property.name*= with value =foo=, use
+search string
#+begin_example
-+-long-and-twisted-property-name-="foo"
+\-long\=and\\twisted\:property\.name\*="foo"
#+end_example
-#+texinfo: @noindent
-Without that extra plus character, the minus character would be taken
-to indicate a negative selection on search term
-=long-and-twisted-property-name-="foo"=.
-
You can configure Org mode to use property inheritance during
a search, but beware that this can slow down searches considerably.
See [[*Property Inheritance]], for details.
diff --git a/lisp/org.el b/lisp/org.el
index 50df1b2d9..78f8eb2e9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11328,15 +11328,14 @@ See also `org-scan-tags'."
"\\(?2:"
;; tag regexp match
"{[^}]+}\\|"
- ;; LEVEL property match. For sake of consistency,
- ;; recognize starred operators here as well. We do
- ;; not need to process them below, however, since
- ;; the LEVEL property is always present.
- "LEVEL\\(?3:" opre "\\)\\*?\\(?4:[0-9]+\\)\\|"
- ;; regular property match
+ ;; property match. Try to keep this subre generic
+ ;; and rather handle special properties like LEVEL
+ ;; and CATEGORY further below. This ensures that
+ ;; the same quoting mechanics can be used for all
+ ;; property names.
"\\(?:"
;; property name [1]
- "\\(?5:[[:alnum:]_-]+\\)"
+ "\\(?5:\\(?:[[:alnum:]_]+\\|[^[:space:]]\\)+\\)"
;; operator, optionally starred
"\\(?6:" opre "\\)\\(?7:\\*\\)?"
;; operand (regexp, double-quoted string,
@@ -11353,13 +11352,19 @@ See also `org-scan-tags'."
(start 0)
tagsmatch todomatch tagsmatcher todomatcher)
-;; [1] The minus characters in property names do *not* conflict
-;; with the exclusion operator above, since the m
Re: [BUG] "make check" reports a failure on test-org/insert-heading @ d5ee33f (this time with Emacs 29)
On 2023-08-24 14:24, Ihor Radchenko wrote: > Jens Schmidt writes: > >> Would you mind if I added a test that explicitly and with some nice >> error message tests for that condition? I.e. if some unwary user >> strips off trailing whitespace in test-org.el, that test would fail >> with a reasonable message. > > There is no universal rule when and when not to add trailing spaces in > the tests. Not sure what you mean by that, but some tests rely on trailing spaces and fail when these are not present. An explicit test on that would make the issue more visible. See below for what I mean. The only (?) downside is that this catches such errors in test-org.el only, and not in all the other tests, many of which also contain (on purpose or inadvertently) trailing whitespace: [org-mode]$ grep -l $'[ \t]$' testing/lisp/* testing/lisp/test-ob-C.el testing/lisp/test-ob-R.el testing/lisp/test-ob-fortran.el testing/lisp/test-org-agenda.el testing/lisp/test-org-element.el testing/lisp/test-org-fold.el testing/lisp/test-org-footnote.el testing/lisp/test-org.el diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index e33f500a3..e49c2f957 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -9363,6 +9363,16 @@ two (string-match-p "\\`Invalid format.*%2" err-text)) err) + +;;; Meta-test on Trailing Whitespace not Being Deleted + +(ert-deftest test-org/trailing-whitespace-deleted () +"Ensure trailing whitespace did not get deleted in this file." + (should + (equal "Do not delete trailing whitespace --> + in this file." + "Do not delete trailing whitespace --> \n in this file."))) + (provide 'test-org) ;;; test-org.el ends here If the blank after the arrow gets removed, this test fails as: Test test-org/trailing-whitespace-deleted condition: (ert-test-failed ((should (equal "Do not delete trailing whitespace --> in this file." "Do not delete trailing whitespace --> in this file.")) :form (equal "Do not delete trailing whitespace --> in this file." "Do not delete trailing whitespace --> in this file.") :value nil :explanation (arrays-of-different-length 62 63 "Do not delete trailing whitespace --> in this file." "Do not delete trailing whitespace --> in this file." first-mismatch-at 37))) FAILED 1068/1095 test-org/trailing-whitespace-deleted (0.000193 sec) [...] 1 unexpected results: FAILED test-org/trailing-whitespace-deleted
Re: [BUG] "make check" reports a failure on test-org/insert-heading @ d5ee33f (this time with Emacs 29)
On 2023-08-24 13:41, Ihor Radchenko wrote: > Jens Schmidt writes: > >> Seems the insert-heading-issue is still struggling, this time during >> a "make check" @ d5ee33fed8dd80d3f9f9811d86a73827fde80780 using Emacs 29: >> ... >>FAILED 998/1094 test-org/insert-heading (0.018306 sec) at >> ../lisp/test-org.el:1845 > > I cannot reproduce on my system. Using Emacs 29. > Our CI tests are also not failing. Not a bug, my bad: I keep forgetting about `delete-trailing-whitespace' on my `before-save-hook'. Would you mind if I added a test that explicitly and with some nice error message tests for that condition? I.e. if some unwary user strips off trailing whitespace in test-org.el, that test would fail with a reasonable message.
[BUG] "make check" reports a failure on test-org/insert-heading @ d5ee33f (this time with Emacs 29)
Seems the insert-heading-issue is still struggling, this time during
a "make check" @ d5ee33fed8dd80d3f9f9811d86a73827fde80780 using Emacs 29:
Test test-org/insert-heading condition:
(ert-test-failed
((should
(equal "* 1\n** 1.1\n** 1.2\n*\n* 2"
(org-test-with-temp-text "* 1\n** 1.1\n** 1.2\n* 2" ...
...)))
:form
(equal "* 1\n** 1.1\n** 1.2\n*\n* 2"
#("* 1\n** 1.1\n** 1.2\n* \n* 2" 0 2
(face org-level-1)
2 3
(face org-level-1)
4 5
(face org-level-2)
5 7
(face org-level-2)
7 10
(face org-level-2)
11 12
(face org-level-2)
12 14
(face org-level-2)
14 17
(face org-level-2)
21 23
(face org-level-1)
23 24
(face org-level-1)))
:value nil :explanation
(arrays-of-different-length 23 24 "* 1\n** 1.1\n** 1.2\n*\n* 2"
#("* 1\n** 1.1\n** 1.2\n* \n* 2" 0 2
(face org-level-1)
2 3
(face org-level-1)
4 5
(face org-level-2)
5 7
(face org-level-2)
7 10
(face org-level-2)
11 12
(face org-level-2)
12 14
(face org-level-2)
14 17
(face org-level-2)
21 23
(face org-level-1)
23 24
(face org-level-1))
first-mismatch-at 19)))
FAILED 998/1094 test-org/insert-heading (0.018306 sec) at
../lisp/test-org.el:1845
Re: [BUG] Compilation warnings when making main @ d5ee33fed8dd80d3f9f9811d86a73827fde80780
On 2023-08-24 13:18, Ihor Radchenko wrote: > Jens Schmidt writes: > >> Compiling /home/jschmidt/work/org-mode/lisp/org-element-ast.el... >> >> In org-element--properties-mapc: >> org-element-ast.el:628:25:Warning: ‘not’ called with 3 args, but requires 1 >> org-element-ast.el:628:30:Warning: reference to free variable ‘eq’ > > I also saw them. They do not make any sense. And they do not appear in > Emacs 29. Sorry for the hassle, I have been indeed using the wrong Emacs here.
[BUG] Compilation warnings when making main @ d5ee33fed8dd80d3f9f9811d86a73827fde80780
Compiling /home/jschmidt/work/org-mode/lisp/org-cycle.el... Compiling /home/jschmidt/work/org-mode/lisp/org-datetree.el... Compiling /home/jschmidt/work/org-mode/lisp/org-duration.el... Compiling /home/jschmidt/work/org-mode/lisp/org-element-ast.el... In org-element--properties-mapc: org-element-ast.el:628:25:Warning: ‘not’ called with 3 args, but requires 1 org-element-ast.el:628:30:Warning: reference to free variable ‘eq’ Compiling /home/jschmidt/work/org-mode/lisp/org-element.el... Compiling /home/jschmidt/work/org-mode/lisp/org-entities.el... Compiling /home/jschmidt/work/org-mode/lisp/org-faces.el... Compiling /home/jschmidt/work/org-mode/lisp/org-feed.el...
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
On 2023-08-24 09:32, Ihor Radchenko wrote: > Jens Schmidt writes: >> Some obvious choice would be a simpler single backslash >> >> (B) "\-" => "-" > > I prefer (B). And we will need to allow escaping of the "\" itself. Like > \\. OK. Since backslash is not used yet in the rest of the regexp, (B) should be rather edge-case-free. So the corresponding subre to match property names would look like \(?5:\(?:[[:alnum:]]+\|\\[^[:space:]]\)+\) IOW, backslash quotes everything except whitespace, which by definition cannot be part of a property name. Will start on this, but with tests and documentation this might take some time.
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
On 2023-08-23 16:00, Jens Schmidt wrote: > Given the property name syntax in > > https://orgmode.org/worg/org-syntax.html#Node_Properties > > the subre in `org-make-tags-matcher' to match property names > should then look similar to > > "\\(?5:[[:alnum:]_]+\\|:[^[:space:]]+?:\\)" > > , right (colons being stripped off later)? I'm really asking > about the trailing plus signs here, but these do not seem to > make sense in property queries. Yet another edge-case: In the Org syntax definition a property name is really delimited by a "colon-whitespace" sequence. This takes out the ambiguity whether a property name is defined non-greedily :[^[:space:]]+?: or greedily :[^[:space:]]+: I'm too lazy right now to think about the consequences, but I hope this makes a difference only for really weird property matches, like this: :foo:=1+:bar:=2 This would be parsed non-greedily as FOO == 1 && BAR == 2 or greedily as FOO:=1+:BAR == 2 I'd go for non-greedily defined property names.
Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]
> On 2023-08-23 12:31, Ihor Radchenko wrote: > >> Jens, we got an edge case with "-", after all. >> >> What is happening here is that the new parser >> (https://orgmode.org/list/9132e58f-d89e-f7df-bbe4-43d53a236...@vodafonemail.de) >> treats the above match string as >> >> property "tag-TODO" not equal "TODO" >> >> instead of >> >> not tag equal "tag" and not TODO equal "TODO" Right. And you already provided in the other branch of this discussion a direction how to resolve that: > [...] In case of ambiguity TAG1-TAG2-TAG3-PROP="" like we see here, we > should prefer multiple shorter conditions: TAG1 && -TAG2 && -TAG3 && PROP="" > > When "TAG1-TAG2" is an actual tag name with dash, we may allow escaping. But I'd like to clarify that. From the Org syntax https://orgmode.org/worg/org-syntax.html#Headings I understood that tag names cannot contain minus characters, and `org-tag-re' does not match any, either. So we are talking about property names only, right? At least I'll do so in the following ... Then the question is what quoting scheme to use for property names. The previous one used before my commit f689eb4 (A) "\\-" => "-" never has been documented and never has been working properly, since the *matching* of these was done on *prop* names, but the *unescaping* on *tag* names. So we are basically free to come up with something new. Some obvious choice would be a simpler single backslash (B) "\-" => "-" And when I have been "fixing" the parser, I also thought that (C) ":...:" => "..." would give a nice and somewhat logical quoting scheme. That is, if a property name contains "special" characters, it could be surrounded by colons to quote these. So we have so far quoting schemes A, B, C, with my preference being C. Any other proposals? I'll focus on C, where there is one big cave-at: The main regexp in `org-make-tags-matcher' also allows for (undocumented) colons as inclusive search term separator: ;; exclusion and inclusion (the latter being implicit) "\\(?1:[-+:]\\)?" ^ Which collides with the colons used by quoting scheme C. I'd rather sacrifice that use of colon as search term separator, TBH. Given the property name syntax in https://orgmode.org/worg/org-syntax.html#Node_Properties the subre in `org-make-tags-matcher' to match property names should then look similar to "\\(?5:[[:alnum:]_]+\\|:[^[:space:]]+?:\\)" , right (colons being stripped off later)? I'm really asking about the trailing plus signs here, but these do not seem to make sense in property queries. What do you think?
Re: [BUG?] Matching tags: & operator no more implicit between tags and special property
On 2023-08-23 12:31, Ihor Radchenko wrote: > Jens, we got an edge case with "-", after all. > > What is happening here is that the new parser > (https://orgmode.org/list/9132e58f-d89e-f7df-bbe4-43d53a236...@vodafonemail.de) > treats the above match string as > > property "tag-TODO" not equal "TODO" > > instead of > > not tag equal "tag" and not TODO equal "TODO" Mails crossing. Let's continue your thread after some cool down.
Re: [BUG?] Matching tags: & operator no more implicit between tags and special property
Thanks for the detailed report!
On 2023-08-23 09:57, Samuel Loury wrote:
> The following tags query used to implicitly behave as a AND
> "-tag-TODO=\"TODO\"".
> Before commit f689eb44f175fbbdc4e8ef0ad6f5201b10863438, this showed only
> "nothing", as expected.
That was my short-sighted attempt to allow for unquoted minus signs
in property names, and your query right now matches all entries having
a property "tag-TODO" different from "TODO". TBH, I didn't think
about your use case, where two negations are concatenated directly
after each other.
OTOH, the unquoting ("\\-") that has been in place before above commit
was broken, which might serve as a hint that few to none actually use
minus signs in property names, at least not in queries.
Ihor, WDYT? I can (with the necessary delay to allow for proper
testing) revert to some sort of quoting in property names which would
allow for Samuel's use case again.
Re: Or probably just fix the org-ctags hook functions?
On 2023-08-11 23:48, Ihor Radchenko wrote: - If you run into this issue, the real pain is to understand what's going on, since org-ctags might get loaded in surprising ways. So probably we should make that easier. The quick fix is unsetting `help-enable-completion-autoload'. Unfortunately, that isn't easy to understand, either. And I do not think that we should be in rush pushing workarounds - org-ctags has been around for a long time in its existing state. I'd prefer to first figure out the general policy for such situations. Right, but even though org-ctags has been stable, something else *has* changed that let's this issue pop up now. For Nick it seems to be the Emacs version, for me I'm pretty sure the recent upgrade from Org 9.5 to 9.6 in Debian testing, with Emacs unchanged on version 28. Anyway, probably let's just wait whether more complaints on that will come in.
Re: Or probably just fix the org-ctags hook functions?
On 2023-08-11 19:01, Nick Dokos wrote: Sure, but we should not reject Jens' proposal just because of this argument. We can use the suggestions to improve org-ctags itself, after it is explicitly loaded. Absolutely. My disagreement was only with the part that I quoted, in particular the "Probably the problem is not the side-effects done by loading =org-ctags= ..." part: from my POV, that is *exactly* the problem which I would like to see addressed. I was trying to provide some facts that could help deciding on this. And to find some compromise here that would fit all users and sizes. More notes and another compromise: - The general discussion in that other branch about all Org libraries, ever, is IMO of general interest but doesn't help users that run into this issue in short term. I'd focus on this single library instead to get a fix soon, and not only in main. - I understand both "no-breaking-changes" and "no-side-effects" positions. Personally, I'd even tend to the "no-side-effects" position. - If you run into this issue, the real pain is to understand what's going on, since org-ctags might get loaded in surprising ways. So probably we should make that easier. How about *not* using the current functions `org-ctags-find-tag' `org-ctags-ask-rebuild-tags-file-then-find-tag' `org-ctags-ask-append-topic' as default value for `org-ctags-open-link-functions', but rather only function `org-ctags-warn-about-enabling-ctags' defined as follows: (defun org-ctags-warn-about-enabling-ctags ( _) (warn "You enabled (on purpose or by accident) org-ctags. If that was not your intention, or if you really only want to open links as you always have been used to, use customize to disable function `org-ctags-warn-about-enabling-ctags' in variable `org-ctags-open-link-functions'. Otherwise, you might want to use customize to disable function `org-ctags-warn-about-enabling-ctags' in `org-ctags-open-link-functions' and instead enable the previous default functions `org-ctags-find-tag', `org-ctags-ask-rebuild-tags-file-then-find-tag', and `org-ctags-ask-append-topic'. Note that in a future Org version automatic enabling of org-ctags might be obsoleted, so consider explicitly enabling it by adding (require 'org-ctags) (org-ctags-enable) to your Emacs initialization file if you actually want to use it.") (remove-hook 'org-open-link-functions #'org-ctags-warn-about-enabling-ctags)) The last line would take care about getting this warning at most once per Emacs session. In addition redefine function `org-ctags-enable' to add a test on `org-ctags-open-link-functions' as follows: (defun org-ctags-enable () (when org-ctags-open-link-functions (put 'org-mode 'find-tag-default-function 'org-ctags-find-tag-at-point) (setq org-ctags-enabled-p t) (dolist (fn org-ctags-open-link-functions) (add-hook 'org-open-link-functions fn t which makes library loading free of side-effect if variable org-ctags-open-link-functions equals nil. That way: - Users who previously have customized the variable are not affected at all by the change. - All others understand better what's going on and can decide either way. If they decide against org-ctags, and customize the variable accordingly, they will have no side-effects from org-ctags in the future. - Any future general solution could resolve this in a more beautiful and, um, general way.
Re: Or probably just fix the org-ctags hook functions? (was: Should we accept breaking changes ...)
On 2023-08-08 10:48, Ihor Radchenko wrote: The situation is a bit more complex. To make it even more complex, here a different point of view. Sorry, I don't have any earlier mails ready I could reply to ... * TL;DR Probably the problem is not the side-effects done by loading =org-ctags=, but rather that these hook function from =org-ctags= try to do their job when the environment is not really ready for them, i.e. when there is no known tag file around. * Full Story I tried to get this thing running. Some issues and observations I came across: 1. When I execute function `org-ctags-create-tags' in file =org-manual.org= of Org =main=, an empty =TAGS= file gets created. Presumably because the asterisk in the generated command line is quoted and the warning generated by that (=cannot open source file "/home/jschmidt/work/org-mode/doc/*"=) is not shown in Emacs: #+begin_example ctags-exuberant --langdef=orgmode --langmap=orgmode:.org \ --regex-orgmode="/<<([^>]+)>>/\1/d,definition/" \ -f "/home/jschmidt/work/org-mode/doc/TAGS" -e -R \ "/home/jschmidt/work/org-mode/doc/*" ^^^^^^ #+end_example If I execute the statement on the command line w/o the quotes on the final parameter, I get a non-empty =TAGS= file. Besides that, I somehow doubt that =-R .../*= (=-R= meaning recursive operation) makes actually sense, this probably should be just =-R ...= instead. Besides *that* the following sexps from the function look fishy: #+begin_src emacs-lisp (expand-file-name (concat dir-name "/TAGS")) (expand-file-name (concat dir-name "/*")) #+end_src Why not =(expand-file-name "TAGS" dir-name)=? 2. When one looks at the =TAGS= file generated thus, one immediately notices that the regular expression from parameter =--regex-orgmode= used to match these <> matches also non-targets, like in the following example section: #+begin_example 1. one item 2. <>another item Here we refer to item [[target]]. #+end_example But that is probably intentional or not avoidable. Probably these are even valid Org targets? Ok, that was more or less cheap criticism. Or a bug report? Anyway, what is more interesting is: 3. When one later visits =org-manual.org=,\\ and there is a =TAGS= file in that directory,\\ and =org-ctags= previously has been loaded, then,\\ by virtue of the following snippet from =org-ctags.el=: #+begin_src emacs-lisp (add-hook 'org-mode-hook (lambda () (when (and org-ctags-enabled-p (buffer-file-name)) ;; Make sure this file's directory is added to default ;; directories in which to search for tags. (let ((tags-filename (expand-file-name (concat (file-name-directory (buffer-file-name)) "/TAGS" (when (file-exists-p tags-filename) (visit-tags-table tags-filename)) #+end_src that =TAGS= file gets automatically visited, meaning that future tag look-ups with =C-c C-o= do not ask about any tag files to load. (Yes, there is again that funny =(expand-file-name (concat ...))= pattern used above.) 4. From that and also from the header documentation: #+begin_example ;; When you click on a link "[[foo]]" and org cannot find a ;; matching "<>" in the current buffer, the tags ;; facility will take over. The file TAGS in the active ^^^ ;; directory is examined to see if the ^ ;; tags facility knows about "<>" in any other files. ;; If it does, the matching file will be opened and the ;; cursor will jump to the position of "<>" in that ;; file. #+end_example I conclude that the whole =org-ctags= functionality is based on the assumption that a =TAGS= file lives in the working directory of the currently visited Org mode file. Why not test for that condition in the hook functions: #+begin_src emacs-lisp org-ctags-find-tag org-ctags-ask-rebuild-tags-file-then-find-tag org-ctags-rebuild-tags-file-then-find-tag org-ctags-ask-append-topic org-ctags-append-topic org-ctags-ask-visit-buffer-or-file org-ctags-visit-buffer-or-file org-ctags-fail-silently #+end_src in some way or other, probably also testing variable =tags-file-name=, and just skip their execution returning =nil=, if the environment does not seem to be ready for a tag search. Then regular link operation would kick in. Of course, that is all based on educated guesses and ad-hoc poking in the code, not on long-term usage. Is there a known user of =org-ctags= who one could ask? I think the number of people using =org-ctags= is much smaller than the number of people not
Re: [BUG] `org-open-at-point' surprisingly asks for tags table [9.7-pre (release_9.6.7-640-ga18ebc @ /home/jschmidt/work/org-mode/lisp/)]
Sorry, just followed that recent side-effect-thread to the root https://list.orgmode.org/orgmode/87o7omg4ie@alphaville.usersys.redhat.com/ and found that everything already got documented. It was that thread that triggered my bug report as an example of a particular nasty side effect.
[BUG] `org-open-at-point' surprisingly asks for tags table [9.7-pre (release_9.6.7-640-ga18ebc @ /home/jschmidt/work/org-mode/lisp/)]
make EMACS=../emacs-master/src/emacs vanilla Create a new Org-mode buffer with the following contents: -- <> [[test][test link]] -- Position point on the link then type C-c C-o: Point jumps to the link as expected. Now type C-h f org- TAB C-g Reposition point on link, type C-c C-o. The following prompt pops up: Visit tags table (default TAGS): ... which is annoying. It took me some time to realize that the innocent sequence C-h f org- TAB C-g autoloads org-ctags, which hooks into `org-open-link-functions' through `org-ctags-enable'.
Re: org-agenda queries for absent properties
On 2023-08-07 13:53, Ihor Radchenko wrote:
Thanks for reviewing.
- If the comparison value is a plain number, a numerical comparison is
done, and the allowed operators are =<=, ===, =>=, =<==, =>==, and
- =<>=.
+ =<>=. As synonym for the equality operator there is also , as
+ synonyms for the inequality operator there are =!== and =/==.
I'd mention which operator is "equality" and "inequality" to avoid
ambiguity:
As a synonym for the equality operator ===, there is also ; =!== and
=/== are synonyms of inequality operator =<>=.
Done.
- (let* ((gv (pcase (upcase (match-string 5 term))
+ (let* (;; Convert property name to an Elisp
+;; accessor for that property (aka. as
+;; getter value?).
>
> Is there any specific reason why you put question mark in the comment
> here?
I was trying to decipher and document the acronyms used for the
let-bindings in that `let*' sexp. I think I got them right but was
unsure about the "gv". Removed the question mark, let's just assume
that "gv" means "getter value" and be done with it.
Updated patch attached.From 6e98356dfaf3466288398ff4ecee7fd147c32a20 Mon Sep 17 00:00:00 2001
From: Jens Schmidt
Date: Sun, 6 Aug 2023 16:38:04 +0200
Subject: [PATCH] org-make-tags-matcher: Add starred property operators, fix
quoting
* lisp/org.el (org-make-tags-matcher): Add starred property operators.
Recognize additional operators "==", "!=", "/=". Clean up and
document match term parsing. Remove needless and buggy unquoting of
minus characters in property and tag names.
(org-op-to-function): Recognize additional inequality operator "/=".
* doc/org-manual.org (Matching tags and properties): Add documentation
on starred and additional operators. Document allowed characters in
property names and handling of minus characters in property names.
* testing/lisp/test-org.el (test-org/map-entries): Add tests for
starred and additional operators. Add tests for property names
containing minus characters.
* etc/ORG-NEWS: (~org-tags-view~ supports more property operators):
Add announcement on starred and additional operators.
Link: https://orgmode.org/list/9132e58f-d89e-f7df-bbe4-43d53a236...@vodafonemail.de
---
doc/org-manual.org | 35 +++-
etc/ORG-NEWS | 10 +++-
lisp/org.el | 120 ---
testing/lisp/test-org.el | 64 -
4 files changed, 192 insertions(+), 37 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..dc9f552e5 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9246,16 +9246,18 @@ When matching properties, a number of different operators can be used
to test the value of a property. Here is a complex example:
#+begin_example
-+work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
++work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<*2
+With={Sarah\|Denny}+SCHEDULED>="<2008-10-11>"
#+end_example
+#+cindex: operator, for property search
#+texinfo: @noindent
The type of comparison depends on how the comparison value is written:
- If the comparison value is a plain number, a numerical comparison is
done, and the allowed operators are =<=, ===, =>=, =<==, =>==, and
- =<>=.
+ =<>=. As a synonym for the equality operator ===, there is also
+ ; =!== and =/== are synonyms of the inequality operator =<>=.
- If the comparison value is enclosed in double-quotes, a string
comparison is done, and the same operators are allowed.
@@ -9273,6 +9275,13 @@ The type of comparison depends on how the comparison value is written:
is performed, with === meaning that the regexp matches the property
value, and =<>= meaning that it does not match.
+- All operators may be optionally followed by an asterisk =*=, like in
+ =<*=, =!=*=, etc. Such /starred operators/ work like their regular,
+ unstarred counterparts except that they match only headlines where
+ the tested property is actually present. This is most useful for
+ search terms that logically exclude results, like the inequality
+ operator.
+
So the search string in the example finds entries tagged =work= but
not =boss=, which also have a priority value =A=, a =Coffee= property
with the value =unlimited=, an =EFFORT= property that is numerically
@@ -9280,6 +9289,28 @@ smaller than 2, a =With= property that is matched by the regular
expression =Sarah\|Denny=, and that are scheduled on or after October
11, 2008.
+Note that the test on the =EFFORT= property uses operator =<*=, so
+that the search result will include only entries that actually have an
+=EFFORT= property defined and with numerical value
Re: org-agenda queries for absent properties
On 2023-08-06 11:19, Jens Schmidt wrote:
I
will also add tests for matching property names having minuses and then
we can see how it goes.
Went well. With a property name regexp
"\\(?5:[[:alnum:]_-]+\\)"
and the following Org file
--
* H1 :BAR:
:PROPERTIES:
:TEST-FOO: 1
:END:
* H2 :FOO:
:PROPERTIES:
:TEST-FOO: 2
:END:
* H3 :BAR:
:PROPERTIES:
:-FOO: 1
:END:
* H4 :FOO:
:PROPERTIES:
:-FOO: 2
:END:
* H5
--
the search expressions "TEST-FOO!=*0-FOO" and "-FOO+TEST-FOO!=*0" work
as expected, finding only the first heading.
The expression "-FOO!=*0-FOO" does *not* work, though, since the leading
minus in the property name is gobbled by the greedy inclusion/exclusion
subexp "\\(?1:[-+:]\\)?". However, the remedy is simple: Add an
explicit plus sign: "+-FOO!=*0-FOO".
Documented that in the Org manual, added tests, looks good. Please
check.
From cb3268c8b1c69371589a9aa44a96d33e29aedbb1 Mon Sep 17 00:00:00 2001
From: Jens Schmidt
Date: Sun, 6 Aug 2023 16:38:04 +0200
Subject: [PATCH] org-make-tags-matcher: Add starred property operators, fix
quoting
* lisp/org.el (org-make-tags-matcher): Add starred property operators.
Recognize additional operators "==", "!=", "/=". Clean up and
document match term parsing. Remove needless and buggy unquoting of
minus characters in property and tag names.
(org-op-to-function): Recognize additional inequality operator "/=".
* doc/org-manual.org (Matching tags and properties): Add documentation
on starred and additional operators. Document allowed characters in
property names and handling of minus characters in property names.
* testing/lisp/test-org.el (test-org/map-entries): Add tests for
starred and additional operators. Add tests for property names
containing minus characters.
* etc/ORG-NEWS: (~org-tags-view~ supports more property operators):
Add announcement on starred and additional operators.
Link: https://orgmode.org/list/9132e58f-d89e-f7df-bbe4-43d53a236...@vodafonemail.de
---
doc/org-manual.org | 35 +++-
etc/ORG-NEWS | 10 +++-
lisp/org.el | 120 ---
testing/lisp/test-org.el | 64 -
4 files changed, 192 insertions(+), 37 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..4252d7ac3 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9246,16 +9246,18 @@ When matching properties, a number of different operators can be used
to test the value of a property. Here is a complex example:
#+begin_example
-+work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
++work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<*2
+With={Sarah\|Denny}+SCHEDULED>="<2008-10-11>"
#+end_example
+#+cindex: operator, for property search
#+texinfo: @noindent
The type of comparison depends on how the comparison value is written:
- If the comparison value is a plain number, a numerical comparison is
done, and the allowed operators are =<=, ===, =>=, =<==, =>==, and
- =<>=.
+ =<>=. As synonym for the equality operator there is also , as
+ synonyms for the inequality operator there are =!== and =/==.
- If the comparison value is enclosed in double-quotes, a string
comparison is done, and the same operators are allowed.
@@ -9273,6 +9275,13 @@ The type of comparison depends on how the comparison value is written:
is performed, with === meaning that the regexp matches the property
value, and =<>= meaning that it does not match.
+- All operators may be optionally followed by an asterisk =*=, like in
+ =<*=, =!=*=, etc. Such /starred operators/ work like their regular,
+ unstarred counterparts except that they match only headlines where
+ the tested property is actually present. This is most useful for
+ search terms that logically exclude results, like the inequality
+ operator.
+
So the search string in the example finds entries tagged =work= but
not =boss=, which also have a priority value =A=, a =Coffee= property
with the value =unlimited=, an =EFFORT= property that is numerically
@@ -9280,6 +9289,28 @@ smaller than 2, a =With= property that is matched by the regular
expression =Sarah\|Denny=, and that are scheduled on or after October
11, 2008.
+Note that the test on the =EFFORT= property uses operator =<*=, so
+that the search result will include only entries that actually have an
+=EFFORT= property defined and with numerical value smaller than 2.
+With the regular =<= operator, the search would handle entries without
+an =EFFORT= property as having a zero effort and would include them in
+the result as well.
+
+Currently, you can use only property names including alphanumeric
+char
Re: org-agenda queries for absent properties
On 2023-08-06 09:55, Ihor Radchenko wrote:
But from here it gets more intersting:
- The code uses subre "-" in property names to (supposedly) allow
for inclusion of minus characters in property names, which (probably)
could be confused with term negation.
Not probably. It is known to be confused.
https://orgmode.org/list/87jzv67k3p.fsf@localhost
Right. But the issue back then appeared because the subre for property
names does not match minus characters, just alnums and underscores:
\\([[:alnum:]_]+\\)
What I'm trying to convey is: If we match plain minus characters in
above subre, these will be greedily goobled up including any following
operator, which makes the whole thing uniquely an operator term. If
there is no following operator, but something else, the whole regexp
backtracks and (hopefully) matches a following negative term.
- Even more, IMO one could do away completely with the minus-quoting and
unquoting, since the overall regexp should allow for unambiguously
matching minus characters both
+ in {tag regexps} (because of "{[^}]+}" gobbling them) and
+ in property names (because a property name must always be followed
by some operator)
*without* them getting confused with term negation.
Or do I miss something here? A cursory test with sth like
+foo-bar="xxx"-patchday=202302
seems to work fine.
Agree.
Ah, OK. I thought you wouldn't. Let me redo this thing as I think it
is correct (including let-binding common subres as you suggested). I
will also add tests for matching property names having minuses and then
we can see how it goes.
Re: org-agenda queries for absent properties
On 2023-08-02 08:45, Ihor Radchenko wrote:
> `rx' would be great.
> But even adding comments like in your example would be an improvement.
Since the future of this code snippet seems to be uncertain I went for
comments only.
And I thought I was pretty much done when I noticed at least one major
issues in the existing code, so I decided to go with a prerelease first
plus some notes and questions.
So there will be a follow up to the attached patch, and I leave it to
you whether you give it already a review or not. But I'd ask you for
your opinion on the following notes, where the first few should be
uncritical:
- I used "\(?NUM: ... \)" constructs to explicitly number the subres.
Hope this is OK w.r.t. style and backward-compatibility.
- I fixed the operator-matching subre to also include `==', `!=', `/='
but exclude `<<' and the like which currently give void-function
errors.
- I did not fix some "a[^b]*b"-style subres to use non-greedy variants
since these are strictly speaking not identical. Even though newline
characters shouldn't play a big role here ...
- I likewise did not fix the number-matching subre allowing for numbers
like "1.2.3" to keep things short at least there. `string-to-number'
silently takes care of these, even if an exponent gets lost that way.
But from here it gets more intersting:
- The code uses subre "-" in property names to (supposedly) allow
for inclusion of minus characters in property names, which (probably)
could be confused with term negation.
- It also unquotes these minus characters for {tag regexps}:
(tag (save-match-data
(replace-regexp-in-string
"-" "-" (match-string 2 term
But it never unquotes them in property names. That missing unquoting
could be easily amended, but:
- The other issue is: Why do we need "-" for both property names and
{tag regexps}? This forces us to do queries like:
{[a\\-z]}|foo\\-bar="baz"
where in my opinion
{[a\-z]}|foo\-bar="baz"
should be sufficient.
- Even more, IMO one could do away completely with the minus-quoting and
unquoting, since the overall regexp should allow for unambiguously
matching minus characters both
+ in {tag regexps} (because of "{[^}]+}" gobbling them) and
+ in property names (because a property name must always be followed
by some operator)
*without* them getting confused with term negation.
Or do I miss something here? A cursory test with sth like
+foo-bar="xxx"-patchday=202302
seems to work fine.
- However, removing the unquoting of {tag regexps} would be a breaking
change. Even though I doubt anybody has ever used it, the more it is
not mentioned in the documentation.
> I had this in mind for a wile, but I am still hoping that we can
> eventually (when it is added to Emacs) rely upon peg.el for parsing.
Given the fact that we have to discuss issues like those above, I
heartily agree.
> https://yhetil.org/emacs-devel/875yvtbbn3@ericabrahamsen.net/
Arthouse thread: Interesting plot, surprising sidelines, not everything
comprehensible, (unfortunately) open end.
From 1765e91d2f7875b321703afe34e32754a022bef4 Mon Sep 17 00:00:00 2001
From: Jens Schmidt
Date: Thu, 3 Aug 2023 22:34:56 +0200
Subject: [PATCH] org-make-tags-matcher: Add starred property operators, more
operator synonyms
* lisp/org.el (org-make-tags-matcher): Add starred property operators.
Recognize additional operators "==", "!=", "/=". Clean up and
document match term parsing.
(org-op-to-function): Recognize additional inequality operator "/=".
* doc/org-manual.org (Matching tags and properties):
* etc/ORG-NEWS: (~org-tags-view~ supports more property operators):
* testing/lisp/test-org.el (test-org/map-entries): Add documentation,
announcement, and tests on starred and additional operators.
---
doc/org-manual.org | 20 -
etc/ORG-NEWS | 10 -
lisp/org.el | 96 +---
testing/lisp/test-org.el | 33 ++
4 files changed, 130 insertions(+), 29 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 16fbb268f..27051fbfc 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9246,16 +9246,25 @@ When matching properties, a number of different operators can be used
to test the value of a property. Here is a complex example:
#+begin_example
-+work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
++work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<*2
+With={Sarah\|Denny}+SCHEDULED>="<2008-10-11>"
#+end_example
+#+cindex: operator, for property search
#+texinfo: @noindent
The type of comparison depends on how the comparison value is written:
- If the compa
Re: org-agenda queries for absent properties
On 2023-07-31 08:45, Ihor Radchenko wrote:
If you are up to a job of adding this to `org-make-tags-matcher' and
not breaking things, you can try.
Depends a bit on the required collateral changes: Updating ORG-NEWS and
doc/org-guide.org should be no problem. Doing a naive grep-based search
I haven't found tests on `org-tags-view' or `org-make-tags-matcher', so
I hopefully wouldn't need to add anything new in that direction.
Finally, the first step probably would be to make that humongous regexp
in `org-make-tags-matcher' a bit more readable. What would you prefer?
`rx' or sth long the following lines (not checked for equality yet):
(re (concat
;; AND operator (OR is done by global splitting)
"^&?"
;; 1: exclusion and inclusion (the latter being
;; implicit)
"\\([-+:]\\)?"
;; 2: query expression
"\\("
;; regular expression matching tag
"{[^}]+}\\|"
;; LEVEL special property match (3: op, 4: level
;; value)
"LEVEL\\([<=>]\\{1,2\\}\\)\\([0-9]+\\)\\|"
;; property match
"\\(?:"
;; 5: property name (with backslash escaping minus)
"\\(\\(?:[[:alnum:]_]+\\(?:-\\)*\\)+\\)"
;; 6: property operator
"\\([<>=]\\{1,2\\}\\)"
;; 7: property value/operand
"\\("
;; regular expression
"{[^}]+}\\|"
;; string
"\"[^\"]*\"\\|"
;; number
"-?[.0-9]+\\(?:[eE][-+]?[0-9]+\\)?"
"\\)"
"\\)\\|"
;; tag match
org-tag-re
"\\)"))
> But we should really provide more
> readable match syntax, similar to org-ql; sooner or later.
Agreed on that if the new syntax will allow for equally succinct
queries. Plus a very cursory, doc-only review of org-ql hasn't
revealed to me how I'd do numeric property comparisons with it.
org-agenda queries for absent properties
The following was initially meant as bug report until I understood that it's actually some sort of feature ... Consider the following todo list: todos.org * TODO relax * TODO do this :PROPERTIES: :patchday: 202302 :END: * TODO do that :PROPERTIES: :patchday: 202305 :END: * TODO work harder :PROPERTIES: :patchday: 202308 :END: todos.org When I use an agenda query patchday>=202305 on that I get the result: Headlines with TAGS match: patchday>=202305 Press ‘C-u r’ to search again todos: TODO do that todos: TODO work harder However for the following: patchday<=202305 I get Headlines with TAGS match: patchday<=202305 Press ‘C-u r’ to search again todos: TODO relax todos: TODO do this todos: TODO do that since the absent property "patchday" on the "relax" todo entry is defaulted to value zero, obviously. So I would like to have something easier to type (and remember! why not "!=" or "/="?) then patchday<>0<=202305 How about starred agenda property operators that match only if the operand property is actually present, which would result in this query: patchday<=*202305 Section does not seem to provide any information on "definedness" expressions for properties. Thanks.
Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]
On 2023-07-29 09:04, Ihor Radchenko wrote: Thanks for checking! Updated our records. And thanks for doing the paperworks. Attached is a patch and commit message with: - patch payload unchanged, - email address in commit message fixed - link to this thread in commit message added. Does look right now? From 74d5c1f5caf4ce425eb888340c2115276b4ddf8a Mon Sep 17 00:00:00 2001 From: Jens Schmidt Date: Sun, 30 Jul 2023 17:51:27 +0200 Subject: [PATCH] ol-gnus.el: Fix issue when storing links from Gnus article buffers * lisp/ol-gnus.el (org-gnus-store-link): Switch to `gnus-summary-buffer' when calling functions that are intended to be called only there. Link: https://list.orgmode.org/orgmode/2fa5914d-2cbf-f41f-8be6-e79e77794...@vodafonemail.de --- lisp/ol-gnus.el | 34 +++--- 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/lisp/ol-gnus.el b/lisp/ol-gnus.el index 7c07ce045..f0e04ce66 100644 --- a/lisp/ol-gnus.el +++ b/lisp/ol-gnus.el @@ -137,27 +137,23 @@ If `org-store-link' was called with a prefix arg the meaning of (let* ((group (pcase (gnus-find-method-for-group gnus-newsgroup-name) (`(nnvirtual . ,_) - (save-excursion - (car (nnvirtual-map-article (gnus-summary-article-number) + (with-current-buffer gnus-summary-buffer + (save-excursion + (car (nnvirtual-map-article (gnus-summary-article-number)) (`(,(or `nnselect `nnir) . ,_) ; nnir is for Emacs < 28. - (save-excursion - (cond - ((fboundp 'nnselect-article-group) - (nnselect-article-group (gnus-summary-article-number))) - ((fboundp 'nnir-article-group) - (nnir-article-group (gnus-summary-article-number))) - (t - (error "No article-group variant bound") + (with-current-buffer gnus-summary-buffer + (save-excursion + (cond + ((fboundp 'nnselect-article-group) + (nnselect-article-group (gnus-summary-article-number))) + ((fboundp 'nnir-article-group) + (nnir-article-group (gnus-summary-article-number))) + (t + (error "No article-group variant bound")) (_ gnus-newsgroup-name))) - (header (if (eq major-mode 'gnus-article-mode) - ;; When in an article, first move to summary - ;; buffer, with point on the summary of the - ;; current article before extracting headers. - (save-window-excursion - (save-excursion - (gnus-article-show-summary) - (gnus-summary-article-header))) - (gnus-summary-article-header))) + (header (with-current-buffer gnus-summary-buffer + (save-excursion + (gnus-summary-article-header (from (mail-header-from header)) (message-id (org-unbracket-string "<" ">" (mail-header-id header))) (date (org-trim (mail-header-date header))) -- 2.30.2
Minimal Gnus setup for test purposes
In the context of some ol-gnus bug I created a minimal Gnus setup. Ihor wanted to have a look at it, so here it is. To use: - create an empty directory /foo/bar/baz and say unzip -qd /foo/bar/baz gnus-minimal-test.zip - if you want to use the nnselect backend based on notmuch (haven't tested other search engines), ensure you have notmuch installed and generate the search index with HOME=/foo/bar/baz notmuch new - HOME=/foo/bar/baz make vanilla, HOME=/foo/bar/baz emacs -Q, whatever. Only ensure to set the home directory to that newly created directory when starting Emacs. - M-x load-file ~/.gnus RET - M-x gnus RET You should see a rather bland *Group* buffer along the following lines: 1: nndraft:drafts 182: nntp+news.gmane.io:gmane.emacs.announce 156101: nntp+news.gmane.io:gmane.emacs.orgmode 0: nnml+archive:test01 0: nnml+archive:test02 0: nnvirtual:test03 0: nnselect:test04 (Please don't judge Gnus by this boring look - after all, this is a minimal test!) From here you can select groups and articles with RET: nndrafts+ - where Gnus saves mail drafts nntp+... - obvious nnml+... - Gnus' own article archive backend nnvitual+ - "virtual" group on archives test01 & test02 nnselect+ - search group searching for "emacs" in archives test01 & test02 and exit from these (and Gnus itself) with `q'. More notes: - Not sure as to how that could be used with ERT. Gnus itself has only very basic tests in the Emacs distribution, AFAICT. Using Gnus is something rather interactive, after all, and I have little ERT experience and none with interactive tests. - Gnus expects all these files relative to the home directory. In particular, there are some reference to that in the configuration files. Here it would be helpful if ERT could be tricked into changing the home directory to some temporary directory, as done in the instructions given above. IIRC the home directory must be set before Gnus starts. - If some of the groups shown above, like nntp (requiring internet connectivity) or nnselect (requiring notmuch), are not suitable for ERT, these could be removed from the setup. - Gnus should be rather stable. Anyhow, if you decide to test Org-Gnus-interaction, you most likely will be testing 10% Org functionality and 90% Gnus functionality. Which comes at a certain risk, of course. Have fun and feel free to ask or comment ...<>
Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]
On 2023-07-26 18:04, Ihor Radchenko wrote: This is not a proper email address and name. Should I use Jens Schmidt ? Sorry, forgot to maintain that yet in my org-mode clone. Will do. May you please add TINYCHANGE cookie to commit message. I do not see you having a copyright status in our records. See https://orgmode.org/worg/org-contribute.html#first-patch I completed already an FSF copyright assignment for Emacs. Does that count for org-mode as well or do I need to extend/repeat that somehow? A TINYCHANGE might be sufficient here but I think we could as well clarify that issue "the thorough way" right from the start. And maybe add a link to this discussion. Will do as well.
Re: Subscript entity in the name of files or some advise for alternatives
On 2023-07-25 01:08, Ypo wrote: Why did you try that variable instead of "org-pretty-entities-include-sub-superscripts"? To be honest: Because I haven't read your mail properly and because I didn't know about "pretty entities". I just noticed the subscripting done on such_file_names in Org HTML exports and searching from that direction found variables `org-use-sub-superscripts' and `org-export-with-sub-superscripts'. After a second look, though, it seems that `org-use-sub-superscripts' is in fact a bit more general than `org-pretty-entities-include-sub-superscripts'. But I don't get the logic in that area completely, so others may comment here as well ...
Re: Subscript entity in the name of files or some advise for alternatives
On 2023-07-24 21:12, Ypo wrote: I wanted it, because I usually use (_) to divide words when naming my_files, and that looks ugly in Orgmode. I had that problem myself recently. Do `org-use-sub-superscripts' and its companion `org-export-with-sub-superscripts' help in your case? See also .
Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]
Uh, I had technical issues and did not get all mails as I expected.
Cobbling things together in one big reply now, with references and
quotes hopelessly broken ... hope you can sort it out.
Anyway, thanks to Eric for chiming in.
> Ideally, it would be nice to have tests, though I have no clue how to
> approach writing them.
I have created a somewhat minimal Gnus setup to develop and test this
patch on my development laptop, where I normally do not use Gnus. It
consists of a bunch of files and directories and a bit of configuration.
I can follow up on this if you like, but preferably in a separate
thread.
>> If we're currently in article-mode. The call to
>> `gnus-article-show-summary' would protect against the case where the
>> summary buffer has been killed in the meantime [...].
Not really. The following executed in an article buffer:
(progn
(kill-buffer gnus-summary-buffer)
(gnus-article-show-summary))
results in
Debugger entered--Lisp error:
(error "There is no summary buffer for this article buffer")
signal(error ("There is no summary buffer for this article buffer"))
error("There is no summary buffer for this article buffer")
gnus-article-show-summary()
[...]
Which, OTOH, shows that I was wrong in one aspect: Gnus at least in some
cases *does* give a reasonable error message when the summary buffer for
an article buffer is gone.
>> Probably it would be enough to wrap the whole containing `let*' in a
>> (with-current-buffer gnus-summary-buffer ...). If we're already in the
>> summary buffer, no harm done.
>
> I am not sure if it is safe.
> There is
> (save-window-excursion (gnus-summary-select-article))
> which calls (set-buffer gnus-summary-buffer)
I agree with Ihor here and would rather go for individual wraps into
`with-current-buffer'. As I have done in my patch already,
incidentially.
>> Ugh, this whole thing is a mess. I think the first question is: should
>> this function "fix" the state of Gnus before it makes a link? Should it
>> attempt to re-open the Summary buffer if it's been closed? Should it
>> switch current articles if the open article buffer is not the one that
>> point is on in the Summary buffer?
>>
>> If we make a decision about that, then it should be easier to decide how
>> to handle the code changes themselves.
>
> ol-gnus should store link for thing at point in current buffer. Ideally,
> without side effects. Everything else should be implementation detail.
Could we agree on: ol-gnus should store Gnus links with as little effort
and side-effect as possible while providing reasonable functionality for
the common use cases. I think, again incidentially, that my patch
matches this criterion.
What optionally could be improved, though, is error handling in these
pathological cases. But that would probably require some macro
(ol-gnus-with-current-summary-buffer BODY)
to have the error handling available in the separate places. Not sure
whether this is worth the effort.
> Or, at least, it was not sufficient at the time when ol-gnus has been
> written (quite a while ago).
I don't think this has changed, really.
Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]
On 2023-07-23 12:26, Max Nikulin wrote: Is nnselect a real NNTP group or is it some instance existing solely in user's configuration? Like nnvirtual and nnir, nnselect exists only in user's configuration, yes. All these three backends are "wrapper backends" that keep track of the original messages which they wrap by pairs (ORIGINAL-GROUP, MESSAGE-ID) Does gnus have global Message-ID index? Gnus can have a global Message-ID cache, but it's not on by default (at least not in Emacs 28, haven't checked others). And anyway, it's a potentially incomplete *cache*, and not an *index*. (info "(url) news/nntp/snews") or or https://www.gnu.org/software/emacs/manual/html_node/url/news_002fnntp_002fsnews.html In any case, Gnus is *not only* an NNTP newsreader, since it has a plethora of other backends (aka. "select methods"), ranging from nnimap to nneething, which turns a directory into a, well, group? See . Funnily enough, I personally stopped using Gnus as NNTP newsreader long ago ... I am curious whether namely "gnus" links have to be used or it is possible to rely on more generic "news:"/"nntp:; links, or even (perhaps with some `browse-url' configuration)? It should improve portability. For nntp groups you already have the option to store links as web links to groups.google.com, by means of `org-gnus-prefer-web-links'. Here again I'm not really an NNTP expert so I cannot tell whether this is portable/optimal/whatever. This could be extended to provide more options for backends that support more specific link types, but I think the default should stay the gnus:" links, since only that covers all the available Gnus backends.
Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]
On 2023-07-22 15:48, Ihor Radchenko wrote:
I am not familiar with Gnus, but looking at the code, may it be that
a Gnus article is open when Gnus summary buffer is not?
Theoretically yes, if you actively and malignantly kill the summary
buffer, for example. In practice and through Gnus key bindings, this
should not happen. IOW, Gnus stops behaving reasonably as well if you
kill the summary buffer other than through Gnus key bindings ("Selecting
deleted buffer", etc.).
If you check function `gnus-summary-work-articles' from gnus-sum.el, the
main work horse for article processing and also good for calling in
article buffers, you will note (focusing on the default case) the same
paradigm
(with-current-buffer gnus-summary-buffer
(cond
[...]
(t
;; Just return the current article.
(list (gnus-summary-article-number))
As a last resort we could also try to drag in Andrew Cohen as a
reviewer, he has been helpful already with one or two of my Gnus bugs.
[BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]
Tags: patch `org-store-link' has a number of related issues when storing links from article buffers related to nnvirtual, nnselect, or nnir groups. I describe them here in prose without providing a full repro case, which would be somewhat difficult to set up. Just let me know if you think you need more information, I have the data available. The most obvious symptom is this: - Create an nnselect group and open an article from that. In the article buffer, do M-x org-store-link RET, then paste the link with C-c C-l in some Org mode buffer. The resulting link looks like gnus:#e18xcfu-0004ht...@fencepost.gnu.org That is, it lacks the group name before the hash sign. Correct would have been: gnus:nnml+archive:test01#e18xcfu-0004ht...@fencepost.gnu.org Starting with Emacs 30, you even more obviously get an error: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) nnselect-article-group(nil) org-gnus-store-link() org-store-link(nil 1) funcall-interactively(org-store-link nil 1) call-interactively(org-store-link record nil) command-execute(org-store-link record) execute-extended-command(nil "org-store-link" nil) funcall-interactively(execute-extended-command nil "org-store-link" nil) call-interactively(execute-extended-command nil nil) command-execute(execute-extended-command) Less obvious, occuring for nnvirtual groups: - Create an nnvirtual group and open an article from that. In the article buffer, do M-x org-store-link RET. Observe the "current article arrow" in the fringe being set in the article header, even though that arrow should be used only in a summary buffer. The root cause is that some of the Gnus functions used in `org-gnus-store-link' must be called only in summary buffers, and not in article buffers. These are: gnus-summary-article-number nnselect-article-group Not sure about these, but it is probably also better to call these in summary buffers only: nnvirtual-map-article nnir-article-group The remedy for these issues is simple: When calling above functions just temporarily and unconditionally switch to the summary buffer with (with-current-buffer gnus-summary-buffer ...) where buffer-local variable `gnus-summary-buffer' in an article buffer points to the summary buffer where the articles comes from. (And for a summary buffer the variable points to the summary buffer itself.) Finally, there is a related inefficiency when determining the article header structure in function `org-gnus-store-link': Here the authors indeed switch to the summary buffer when currently in the article buffer, but using "user-land" interactive function `gnus-article-show-summary' to do so where a simple (with-current-buffer gnus-summary-buffer ...) would suffice. Emacs : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2023-07-20 Package: Org mode version 9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)From e1bc9aefd4fd0080012c172d1c21c684a5b2fe51 Mon Sep 17 00:00:00 2001 From: farblos <43711228+farb...@users.noreply.github.com> Date: Sat, 22 Jul 2023 10:30:19 +0200 Subject: [PATCH] ol-gnus.el: Fix issue when storing links from Gnus article buffers * lisp/ol-gnus.el (org-gnus-store-link): Switch to `gnus-summary-buffer' when calling functions that are intended to be called only there. --- lisp/ol-gnus.el | 34 +++--- 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/lisp/ol-gnus.el b/lisp/ol-gnus.el index 7c07ce045..f0e04ce66 100644 --- a/lisp/ol-gnus.el +++ b/lisp/ol-gnus.el @@ -137,27 +137,23 @@ If `org-store-link' was called with a prefix arg the meaning of (let* ((group (pcase (gnus-find-method-for-group gnus-newsgroup-name) (`(nnvirtual . ,_) - (save-excursion - (car (nnvirtual-map-article (gnus-summary-article-number) + (with-current-buffer gnus-summary-buffer + (save-excursion + (car (nnvirtual-map-article (gnus-summary-article-number)) (`(,(or `nnselect `nnir) . ,_) ; nnir is for Emacs < 28. - (save-excursion - (cond - ((fboundp 'nnselect-article-group) - (nnselect-article-group (gnus-summary-article-number))) - ((fboundp 'nnir-article-group) - (nnir-article-group (gnus-summary-article-number))) - (t - (error "No article-group variant bound") + (with-current-buffer gnus-summary-buffer + (save-excursion + (cond + ((fboundp 'nnselect-article-group) + (nnselect-article-group (gnus-summary-article-number))) + ((fboundp 'nnir-article-group) + (nnir-article-group (gnus-summary-article-number))) + (t + (error "No article-group variant bound")) (_ gnus-newsgroup-name))) - (header (if (eq major-mode 'gnus-article-mode) - ;; When in an article, first move to summary - ;; buffer, with
Re: [BUG] SPACE jumps to tag in header line after hidden emphasis marker [9.7-pre (release_9.6.7-562-g5b6268 @ /home/jschmidt/work/org-mode/lisp/)]
On 2023-07-18 10:13, Ihor Radchenko wrote: No, it is space. In particular, it is `org--align-tags-here' + some bug in Emacs that screws up column computation. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64696 FWIW the third test yields ■ Warning (emacs): Test #3:: ’word’ is hidden applying ’invisible text property to heading body. ■ Warning (emacs): Moved point after first ’word’ ■ Warning (emacs): 1:: current-column = 0 ■ Warning (emacs): redisplayed ■ Warning (emacs): 2:: current-column = 0 ■ Warning (emacs): Indented to column 50 ■ Warning (emacs): 3:: current-column = 0 ■ Warning (emacs): redisplayed ■ Warning (emacs): 4:: current-column = 0 ■ Warning (emacs): Enabled visible mode ■ Warning (emacs): 5:: current-column = 50 ■ Warning (emacs): redisplayed ■ Warning (emacs): 6:: current-column = 50 on my system which seems to be different from what you described. And for the fun of it: With (indent-tabs-mode -1) tests 3 and 4 report column 54 for "5::" and "6::".
Re: [BUG] SPACE jumps to tag in header line after hidden emphasis marker [9.7-pre (release_9.6.7-562-g5b6268 @ /home/jschmidt/work/org-mode/lisp/)]
On 2023-07-19 09:10, Ihor Radchenko wrote: I see no good way to address this quickly, so I re-added stickiness to the opening emphasis marker, as you suggested. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=724135dda Follow-ups: 1. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64724 (for Emacs point adjustment rules) 2. https://orgmode.org/list/87edl41jf0.fsf@localhost (for proper handling of emphasis markers when moving across words) Thanks. What a wasps' nest.
Re: [BUG] SPACE jumps to tag in header line after hidden emphasis marker [9.7-pre (release_9.6.7-562-g5b6268 @ /home/jschmidt/work/org-mode/lisp/)]
[Resent with correct identity to make this visible on the list as well - sorry for the hassle.] On 2023-07-18 10:13, Ihor Radchenko wrote: Confirmed. Thanks for caring about this so quickly ... https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64696 ... and for the discussion with Eli & co. Which I did not try to follow TBH. Fixed, on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3e3b873d3 Well, I have one not-so-minor nit here: With that commit you cannot insert text *before* some text having hidden emphasis without breaking the emphasis. More concretely (in an empty org-mode buffer): t ;; org-self-insert-command e ;; org-self-insert-command s ;; org-self-insert-command t ;; org-self-insert-command SPC ;; org-self-insert-command = ;; org-self-insert-command t ;; org-self-insert-command e ;; org-self-insert-command s ;; org-self-insert-command t ;; org-self-insert-command = ;; org-self-insert-command SPC ;; org-self-insert-command t ;; org-self-insert-command e ;; org-self-insert-command s ;; org-self-insert-command t ;; org-self-insert-command C-;; left-word C-;; left-word SPC ;; org-self-insert-command The last SPC breaks the emphasis around the middle "test", which it did not previously. Previously, the SPC would just move the whole emphasized word one space to the right. Which I somehow got used to, and probably many others as well. OTOH, to fix my bug, only the first of the new `org-rear-nonsticky-at' calls is actually needed. So probably we could have something like the following to get my bug fixed without any changes in behavior (diff on top of main, that is, in addition to your commit): diff --git a/lisp/org.el b/lisp/org.el index 0d8b5386c..71f482f64 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5153,8 +5153,7 @@ stacked delimiters is N. Escaping delimiters is not possible." ;; https://orgmode.org/list/8b691a7f-6b62-d573-e5a8-80fac3dc9...@vodafonemail.de (org-rear-nonsticky-at (match-beginning 5)) (add-text-properties (match-beginning 3) (match-end 3) -'(invisible t)) -(org-rear-nonsticky-at (match-end 3))) +'(invisible t))) (throw :exit t (defun org-emphasize ( char)
[BUG] SPACE jumps to tag in header line after hidden emphasis marker [9.7-pre (release_9.6.7-562-g5b6268 @ /home/jschmidt/work/org-mode/lisp/)]
[emacs-29]$ ./src/emacs -Q -L ~jschmidt/work/org-mode/lisp/ (org-version nil t) "Org mode version 9.7-pre (release_9.6.7-562-g5b6268 @ /home/jschmidt/work/org-mode/lisp/)" (setq org-hide-emphasis-markers t) t ;; assume test.org being absent in cwd C-x 4 f ;; find-file-other-window t;; self-insert-command e;; self-insert-command s;; self-insert-command t;; self-insert-command .;; self-insert-command o;; self-insert-command r;; self-insert-command g;; self-insert-command ;; minibuffer-complete-and-exit *;; org-self-insert-command SPC ;; org-self-insert-command t;; org-self-insert-command e;; org-self-insert-command s;; org-self-insert-command t;; org-self-insert-command C-c C-q ;; org-set-tags-command t;; self-insert-command e;; self-insert-command s;; self-insert-command t;; self-insert-command ;; exit-minibuffer SPC ;; org-self-insert-command =;; org-self-insert-command t;; org-self-insert-command e;; org-self-insert-command s;; org-self-insert-command t;; org-self-insert-command =;; org-self-insert-command SPC ;; org-self-insert-command The final SPC after the closing equal sign lets point jump to before the colon of the ":test:" tag. Most likely, this is not limited to space, but that is just the character I most frequently type after closing emphasis.
Re: How to tell `org-html-link' to create a link with some HTML class?
On 2023-06-20, Marcin Borkowski wrote: > Dear Orgers, > > as I mentioned some time ago, I'm writing a custom exporter (actually, > a very thin wrapper around the HTML exporter). I'd like `org-html-link' > to add some class to the links it generates. Is that possible? Dear Marcin, yes, that’s possible, ":attr_html" is read in `org-html-link'. You have to set that in your code, see [1] for an example for classes in my reveal.js backend. Briefly, with `elem' being the link, I use this: `(org-element-put-property elem :attr_html (list newattrs))' Best wishes Jens [1] https://gitlab.com/oer/org-re-reveal/-/blob/master/org-re-reveal.el#L2167
Re: Where does headline data end for the purpose of `org-adapt-indentation´ == ´headline-data
On 2023-06-09 09:34, Ihor Radchenko wrote: Emacs master tracks the latest stable Org release. OK, so I cobbled up Org main with branch emacs-29. ./src/emacs -Q M-x org-version Org mode version 9.7-pre (release_9.6.6-408-g9082fa @ ...) (setq org-adapt-indentation 'headline-data) Paste the following into a new org file, headline A being the on the first line: snip ** Headline A ** Headline B ** Headline C :properties: snip Then try TAB on lines (my humble opinion in parentheses) 2: no indent (NOK) 3: no indent (OK) 6: indent (OK) 7: indent (NOK) 11: no indent (NOK) I could try "fixing" that, but I'm not sure what is intended an what not. WDYT?
Re: [POLL] Add command names to key bindings in Org Guide? (was: Suggestion: for each listed keybinding, also name the command)
> > On the other hand, new users may benefit from seeing the command names > alongside with the bindings, especially users of pre-packages Emacs > where the bindings may be shadowed by evil-mode and the likes. > > WDYT? I am in favor. One of my main problems in learning emacs: I started with evil and all documentation lacking the function names was literally a huge source of frustration. Also, humans are much better at remembering names than high entropy keystrokes. If I just remember a bit of the name, I can easily find the key binding in the help. The other way around is not possible. Just like a phone book. The numbers (key bindings) are shorter, yes. But good luck trying to find 555-12346 when you remember 555-12345. BR Jens
Re: [BUG] Filling in source blocks fills by region, not paragraph [9.5.5 (release_9.5.5/master)]
Forget about that one, it is already fixed in master. I had the wrong load path and used actually 9.5.5 and not org-mode cloned from master, as intended.
Re: Unicode problem with export of literal contents
On 2023-02-20, Bruno Barbier wrote: > Jens Lechtenboerger writes: > >> On 2023-02-20, Bruno Barbier wrote: >> >> However, if I use insert-file-contents-literally with a unicode >> file, I do *not* have to set the coding-system-for-write. This just >> works: >> >>(with-temp-buffer >> (insert-file-contents-literally "~/unicode.org") >> (secure-hash 'md5 (current-buffer))) > > Humm. Emacs is amazing: it managed to guess the right encoding, from the > buffer context, probably... > > But, what you are giving to 'org-export-string-as' is not the buffer, > it's a string. So, let's try the same without using an org function: > > (with-temp-buffer >(insert (with-temp-buffer > (insert-file-contents-literally "~/unicode.org") > (buffer-string))) >(secure-hash 'md5 (current-buffer))) > > And, that fails, requesting an encoding. Thank you for this example. >> In the context of Org export, secure-hash seems to require a coding >> system. Why? > > I'm not an expert, so, you'll need to confirm with other sources. But > secure-hash requires an encoding in all cases, to compute the hash of > some text, because it needs the array of bytes that represents that text > to compute its hash. > > I don't see any bug in org, and, I don't see any bug in secure-hash either. > > You literally shoud stop using "literally" ;-) Indeed. > And, you might want to read: >(info "(elisp) Non-ASCII Characters") The first section was already helpful, thanks! (I still need to read more of this...) Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: Unicode problem with export of literal contents
On 2023-02-20, Bruno Barbier wrote: > If you're always using utf-8, here is a way to force it so that > secure-hash can compute the hash. This should work: > >(with-temp-buffer > (let ((coding-system-for-write 'utf-8)) > (insert "Lechtenb\303\266rger") > (secure-hash 'md5 (current-buffer Yes, that works. However, if I use insert-file-contents-literally with a unicode file, I do *not* have to set the coding-system-for-write. This just works: (with-temp-buffer (insert-file-contents-literally "~/unicode.org") (secure-hash 'md5 (current-buffer))) In the context of Org export, secure-hash seems to require a coding system. Why? Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: Unicode problem with export of literal contents
On 2023-02-17, Ihor Radchenko wrote: > Jens Lechtenboerger writes: >> Also, when I call secure-hash on the literal buffer-string, no >> problem arises. > > Org is calling secure-hash on buffer. Calling on buffer-string would > require unnecessary memory allocation to create the string. I can call secure-hash on the buffer with literally inserted contents without problems. >> It is not obvious that Org tries to write something here and why >> that fails now > > Org is not trying to write something. In you example, Org is just trying > to calculate buffer string hash - nothing wrong on Org side. "Something > wrong with encoding" way my guess. If you think that your case should be > perfectly fine, I recommend asking Emacs devs by filing a bug report to > them. Thank you for the clarifications. Probably I have to do that. For the record, if I insert "Lechtenb\303\266rger" as string into a buffer, secure-hash asks for a decoding. If I insert that literally via an UTF-8 encoded file, secure-hash works. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: Unicode problem with export of literal contents
On 2023-02-17, Bruno Barbier wrote: > Here is a way to reproduce that doesn't use org, in case it might help > to manully fix your encoding issue: > >(with-temp-buffer > (insert "Lechtenb\303\266rger") > (let ((buffer-file-name (make-temp-file "mailtest"))) > (save-buffer))) > > Does it work with your old config (with your old org) ? This also asks for an encoding. > What kind of failure do you get elsewhere if you let Emacs use the > correct encoding (i.e. if you use `insert-file-contents') ? I want to be sure to use the file contents in unchanged form, as promised by insert-file-contents-literally. For now, I copied part of the code from insert-file-contents-literally to avoid after-insert processing and file handlers. I still do not understand what is happening differently in my case, though... Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: Unicode problem with export of literal contents
On 2023-02-17, Ihor Radchenko wrote: > Jens Lechtenboerger writes: > >> With Org 9.6.1 from Emacs master, I get the following warning, and I >> am asked to select a coding system: >> >>> These default coding systems were tried to encode the following >>> problematic characters in the buffer ‘ *temp*’: >>> ... >> >> With previous Org versions, this did not happen, export would just >> work. Note that I insert contents literally because I do not want >> ‘find-file-hook’, automatic uncompression, etc. (which are avoided >> according to the doc string of insert-file-contents-literally). > > This warning appears upon Org calling `secure-hash'. > Org is doing nothing wrong here - your file does not have proper encoding. > You did not see this error in the past by chance. I was afraid you would say so. To me, this is a breaking change. Also, when I call secure-hash on the literal buffer-string, no problem arises. > Not a bug. You need to fix your files with improper encoding. The file has the proper encoding. I insert literally on purpose as stated above. It is not obvious that Org tries to write something here and why that fails now (I could use the results in exporters writing to files just fine previously). Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: Unicode problem with export of literal contents
Hi Bruno, On 2023-02-17, Bruno Barbier wrote: > Hi Jens, > > Jens Lechtenboerger writes: > >> ... >> Note that I insert contents literally because I do not want >> ‘find-file-hook’, automatic uncompression, etc. (which are avoided >> according to the doc string of insert-file-contents-literally). >> >> Could the old behavior be restored? > > By using `insert-file-contents-literally' (as opposed to > `insert-file-contents'), you're also forbidding Emacs to decode the > binary content of your file into text. > > My guess is that it was working by chance in previous versions. in any case, this will introduce failures elsewhere. > In case somebody might help you, here is a simple way to trigger the > encoding question with a recent version of org (mine is Org mode version > 9.6.1). > >(with-temp-buffer > (insert "Lechtenb\303\266rger") > (org-mode)) Thank you for the simpler recipe. This indeed fails now. So, maybe my question is: Must text be decoded for Org mode from now on? Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Unicode problem with export of literal contents
Hi there, consider this piece code, where unicode-file.org contains umlauts (say, just the word “Lechtenbörger”): (org-export-string-as (with-temp-buffer (insert-file-contents-literally "unicode-file.org") (buffer-string)) 'html t) With Org 9.6.1 from Emacs master, I get the following warning, and I am asked to select a coding system: > These default coding systems were tried to encode the following > problematic characters in the buffer ‘ *temp*’: > ... With previous Org versions, this did not happen, export would just work. Note that I insert contents literally because I do not want ‘find-file-hook’, automatic uncompression, etc. (which are avoided according to the doc string of insert-file-contents-literally). Could the old behavior be restored? Best wishes Jens
Re: Syntax question: What is BORDER in 4.17. Text Markup?
On 2022-12-07, Timothy wrote: > Hi Jens, > >> Actually, what about this? Get rid of both, BORDER and BODY, and >> specify CONTENTS as follows: >> “Either a string (when MARKER represents code or verbatim) or a >> series of objects from the standard set, not spanning more than >> three lines. In any case, CONTENTS must neither begin nor end with >> whitespace.” > > This seems like an improvement to me, implemented in 56338725e61 :) Many thanks, Timothy! Best wishes Jens
Re: Syntax question: What is BORDER in 4.17. Text Markup?
On 2022-12-07, Jens Lechtenboerger wrote: > On 2022-12-07, Max Nikulin wrote: > >> On 07/12/2022 01:28, Jens Lechtenboerger wrote: >>> Hi there, >>> the syntax for Text Markup such as *bold* at [1] specifies >>> PRE MARKER CONTENTS MARKER POST with >>> CONTENTS as BORDER BODY BORDER and >>> BORDER as “Any non-whitespace character.” >>> What is the role of BORDER here? Does it really exist? >> >> I think, the idea is to stress that >> >> / / or * word * >> >> must not be considered as emphasis. > > I see, thanks. > >>> What is BORDER if CONTENTS should be a single character, e.g., in >>> the two strings “*x*” and “~*~”? Are single characters forbidden? >> >> The spec is not precise here. It is close to the code that actually >> allows single character contents, see >> `org-element--parse-generic-emphasis' and the docstring of >> `org-emphasis-regexp-components'. >> >> Perhaps it should be stated as (in regexp notation) >> >> BORDER (BODY? BORDER)? >> >> or as alternatives >> >> BORDER or BORDER BORDER or BORDER BODY BORDER. > > If find this confusing. What is BODY (semantically) if two of its > characters are assigned to BORDERs? > > What about getting rid of BORDER in the spec and replacing > “Where BORDER and BODY are not separated by whitespace.” > with > “Where BODY does neither begin nor end with whitespace”? > (If that is correct...) > > The implementation with regexps is a different issue. Actually, what about this? Get rid of both, BORDER and BODY, and specify CONTENTS as follows: “Either a string (when MARKER represents code or verbatim) or a series of objects from the standard set, not spanning more than three lines. In any case, CONTENTS must neither begin nor end with whitespace.” Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: Syntax question: What is BORDER in 4.17. Text Markup?
On 2022-12-07, Max Nikulin wrote: > On 07/12/2022 01:28, Jens Lechtenboerger wrote: >> Hi there, >> the syntax for Text Markup such as *bold* at [1] specifies >> PRE MARKER CONTENTS MARKER POST with >> CONTENTS as BORDER BODY BORDER and >> BORDER as “Any non-whitespace character.” >> What is the role of BORDER here? Does it really exist? > > I think, the idea is to stress that > > / / or * word * > > must not be considered as emphasis. I see, thanks. >> What is BORDER if CONTENTS should be a single character, e.g., in >> the two strings “*x*” and “~*~”? Are single characters forbidden? > > The spec is not precise here. It is close to the code that actually > allows single character contents, see > `org-element--parse-generic-emphasis' and the docstring of > `org-emphasis-regexp-components'. > > Perhaps it should be stated as (in regexp notation) > > BORDER (BODY? BORDER)? > > or as alternatives > > BORDER or BORDER BORDER or BORDER BODY BORDER. If find this confusing. What is BODY (semantically) if two of its characters are assigned to BORDERs? What about getting rid of BORDER in the spec and replacing “Where BORDER and BODY are not separated by whitespace.” with “Where BODY does neither begin nor end with whitespace”? (If that is correct...) The implementation with regexps is a different issue. Best wishes Jens
Syntax question: What is BORDER in 4.17. Text Markup?
Hi there, the syntax for Text Markup such as *bold* at [1] specifies PRE MARKER CONTENTS MARKER POST with CONTENTS as BORDER BODY BORDER and BORDER as “Any non-whitespace character.” What is the role of BORDER here? Does it really exist? What is BORDER if CONTENTS should be a single character, e.g., in the two strings “*x*” and “~*~”? Are single characters forbidden? Best wishes Jens [1] https://orgmode.org/worg/org-syntax.html#Emphasis_Markers
Re: index for HTML export
On 2022-07-14, Fraga, Eric wrote: > On Thursday, 14 Jul 2022 at 08:13, Jens Lechtenboerger wrote: >> (list "index-terms" > > [...] > >> :preparation-function 'oer-reveal--add-advice-link >> :completion-function 'oer-reveal--remove-advice-link >> :publishing-function '(org-html-publish-to-html) >> :publishing-directory "./public") >> >> So, do you see theindex.org and theindex.inc? Do you publish the >> former? > > Yes, I do see theindex.org and theindex.inc but there are no index > entries. That is strange. File theindex.inc should contain the index entries. I believe that “:makeindex t” on the Org source files with #+INDEX: entries should do the job. > What do the first two functions listed above do? They adapt the link format for my specific export backend (to point to slides of presentations). That is not relevant in your case. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: index for HTML export
On 2022-07-13, Fraga, Eric wrote:
> Publishing works, in the sense that my org file is exported to HTML just
> fine. An index file is created but is not populated with any index
> links. What am I missing? The info page is less than helpful
> unfortunately. Are index lines, e.g.
>
> #+index: test!org publishing
>
> processed in any way?
Over here, yes: https://oer.gitlab.io/OS/index-terms.html
I use this in my publish code:
(list "org-presentations"
:base-directory "."
:base-extension "org"
:makeindex oer-reveal-publish-makeindex
:exclude
"index\\|backmatter\\|config\\|course-list\\|license-template\\|imprint\\|privacy\\|README\\|CONTRIBUTING\\|CHANGELOG"
:publishing-function
oer-reveal-publish-org-publishing-functions
:publishing-directory "./public")
where oer-reveal-publish-makeindex is t and my publish.el makes sure
to publish to HTML:
https://gitlab.com/oer/OS/-/blob/master/elisp/publish.el
(list "index-terms"
:base-directory "."
;; A file theindex.org (which includes theindex.inc)
;; is created due to assignment to
;; oer-reveal-publish-makeindex above.
;; Using that setting, the file is automatically published with
;; org-re-reveal, which is useless.
;; Thus, publish as HTML here. For this to work, index-terms.org
;; is a manually created file including theindex.inc.
;; The preparation and completion functions below set up an
;; advice on org-html-link to rewrite links into presentations
;; using org-re-reveal's anchor format.
:include '("index-terms.org")
:exclude ".*"
:preparation-function 'oer-reveal--add-advice-link
:completion-function 'oer-reveal--remove-advice-link
:publishing-function '(org-html-publish-to-html)
:publishing-directory "./public")
So, do you see theindex.org and theindex.inc? Do you publish the
former?
Best wishes
Jens
Re: Publish to HTML and LaTeX/PDF with cross-file links?
On 2022-06-16, at 09:55, Tim Cross wrote: > Jens Lechtenboerger writes: > >> [...] >> More precisely: For HTML export, a link like >> [[file:foo.org::#custom-id][elsewhere]] turns into a hyperlink to >> “foo.html#custom-id”, which is what I want. >> >> However, for LaTeX/PDF export, the hyperlink points to the source >> file “foo.org”, which in my case is a broken link. I would like >> that to be “foo.pdf” (or even something pointing at the proper >> section in the PDF file). >> >> Is this (easily) possible? >> > > I think what you need is an export filter function for links in latex > exports. Have a look at the docstring for variable > org-export-filter-link-functions. > > As a very basic example, the following should work > [...] Thank you for the suggestion! I am still undecided which way to go. Maybe a refactoring of code from ox-html (to be usable across backends) would be appropriate here. Best wishes Jens
Publish to HTML and LaTeX/PDF with cross-file links?
Hi all, I publish OER (https://oer.gitlab.io/) from Org sources and wonder about links to local files as documented at [1]. That page only talks about HTML export. How can I achieve similar behavior for LaTeX/PDF export? More precisely: For HTML export, a link like [[file:foo.org::#custom-id][elsewhere]] turns into a hyperlink to “foo.html#custom-id”, which is what I want. However, for LaTeX/PDF export, the hyperlink points to the source file “foo.org”, which in my case is a broken link. I would like that to be “foo.pdf” (or even something pointing at the proper section in the PDF file). Is this (easily) possible? Best wishes Jens [1] https://orgmode.org/manual/Publishing-links.html#Publishing-links
Re: Cannot clone org-mode's git repository
On 2021-10-03, Colin Baxter wrote: > Hello, > > I get a strange error when I try to clone org-mode: > > redknight@jetstar:~/git$ git clone > https://git.savannah.gnu.org/git/emacs/org-mode.git > Cloning into 'org-mode'... > fatal: unable to access > 'https://git.savannah.gnu.org/git/emacs/org-mode.git/': server certificate > verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none Hi there, I got a similar error in a Docker image (with "CAfile: none" instead). A CA certificate was missing. Eventually, I updated the entire image (in particular, with a new version of ca-certificates). Hopefully this helps: https://stackoverflow.com/questions/35821245/github-server-certificate-verification-failed/35824116#35824116 Best wishes Jens
Re: Help requested: Support for basic Org mode support in tools outside of Emacs
Hi on iOS the (really amazing) git client „working copy“ has support for org rendering Jens > On 3. Aug 2021, at 11:32, Karl Voit wrote: > > Hi, > > I'm collecting information on basic Org mode support in tools that > are not Emacs. > > I already have: GitHub, GitLab (exactly like GitHub), OrgModeWeb, > Orgzly, Orgro, Emacs, vim-orgmode. > > What I need is information on much more tools. > > I have set up a syntax checking file on > https://github.com/novoid/github-orgmode-tests/blob/master/orgmode_support.org > which also contains my current compatibility table for the most > basic set that makes sense as a Markdown-pendant outside of Emacs > according to my subjective judgement on Org mode at the bottom. > > My focus is on tools that - at least - offer text formatting syntax > highlighting for *bold* /italic/ and so forth. The rest could be > "works as text but has no special support for outlining and more". > > The goals is to emphasize that there are much more tools that allow > for viewing and/or editing data in Org mode syntax. > > Since I don't have an iPhone, iOS-based tools supporting Org mode > syntax is very much appreciated. > > Please do hand in more lines for the table either here, via email or > as a GitHub pull request. > > Thank you! > > -- > get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: >> get Memacs from https://github.com/novoid/Memacs < > Personal Information Management > http://Karl-Voit.at/tags/pim/ > Emacs-related > http://Karl-Voit.at/tags/emacs/ > >
Re: Dynamic block tables: adding prefix of "id:" to %ID
Hi Karl,
I use a wrapper around org-map-entries to create custom tables.
Calling the wrapper takes a configuration for each table column. This is quite
nice for other use cases as well, to e.g. convert properties (":TASK_PROGRESS:
75") into graphical representations like harvey balls.
Each column takes the following configuration values:
- colname :: The name of the column
- entry :: the property value of the column
- map :: a lambda function called with the value (optional)
- default :: default value if nothing yields a non nil value (optional)
(defun neuhalje/org-generate-table-from-sections-mapped (query default scope
mapping add-headline)
"See my library of Babel."
(let* (
(org-use-tag-inheritance nil)
(title-row (mapcar '(lambda (cfg) (cdr (assoc "colname" cfg)))
mapping))
(rows (org-map-entries #'(lambda ()
(mapcar '(lambda (column) (let*
((default-value (or (cdr (assoc "default" column)) default))
(entry (cdr
(assoc "entry" column)))
(mapping (cdr
(assoc "map" column)))
(raw
(org-entry-get nil entry))
(mapped (if
mapping (funcall mapping raw) raw)))
(or mapped
default-value))) mapping)) query scope)))
(if add-headline (append `(,title-row hline) rows) rows)))
#+NAME: generate-table-from-sections-mapped
#+BEGIN_SRC emacs-lisp :exports results :results table :var query='() :var
default="N/A" scope='file :var mapping='() :var add-headline='t :cache no
(neuhalje/org-generate-table-from-sections-mapped query default scope mapping
add-headline)
#+end_src
I call it from my org files like this:
#+name: demoprops2
#+begin_src emacs-lisp
'(
(("colname" . "ROW") ("entry" . "ITEM"))
(("colname" . "default") ("entry" . "x-prop-xxx"))
(("colname" . "custom default") ("entry" . "x-prop-b") ("default" . "not
there"))
(("colname" . "link") ("entry" . "CUSTOM_ID") ("map" . (lambda (value) (if
value (format "[[#%s][%s]]" value value) ""
(("colname" . "linked item") ("entry" . "CUSTOM_ID") ("map" . (lambda
(value) (if value (format "[[#%s][%s]]" value (org-entry-get nil "ITEM"))
(org-entry-get nil "ITEM")
)
#+end_src
#+CALL: generate-table-from-sections-mapped(scope='file, mapping=demoprops2,
query="+mytag-exclude")
Regards
Jens
> Hi,
>
> * Kristian Grönberg wrote:
>>
>> I didn't read your question properly.
>> Would it work for you to use the "<>"?
>>
>> *** <> barheading
>>:PROPERTIES:
>>:ID: [[bar][barheading]]
>>:END:
>>
>> /Kris
>
> I'm afraid not because the dynamic block would duplicate the
> target definition and not generating a link.
>
> --
> get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
>> get Memacs from https://github.com/novoid/Memacs <
> Personal Information Management > http://Karl-Voit.at/tags/pim/
> Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [wip-cite-new] Merging tomorrow?
Hi Nicolas,
first: thank you for all the work, especially for thinking of documentation for
end users. My biggest struggle with the current org (and emacs) documentation
is the lack of end-to-end examples. This makes it incredibly difficult to get
things working. It often is like „this is a big puzzle, some pieces are in
other boxes and we don’t provide a picture of how the final puzzle will look
like“. The documentation often makes sense once I get it running, though . But
this is to late.
This being the motivation, I would greatly appreciate the following:
——— snip ———-
Consider the following minimal viable example where an org file with one bibtex
file is rendered to pdf and html.
This is the BibTex file
#+begin_example bibtex
….
#+end_example
This is the org file
#+begin_example org
….
#+end_example
and this is the rendered html/Latex
- picture 1
- screenshot 2
This has been achieved with the following minimal configuration:
#+begin_example elisp
….
#+end_example
As you can see in line 42 the … etc, etc
If you would like to use two bibtex files you would need to change …
#+begin_example elisp
….
; change line 14 in the sample for one file like this:
(…)
…
#+end_example
——- snap ——-
That kind of documentation would have made many, many hours of frustrating
„search in google/github for a solution someone else has found“ and replace it
with „wow that was actually quite beginner friendly!“. Pictures also make it
much easier to visualize what is actually achieved.
Cheers
Jens
> On 8. Jul 2021, at 02:18, Nicolas Goaziou wrote:
>
> Hello,
>
> I think the "wip-cite-new" branch is in good shape now. As
> a consequence, I'd like to merge it tomorrow.
>
> It is documented, but the documentation is scattered across the various
> "oc" libraries, and some threads in the mailing list. I'll do a summary
> here, from a user point of view.
>
> --8<---cut here---start->8---
> Basically, in order to use it, you need to first set-up a bibliography,
> using one or more "bibliography" keywords. on such a keyword
> visits the related file. Out of the box, Org supports JSON-CSL and
> BibTeX (or biblatex) bibliographies.
>
> Then, citations can be inserted with the following syntax:
>
> [cite/style:common prefix ;prefix @key suffix; ... ; common suffix]
>
> Spaces are meaningful except those after the initial colon and before
> the closing bracket.
>
> Every part of the syntax is optional, except the brackets, "cite" and
> the colon. Also the citation must contain at least a key. So its minimal
> form is:
>
> [cite:@key]
>
> The "style" part is detailed below, in the part related to export.
>
> Org can insert or edit citations with (and delete them with
> ), follow them with , fontify them, and export
> them. These four actions (insert, follow, activate, and export) are
> called capabilities. Libraries responsible for these capabilities are
> called citation processors.
>
> You can select one citation processor for each capability, independently
> on the others, through the following variables:
>
> - org-cite-activate-processor
> - org-cite-export-processors
> - org-cite-follow-processor
> - org-cite-insert-processor
>
> Out of the box, Org provides the "basic" (in "oc-basic.el") processor
> for all of these tasks. It also boasts processors dedicated for export:
> "csl", "natbib" and "biblatex".
>
> During export, output for citations is controlled by their style, which
> is an Org label that the export processor may recognize and associate to
> a specific display, or fall-back to a default style (called "nil"). For
> example, most processors support "noauthor" and "text" styles.
>
> Some styles can accept a variant, with the syntax "style/variant".
> Again, it's up to the processor to associate it to a specific display.
> Common variants include "bare", "caps" or "full". They also accept
> short-hands, like "b", "c" and "f". Please refer to the export
> processors' libraries ("oc-basic.el", "oc-csl.el", …) for more information.
>
> It is possible to define a default style for a whole document (with
> "cite_export"), or for all documents (with `org-cite-export-processors').
>
> References are displayed with the "print_bibliography" keyword. It is
> possible to add parameters to its value, as some export processors could
> make use of them.
> --8<---cut here---end--->8---
>
> Please let me know if there are any objections to the merge.
>
> Regards,
> --
> Nicolas Goaziou
>
Re: modify citation links in a derived HTML backend
On 2021-07-03, Matt Price wrote: > I've added some comments in the issue you linked to, but in the meantime > I've also come up with what seems to be at least a semi-viable hack for > adding native CSL citation support to org-re-reveal. It involves creating > two new variables and then let-setting `citeproc-fmt--formatters-alist` in > `org-re-reveal-export-to-html`. Something similar could presumably be done > in other derived backends. > > I find it quite hackish and I don't know whether perhaps some more general > solution could be found, but in any case here is the code, which I have > inserted into org-re-reveal.el locally: Thank you for sharing your code, Matt! What is the general state of this new citation handling with respect to export backends? Did you create the settings for HTML from scratch or did you take inspiration from HTML export functionality? I guess that basic support should go into ox-html, while small modifications could than take care of specifics for reveal.js presentations... Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: modify citation links in a derived HTML backend
On 2021-07-02, Matt Price wrote: > Hi, > > (cc:ing Jens L. in case this is relevant for his dev work on org-re-reveal). Hi Matt, just a quick reply: Yes, that is certainly relevant for me, but I do not have the time to investigate this at the moment. Note that I use references with org-ref and org-re-reveal-ref (for which Bruce opened an issue for org-cite support [1]). Currently, I configure org-ref-ref-html (although its doc string suggests otherwise). Best wishes Jens [1] https://gitlab.com/oer/org-re-reveal-ref/-/issues/2 smime.p7s Description: S/MIME cryptographic signature
Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag
On 2021-04-20, Tim Visher wrote: > I guess regardless it sounds like if I were to go to the trouble of making > a patch for this it would be good to make sure that it was behind an option > and probably defaulting to the current HEAD behavior of including the ASCII > markup with an option to strip the non-word characters from it. That would be great. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag
On 2021-04-19, Kyle Meyer wrote: > Tim Visher writes: > >> Unfortunately, the title now is essentially the exact text of the org >> heading, which is awkward in terms of readability for a general audience >> (and probably for SEO etc.). I know I said in my original message that I >> think stripping all the markup characters would be going too far but now I >> think I've come full circle and rendering the title as nothing but the >> plain text without any markup information feels like the right solution >> given what the title is supposed to convey. >> >> So, would we be willing to accept a patch to that effect? :) > > I don't have an informed opinion about the above, but providing a patch > might prompt those that do (including TEC, the author of the above > commit, as well as Jens, who provided reviews) to give their input. The following is not a strong opinion: The author writes “what the title is supposed to convey”. If there is *emphasis*, why not export that as ASCII markup to HTML? With an additional option, authors could choose. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] tweaks to ox-html style
On 2021-02-13, Timothy wrote: > Jens Lechtenboerger writes: > >> On 2021-02-12, Jens Lechtenboerger wrote: >> >>> I do not know why the CDATA lines exist. I don’t see a reason to >>> keep them (patch 0001), but that might be a lack of understanding on >>> my part. >> >> OK, that is probably for XHTML, where < and & are only allowed >> inside CDATA sections. >> >> Timothy, did you try to validate XHTML output? > > If you look at the commit message for 001, you can see the following: > >> remove CDATA strings, as they are now >> considered obsolete --- see >> https://developer.mozilla.org/en-US/docs/Web/API/CDATASection#specifications > > Does that page clear things up for you? No, sorry, I don’t get it. I see: “Re-added in issue #295 due to web breakage” > I did a bit more googling and found > https://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5 > which mentions CDATA: > >> The CDATA code is then seen as text by the HTML parser (and can thus >> interfere with the scripting or styling language!), while the XML >> parser sees the content as text without markup semantics. > > In other words, CDATA allows you to keep XML comparability, Exactly. In fact, the “&” in the magnet URI should be “” or it might be placed into the CDATA section. > but now breaks strict HTML comparability. What do you mean? If I use html5 as HTML_DOCTYPE, the validator at https://validator.w3.org/nu/ does not complain. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] tweaks to ox-html style
On 2021-02-12, Jens Lechtenboerger wrote: > I do not know why the CDATA lines exist. I don’t see a reason to > keep them (patch 0001), but that might be a lack of understanding on > my part. OK, that is probably for XHTML, where < and & are only allowed inside CDATA sections. Timothy, did you try to validate XHTML output? Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] tweaks to ox-html style
On 2021-02-12, Kyle Meyer wrote: > TEC writes: > >> Hi All, >> >> This is just some tweaks to the styling in ox-html that I think may >> appeal (and prevent ridiculously long lines on non-small displays, which >> are an issue for legibility). >> >> I also took the opportunity to remove the (obsolete) CDATA strings and >> make the CSS more consistently formatted. If you don't want this to >> get its own commit, please just squash it. >> >> Style changes: >> - Restrict max content width, and centre >> - tweak styling of source code blocks > > I'm sure there are plenty of opinionated ox-html users on the list. Is > anyone willing to provide feedback on this series? Please don't assume > you need commit access to provide reviews. Hi there, I do not know why the CDATA lines exist. I don’t see a reason to keep them (patch 0001), but that might be a lack of understanding on my part. Patch 0003 is about whitespace fixes. Patches 0002, 0004, 0005 change defconst styling. I don’t have a strong opinion here. However, if they are changed now, what about turning them into defcustoms? Then each of us would be entitled to their own opinion ;) The docstring for org-html-head-include-default-style says that org-html-style-default (a defconst proposed to be changed here) should not be changed. Why not? Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
On 2021-01-14, TEC wrote: > TEC writes: > >>> Sorry, I still see the flycheck warning and "amp;" for "&". >> Maybe I accidently sent you the old patches? I'll check tomorrow. > > Hah, I check and guess what I see? The changes were unstaged . > > Sorry about that, here's an actual revision. This looks fine to me. Many thanks! Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
On 2021-01-10, TEC wrote: > Jens Lechtenboerger writes: > >> On line 1432 I get this suggestion from flycheck: >> There should be two spaces after a period (emacs-lisp-checkdoc) >> >> More importantly, I just realized that for author information, >> org-html-plain-text is applied twice, leading to "amp;" when >> translating "&". (Once inside org-html-meta-tags-default, then in >> org-html--build-meta-entry.) This should not happen. >> >> Best wishes >> Jens > > Fixed. [exhales] Sorry, I still see the flycheck warning and "amp;" for "&". Please try with: "#+AUTHOR: Foo & Bar" In org-html-meta-tags-default, function org-html-plain-text replaces "&" with "", and in org-html--build-meta-entry, function org-html-encode-plain-text replaces "&" once more. I suggest to remove org-html-plain-text from org-html-meta-tags-default. Best wishes Jens
Re: [PATCH] Enhance org-html--build-meta-info
On 2021-01-04, TEC wrote: > Jens Lechtenboerger writes: > >> org-html--build-meta-entry and org-html--build-meta-info include some long >> lines. > > Hehe. We've had a lot of back-and-forth haven't we. > At least it feels like it's coming to a close now. On line 1432 I get this suggestion from flycheck: There should be two spaces after a period (emacs-lisp-checkdoc) More importantly, I just realized that for author information, org-html-plain-text is applied twice, leading to "amp;" when translating "&". (Once inside org-html-meta-tags-default, then in org-html--build-meta-entry.) This should not happen. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
On 2021-01-03, TEC wrote: > Jens Lechtenboerger writes: > >> The doc strings of org-html-meta-tags and org-html-meta-tags-default >> need to be updated, they still mention author and title. > > Ah, yep. Fixed. > >> Also, please try checkdoc ;) > > Ahhh yes. Actually, I use flycheck (https://www.flycheck.org/), which displays warnings right away. org-html--build-meta-entry and org-html--build-meta-info include some long lines. For org-html-meta-tags-default, I suggest this as last line for the doc string (typos, active voice): Use document's plist INFO to derive relevant information for the tags. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
On 2021-01-03, TEC wrote: > After considering the information passed to a meta info generation > function, I'm now in agreement with you that just passing `info' is the > most sensible way forward. Hi Timothy, great, thanks :-) > Attached is a (final?) set of patches, which is as described. The doc strings of org-html-meta-tags and org-html-meta-tags-default need to be updated, they still mention author and title. Also, please try checkdoc ;) Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
On 2020-12-20, TEC wrote: > Jens Lechtenboerger writes: > >>> For people who want to customise this to add metadata, the page title is >>> something they're probably interested in. >> >> What metadata would you derive from the title? > > In my earlier example, I use the "og:title" property. I see. Maybe the doc string could explain such a use case? (I do not understand the benefit of adding that redundantly to an HTML page, but that is not our topic here.) >>> If so, I think it's work giving the title processed by >>> org-html--build-meta-info as it's not so simple as >>> (plist-get info :title). >> >> Extracting it from ~info~ might be more flexible as it would not be >> tied to the current implementation. > > My thoughts are just that its seems like title/author may be handy, and > we've already worked those out, so why not just pass them along? > > Could probably reduce to just info, not sure what's best though. My personal view: If those attributes are present in the default value, they should be used or their use should at least be explained. > Other than this, is there anything else you think might be worth > considering before merging? No suggestions from my side. Thank you for your work! Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
On 2020-12-16, TEC wrote: > Jens Lechtenboerger writes: >>> Maybe it should be applied to the rest (in ~org-html--build-meta-info~)? >>> I'm not sure. >> >> I’m not sure either. Maybe people expect their typed characters, >> maybe not. This might call for a new variable. > > I'm tempted to leave the current behaviour as-is, and then we can > introduce a new variable if we want later :) I agree. >> I like the new variant much better. However, I still do not >> understand why you pass the title into org-html-meta-tags-default >> just to ignore it. The title is already dealt with elsewhere, isn’t >> it? > > For people who want to customise this to add metadata, the page title is > something they're probably interested in. What metadata would you derive from the title? > If so, I think it's work giving the title processed by > org-html--build-meta-info as it's not so simple as > (plist-get info :title). Extracting it from ~info~ might be more flexible as it would not be tied to the current implementation. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
Hello everyone, On 2020-12-15, TEC wrote: > Jens Lechtenboerger writes: > >> [title export being dodgy, how about treating like author?] > > Yep, ~org-element-interpret-data~ is necessary. I found that wrapping it > in ~org-html-plain-text~ seems better again though, as it encodes > entities like "---" (org) to "", and doesn't seem to introduce > any nested tags. I've also applied this to the author field as a result. I like this! > Maybe it should be applied to the rest (in ~org-html--build-meta-info~)? > I'm not sure. I’m not sure either. Maybe people expect their typed characters, maybe not. This might call for a new variable. I like the new variant much better. However, I still do not understand why you pass the title into org-html-meta-tags-default just to ignore it. The title is already dealt with elsewhere, isn’t it? Some comments raise complaints by checkdoc (lines too long, no sentence in fist line). (Actually, the file has more problems in that regard.) Many thanks for your continued work! Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
Hi everybody, On 2020-12-14, Bastien wrote: > Hi Timothy, > > TEC writes: > >> Thanks for testing this :) I haven't forgotten about this. > > Let's wait for Jens feedback on this patch, since he took care of > testing it so far. I exported this: #+begin_src org ,#+TITLE: A title with *bold* index_1^2 and characters &ß<" ,#+AUTHOR: An /emphasized/ "anonymous" author_1^2 with [[https://example.org][hyperlink]] and characters &ß<" ,#+DESCRIPTION: A description_1^2 with /emphasis/ and [[https://example.org][hyperlink]] and characters &ß<" ,#+KEYWORDS: key, wörd, *bold*, sub_script Test #+end_src The title now exports follows, which needs fixing: A title with What about treating the title like the author? (Again, Org mode currently produces invalid HTML as nested sub-elements are produced inside the title element.) The keywords export as follows, where the name attribute is missing: The current lambda functions in org-html-meta-tags all accept three arguments, where the first one is ignored in all cases. The second one is used in exactly one case. Why not add four calls to org-html--build-meta-entry (for author, description, keywords, generator) in org-html--build-meta-info? Best wishes Jens
[SUGGESTION] Allow EXPORT_FILE_NAME to use elisp
Dear all, I wrote a patch that allows the users to generate the exported filename via elisp in EXPORT_FILE_NAME. This suggestion encourages to reuse configuration (e.g. the document version or title) in the export filename. A common use case when writing documentation is that different versions of the document will be exported over time. These are then distributed, e.g. via e-mail or archived. By allowing the user to derive descriptive names during export exchange of the document is greatly simplified. E.g. the following excerpt will create a filename that contains the date of export, the document title and the document version: #+TITLE: My wonderful document #+X-DOCUMENT-VERSION: 0.2-snapshot #+EXPORT_FILE_NAME: `(format "%s-%s (v%s)" (org-format-time-string "%Y-%m-%d_%Hh%Mm" (org-current-time)) (org-macro--find-keyword-value "TITLE") (org-macro--find-keyword-value "X-DOCUMENT-VERSION"))` Including the patch would make the life of "document writers" easier by improving the consistency of their work. Just including the document version in the filename would make it easier to exchange documents with others. Allowing pure lisp is just the next step. The gist of the patch is attached below. The whole patch is still on GitHub. As soon as I have the papers with the fsf signed, I can send the whole patch. SECURITY CONSIDERATION: Since running elisp on export is a security risk I am looking for advice on how to make sure the user knows. Any suggestions on how to achieve that? https://github.com/neuhalje/org-mode/compare/master...eval_export_filename diff --git a/lisp/ox.el b/lisp/ox.el index 6dd2cd4a0..b79880666 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -6147,6 +6147,14 @@ to `:default' encoding. If it fails, return S." (plist-get translations :default) s))) +(defconst org-export--backquote-lisp-expression-regexp + "^[[:space:]]*`\\(.*\\)`[[:space:]]*$" + "A regexp to recognize an anchored lisp-expression between backticks. + +Spaces before and after the backticks are ignored. + +The syntax of the expression is not validated.") + ;;; Asynchronous Export @@ -6390,6 +6398,16 @@ or FILE." (or (and (functionp post-process) (funcall post-process file)) file)) +(defun org-export-output-file-name--expand-name (file-name) + "If the filename is surrounded by `EXPR` then EXPR is evaluated and returned. + Otherwise return FILE-NAME" + (if (string-match org-export--backquote-lisp-expression-regexp file-name) + (let ((expression (match-string 1 file-name))) + (eval (car (read-from-string expression))) + ) +file-name) +) + (defun org-export-output-file-name (extension subtreep pub-dir) "Return output file's name according to buffer specifications. @@ -6400,6 +6418,16 @@ With a non-nil optional argument SUBTREEP, try to determine output file's name by looking for \"EXPORT_FILE_NAME\" property of subtree at point. +If the filename (without extension) is enclosed in backticks, then +the text between the backticks is evaluated and the result is taken +as file name. + +E.g. + +#+EXPORT_FILE_NAME: `(format \"This is a %s\" \"test\")` + +will evaluate to \"This is a test\". + When optional argument PUB-DIR is set, use it as the publishing directory. @@ -6407,7 +6435,7 @@ Return file name as a string." (let* ((visited-file (buffer-file-name (buffer-base-buffer))) (base-name (concat - (file-name-sans-extension + (org-export-output-file-name--expand-name (file-name-sans-extension (or ;; Check EXPORT_FILE_NAME subtree property. (and subtreep (org-entry-get nil "EXPORT_FILE_NAME" 'selective)) @@ -6426,7 +6454,7 @@ Return file name as a string." ;; Can't determine file name on our own: ask user. (read-file-name "Output file: " pub-dir nil nil nil - (lambda (n) (string= extension (file-name-extension n t)) + (lambda (n) (string= extension (file-name-extension n t))) extension)) (output-file ;; Build file name. Enforce EXTENSION over whatever user
Re: Reply-All noise
On 2020-10-09, to...@tuxteam.de wrote: > On Fri, Oct 09, 2020 at 10:10:41PM +0200, to...@tuxteam.de wrote: >> On Fri, Oct 09, 2020 at 09:24:34PM +0200, c.bu...@posteo.jp wrote: >> > Hi, > > [...] > >> There is no clear-cut answer to that [...] > > You might also want to experiment with setting the Mail-Followup-To: > header [1] in your mails to the list (I have no experience with that, > so take with a fist of salt!). > [...] > [1] https://cr.yp.to/proto/replyto.html That is what I’m using with Gnus, see [2]. In my case, message-subscribed-addresses contains "emacs-orgmode@gnu.org". With that setting I say: Please send replies just to the list, not to me individually. Best wishes Jens [2] https://www.gnu.org/software/emacs/manual/html_node/message/Mailing-Lists.html
Re: [PATCH] Enhance org-html--build-meta-info
On 2020-09-28, TEC wrote: > Jens Lechtenboerger writes: > >> On 2020-09-28, TEC wrote: >> >>> Jens Lechtenboerger writes: >>>> Also, in org-html--build-meta-info you call >>>> org-html-encode-plain-text with two arguments, but it just accepts >>>> one. >>> >>> ? No I don't. >> >> Your patch contains this: >> >> + (let* ((title (org-html-encode-plain-text (plist-get info :title) >> info)) > > O, that's the bit you were referring to. That's just copied from > the > current state (iirc). Anyway, I dropped the second argument. Without the second argument I get an error “Wrong type argument: stringp,” when evaluating regular expressions against the cons cell that is returned as title. As I see now, author and title are cons cells, which is why org-element-interpret-data is necessary to produce strings with Org syntax. Also, after fixing the title, I get “wrong-type-argument sequencep utf-8” for “(concat "text/html;charset=" charset)”. Best wishes Jens
