[O] Bug: agenda-tag-filter-preset not working, when ":newline" inside a tag radiogroup [9.2.3 (9.2.3-20-g31873e-elpaplus @ /home/msm/.emacs.d/elpa/org-plus-contrib-20190527/)]
--text follows this line--
I use the org-agenda-tag-filter-preset in my custom agenda
commands.
This breaks, when there is a (:newline) inside a radiogroup in
org-tag-alist. When calling the agenda command, it gives the error:
"mapcar: Wrong type argument: char-or-string-p, :newline"
and the agenda gets built without the filter-preset.
The minimal configuration (via customize-interface) below, shows the state
triggering the error. Remove the (:newline) from inside the radiogroup in
org-tag-alist and the filter-preset works again.
Please fix it, so the filter-presets can be used together with
(:newline) in tag-radiogroups.
Questions anytime..
Thanks for your effort and great piece of software!
-Jens
Emacs : GNU Emacs 26.2 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2019-04-12
Package: Org mode version 9.2.3 (9.2.3-20-g31873e-elpaplus @
/home/msm/.emacs.d/elpa/org-plus-contrib-20190527/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-agenda-files '("~/org-test.org")
org-tag-alist '((:startgroup) ("domain" . 32) (:grouptags) ("work" . 119)
(:newline) ("private" . 112)
(:endgroup) (:newline) ("other" . 32))
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php)
("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer" . latex) ("calc" .
fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp" . emacs-lisp)
("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("id" :follow org-id-open) ("eww" :follow eww :store
org-eww-store-link)
("rmail" :follow org-rmail-open :store org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link :export
org-irc-export)
("info" :follow org-info-open :export org-info-export :store
org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete
org-bbdb-complete-link
:store org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys") ("file+emacs")
("doi" :follow org--open-doi-link) ("elisp" :follow
org--open-elisp-link)
("file" :complete org-file-complete-link)
("ftp" :follow (lambda (path) (browse-url (concat "ftp:" path
("help" :follow org--open-help-link)
("http" :follow (lambda (path) (browse-url (concat "http:" path
("https" :follow (lambda (path) (browse-url (concat "https:" path
("mailto" :follow (lambda (path) (browse-url (concat "mailto:";
path
("news" :follow (lambda (path) (browse-url (concat "news:"; path
("shell" :follow org--open-shell-link))
org-agenda-custom-commands '(("n" "Agenda and all TODOs" ((agenda "" nil)
(alltodo "" nil))
((org-agenda-tag-filter-preset (quote ("-work")
)
)
[Orgmode] Typo in website worg/org-blog-articles.php
Hi, in http://orgmode.org/worg/org-blog-articles.php> is a link "Using org-mode with ikiwiki". The URl reads http://www.golden-gryphon.com/blog/manoj/blog/2008/06/08/Using_org-mode_with_Ikiwiki/%20%3E%3E>. But the %20%3E%3E ( >>) is wrong here and should be removed. Thanks -- Jens Kubieziel http://www.kubieziel.de FdI#365: Spannung Geruch nach Ozon und evt. Stickoxiden (Vinzent Höfler) signature.asc Description: Digital signature ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [O] canonical way to go beginning of a link
> but in things like font-lock it seems slow compared to a > regexp. I have not found a reliable regexp approach though. say > I want to search back for "cite:" with point at the ^ position > below: > some text cite:a-key > ^ > If I run (re-search-backward "cite:") at the point above, it does not go to > the point 2 characters back. > Any ideas? Given this setting: some more text cite:a-key some text cite:a-key ^ When you run (re-search-backward "cite:") at the point above, the result is as follows: some more text cite:a-key some text cite:a-key ^ This is exactly what I expected it to act. In your example above, the whole search pattern could not be found in ist entirety from the indicated point on, so it could not be found at all and point is not moved. Maybe it is a good idea to move point forward for at least count of chars in search pattern before the search executes? Greets, Jens Haustedt
[O] Bug: Missing command description in org-mode manual [8.2.10 (release_8.2.10 @ c:/Users/j.haustedt/AppData/Roaming/.emacs.d/elpa/org-20150119/)]
aybe)
org-todo-keywords '((sequence "TODO(t)" "STARTED(s!)" "WAITING(w@/!)" "APPT(a)"
"PROJ(p)" "DELEGATED(g@/!)" "|" "DONE(d!)"
"ZKTO(z)" "CANCELED(c@)")
)
org-agenda-files '("~/org/start.org" "~/org/RandomAccess.org")
org-drawers '("PROPERTIES" "CLOCKTABLE" "LOGBOOK" "CLOCK")
org-agenda-finalize-hook '(my-org-agenda-to-appt voice-recordings)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-todo-keyword-faces '(("TODO" :foreground "#b70101" :weight bold) ("STARTED"
:foreground "#b70101" :weight bold)
("APPT" :foreground "sienna"
:weight bold) ("PROJ" :foreground "blue" :weight bold)
("ZKTO" :foreground "orange"
:weight bold) ("WAITING" :foreground "orange" :weight bold)
("DONE" :foreground "forestgreen"
:weight bold)
("DELEGATED" :foreground
"forestgreen" :weight bold) ("CANCELED" . shadow))
org-agenda-start-with-clockreport-mode t
org-confirm-shell-link-function 'yes-or-no-p
)
Dear Sirs,
in the description of the date/time prompt, a section describes the
control of the calendar from the minibuffer.
There, a description of scrolling the calendar by 1 year is missing. The
keyboard shortcut is M-S-/ and works perfectly.
Best regards, Jens Haustedt
--
Pflichtinformationen: siehe www.euroimmun.de/impressum.htm
[O] Bug: Agenda clocktable-report properties columns not populated anymore [9.0.7 (9.0.7-elpa @ h:/somefolder/myuser/.emacs.d/elpa/org-20170515/)]
ashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-agenda-time-grid nil
org-yank-adjusted-subtrees t
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines org-optimize-window-after-visibility-change)
org-agenda-hide-tags-regexp ".*"
org-agenda-start-with-log-mode t
org-agenda-start-with-clockreport-mode t
org-agenda-finalize-hook '(org-agenda-to-appt)
org-clock-clocktable-language-setup '(("de" "Datei" "E" "Zeitstempel"
"Kopfzeile" "Dauer" "GESAMT" "Gesamtdauer" "Dateizeit" "Erstellt am")
("en" "File" "L" "Timestamp" "Headline" "Time" "ALL" "Total time"
"File time" "Clock summary at")
("es" "Archivo" "N" "Fecha y hora" "Tarea" "Tiempo" "TODO" "Tiempo
total" "Tiempo archivo" "Clock summary at")
("fr" "Fichier" "N" "Horodatage" "En-tête" "Durée" "TOUT" "Durée
totale" "Durée fichier" "Horodatage sommaire à")
("nl" "Bestand" "N" "Tijdstip" "Hoofding" "Duur" "ALLES" "Totale
duur" "Bestandstijd" "Clock summary at"))
org-ditaa-eps-jar-path
"h:/somefolder/myuser/.emacs.d/elpa/contrib/scripts/DitaaEps.jar"
org-use-property-inheritance t
org-download-annotate-function 'org-download-annotate-default
org-todo-keywords '((sequence "ZU-ERLEDIGEN" "IN-ARBEIT" "UNTERBROCHEN"
"|" "ERLEDIGT" "STORNIERT")
(sequence "WARTEN-RÜCKM-KUNDE" "WARTEN-RÜCKM-INTERN" "WARTEN-WARE" "|"))
org-hide-emphasis-markers t
org-clock-report-include-clocking-task t
org-agenda-span 'day
org-catch-invisible-edits 'error
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-ditaa-jar-path "H:/OtherFolder/Ditaa/ditaa0_9.jar"
org-startup-truncated nil
org-link-parameters '(("id" :follow org-id-open) ("rmail" :follow
org-rmail-open :store org-rmail-store-link) ("mhe" :follow org-mhe-open
:store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link) ("info"
:follow org-info-open :export org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete
org-bbdb-complete-link :store org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys") ("file+emacs")
("outlook" :follow org-outlook-open :export nil) ("doi" :follow
org--open-doi-link)
("elisp" :follow org--open-elisp-link) ("file" :complete
org-file-complete-link) ("ftp" :follow (lambda (path) (browse-url (concat
"ftp:" path
("help" :follow org--open-help-link) ("http" :follow (lambda (path)
(browse-url (concat "http:" path
("https" :follow (lambda (path) (browse-url (concat "https:" path
("mailto" :follow (lambda (path) (browse-url (concat "mailto:"; path
("message" :follow (lambda (path) (browse-url (concat "message:"
path ("news" :follow (lambda (path) (browse-url (concat "news:"; path
("shell" :follow org--open-shell-link))
org-babel-load-languages '((ditaa . t))
org-agenda-files '("~/org/active/internal.org" "~/org/active/private.org"
"H:/Nicefolder/kunden.org")
org-clock-out-hook '(org-clock-remove-empty-clock-drawer))
--
Mit freundlichen Grüssen / With kind regards:
Jens Lange
Re: [O] Help with sharing emacs-org presentation
On 2018-10-25, Feiming Chen wrote: > I gave a talk on emacs-org in a local workshop (Government Advances > in Statistical Programming) in Washington D.C. yesterday. I'd like to > share the slides and org source file with the community (see attached). Thanks for sharing! I wonder why you stress the following: - Not good for collaborative use (unlike Microsoft Office). - Good for private, non-collaborative use. My view is the opposite: Org mode is excellent for collaboration as it is plain text, suitable for diff/merge in Git repositories. Thanks to the separation of contents from style, cross-organizational collaboration is possible, which I find *very* hard with any office tool: Changing a document master leads to all kinds of layout destruction. Switching to a different corporate identity is just hard with what-you-see-is-what-you-get tools. In contrast, Org mode can be a basis for what is called Single Sourcing [1] in the context of technical writing. You can see my approach towards Open Educational Resources with Org mode at [2]. Best wishes Jens [1] http://rockley.com/articles/Single_Sourcing_and_Technology.pdf [2] https://gitlab.com/oer/OS
[O] PATCH: Allow class attribute for headline in HTML export
Dear all,
the attached patch allows to add a class attribute to headline
elements in HTML export. Is that acceptable for inclusion?
Best wishes
Jens
P.S. The change is tiny, but I assigned copyright to the FSF in
2015.
>From e8f16b04903bc32c4ea006727c82dbcb40b591a8 Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger
Date: Sun, 2 Dec 2018 19:05:55 +0100
Subject: [PATCH] ox-html.el: New property HTML_HEADLINE_CLASS for class of
headline
* lisp/ox-html.el (org-html-headline): Add new property
HTML_HEADLINE_CLASS to assign class attribute to headline.
* doc/org-manual.org: Document new property HTML_HEADLINE_CLASS.
---
doc/org-manual.org | 6 +-
lisp/ox-html.el| 5 -
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 458e59a4a..9d14c4cdc 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12780,7 +12780,11 @@ external file.
In order to add styles to a sub-tree, use the =HTML_CONTAINER_CLASS=
property to assign a class to the tree. In order to specify CSS
styles for a particular headline, you can use the ID specified in
-a =CUSTOM_ID= property.
+a =CUSTOM_ID= property or =HTML_HEADLINE_CLASS= as described next.
+
+#+cindex: @samp{HTML_HEADLINE_CLASS}, property
+In order to assign a class to a headline, use the =HTML_HEADLINE_CLASS=
+property.
Never change the ~org-html-style-default~ constant. Instead use other
simpler ways of customizing as described above.
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 6a81be126..d9d976753 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2608,6 +2608,7 @@ holding contextual information."
(format "\n" html-type
;; Standard headline. Export it as a section.
(let ((extra-class (org-element-property :HTML_CONTAINER_CLASS headline))
+ (headline-class (org-element-property :HTML_HEADLINE_CLASS headline))
(first-content (car (org-element-contents headline
(format "<%s id=\"%s\" class=\"%s\">%s%s\n"
(org-html--container headline info)
@@ -2616,9 +2617,11 @@ holding contextual information."
(concat (format "outline-%d" level)
(and extra-class " ")
extra-class)
- (format "\n%s\n"
+ (format "\n%s\n"
level
id
+ (when headline-class
+ (format " class=\"%s\"" headline-class))
(concat
(and numberedp
(format
--
2.17.1
Re: [O] PATCH: Allow class attribute for headline in HTML export
On 2018-12-02, at 19:25, Jens Lechtenboerger wrote:
> Dear all,
>
> the attached patch allows to add a class attribute to headline
> elements in HTML export. Is that acceptable for inclusion?
In that patch, "when" should have been "if", sorry. Fixed version
attached.
Best wishes
Jens
>From 068fb45f5276d61e86271988efbcf6c29e08c411 Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger
Date: Sun, 2 Dec 2018 20:25:38 +0100
Subject: [PATCH] ox-html.el: New property HTML_HEADLINE_CLASS for class of
headline
* lisp/ox-html.el (org-html-headline): Add new property
HTML_HEADLINE_CLASS to assign class attribute to headline.
* doc/org-manual.org: Document new property HTML_HEADLINE_CLASS.
---
doc/org-manual.org | 6 +-
lisp/ox-html.el| 6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 458e59a4a..9d14c4cdc 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12780,7 +12780,11 @@ external file.
In order to add styles to a sub-tree, use the =HTML_CONTAINER_CLASS=
property to assign a class to the tree. In order to specify CSS
styles for a particular headline, you can use the ID specified in
-a =CUSTOM_ID= property.
+a =CUSTOM_ID= property or =HTML_HEADLINE_CLASS= as described next.
+
+#+cindex: @samp{HTML_HEADLINE_CLASS}, property
+In order to assign a class to a headline, use the =HTML_HEADLINE_CLASS=
+property.
Never change the ~org-html-style-default~ constant. Instead use other
simpler ways of customizing as described above.
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 6a81be126..b043ab8fd 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2608,6 +2608,7 @@ holding contextual information."
(format "\n" html-type
;; Standard headline. Export it as a section.
(let ((extra-class (org-element-property :HTML_CONTAINER_CLASS headline))
+ (headline-class (org-element-property :HTML_HEADLINE_CLASS headline))
(first-content (car (org-element-contents headline
(format "<%s id=\"%s\" class=\"%s\">%s%s\n"
(org-html--container headline info)
@@ -2616,9 +2617,12 @@ holding contextual information."
(concat (format "outline-%d" level)
(and extra-class " ")
extra-class)
- (format "\n%s\n"
+ (format "\n%s\n"
level
id
+ (if headline-class
+ (format " class=\"%s\"" headline-class)
+ "")
(concat
(and numberedp
(format
--
2.17.1
Re: [O] PATCH: Allow class attribute for headline in HTML export
On 2018-12-02, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> From 068fb45f5276d61e86271988efbcf6c29e08c411 Mon Sep 17 00:00:00 2001 >> From: Jens Lechtenboerger >> Date: Sun, 2 Dec 2018 20:25:38 +0100 >> Subject: [PATCH] ox-html.el: New property HTML_HEADLINE_CLASS for class of >> headline > > Thank you. > >> * lisp/ox-html.el (org-html-headline): Add new property >> HTML_HEADLINE_CLASS to assign class attribute to headline. > > Doesn't CUSTOM_ID already fit the bill? Good morning, I plan to use that for a table-of-contents plugin [1] of reveal.js, which looks for class attributes inside h-elements to exclude them selectively. Best wishes Jens [1] https://github.com/e-gor/Reveal.js-TOC-Progress
Re: [O] PATCH: Allow class attribute for headline in HTML export
Hello, On 2018-12-04, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> I plan to use that for a table-of-contents plugin [1] of reveal.js, >> which looks for class attributes inside h-elements to exclude them >> selectively. > > Then I suggest to submit it to "ox-reveal" > (https://github.com/yjwen/org-reveal/) instead. Function org-reveal-headline calls org-html-headline to generate h-elements. Of course, I could parse the generated HTML in ox-reveal and add a class attribute based on org properties, but doing so in ox-html seems much cleaner to me. (Besides, given the current situation of ox-reveal [1], that change would only make it into my fork, not into the original project.) Best wishes Jens [1] https://github.com/yjwen/org-reveal/issues/349
Re: [O] PATCH: Allow class attribute for headline in HTML export
Hello! On 2018-12-08, at 12:46, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> Function org-reveal-headline calls org-html-headline to generate >> h-elements. Of course, I could parse the generated HTML in >> ox-reveal and add a class attribute based on org properties, but >> doing so in ox-html seems much cleaner to me. (Besides, given the >> current situation of ox-reveal [1], that change would only make it >> into my fork, not into the original project.) > > Fair enough. I applied your patch on "next" branch. Thank you, I really appreciate this change! Best wishes Jens
[O] PATCH: Extract HTML attributes from link if present
Hi there, for HTML export, attributes are added to links with what is called a “HACK” in a comment in ox-html.el: Attribute :attr_html is read from the parent, to be transferred to the first link. That mechanism can used to assign attributes to the first link in each paragraph/sentence. For org-reveal, I would like to assign computed classes to links in general (several per paragraph). The attached patch extends the current functionality to add attributes of the link to those of the parent. Could that please be included? Best wishes Jens >From 3ac50ac3a3c8951d59a1d30b047ae0407731b789 Mon Sep 17 00:00:00 2001 From: Jens Lechtenboerger Date: Sat, 8 Dec 2018 16:44:06 +0100 Subject: [PATCH] ox-html.el: Export attributes specified with :attr_html for links * lisp/ox-html.el (org-html-link): Export :attr_html from link --- lisp/ox-html.el | 30 ++ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 6a81be126..bbe38d8e2 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -3045,19 +3045,25 @@ INFO is a plist holding contextual information. See "#" (org-publish-resolve-external-link option path t)) (t raw-path))) - ;; Extract attributes from parent's paragraph. HACK: Only do - ;; this for the first link in parent (inner image link for - ;; inline images). This is needed as long as attributes - ;; cannot be set on a per link basis. (attributes-plist - (let* ((parent (org-export-get-parent-element link)) - (link (let ((container (org-export-get-parent link))) - (if (and (eq (org-element-type container) 'link) - (org-html-inline-image-p link info)) - container - link - (and (eq (org-element-map parent 'link 'identity info t) link) - (org-export-read-attribute :attr_html parent + (org-combine-plists + ;; Extract attributes from parent's paragraph. HACK: Only do + ;; this for the first link in parent (inner image link for + ;; inline images). This is needed as long as attributes + ;; cannot be set on a per link basis. + (let* ((parent (org-export-get-parent-element link)) + (link (let ((container (org-export-get-parent link))) + (if (and (eq (org-element-type container) 'link) + (org-html-inline-image-p link info)) + container + link + (and (eq (org-element-map parent 'link 'identity info t) link) + (org-export-read-attribute :attr_html parent))) + ;; Also add attributes from link itself. Currently, those need + ;; to be added programmatically before org-html-link is invoked, + ;; for example, by backends building upon HTML export, such as + ;; org-reveal. + (org-export-read-attribute :attr_html link))) (attributes (let ((attr (org-html--make-attribute-string attributes-plist))) (if (org-string-nw-p attr) (concat " " attr) "" -- 2.17.1
Re: [O] [PATCH] ox.el: Define subtitle macro
Hi there, On 2017-11-21, Nicolas Goaziou wrote: > For the record, I implemented a "keyword" macro (master branch). That has been in master for over a year now. Are there plans for inclusion in a release? (Or did I overlook that?) Best wishes Jens
[O] Quoting of macros with eval
Hi there,
given a macro like
#+MACRO: foo (eval (message "%s" $1))
I need to call {{{foo("text")}}} with Org mode 9.1.14-9-g131531-elpa.
On the master branch, that call will include the quotation marks as
part of the string, so I need to call {{{foo(text)}}} (documented in
the manual, but I didn’t notice that until now).
Could the master branch offer backward compatible functionality,
please? I’m thinking about checking for and removing leading and
trailing quotation marks...
Best wishes
Jens
[O] License information for figures in Org mode?
Hi there,
I’ve written code based on Org mode to generate Open Educational
Resources (OER, learning material under free licenses, typically
variants of Creative Commons), which include figures with proper
license attribution (source, author, license) [1]. If you ever wanted
to publish OER yourself, you are probably aware of the hassle of doing
that properly as figures usually do not embed license information,
which needs to be obtained and annotated separately.
Currently, I use Org macros to embed figures, e.g.:
#+BEGIN_SRC org
{{{reveallicense("./figures/org/jitt/JiTT-Java-MX.meta","33vh","figure fragment
appear")}}}
#+END_SRC
The meta file in the first argument uses an ad-hoc text format,
embedding a path for the figure along with licensing information
inspired by standard metadata vocabularies, e.g.:
#+BEGIN_SRC emacs-lisp
((filename . "./figures/org/jitt/JiTT-Java-MX.png")
(licenseurl . "https://creativecommons.org/licenses/by-sa/4.0/";)
(licensetext . "CC BY-SA 4.0")
(cc:attributionName . "Jens Lechtenbörger")
(cc:attributionURL . "https://gitlab.com/lechten";)
(dc:source .
"https://gitlab.com/oer/figures/blob/master/org/jitt/JiTT-Java-MX.org";)
(sourcetext . "GitLab")
(dc:title . "Improved Java MX understanding")
(texwidth . 0.9)
)
#+END_SRC
Currently, export to LaTeX (and, thus, PDF) and reveal.js (HTML with
RDFa) are supported (templates and the essential function
reveal-export-attribution are in [2]).
The above macro uses eval, whose syntax differs between released Org
mode versions and the master branch, which implies that I need to
reconsider my approach. Any ideas or interest how such functionality
could be integrated into Org mode in general?
Best wishes
Jens
[1] https://gitlab.com/oer/emacs-reveal
[2] https://gitlab.com/oer/emacs-reveal/blob/master/reveal-config.el
[O] Bug: LaTeX export of table with caption broken
Hi there,
when exporting a table with caption to LaTeX on the master branch,
invalid code is generated.
Example Org file:
#+CAPTION: Some text
| Col1 | Col2 |
|--+--|
| foo | bar |
The resulting tex file contains this, without table environment,
which is necessary for the use of captions:
begin{center}
\caption{Some text}
\begin{tabular}{ll}
Col1 & Col2\\
\hline
foo & bar\\
\end{tabular}
\end{center}
The above happens on the current master branch, but did already
happen last month on the next branch:
Org mode version 9.2 (release_9.2-193-ge7901c @
/usr/share/emacs/24.5/site-lisp/org/)
Org mode version 9.1.14 (release_9.1.14-1178-gdd26f0 @
/usr/share/emacs/24.5/site-lisp/org/)
In contrast, Org mode version 9.1.9 (release_9.1.9-65-g5e4542)
shipping with Emacs is fine, creating the following:
\begin{table}[htbp]
\caption{Some text}
\centering
\begin{tabular}{ll}
Col1 & Col2\\
\hline
foo & bar\\
\end{tabular}
\end{table}
Best wishes
Jens
Re: [O] Bug: LaTeX export of table with caption broken
On 2019-01-19, at 16:06, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> when exporting a table with caption to LaTeX on the master branch, >> invalid code is generated. > > Fixed. Thank you. Wow, that was lightning fast. Many thanks! Jens
[O] Key bindings for Org export back-ends?
Hi there, I need to assign a key to an Org export back-end. My first attempt ended in a conflict, so I’d like to collect a (full?) list. Built-in - iCalendar: c - HTML: h - Texinfo: i - LaTeX and Beamer: l - Man: M - Markdown: m - ODT: o - Org: O - Publish: P - Plain text: t Contrib (ox-bibtex, ox-extra, ox-confluence without keys): - Deck.js: d - Freemind: f - Groff: g - Taskjuggler: J - KOMA: k - RSS: r - s5: s Other: - ox-hugo [1]: H - org-opml [2]: m (conflict with Markdown) - org-reveal [3]: R - org-re-reveal [4]: r (conflict with RSS) - ox-rst [5]: r (conflict with RSS) - ox-slimhtml [6]: s (conflict with s5) So, these keys are taken: c, d, f, g, h, H, i, J, k, l, M, m, o, O, P, R, r, s, t Besides, SPC, DEL, C-a, C-b, C-f, C-n, C-p, C-s, C-v are taken. Anyone with additional back-ends and keys? Where could we document the resulting list? I’m thinking of changing org-re-reveal to p (for presentation) or v (as occurring letter). Or C-r? So far, no back-end uses the control key. Any reasons not to do this? Best wishes Jens [1] https://ox-hugo.scripter.co/ [2] https://github.com/org-opml/org-opml [3] https://github.com/yjwen/org-reveal [4] https://gitlab.com/oer/org-re-reveal [5] https://github.com/msnoigrs/ox-rst [6] https://github.com/balddotcat/ox-slimhtml
Re: [O] Key bindings for Org export back-ends?
On 2019-02-08, at 06:51, Kaushal Modi wrote: > On Fri, Feb 8, 2019, 3:28 AM Jens Lechtenboerger wrote: > >> - org-reveal [3]: R >> - org-re-reveal [4]: r (conflict with RSS) > > I see that org-re-reveal is based off org-reveal. So do you see a use case > where people would `require' both org-reveal and org-re-reveal? If not, > then using the same binding as that of org-reveal should be fine too. I don’t recommend that but org-re-reveal should allow for a parallel installation. Therefore, I would like to bind a different key. > I'm pretty sure there are many more Org backends out there. For example, I > have a little ox-minutes backend that uses the M binding (and overrides the > binding for ox-man, but that's fine for me as I don't use ox-man). > > We can start collecting a list of all Org backends on the Worg wiki. That's > a good idea. OK, let’s see whether additional input arrives. > But doing so in order to not override the binding of some > other backend might not be possible. Fair enough. At least some guidance will be given. >> Or C-r? So far, no back-end uses the >> control key. Any reasons not to do this? >> > > You could probably use C-, but one has to ensure that it doesn't > override the inbuilt bindings like C-s (C-c C-e C-s ..). Also, not sure if > that override would actually be effective. On my machine using "?\C-r" instead of "?r" as letter works, (resulting in integer number 18 in org-export-registered-backends). However, the Org Export Dispatcher shows "[^R]" as key, which is not ideal. Best wishes Jens
Re: [O] Key bindings for Org export back-ends?
On 2019-02-08, at 06:51, Kaushal Modi wrote: > On Fri, Feb 8, 2019, 3:28 AM Jens Lechtenboerger wrote: > >> - org-reveal [3]: R >> - org-re-reveal [4]: r (conflict with RSS) > > I see that org-re-reveal is based off org-reveal. So do you see a use case > where people would `require' both org-reveal and org-re-reveal? If not, > then using the same binding as that of org-reveal should be fine too. I don’t recommend that but org-re-reveal should allow for a parallel installation. Therefore, I would like to bind a different key. > I'm pretty sure there are many more Org backends out there. For example, I > have a little ox-minutes backend that uses the M binding (and overrides the > binding for ox-man, but that's fine for me as I don't use ox-man). > > We can start collecting a list of all Org backends on the Worg wiki. That's > a good idea. OK, let’s see whether additional input arrives. > But doing so in order to not override the binding of some > other backend might not be possible. Fair enough. At least some guidance will be given. >> Or C-r? So far, no back-end uses the >> control key. Any reasons not to do this? >> > > You could probably use C-, but one has to ensure that it doesn't > override the inbuilt bindings like C-s (C-c C-e C-s ..). Also, not sure if > that override would actually be effective. On my machine using "?\C-r" instead of "?r" as letter works, (resulting in integer number 18 in org-export-registered-backends). However, the Org Export Dispatcher shows "[^R]" as key, which is not ideal. Best wishes Jens
Re: [O] Key bindings for Org export back-ends?
On 2019-02-08, at 10:54, Kaushal Modi wrote: > On Fri, Feb 8, 2019 at 10:48 AM Thomas S. Dye wrote: > >> One place for the list of key bindings might be here: >> https://orgmode.org/worg/exporters/index.html >> > > That's a great idea! How about creating a single Org table with columns > like Name, Description, Binding, Core/Contributed, and then sort the rows > by the Binding column? > > We can leave the obsolete exporters section separate as it is right now. Should the description really go into a table? Or might the table just provide an overview before the current section “Core exporters”? Best wishes Jens
Re: [O] Key bindings for Org export back-ends?
On 2019-02-08, at 22:03, Jens Lechtenboerger wrote: > On 2019-02-08, at 10:54, Kaushal Modi wrote: > >> On Fri, Feb 8, 2019 at 10:48 AM Thomas S. Dye wrote: >> >>> One place for the list of key bindings might be here: >>> https://orgmode.org/worg/exporters/index.html >>> >> >> That's a great idea! How about creating a single Org table with columns >> like Name, Description, Binding, Core/Contributed, and then sort the rows >> by the Binding column? >> >> We can leave the obsolete exporters section separate as it is right now. > > Should the description really go into a table? Or might the table > just provide an overview before the current section “Core > exporters”? Actually, a similar table exists, marked as in progress: https://orgmode.org/worg/exporters/ox-overview.html Column “Worg Tutorial” is mostly empty. Column “Org-mode Manual” only contains entries for the upper half. Should we combine both into one, “Tutorial/Manual”? Or is such a table a futile goal given the potential amount of back-ends pointed out by Chuck in a parallel answer? Best wishes Jens
Re: [O] [RFC] Fixing link encoding once and for all
On 2019-02-24, Nicolas Goaziou wrote:
> Recently[1], issues about link escaping have resurfaced. I'd like to
> solve this once and for all.
Good morning,
I updated to Org mode version 9.2.1 (9.2.1-33-g029cf6-elpa @
/home/user/.emacs.d/elpa/org-20190225/).
When exporting the following link to LaTeX, the decoding fails.
--8<---cut here---start->8---
[[https://en.wikipedia.org/wiki/Red%E2%80%93black_tree][Red-black trees]]
--8<---cut here---end--->8---
The output is this:
--8<---cut here---start->8---
\href{https://en.wikipedia.org/wiki/Red\â\\black\_tree}{Red-black trees}
--8<---cut here---end--->8---
Previously, I got:
--8<---cut here---start->8---
\href{https://en.wikipedia.org/wiki/Red\%E2\%80\%93black\_tree}{Red-black trees}
--8<---cut here---end--->8---
Best wishes
Jens
Re: [O] [RFC] Fixing link encoding once and for all
On 2019-02-27, Nicolas Goaziou wrote: > Hello, > > Jens Lechtenboerger writes: > >> When exporting the following link to LaTeX, the decoding fails. >> >> --8<---cut here---start->8--- >> [[https://en.wikipedia.org/wiki/Red%E2%80%93black_tree][Red-black trees]] >> --8<---cut here---end--->8--- > > According to my suggestion in this thread, this link should be written > > [[https://en.wikipedia.org/wiki/Red%25E2%2580%2593black_tree][Red-black > trees]] > > i.e., either you wrote it by hand, or `org-insert-link' failed. I copied that from the address bar of my browser, probably two years ago. Today, I was surprised by a compilation failure. > With the \-escape solution suggested by Neil, it would be correctly > processed without additional change. Of course, that would entail other > difficulties. You mentioned Windows file names. I’m not affected by that. URLs in my Org files neither contain “[” nor “\” (but lots of “%”). So the suggestion by Neil would be fine for me. Best wishes Jens
Re: [O] [RFC] Fixing link encoding once and for all
Hi there, I like this proposal. On 2019-03-01, Nicolas Goaziou wrote: > 3. There will be some backward compatibility issues. We can add >a checker in Org Lint to catch most of those. For example, we could >look at URI where every percent is followed only by 25, 5B, and 5D. I do not understand this point. What is special about URIs where *only* those occur? Might compatibility issues not arise if those occur at all (while others such as %28 and %29 for parentheses might occur without problems as well)? Best wishes Jens
Re: [O] [RFC] Fixing link encoding once and for all
On 2019-03-01, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> On 2019-03-01, Nicolas Goaziou wrote: >> >>> 3. There will be some backward compatibility issues. We can add >>>a checker in Org Lint to catch most of those. For example, we could >>>look at URI where every percent is followed only by 25, 5B, and 5D. >> >> I do not understand this point. What is special about URIs where >> *only* those occur? Might compatibility issues not arise if those >> occur at all (while others such as %28 and %29 for parentheses might >> occur without problems as well)? > > If a URI seems percent encoded, but only uses %25, %5B and %5D as escape > combinations, there is a high chance that it is Org-encoded, and > therefore uses a deprecated syntax. We could send a warning to the user > in this case; they might want to clean the URI. > > OTOH, if there is %28, or %29, we are sure it isn't Org-encoded, and > therefore, the percent-encoding was intended right from the start (like > in your Wikipedia link). Thanks for the clarification. Makes sense. Best wishes Jens
Re: [O] Two bibliography slides using org-reveal
I created org-re-reveal-ref [1] based on my fork org-re-reveal for bibliographies with org-ref. I only use it for export to reveal.js and PDF, but HTML seems fine as well. That package is part of emacs-reveal [2]. Best wishes Jens [1] https://gitlab.com/oer/org-re-reveal-ref [2] https://gitlab.com/oer/emacs-reveal John Kitchin writes: > the bibliography export is not too fancy. It is defined in the function > org-ref-bibliography-format. > > I am not sure you can win, for latex export it doesn't make sense to put the > bibliography link in a heading. you might be able to add a specific reveal > export > option to the export function though. > > John > > --- > Professor John Kitchin > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu > > On Thu, Jul 25, 2019 at 9:55 AM Johannes Brauer > wrote: > > Yes, I have tried that and indeed then I get only one bib slide. But then, > in normal Html export, the bibliography appears under the preceding headline, > that’s ugly. > > > Am 25.07.2019 um 14:41 schrieb Fraga, Eric : > > > > I have no idea but, on the off-chance, maybe don't make that line a > > headline? > > -- > > Eric S Fraga via Emacs 27.0.50, Org release_9.2.4-399-g4e6222
Re: [O] Two bibliography slides using org-reveal
Johannes Brauer writes: > I downloaded [1] but when I try M-x load-library followed by > org-re-reveal-ref I get > "Cannot open load file: No such file or directory, org-re-reveal" > although I’ve org-ref installed. What is going wrong? Hi Johannes, you also need to install org-re-reveal, from MELPA or from GitLab [2]. I just updated org-re-reveal-ref to clarify this. Sorry for the omission. Best wishes Jens [2] https://gitlab.com/oer/org-re-reveal/
Re: [O] Two bibliography slides using org-reveal
Johannes Brauer writes:
> GET
> file:///Users/jb/Downloads/org-re-reveal-ref-master/reveal.js/lib/js/head.min.js
> net::ERR_FILE_NOT_FOUND README.html:173
>
> Is this a relevant message?
Hi Johannes,
that message appears for newer versions of reveal.js (but does not
hurt). You can avoid it by customizing variable
org-re-reveal-script-files to remove lib/js/head.min.js, which does not
seem to exist for your version.
Alternatively, if you added (require 'org-re-reveal) in your ~/.emacs,
you could add the following:
(setq org-re-reveal-script-files '("js/reveal.js"))
Best wishes
Jens
[O] org-flag-region missing?
Could it be that the function org-flag-region is recently missing from org.el? I got some errors after narrowing to region because that function is not defined. After getting the source from somewhere else and adding it to scratch the errors disappeared. -- Mit freundlichen Grüssen / With kind regards: Jens Lange
[O] [PATCH] ox-html: add option to restore old src block behaviour?
On 2019-09-19, Matt Price wrote: > Over the summer, commit ded3d27b1468b878197e5fe55a70c5e13350ea27 > by Nik Clayton was merged to master. It's a one-line change that > adds new ~~ tags around each lin of code in html export of > source blocks. It's useful because it allows individual lines to > be addressed directly by CSS. > > However, at least one very common syntax highlighter, > https://highlinghtjs.org, expects just a single tag, as do > other common CSS frameworks. > [...] The attached patch adds a new variable org-html-wrap-src-lines to control whether code tags should be added or not. I’m not sure whether :package-version 9.3 is correct. Also, I set the value to t, which does not change the current functionality. However, for backwards compatibility (up to version 9.2.6), a value of nil would be preferable. Any thoughts? Best wishes Jens >From ba3130deb9dbbab3c7d293f901ff08be839a8a9d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jens=20Lechtenb=C3=B6rger?= Date: Sat, 21 Sep 2019 12:01:59 +0200 Subject: [PATCH] ox-html: Control source line wrapping * list/ox-html.el (org-html-do-format-code): Use new variable org-html-wrap-src-lines to control whether source code lines should be wrapped in code elements or not. Allow to revert to behavior before commit ded3d27b1468b878197e5fe55a70c5e13350ea27. --- lisp/ox-html.el | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 757006321..969e649fc 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -932,6 +932,14 @@ in all modes you want. Then, use the command :group 'org-export-html :type 'string) +(defcustom org-html-wrap-src-lines t + "If t, wrap individual lines of source blocks in \"code\" elements. +In this case, add line number in attribute \"data-ox-html-linenr\" when line +numbers are enabled." + :group 'org-export-html + :package-version '(Org . "9.3") + :type 'boolean) + Table (defcustom org-html-table-default-attributes @@ -2256,11 +2264,13 @@ line of code." (format "%s" (format num-fmt line-num))) ;; Transcoded src line. - (format "%s" - (if num-start - (format " data-ox-html-linenr=\"%s\"" line-num) -"") - loc) + (if org-html-wrap-src-lines + (format "%s" + (if num-start + (format " data-ox-html-linenr=\"%s\"" line-num) +"") + loc) + loc) ;; Add label, if needed. (when (and ref retain-labels) (format " (%s)" ref ;; Mark transcoded line as an anchor, if needed. -- 2.20.1
[O] ox-html: Bug or feature for export of title and meta information?
Hi there, I wonder about the treatment of different pieces of HTML header information in org-html--build-meta-info: Contents for the title element are computed by org-export-data. This interprets Org markup such as italics or hyperlinks although title elements are not allowed to contain the resulting sub-elements. Why is org-export-data applied? Why not produce plain text? Contents for the description and keywords meta attributes are computed with org-html-encode-plain-text and replacement of quotation marks. Seems fine to me. Contents for the author meta attribute are computed with org-element-interpret-data, before org-html-encode-plain-text and quotation mark replacement are applied. How would author information look like that benefits from this more complex treatment (compared to description and keywords)? Thanks Jens
Re: [O] [PATCH] ox-html: add option to restore old src block behaviour?
On 2019-10-08, at 11:31, Nicolas Goaziou wrote:
> Jens Lechtenboerger writes:
>
>> The attached patch adds a new variable org-html-wrap-src-lines to
>> control whether code tags should be added or not.
>
> Thank you.
>
> However, the patch is not right. Exporters do not use defcustoms
> directly. Instead, you register them within :options-alist in the the
> back-end definition, e.g., under :html-wrap-src-lines and then call
> (plist-get info :html-wrap-src-lines) in the function. This allows to
> control these options during publishing.
Indeed, sorry. Many thanks for the detailed feedback!
I had to change the calling function org-html-format-code and add an
argument to org-html-do-format-code as info is not available in the
latter function.
> Also, this would need an entry in the manual, if only in the "options
> for the exporters" subsection.
Done.
>> I’m not sure whether :package-version 9.3 is correct.
>
> It is correct. You can also use :safe t.
Added.
>> Also, I set the value to t, which does not change the current
>> functionality. However, for backwards compatibility (up to version
>> 9.2.6), a value of nil would be preferable. Any thoughts?
>
> I agree with the nil default value.
Done.
>> +(defcustom org-html-wrap-src-lines t
>> + "If t, wrap individual lines of source blocks in \"code\" elements.
>
> When non-nil, wrap...
Done.
Best wishes
Jens
>From 961c0b45ff3e5548df11fc3fe9274e913c467c65 Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger
Date: Tue, 8 Oct 2019 20:15:06 +0200
Subject: [PATCH] ox-html: Control wrapping of source lines
* lisp/ox-html.el (org-html-format-code, org-html-do-format-code):
Use new export option :html-wrap-src-lines with variable
org-html-wrap-src-lines to control whether source code lines should
be wrapped in code elements or not.
* doc/org-manual.org: Document the new option
---
doc/org-manual.org | 3 ++-
lisp/ox-html.el| 39 +++
2 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index f2f059e77..68543d67c 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -10789,7 +10789,7 @@ environments and math templates. Inside Org mode, you can make use of
some of the features of CDLaTeX mode. You need to install
=cdlatex.el= and =texmathp.el= (the latter comes also with AUCTeX)
using [[https://melpa.org/][MELPA]] with the [[https://www.gnu.org/software/emacs/manual/html_node/emacs/Package-Installation.html][Emacs packaging system]] or alternatively from
-[[https://staff.fnwi.uva.nl/c.dominik/Tools/cdlatex/]]. Do not use
+[[https://staff.fnwi.uva.nl/c.dominik/Tools/cdlatex/]]. Do not use
CDLaTeX mode itself under Org mode, but use the special version Org
CDLaTeX minor mode that comes as part of Org. Turn it on for the
current buffer with {{{kbd(M-x org-cdlatex-mode)}}}, or for all Org
@@ -15753,6 +15753,7 @@ Settings]]), however, override everything.
| ~:html-use-infojs~ | ~org-html-use-infojs~ |
| ~:html-validation-link~| ~org-html-validation-link~|
| ~:html-viewport~ | ~org-html-viewport~ |
+| ~:html-wrap-src-lines~ | ~org-html-wrap-src-lines~ |
| ~:html-xml-declaration~| ~org-html-xml-declaration~|
LaTeX specific properties
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 882f82dcb..83d0fd2e9 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -172,6 +172,7 @@
(:html-table-row-open-tag nil nil org-html-table-row-open-tag)
(:html-table-row-close-tag nil nil org-html-table-row-close-tag)
(:html-xml-declaration nil nil org-html-xml-declaration)
+(:html-wrap-src-lines nil nil org-html-wrap-src-lines)
(:html-klipsify-src nil nil org-html-klipsify-src)
(:html-klipse-css nil nil org-html-klipse-css)
(:html-klipse-js nil nil org-html-klipse-js)
@@ -932,6 +933,15 @@ in all modes you want. Then, use the command
:group 'org-export-html
:type 'string)
+(defcustom org-html-wrap-src-lines nil
+ "If non-nil, wrap individual lines of source blocks in \"code\" elements.
+In this case, add line number in attribute \"data-ox-html-linenr\" when line
+numbers are enabled."
+ :group 'org-export-html
+ :package-version '(Org . "9.3")
+ :type 'boolean
+ :safe t)
+
Table
(defcustom org-html-table-default-attributes
@@ -2231,14 +2241,15 @@ is the language used for CODE, as a string, or nil."
(if (and beg end) (substring code beg end) code)
(defun org-html-do-format-code
- (code &optional lang refs retain-labels num
Re: [O] [PATCH] ox-html: add option to restore old src block behaviour?
On 2019-10-13, at 09:30, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> Subject: [PATCH] ox-html: Control wrapping of source lines >> >> * lisp/ox-html.el (org-html-format-code, org-html-do-format-code): >> Use new export option :html-wrap-src-lines with variable >> org-html-wrap-src-lines to control whether source code lines should >> be wrapped in code elements or not. >> * doc/org-manual.org: Document the new option > > Applied. Would you mind adding an ORG-NEWS entry about it? Thanks! A patch is attached. Best wishes Jens >From f2f93c573fef6a079c2f7f434e6c65d51e2f0906 Mon Sep 17 00:00:00 2001 From: Jens Lechtenboerger Date: Sun, 13 Oct 2019 14:06:09 +0200 Subject: [PATCH] Mention option html-wrap-src-lines in ORG-NEWS * etc/ORG-NEWS: Mention new option html-wrap-src-lines. --- etc/ORG-NEWS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 9fff4ad16..0e07326cb 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -123,6 +123,12 @@ auto-commit attachments to git: one need to require the =org-attach-git= module in the startup. ** New features +*** New option to wrap source code lines in HTML export + +When new option ~html-wrap-src-lines~ (with variable +~org-html-wrap-src-lines~) is non-nil, HTML export wraps source code +lines in HTML ~code~ elements. + *** New option to handle schedules and deadlines in iCalendar export Export ignore done tasks with a deadline when -- 2.17.1
[PATCH] Derive non-default start value for ordered list
Hi there,
currently, we have to write the following to continue an ordered
list from a value different from 1:
42. [@42] Answer
43. Question?
The requirement to type redundant information with the @-syntax
always struck me as odd. For my export backend org-re-reveal, I
recently received a request to export lists without @-syntax to
their “correct” start values [1].
Before working on my backend, I’d like to ask for feedback: Why was
the @-syntax introduced? Of what non-obvious effects should I be
aware?
What do you think about the attached patch that allows to omit the
@-syntax? Controlled by the new variable
org-list-use-first-bullet-as-non-standard-counter, the code assigns
a counter value to the first list item from its bullet string if the
item
1. does not specify a counter itself,
2. has an alphanumeric bullet, and
3. does not have a default start value (1, a, A).
I hacked this as postprocessing step on the list’s struct. Maybe an
Org expert could suggest how to do this in one pass?
Best wishes
Jens
P.S. I did not work on documentation yet as I’m not sure that this
change is acceptable.
[1] https://gitlab.com/oer/org-re-reveal/merge_requests/27
>From 2eea43d84687259633f847bd17883e5fe578b6bc Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger
Date: Sun, 1 Dec 2019 21:17:43 +0100
Subject: [PATCH] Use bullet as non-standard counter
* lisp/org-list.el: New variable
org-list-use-first-bullet-as-non-standard-counter and new function
org-list-struct-maybe-add-counters to assign counters from bullets
that indicate non-standard start values.
(org-list-struct): Use new variable and function.
* lisp/org-element.el (org-element-item-parser): Use new variable and
mirror behavior of org-list.el.
---
lisp/org-element.el | 19 ++-
lisp/org-list.el| 33 -
2 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 56b3cc413..80b7cab99 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -1269,6 +1269,8 @@ Assume point is at the beginning of the item."
(beginning-of-line)
(looking-at org-list-full-item-re)
(let* ((begin (point))
+ (prevs (org-list-prevs-alist struct))
+ (prev-item (org-list-get-prev-item begin struct prevs))
(bullet (match-string-no-properties 1))
(checkbox (let ((box (match-string 3)))
(cond ((equal "[ ]" box) 'off)
@@ -1277,7 +1279,22 @@ Assume point is at the beginning of the item."
(counter (let ((c (match-string 2)))
(save-match-data
(cond
- ((not c) nil)
+ ((not c)
+ (and
+ org-list-use-first-bullet-as-non-standard-counter
+ ;; As in org-list-struct-maybe-add-counters,
+ ;; assign non-standard counter from bullet of
+ ;; first list item. To exclude "A", check range
+ ;; from "B".
+ (not prev-item)
+ (or (and (string-match "[B-Zb-z]" bullet)
+(- (string-to-char
+ (upcase (match-string 0 bullet)))
+ 64))
+ (and (string-match "[0-9]+" bullet)
+(string< "1" (match-string 0 bullet))
+(string-to-number
+ (match-string 0 bullet))
((string-match "[A-Za-z]" c)
(- (string-to-char (upcase (match-string 0 c)))
64))
diff --git a/lisp/org-list.el b/lisp/org-list.el
index c4aef32fc..fe8742f42 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -336,6 +336,14 @@ clearly distinguish sub-items in a list."
:version "24.1"
:type 'integer)
+(defcustom org-list-use-first-bullet-as-non-standard-counter nil
+ "Non-nil means to use first bullet of an ordered list as counter.
+Then, you can start an ordered list with \"42. Answer\" instead of
+\"42. [@42] Answer\"."
+ :group 'org-plain-lists
+ :package-version '(Org . "9.3")
+ :type 'boolean)
+
(defvar org-list-forbidden-blocks '("example" "verse" "src" "export")
"Names of blocks where lists are not allowed.
Names must be in lower case.")
@@ -731,7 +739,30 @@ Assume point is at an item."
;; 3. Associate each item to its end position.
(org-list-struct-assoc-end struct end-lst)
;; 4. Return STRUCT
- struct)))
+ (if org-list-use-first-bullet-as-non-standard-counter
+ (org-list-struct-maybe-add-counters struct)
+struct
+
+(defun org-list-struct-maybe-add-counters (struct)
+ "Maybe add counters to first list items of STRUCT.
+For the first list items in STRUCT (those without previous item) that
+1. do not specify a counter,
+2. has an alphanumeric bullet, and
+3. do not have a default start value (1, a, A),
+set the counter to t
Re: [PATCH] Derive non-default start value for ordered list
On 2019-12-01, at 14:13, Samuel Wales wrote: > i think it might be partlly a question of whether these numbers are > fixed things that refer to fixed items [like referring to sections in > a law that is not in the document] vs. being used to continue lists. > > they are both legitimate uses. in the first case, the @ syntax makes > sense to me, because it specifies a fixed alphanumber. yes i made > that word up. > > some exporters assume the numbers in the org source list don't matter > and start from 1 or the @ in the exported text. If I took the effort to type something, then that should not be ignored by an exporter. > so your solution would be anomalous. But meet some users’ expectations. Quite likely, those of new Org users. > and i'm used to exporters doing that so it feels strange to me to rely > on the org text. If text is ignored, I should not need to type it in the first place. > i view that as potentially changing. what should > occur if you do something that renumbers it? If I renumber, then, of course, I want to see the new numbers after export. > in the second case, the @ syntax and your solution both seem brittle > to me. you might add to the first list. I agree. > i think there can be a third solution that would be less brittle. > > just as a brainstorm, consider the common case of continued lists like > > vvv > 1. asdf > 2. <> asdf > > a paragraph. > > 3. [@asdf-list-end] asdf > ^^^ This would indeed be a cool solution. Thanks Jens
Re: [PATCH] Derive non-default start value for ordered list
On 2019-12-02, at 08:23, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> [...] >> What do you think about the attached patch that allows to omit the >> @-syntax? Controlled by the new variable >> org-list-use-first-bullet-as-non-standard-counter, the code assigns >> a counter value to the first list item from its bullet string if the >> item >> 1. does not specify a counter itself, >> 2. has an alphanumeric bullet, and >> 3. does not have a default start value (1, a, A). > > I think the current situation is better. It works, as advertised, and it > allows you to re-number any item in the list, not necessarily the first > one. One can still do this. > Of course, it may be less "elegant", but the overhead is negligible, > and, as a data point, I'd rather have continuation lists more visible > than not, as it could create confusion in the document. I understand. > I do not know about org-re-reveal, but included exporters do not display > the [@xxx] part. However, they use its value to start lists at an > appropriate number, if technically possible. I suggest org-re-reveal to > do the same if that's not the case. My backend does this, but maybe the user did not know about the @-syntax. Also, he did not want to change all his preexisting lists. Thanks for your feedback Jens
Re: ox-html: Bug or feature for export of title and meta information?
On 2020-02-11, at 09:16, Bastien wrote: > Hi Jens, > > it is difficult to justify existing code, it is easier to answer to > bug reports. If you think there is a bug in this aread, can you tell > what it is? Hi Bastien, many thanks for following up on this! I see two or more bugs: 1. Export to HTML when the title contains markup, say this one: #+TITLE: This does *not* work The HTML title element contains a nested b element, which is invalid as only text is allowed. 2. The documentation does not explain which headers are exported how to HTML. I described different variants in my previous e-mail. I’m not sure whether there was a reason to treat them differently. So, this is at least a bug in the documentation (with potentially more bugs in the code if the current treatment was not desirable). Best wishes Jens
Re: ox-html: add option to restore old src block behaviour?
On 2020-02-11, at 16:40, Bastien wrote: > Matt Price writes: > >> However, at least one very common syntax highlighter, https:// >> highlinghtjs.org, expects just a single tag, as do other >> common CSS frameworks. These often leave odd borders or background >> color disruptions which somewhat distort the view of the code. >> There's also a funny conflict with `org-re-reveal`, which expects the >> old behaviour (see https://gitlab.com/oer/org-re-reveal/issues/27). >> It would in principal be possible to fix these issues directly in >> CSS, but it might be much more practical to have an option -- a >> defvar or a file/headline-settable property -- that restores the old >> behaviour when desired. If this would be welcome, I could do it. I >> know org already has a bewildering number of options,though,and the >> code change would be oddly a number of times as large as the >> substantive change of that commit, os thought I'd check first. > > Yes, an option makes sense here -- can you provide one that allows to > restore the old behavior (and avoid all those ... lines)? Hi Bastien, that issue has been resolved: https://lists.gnu.org/archive/html/emacs-orgmode/2019-10/msg00099.html Best wishes Jens
Re: ox-html: Bug or feature for export of title and meta information?
On 2020-02-14, at 20:31, Nicolas Goaziou wrote: > Hello, > > Jens Lechtenboerger writes: > >> 1. Export to HTML when the title contains markup, say this one: >> >> #+TITLE: This does *not* work > > What does not work? > >> The HTML title element contains a nested b element, which is >> invalid as only text is allowed. > > Who said that? The above is perfectly valid. Good morning (over here), the W3C Markup Validator [1] disagrees with this output from ox-html (which I reduced to the essential parts): #+begin_src html http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> This does not work #+end_src Best wishes Jens [1] https://validator.w3.org/#validate_by_input
Re: ox-html: Bug or feature for export of title and meta information?
Hi there! On 2020-02-15, at 15:02, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> the W3C Markup Validator [1] disagrees with this output from >> ox-html (which I reduced to the essential parts): > > OK. I was talking about the Org syntax. I misread your initial report. > > I won't comment about the generated HTML. If needed, the HTML exporter > can prevent parsing TITLE keyword. I do not know what is needed. Function org-html--build-meta-info should return valid XHTML (also in case of HTML5, I believe that Org syntax is preferable over ignored [1] HTML tags). Based on the treatment of meta elements for author and description in that function, alternatives might use org-element-interpret-data (author) or not (description). I do not understand the role of org-element-interpret-data to generate author information. Which “non exportable objects” can be skipped by that function (as mentioned in a comment in org-html--build-meta-info)? Should they also be skipped for description or title? Best wishes Jens [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title
Re: ox-html: Bug or feature for export of title and meta information?
Hi there! On 2020-02-17, at 10:47, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: >> Which “non exportable objects” can be skipped by that function (as >> mentioned in a comment in org-html--build-meta-info)? Should they also >> be skipped for description or title? > > That non-exportable part is confusing. I think > > (org-element-interpret-data auth) > > is sufficient. I pushed a change in that direction. Thank you! The function org-element-interpret-data seems to return the empty string for nil. Is that by contract or accident? In the former case, maybe use (org-element-interpret-data (plist-get info :author)) instead of the let statement? What do you think about applying org-element-interpret-data (instead of org-export-data) when let-binding title, like the following? (org-html-encode-plain-text (org-element-interpret-data (plist-get info :title))) As far as I can tell, this would create valid (X)HTML. Best wishes Jens
[O] Announce: Audio presentations with reveal.js from Org mode
Hi there, you may be aware of Org-Reveal [1] to generate reveal.js [2] presentations, which are HTML presentations, from Org mode. I extended Org-Reveal to generate presentations with embedded audio and bundled that along with some reveal.js plugins and necessary configuration in the GitLab repository emacs-reveal [3]. Sample presentations are available at [4]. I use the result for talks and teaching and believe it to be particularly well-suited for presentations in the spirit of Open Educational Resources (OER) [5], for the following reasons: - Self-contained presentations, usable on lots of (including mobile and offline) devices with free software - Separation of layout and content for ease of creation - Text format for diff and merge for ease of collaboration I hope this to be useful for your talks or teaching as well. Feedback is highly appreciated. Best wishes Jens [1] https://github.com/yjwen/org-reveal/ [2] http://lab.hakim.se/reveal-js/ [3] https://gitlab.com/oer/emacs-reveal [4] https://oer.gitlab.io/OS/ [5] https://en.wikipedia.org/wiki/Open_educational_resources
[O] Bug: org-emphasis-alist not fully applied [9.1.1 (9.1.1-1-g80cbf9-elpa @ x:/folder/user/.emacs.d/elpa/org-20170918/)]
jar"
org-startup-truncated nil
org-link-parameters '(("id" :follow org-id-open) ("rmail" :follow
org-rmail-open :store org-rmail-store-link) ("mhe" :follow org-mhe-open
:store org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link) ("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete org-bbdb-complete-link :store org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys")
("file+emacs") ("outlook" :follow org-outlook-open :export nil) ("doi"
:follow org--open-doi-link)
("elisp" :follow org--open-elisp-link) ("file"
:complete org-file-complete-link) ("ftp" :follow (lambda (path) (browse-url
(concat "ftp:" path
("help" :follow org--open-help-link) ("http" :follow
(lambda (path) (browse-url (concat "http:" path
("https" :follow (lambda (path) (browse-url (concat
"https:" path ("mailto" :follow (lambda (path) (browse-url (concat
"mailto:"; path
("news" :follow (lambda (path) (browse-url (concat
"news:"; path ("shell" :follow org--open-shell-link))
org-babel-load-languages '((ditaa . t) (latex . t))
org-agenda-files '("~/org/xx/xx.org" "~/org/xx/xxx.org"
"x:/xx/xx.org" "x:/xxx/xxx.org")
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
)
--
Mit freundlichen Grüssen / With kind regards:
Jens Lange
Re: [O] Bug: org-emphasis-alist not fully applied [9.1.1 (9.1.1-1-g80cbf9-elpa @ x:/folder/user/.emacs.d/elpa/org-20170918/)]
Hmm, but that worked until recently. Without any hook.
Or was your answer like: Good for you that it worked in the past but since
it ain't supported we won't make it work again?
With kind regards,
Jens Lange
2017-09-19 8:02 GMT+02:00 Nicolas Goaziou :
> Hello,
>
> Jens Lange writes:
>
> > What exactly did you do?
> > ===
> > 1. Configure block below in custom-set-variables.
> >
> > '(org-emphasis-alist
> >(quote
> > (
> > ("!" org-habit-overdue-face)
> > ("%" org-habit-alert-face)
> > ("*" bold)
> > ("/" italic)
> > ("_" underline)
> > ("=" org-verbatim verbatim)
> > ("~" org-code verbatim)
> > ("+" (:strike-through t))
> > )))
> >
> > 2. Type %blabla% and !blabla! in org-mode
>
> Adding new syntax is not supported. The variable exists to allow users
> to change the face of already existing constructs.
>
> You may want to tweak font-lock related variables, e.g.,
> `org-font-lock-hook' to achieve that effect.
>
> Regards,
>
> --
> Nicolas Goaziou
>
--
Mit freundlichen Grüssen / With kind regards:
Jens Lange
Re: [O] Bug: org-emphasis-alist not fully applied [9.1.1 (9.1.1-1-g80cbf9-elpa @ x:/folder/user/.emacs.d/elpa/org-20170918/)]
Thanks, for that information. Since I have no coding knowlege I reached out to stackexchange for some help for a workaround. Question is here: https://emacs.stackexchange.com/questions/35626/how-to-make-my-own-org-mode-text-emphasis-work-again One guy mentioned this after I wrote about this bug report: "If they don't want items added to org-emphasis-alist they shouldn't use the repeat customization type which allows insertion and deletion. Furthermore, they should add a note about this restriction in the doc string of org-emphasis-alist. Maybe, you can give a follow-up in the bug-report about that." So I did what he requested. He also provided me with a working solution. Even with that said I might ask if you could consider supporting adding new emphasis definitions in the future? For people like me who are not able to write a function to solve the problem in an instant this customize option is like the red carpet already lying on the floor. With kind regards, Jens Lange 2017-09-19 21:23 GMT+02:00 Nicolas Goaziou : > Jens Lange writes: > > > Hmm, but that worked until recently. Without any hook. > > > > Or was your answer like: Good for you that it worked in the past but > since > > it ain't supported we won't make it work again? > > That's more like it, sorry. The fact that it worked doesn't mean it was > supported. > > As I suggested there are other ways to achieve what you want. > > Regards, > -- Mit freundlichen Grüssen / With kind regards: Jens Lange
[O] [PATCH] ox-publish.el: Fix regexp `match' to be non-nil
Hi there,
recursive publishing fails with base-extension any because a nil
regexp is passed. The attached patch fixes this.
Best wishes
Jens
P.S. I did the necessary paperwork (copyright assignment) for Emacs.
>From 6584a78c350016e39c199bb61d203bc12c0c4c53 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jens=20Lechtenb=C3=B6rger?=
Date: Fri, 22 Sep 2017 11:30:13 +0200
Subject: [PATCH] ox-publish.el: Fix regexp `match' to be non-nil
* lisp/ox-publish.el (org-publish-get-base-files): Make sure `match'
is a string (not nil) before calling `directory-files-recursively'.
---
lisp/ox-publish.el | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index 753176b..b592bc9 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -435,8 +435,9 @@ This splices all the components into the list."
(let* ((base-dir (file-name-as-directory
(org-publish-property :base-directory project)))
(extension (or (org-publish-property :base-extension project) "org"))
- (match (and (not (eq extension 'any))
- (concat "^[^\\.].*\\.\\(" extension "\\)$")))
+ (match (or (and (not (eq extension 'any))
+ (concat "^[^\\.].*\\.\\(" extension "\\)$"))
+ ""))
(base-files
(cl-remove-if #'file-directory-p
(if (org-publish-property :recursive project)
--
2.1.4
Re: [O] Bug: org-emphasis-alist not fully applied [9.1.1 (9.1.1-1-g80cbf9-elpa @ x:/folder/user/.emacs.d/elpa/org-20170918/)]
Nicolas, I understand the dilemma. But then I must ask for a format enhancment. Before crying out loud please read my argumentation. Why did I create my own "fancy" markers? Because there is no default way to recreate the "Textmarker-Experience" - or at least I couldn't find any. All default emphasis markers recreate what I would call the "Ballpoint-Experience". This puzzles me because marking text on a piece of paper is one of the most basic things. Do I have a point here or not? I just opened my pen-drawer and took out the text-markers. I found (the typical) neon-yellow, neon-green, neon-pink and neon-blue. How about adding four markers using something like "org-emphasis-colours-alist" and let the users be able to define the colours? Just one final remark: Tobias, the guy on stackexchange who helped me out here gave me a working solution, so I can live with that but currently I still think the "Textmarker-Experience" is missing in org-mode and should be inside it without any user defined functions. With kind regards, Jens Lange 2017-09-22 23:38 GMT+02:00 Nicolas Goaziou : > Hello, > > Jens Lange writes: > > > "If they don't want items added to org-emphasis-alist they shouldn't use > > the repeat customization type which allows insertion and deletion. > > Furthermore, they should add a note about this restriction in the doc > > string of org-emphasis-alist. Maybe, you can give a follow-up in the > > bug-report about that." > > Indeed, the customize type needs to be fixed. Patch welcome! > > > So I did what he requested. He also provided me with a working solution. > > Even with that said I might ask if you could consider supporting adding > new > > emphasis definitions in the future? > > I'm not even sure about what you are talking about. > > Allowing to extend `org-emphasis-alist' with any marker means there is > not anymore a single Org format. Any one can define its own with fancy > markers. This is not portable.Besides, having syntax you cannot control > is asking for trouble. I'm totally against this idea. > > Org already provides 6 emphasis markers, which is enough in my book. > > On the other hand, you may be only interested in marking some text with > a special face in a buffer. Both Org and Emacs provide ways to do that > without messing with Org syntax. As pointed out in the thread, > `org-font-lock-set-keywords-hook' is one of them. > > Regards, > > -- > Nicolas Goaziou > -- Mit freundlichen Grüssen / With kind regards: Jens Lange
[O] [PATCH] ox.el: Define subtitle macro
Hi there,
the attached patch adds a subtitle macro with documentation.
Best wishes
Jens
>From 3f54f515847f1f3034274d79fff6cfd1f92c72a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jens=20Lechtenb=C3=B6rger?=
Date: Thu, 16 Nov 2017 15:03:33 +0100
Subject: [PATCH] Define and document subtitle macro
* lisp/ox.el (org-export-as): Define macro for subtitle.
* lisp/org-macro.el: Mention new macro in comment among others.
* doc/org.texi: Document new macro.
---
doc/org.texi | 2 ++
lisp/org-macro.el | 2 +-
lisp/ox.el| 6 --
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index e116a9b..3907eda 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -11080,9 +11080,11 @@ Org comes with following pre-defined macros:
@table @code
@item @{@{@{title@}@}@}
+@item @{@{@{subtitle@}@}@}
@itemx @{@{@{author@}@}@}
@itemx @{@{@{email@}@}@}
@cindex title, macro
+@cindex subtitle, macro
@cindex author, macro
@cindex email, macro
Org replaces these macro references with available information at the time of
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 1d2823e..c82bfd8 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -43,7 +43,7 @@
;; {{{n(counter,action}}}.
;; Upon exporting, "ox.el" will also provide {{{author}}}, {{{date}}},
-;; {{{email}}} and {{{title}}} macros.
+;; {{{email}}}, {{{title}}}, and {{{subtitle}}} macros.
;;; Code:
(require 'cl-lib)
diff --git a/lisp/ox.el b/lisp/ox.el
index cc3c48b..6feec3e 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -3083,8 +3083,8 @@ Return code as a string."
(let ((result (funcall filter info backend-name)))
(when result (setq info result)
;; Expand export-specific set of macros: {{{author}}},
- ;; {{{date(FORMAT)}}}, {{{email}}} and {{{title}}}. It must
- ;; be done once regular macros have been expanded, since
+ ;; {{{date(FORMAT)}}}, {{{email}}}, {{{title}}}, and {{{subtitle}}}.
+ ;; It must be done once regular macros have been expanded, since
;; parsed keywords may contain one of them.
(org-macro-replace-all
(list
@@ -3102,6 +3102,8 @@ Return code as a string."
value)))
(cons "email" (org-element-interpret-data (plist-get info :email)))
(cons "title" (org-element-interpret-data (plist-get info :title)))
+ (cons "subtitle"
+ (org-element-interpret-data (plist-get info :subtitle)))
(cons "results" "$1"))
'finalize
parsed-keywords)
--
2.1.4
Re: [O] [PATCH] ox.el: Define subtitle macro
On 2017-11-17, Rasmus wrote: > Jens Lechtenboerger writes: > >> the attached patch adds a subtitle macro with documentation. > > AFAIK it’s already added to the backends where it makes sense. It’s not a > basic keyword like "#+author". It should be documented under the relevant > backends that support it. Sorry, I don't understand your suggestion. I'm interested in org-reveal [1], which is based on ox-html.el. In ox-html.el, subtitles are used at some hardcoded positions (preamble, postamble, template), but I need access to the subtitle elsewhere. What should I document where? Best wishes Jens [1] https://github.com/lechten/org-reveal
Re: [O] [PATCH] ox.el: Define subtitle macro
On 2017-11-17, Nicolas Goaziou wrote:
> SUBTITLE keyword may not be supported in every back-end. As
> a consequence, supporting a global {{{subtitle}}} macro sounds
> presumptuous.
>
> Anyway, it begs for generalisation. The same problem is going to arise
> for CREATOR, KEYWORDS, and WHATNOT. Instead of {{{subtitle}}}, we could
> implement {{{option(KWD)}}}. Basically,
>
> {{{option(SUBTITLE)}}} => (org-element-interpret-data (plist-get
> info :subtitle))
>
> Options with a `split' behaviour would need a special treatment,
> however.
>
> WDYT? Do you want to have a stab at it?
Thanks for your reply. That would be great but goes way beyond my
current understanding of org internals. I've never heard of `split'
behaviour. Currently I don't have time to investigate this.
I'll stick with a local change for now.
Best wishes
Jens
Re: [O] [PATCH] ox.el: Define subtitle macro
On 2017-11-21, Nicolas Goaziou wrote: > For the record, I implemented a "keyword" macro (master branch). Excellent, that works for me. Many thanks Jens
Re: [O] org-reveal: content side by side
On 2018-02-11, Michael Welle wrote: > Looks easy, eh? A header at the top, a footer at the bottom and a lot > of space in between. In some cases, like in [1], I wanted content (e.g. > Ich...OS/2 Warp 4) to be centered horizontally and > vertically between the footer and the header. I created emacs-reveal [0] for my own slides. Contents are centered vertically (default for reveal.js). CSS with “text-align: center” can be used for horizontal alignment. The howto for emacs-reveal is available at [1]. First-level headings are centered vertically and horizontally. I just added slide 20 with horizontally centered text (underneath a heading, which—as ugly hack—could just be a non-breaking space I guess). I hope that helps and would be happy to help more. (Responses may be slow in the coming days, though.) Best wishes Jens [0] https://gitlab.com/oer/emacs-reveal [1] https://oer.gitlab.io/emacs-reveal-howto/howto.html
Re: [O] org-reveal: content side by side
On 2018-02-13, Michael Welle wrote: > That jumping of the headings is one of my main issues, I think it's not > acceptable. I see. I don’t know how to fix the headings at the top and have the contents vertically centered. Best wishes Jens
Re: [O] org-crypt broken on Ubuntu 18.04
On 2018-06-14, Óscar Fuentes wrote: > While trying to create a demo file I noticed that decryption works fine > as long as the content was relatively new, while it fails for content > that was encrypted years ago. > > I tried setting epg-gpg-program to "gpg" (it is "gpg2" by default) for > encrypting some tests but then decryption worked fine on those tests. Probably you encrypted without integrity protection, which was always a bad idea but in view of EFAIL attacks has recently gained lots of attention as Bad Thing. Nowadays GnuPG returns a failure, you can override that if you know what you are doing. See there: https://dev.gnupg.org/T3714 Best wishes Jens
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: emacs + org-mode in virtual machine/docker/...
On 2020-05-21, John Kitchin wrote: > Has anyone had any success in creating or using any kind of virtual machine > that can work across platforms to run emacs+org-mode? I maintain Docker images, emacs-reveal includes org-ref. It is large, though: https://gitlab.com/oer/emacs-reveal/container_registry Best wishes Jens
Re: emacs + org-mode in virtual machine/docker/...
On 2020-05-21, John Kitchin wrote: > What do you do with this image? I would be happy to continue this off-list > if it seems better. I generate self-study HTML presentations with audio as OER based on reveal.js. See there for a course about to start in two weeks: https://oer.gitlab.io/OS/ Material generated from this: https://gitlab.com/oer/OS/-/blob/master/.gitlab-ci.yml A howto: https://oer.gitlab.io/emacs-reveal-howto Best wishes Jens
Re: emacs + org-mode in virtual machine/docker/...
On 2020-05-23, Olivier Berger wrote: > Hi. > > This looks quite similar to my approach to producing course material, > which is documented here : https://olberger.gitlab.io/org-teaching > including the use of Docker (see > https://gitlab.com/olberger/docker-org-teaching-export/ ) Indeed, the philosophy of using the right source format is the same. Thanks for the pointer. What I see as differences: Emacs-reveal embeds plugins for audio and quizzes to create what I hope to be material for asynchronous learning (particularly useful in Corona times but preferable to lecturing in “normal” years as well). It supports a bibliography slide and focuses on Free and Open Educational Resources with simplified (in my view) treatment of license information. Do you share your teaching material for “Web architecture and applications (CSC4101)”? Best wishes Jens
Re: ox-* vs org-* naming convention?
On 2020-06-07, Diego Zamboni wrote: > Hi, > > I am working on submitting a new set of exporters I've been working on > (https://gitlab.com/zzamboni/ox-leanpub) to MELPA, and I received > feedback [1] about the discrepancy between the package names > (ox-leanpub-*) and the functions they define (org-leanpub-*). This is > also flagged by =package-lint=. > > [1] https://github.com/melpa/melpa/pull/6942 > > [...] > > I would appreciate any feedback about this - what are strong arguments > for or against insisting in this convention vs just adapting to the > rules suggested by package-lint? Hi there, for org-re-reveal, I use a small wrapper ox-re-reveal.el [2], whose commentary explains this: ;; Org export back-ends have file names starting with "ox-". ;; However, such files typically define variables and functions ;; starting with "org-", which causes errors by package-lint. To ;; define variables and functions with the usual prefix "org-" while ;; avoiding errors by package-lint, code is located in ;; org-re-reveal.el. ;; However, the prefix "ox-" is hard-coded in org.el and used to load ;; back-ends in `org-export-backends'. With this file, you can ;; customize `org-export-backends' and add `re-reveal'. Then, when ;; pressing `C-c C-e', this file will be loaded, which loads ;; org-re-reveal.el. Best wishes Jens [2] https://gitlab.com/oer/org-re-reveal/-/blob/master/ox-re-reveal.el
Emacs version for Org 9.4?
Hi there, if I open an Org file on “GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-12 on hullmann, modified by Debian” I get this error (which I don’t know how to debug): Eager macro-expansion failure: (wrong-type-argument listp :pcase--succeed) Recipe: touch empty.org curl -L https://orgmode.org/elpa/org-plus-contrib-20200914.tar > org.tar mkdir org && tar xf org.tar -C org --strip-components 1 rm -f org.tar emacs -Q -L org C-x C-f empty.org In ORG-NEWS, I only found that “Emacs 24.4 or above is suggested.” Did that change? Best wishes Jens
Re: Emacs version for Org 9.4?
On 2020-09-15, Jeremie Juste wrote: > Hello Jens, > > I'm afraid I cannot test your issue. I don't have the ability to switch > emacs version yet. > > What I can tell you is that org-9.4 is working fine on GNU Emacs 27.1, > and on Emacs 28.0.50. Hello Jeremie, thanks for your reply. Yes, I’m aware that newer versions of Emacs work. I’m interested in the officially supported “lowest” version of Emacs. (When trying Org mode 9.4, I got a test failure with org-re-reveal, for which I still promise compatibility with Emacs 24: https://gitlab.com/oer/org-re-reveal/-/pipelines/190002022) Best wishes Jens
Re: pcase failure with Emacs 24 (was Emacs version for Org 9.4?)
On 2020-09-15, Kyle Meyer wrote: > It is pretty tricky to debug, but the failure starts with 4a27b67fd > (org-element: Fix property drawers parsing, 2020-04-22). As far as I > can see, the pattern introduced there is perfectly valid and should be > compatible with Emacs 24. I'd _guess_ this is a pcase bug in Emacs 24, > particularly the one fixed by 528872c5f8 (bug#18554, 2014-09-27), but I > didn't make an effort to try to understand that commit. > > Interestingly, the error goes away if I just swap the elements in the > pcase (and ...) pattern added by that commit. Dunno, but if that clears > up the failure on your end as well, I don't see any reason to not make > that change. > > > diff --git a/lisp/org-element.el b/lisp/org-element.el > [...] Yes, that fixes the problem over here. Many thanks for debugging this, I’m deeply impressed. Best wishes Jens
Re: [PATCH] Enhance org-html--build-meta-info
On 2020-09-17, TEC wrote: > Hi All, > > This just replaces the current `org-html--build-meta-info' with a > cleaner, more extensible (I also added a new variable) > version. Please give it a look and let me know what you think! Hi Timothy, yes, I agree that org-html--build-meta-info needs work, and the HTML backend would benefit from more documentation. Back then [1], I wondered which parts of meta data need to be treated how. That was continued in thread [2]. As pointed out back then, using org-export-data on the title is wrong as it creates nested elements, leading to invalid HTML. Currently, org-element-interpret-data is applied for author information, while description and keywords are treated differently. Your patch goes for org-html-encode-plain-text in the new function org-html--build-meta-entry, which (if I’m not mistaken) produces author and description. Did you think about using org-element-interpret-data instead? What if that was used? I believe this to be an important question as it might affect backward compatibility and should be documented. Does this really work for you? For the author, first org-html--build-meta-entry gets called from the new defcustom. The result is assigned with setq to form, which then is non-nil so that org-html--build-meta-entry is applied again, leading to an error here. Besides, did you forget keywords or remove them on purpose? Best wishes Jens [1] https://lists.gnu.org/archive/html/emacs-orgmode/2019-09/msg00193.html [2] https://lists.gnu.org/archive/html/emacs-orgmode/2020-02/msg00368.html smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
On 2020-09-18, TEC wrote: > Jens Lechtenboerger writes: > [...] > I was not aware of org-element-interpret-data, and I can't say I can > really tell what it does. If you'd care to elaborate that would be > helpful. Hi Timothy, I don’t know why that is used. For this test case: #+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 &ß<" Test #+end_src I get this with Org master: #+begin_src html A title with bold index12 and characters &ß<" https://example.org][hyperlink]] and characters &ß<"" /> https://example.org][hyperlink]] and characters &ß<"" #+end_src The title is not valid HTML. I suggest to export it with Org syntax. I cannot see a difference between the handling of author and description. So, for this example, org-element-interpret-data is not necessary for author. I don’t know whether others have author information where a difference would be visible. My suggestion would be to go with the handling of description in all cases, including the title. >> Besides, did you forget keywords or remove them on purpose? > > This is a deliberate omission. My impression is that the value of > keywords in HTML documents has evaporated over the past decade, see: > https://yoast.com/meta-keywords/ I added keywords to my OER presentations because some crawlers use them to extract topics for classification of documents. I’d like to keep that. Best wishes Jens
Re: [PATCH] Enhance org-html--build-meta-info
On 2020-09-26, TEC wrote: > @Maintainers I think this is ready for a review. > > Jens Lechtenboerger writes: > >> My suggestion would be to go with the handling of description in all >> cases, including the title. > > Currently the only element handled differently to > `org-html-encode-plain-text' is "author". I don't know why so I don't > want to touch it. I believe that was also the previous conclusion. However, as this is not documented, maybe now could be the chance to change this? >> I added keywords to my OER presentations because some crawlers use >> them to extract topics for classification of documents. I’d like to >> keep that. > > Re-added. > > Let me know if there's anything else, I must I admit that I do not fully understand your approach. Why do you treat keywords and description differently (with description in org-html-meta-tags and keywords in org-html--build-meta-info)? Why do you pass _title into the lambda expressions in org-html-meta-tags when it is never used? Currently, the variable org-html-meta-tags does not seem user-friendly to me. Also, in org-html--build-meta-info you call org-html-encode-plain-text with two arguments, but it just accepts one. Best wishes Jens
Re: [PATCH] Enhance org-html--build-meta-info
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)) Best wishes Jens
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
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
[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 &optional 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
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: 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
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: 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
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: 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
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, 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
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: 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
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
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: >> 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-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-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: [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: [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: 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: 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
[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: [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 (&optional char)
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/)]
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::".
[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 point
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.
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/)]
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: 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: 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: [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.
