Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]
> From: Ihor Radchenko > Date: Sun, 28 Apr 2024 10:37:58 +0000 > > Protesilaos Stavrou writes: > >> Since we are now using labels for the HTML export, I think it makes >> sense to optionally use those for the anchor tags as well. >> >> See the attached patch for a possible way of doing this. >> >> As always, you are welcome to make any further changes. > > We can indeed add such option, but is it of any practical use? > Do you have examples of workflows when such new option will be useful? An important purpose of using labels is sustainability. If the document changes, the labels remain (as would CUSTOM_ID). The problem when numbers are used in the anchor text is that if others want to make a reference to the footnote (cite it), they will use what they see (not the ID, which appears in the source only). And if the document changes, their references will be broken. Now, the problem with labels is that their are not visually appealing, especially the longer they get. Another approach is to have a string for the anchor text of the footnote references. Something like "[^]" with a hover/tooltip effect, which shows the full label. [ Of course, the hover/tooltip text can be further enhanced with CSS and JavaScript, but we are keeping it simple for now. Though I think that would ultimately be the best user experience. ] For a proof of concept, see the attached patch, which expands on the previous proposal. While clicking around the footnotes, I noticed that we can also improve the user experience by adding a CSS ":focus" state so that it is easier to spot where we are after following an internal link. I can send this as a separate patch/thread. -- Protesilaos Stavrou https://protesilaos.com >From c6c0aebec12ee19da6ebf7daa972af5b23119358 Mon Sep 17 00:00:00 2001 Message-Id: From: Protesilaos Stavrou Date: Fri, 3 May 2024 11:44:34 +0300 Subject: [PATCH] Add option on how to format of HTML footnote anchor text * lisp/ox-html.el (org-html-footnote-anchor-text): Define new user option. (org-html-footnote-section): Use the new option for the footnote definitions. (org-html-footnote-reference): Use the new option for the footnote references. --- lisp/ox-html.el | 43 +-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index b35a31865..bbad21a7b 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -766,6 +766,25 @@ (defcustom org-html-prefer-user-labels nil :type 'boolean :safe #'booleanp) +(defcustom org-html-footnote-anchor-text nil + "Choose how to format HTML footnotes. + +When the value is nil, automatically number footnotes and use the number +for the anchor text in both references and definitions. + +When the value is non-nil, use the footnote label as the anchor text for +both the references and definitions. + +When the value is a string, use it for the anchor text of references. +For the anchor text of definitions use either the label, if present, or +an automatically assigned number." + :group 'org-export-html + :version "30.1" + :package-version '(Org . "9.7") + :type '(choice (const :tag "Do not show labels in HTML anchor text; use numbers" nil) + (const :tag "Use labels in HTML anchor text for both references and definitions" t) + (string :tag "Use custom string for HTML anchor text for references and labels for definitions"))) + Inlinetasks (defcustom org-html-format-inlinetask-function @@ -1898,7 +1917,12 @@ (defun org-html-footnote-section (info) #'identity nil t))) (anchor (org-html--anchor (format "fn.%s" (or label n)) - n +(cond + ((and org-html-footnote-anchor-text label) + label) + ((and org-html-footnote-anchor-text (null label)) + (user-error "All footnotes must have labels for `org-html-footnote-anchor-text' to work")) + (t n)) (format " class=\"footnum\" href=\"#fnr.%s\" role=\"doc-backlink\"" (or label n)) info)) (contents (org-trim (org-export-data def info @@ -2757,6 +2781,7 @@ (defun org-html-footnote-reference (footnote-reference _contents info) (equal label (number-to-string (string-to-number label nil label)) + (anchor-is-string (stringp org-html-footnote-anchor-text)) (id (format "fnr.%s%s" (or label n) (if (org-export-footnote-first-reference-p @@ -2774,7 +2799,21 @@ (defun org-html-footnote-reference (footnote-reference _contents info) (format (plist-get inf
Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]
> From: Ihor Radchenko > Date: Sun, 28 Apr 2024 10:22:50 +0000 > > Protesilaos Stavrou writes: > >>> See the attached tentative patch. >> >>> [... 144 lines elided] >> >> Thank you! I just tried it. I encountered two problems with it, which I >> am addressing with the two attached patches (feel free to modify as >> needed). In short: >> >> 1. The footnote definitions at the bottom of the file were still using >> the ordinal HTML id, which did not correspond to the href with the >> label. >> >> 2. If the file had a mixture of labeled and anonymous/unlabeled >> footnotes, then the export would break as it would be passing a nil >> value to 'string-to-number'. >> >> Please let me know how to proceed. > > Applied, onto main, after squashing the patches together. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=065af4b42 > Handled. Thank you! -- Protesilaos Stavrou https://protesilaos.com
Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]
> From: Max Nikulin > Date: Fri, 26 Apr 2024 16:53:23 +0700 > > On 26/04/2024 15:17, Protesilaos Stavrou wrote: >> Since we are now using labels for the HTML export, I think it makes >> sense to optionally use those for the anchor tags as well. > [...] > >> +(defcustom org-html-footnote-use-label-for-anchor-text nil > > Another option may be to rely on the existing one: > `org-html-prefer-user-labels' Yes, sure. It is fine to reuse an existing user option. Though reading through its docstring and the code, I cannot tell what this is doing exactly. Is it applying to all HTML elements, or just headings? On my end, I have that option set to nil, but exported headings do use their CUSTOM_ID. -- Protesilaos Stavrou https://protesilaos.com
Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]
Hello again! A follow-up on the patches below: > From: Protesilaos Stavrou > Date: Fri, 26 Apr 2024 10:55:50 +0300 > [... 41 lines elided] > Thank you! I just tried it. I encountered two problems with it, which I > am addressing with the two attached patches (feel free to modify as > needed). In short: > > 1. The footnote definitions at the bottom of the file were still using > the ordinal HTML id, which did not correspond to the href with the > label. > > 2. If the file had a mixture of labeled and anonymous/unlabeled > footnotes, then the export would break as it would be passing a nil > value to 'string-to-number'. > > Please let me know how to proceed. Since we are now using labels for the HTML export, I think it makes sense to optionally use those for the anchor tags as well. See the attached patch for a possible way of doing this. As always, you are welcome to make any further changes. -- Protesilaos Stavrou https://protesilaos.com >From 681db0934e55ae6c2971ccfbfd9de7c0828506c9 Mon Sep 17 00:00:00 2001 Message-Id: <681db0934e55ae6c2971ccfbfd9de7c0828506c9.1714119282.git.i...@protesilaos.com> From: Protesilaos Stavrou Date: Fri, 26 Apr 2024 11:14:28 +0300 Subject: [PATCH] Provide option to use footnote label as the HTML anchor text * lisp/ox-html.el (org-html-footnote-use-label-for-anchor-text): Define new user option. (org-html-footnote-section, org-html-footnote-reference): Use the new option. --- lisp/ox-html.el | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 0237e61..804a464 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -699,6 +699,17 @@ (defcustom org-html-footnote-separator ", " :group 'org-export-html :type 'string) +(defcustom org-html-footnote-use-label-for-anchor-text nil + "When non-nil, use the footnote label as the anchor text. +When nil, use the number of the footnote as the anchor text. + +- For footnotes, this is the format: [fn:LABEL]. +- For inline footnotes, it is this: [fn:LABEL: Some text]." + :group 'org-export-html + :version "30.1" + :package-version '(Org . "9.7") + :type 'boolean) + Headline (defcustom org-html-toplevel-hlevel 2 @@ -1900,7 +1911,9 @@ (defun org-html-footnote-section (info) (if label (format "fn.%s" label) (format "fn.%d" n)) - n +(if (and org-html-footnote-use-label-for-anchor-text label) +label + n) (format " class=\"footnum\" href=\"#fnr.%s\" role=\"doc-backlink\"" (or label n)) info)) (contents (org-trim (org-export-data def info @@ -2768,7 +2781,11 @@ (defun org-html-footnote-reference (footnote-reference _contents info) (format (plist-get info :html-footnote-format) (org-html--anchor - id n (format " class=\"footref\" href=\"#fn.%s\" role=\"doc-backlink\"" (or label n)) info) + id + (if (and org-html-footnote-use-label-for-anchor-text label) + label + n) + (format " class=\"footref\" href=\"#fn.%s\" role=\"doc-backlink\"" (or label n)) info) Headline -- 2.39.2
Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]
> From: Ihor Radchenko > Date: Sat, 13 Apr 2024 14:00:48 +0000 > > Protesilaos Stavrou writes: > >> With regard to the disambiguation scheme, I am playing around with >> various scenaria to see how Org HTML export behaves. Using the >> following: >> ... >> This is test 2 > role="doc-backlink">1 >> ... >> This is test 3 > role="doc-backlink">1 >> >> Notice that the 100 in the ID is not incremented further. I guess this >> is something that can be worked on but, again, I think it is separate >> from the issue of using the label for the ID and HREF. >> >> Any thoughts? > > Duplicate IDs are against HTML spec: > https://softwareengineering.stackexchange.com/questions/127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really > > So, this is a bug. Indeed! We can look into this separately. >>>> Though I should have clarified my intent earlier: the idea is to use the >>>> label as a fixed reference to the footnote, so that the link does not >>>> change between exports. This is the same principle as what we do with >>>> links to headings that have a CUSTOM_ID. >>>> >>>> As such, the anchor text can still be the way it is now as an >>>> automatically generated number sequence (^1, ^2, etc.), but the HTML >>>> "id" and "href" values will be constructed based on the label of the >>>> footnote, NOT its number in the sequence. > > See the attached tentative patch. > [... 144 lines elided] Thank you! I just tried it. I encountered two problems with it, which I am addressing with the two attached patches (feel free to modify as needed). In short: 1. The footnote definitions at the bottom of the file were still using the ordinal HTML id, which did not correspond to the href with the label. 2. If the file had a mixture of labeled and anonymous/unlabeled footnotes, then the export would break as it would be passing a nil value to 'string-to-number'. Please let me know how to proceed. -- Protesilaos Stavrou https://protesilaos.com >From 0fb81645aafb780116465e13758601ff1183e043 Mon Sep 17 00:00:00 2001 Message-Id: <0fb81645aafb780116465e13758601ff1183e043.1714117826.git.i...@protesilaos.com> From: Protesilaos Stavrou Date: Fri, 26 Apr 2024 10:41:51 +0300 Subject: [PATCH 1/2] Use the label, if present, in footnote definition * lisp/ox-html.el (org-html-footnote-section): Account for a non-nil label value. --- lisp/ox-html.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index aa0f891..95ecb44 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -1896,7 +1896,9 @@ (defun org-html-footnote-section (info) (let ((inline? (not (org-element-map def org-element-all-elements #'identity nil t))) (anchor (org-html--anchor - (format "fn.%d" n) +(if label + (format "fn.%s" label) + (format "fn.%d" n)) n (format " class=\"footnum\" href=\"#fnr.%s\" role=\"doc-backlink\"" (or label n)) info)) -- 2.39.2 >From 112c5671e5f55ea1d9e5e9fb6dd647e6a739c9ac Mon Sep 17 00:00:00 2001 Message-Id: <112c5671e5f55ea1d9e5e9fb6dd647e6a739c9ac.1714117826.git.i...@protesilaos.com> In-Reply-To: <0fb81645aafb780116465e13758601ff1183e043.1714117826.git.i...@protesilaos.com> References: <0fb81645aafb780116465e13758601ff1183e043.1714117826.git.i...@protesilaos.com> From: Protesilaos Stavrou Date: Fri, 26 Apr 2024 10:49:26 +0300 Subject: [PATCH 2/2] Guard against nil label value for footnotes * lisp/ox-html.el (org-html-footnote-section) (org-html-footnote-reference): Check if label is a string before passing it to 'string-to-number'. This fixes the case where we are exporting some footnotes with a label and some without a label. --- lisp/ox-html.el | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 95ecb44..0237e61 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -1886,7 +1886,8 @@ (defun org-html-footnote-section (info) ;; - the footnotes are re-numbered by ;; `org-export-get-footnote-number'. If the label is not ;; a number, keep it. - (when (equal label (number-to-string (string-to-number label))) + (when (and (stringp label) +(equal label (number-to-string (string-to-number label (setq label nil)) ;; `org-export-collect-footnote-definitions' can return ;; two kinds of footnote definitions: inline and blocks. @@ -2754,8 +2755,10 @@ (defun org-html-footnote-reference (footnote-reference _contents info)
Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]
> From: Ihor Radchenko > Date: Wed, 10 Apr 2024 14:31:22 +0000 > > Protesilaos Stavrou writes: > >> Though I should have clarified my intent earlier: the idea is to use the >> label as a fixed reference to the footnote, so that the link does not >> change between exports. This is the same principle as what we do with >> links to headings that have a CUSTOM_ID. >> >> As such, the anchor text can still be the way it is now as an >> automatically generated number sequence (^1, ^2, etc.), but the HTML >> "id" and "href" values will be constructed based on the label of the >> footnote, NOT its number in the sequence. >> >> What do you think? > > That may work. One may simply change the anchors for footnote references > and footnotes when they are labeled. However, we should be careful when > labels are duplicated (multiple references to the same named footnote) - > only a single back-reference is possible from the footnote definition > back to footnote reference. I think the issue of labelling the footnotes is separate from disambiguating them and avoiding duplicates. Of course, having the latter is nice. But the part about the labels should be limited to the use of the data we already have to keep the patch/change small (maybe subject to an opt-in user option to not disrupt any existing workflow). With regard to the disambiguation scheme, I am playing around with various scenaria to see how Org HTML export behaves. Using the following: * Heading This is test 1 [fn:hello] This is test 2 [fn:hello] This is another test [fn:1] This is test 3 [fn:hello] * Footnotes [fn:1] [fn:hello] Hello We get this excerpt from the HTML output: This is test 1 1 This is test 2 1 This is another test 2 This is test 3 1 Notice that the 100 in the ID is not incremented further. I guess this is something that can be worked on but, again, I think it is separate from the issue of using the label for the ID and HREF. Any thoughts? -- Protesilaos Stavrou https://protesilaos.com
Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]
Thank you Ihor for looking into this! > From: Ihor Radchenko > Date: Fri, 5 Apr 2024 14:33:49 + > [... 13 lines elided] >> I looked into the ox.el and noticed that the export data does include >> the labels. But 'org-html-footnote-reference' does not have a call to >> get the label: it assigns a number outright. To experiment with >> retrieving the data, I tried this: >> ... >>(let* ((n (or >> (org-export-get-footnote-label footnote-reference) >> (org-export-get-footnote-number footnote-reference info))) >> ... >> Can we have footnotes with their label preserved? Or maybe is this going >> to break a lot of functionality? I am aware the above not work for >> footnote definitions, as those also get the number. > > The problem arises when only some footnotes have a label: > > This is a test 1 [fn:n24aa:These are the contents] and here is > more[fn::another one]. > > What to do with the unlabelled ones? Assign a number? If yes, what kind > of number? `org-export-get-footnote-number' counts all the footnotes, > including labelled ones; so that returned number will be 2 in the above > example, leading to awkward ^n24aa followed by ^2 footnote. > But even without `org-export-get-footnote-number', ^n24aa ^1 mixture > might be awkward. > > One way could be only using footnote labels when _all_ the footnotes > are labelled. I think it is fine to have an all or nothing approach, if this is easier to do. Though I should have clarified my intent earlier: the idea is to use the label as a fixed reference to the footnote, so that the link does not change between exports. This is the same principle as what we do with links to headings that have a CUSTOM_ID. As such, the anchor text can still be the way it is now as an automatically generated number sequence (^1, ^2, etc.), but the HTML "id" and "href" values will be constructed based on the label of the footnote, NOT its number in the sequence. What do you think? Thank you again for your time and efforts! -- Protesilaos Stavrou https://protesilaos.com
[BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]
Dear maintainer, I have an Org file with contents like the following: This is a test 1 [fn:n24aa:These are the contents] and here is more. When I do an HTML export, the footnote's label (n24aa) is not preserved in the exported HTML. Is this intended behaviour? I was expecting it to keep the label as a user-defined unique identifier. I looked into the ox.el and noticed that the export data does include the labels. But 'org-html-footnote-reference' does not have a call to get the label: it assigns a number outright. To experiment with retrieving the data, I tried this: ;; PROOF-OF-CONCEPT that works for footnote references but not ;; footnote definitions (defun org-export-get-footnote-label (footnote) (org-element-property :label footnote)) (defun org-html-footnote-reference (footnote-reference _contents info) "Transcode a FOOTNOTE-REFERENCE element from Org to HTML. CONTENTS is nil. INFO is a plist holding contextual information." (concat ;; Insert separator between two footnotes in a row. (let ((prev (org-export-get-previous-element footnote-reference info))) (when (eq (org-element-type prev) 'footnote-reference) (plist-get info :html-footnote-separator))) (let* ((n (or (org-export-get-footnote-label footnote-reference) (org-export-get-footnote-number footnote-reference info))) (id (format "fnr.%s%s" n (if (org-export-footnote-first-reference-p footnote-reference info) "" ".100" (format (plist-get info :html-footnote-format) (org-html--anchor id n (format " class=\"footref\" href=\"#fn.%s\" role=\"doc-backlink\"" n) info) Can we have footnotes with their label preserved? Or maybe is this going to break a lot of functionality? I am aware the above not work for footnote definitions, as those also get the number. I am happy to keep studying the export infrastructure if you give me some pointers. Thank you for your time and for maintaining this wonderful project! All the best, Protesilaos (or simply "Prot") * * * Emacs : GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.16.0) of 2024-04-03 Package: Org mode version 9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/) -- Protesilaos Stavrou https://protesilaos.com
Re: Fwd: [BUG] Sparse tree does not work on properties with dashes
> From: Ihor Radchenko > Date: Tue, 19 Mar 2024 14:03:23 + > > Ihor Radchenko writes: > >> `org-make-tags-matcher' is now supposed to handle \-escaped dashes in >> properties. However, it does not seem to work: >> >> (org-make-tags-matcher "TEST\-HELLO=\"one\"" t) yields > > ... which was as expected - I forgot to quote \ inside "...". > > The problem was different - sparse tree should escape "-" in property > names by itself when building the matcher. > > Fixed, on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=63b10621a Thank you! -- Protesilaos Stavrou https://protesilaos.com
Re: [DISCUSSION] Face priority in Org fontification (was: [BUG] org dates, radio links, and special keywords override heading backgrounds [9.7 (9.7-??-902dacb @ /home/st/.config/emacs/.local/straight/
> From: Ihor Radchenko > Date: Wed, 13 Mar 2024 14:27:18 + > [... 16 lines elided] >>> CCing Protesilaos. This discussion might be of interest for him. >> >> I think it makes sense to not override the background because otherwise >> the heading can look visually "broken". See attached screenshot for an >> example: it is called "demo-org-heading-with-background.png". In that >> screenshot I include an overline for the heading, to show how this is >> not limited to the background colour but extends to all face attributes. >> To this end, I also attach "demo-org-heading-with-more-height.png" which >> shows how the date is not scaling to match the heading's increased text >> height. > > I agree that override (what we do now) is clearly not good. > The question, however, is whether we should prioritize object face over > the containing element face or vice versa: > > Should link properties take precedence over headline or should headline > properties take precedence? > > For example, if link explicitly sets face height to be smaller, should > we honor it? Or should we honor the headline face height, if set? > Similar for background. In your example, the white background override > does not really look nice when heading has its own background. This can get tricky, I know. The idea is to make this behave how all faces relate to the 'default' face with regard to their 'undefined' attributes. Namely, if a face defines an attribute, then it overrides the 'default' face, otherwise it falls back to it for the value of the given attribute. In the case of the headlines then, every other element should attain the attributes of the heading unless it explicitly overrides them. So a link with an 'undefined' height will be as high as the heading, but a link with a height of, say, 1.0 will keep that height even if the heading is at a 2.0 height (or whatever). Same idea for all face attributes. Now the tricky part is to figure out which combinations can work this way. Headings and source blocks are two obvious ones. Maybe there are more, but I cannot think of one right now. -- Protesilaos Stavrou https://protesilaos.com
Re: [DISCUSSION] Face priority in Org fontification (was: [BUG] org dates, radio links, and special keywords override heading backgrounds [9.7 (9.7-??-902dacb @ /home/st/.config/emacs/.local/straight/
Thank you, Ihor! > From: Ihor Radchenko > Date: Mon, 4 Mar 2024 10:32:38 + > > StrawberryTea writes: > >> Hello. Currently, if you have a heading background, and you have a date, >> radio link, or special keyword, the background is overridden. I have >> attached a patch that fixes this issue by using the `prepend' property >> instead of the `t' property. Here is also a minimal example to reproduce >> the issue: > > This is not an exhaustive list. We have a number of markup objects that > are fontified overriding the containing element/paragraph/heading face: > > - target links > - timestamps > - footnotes > - radio targets > - macros > - inline export snippets > > I am not 100% sure we should unconditionally prepend their faces to > the containing headline/table/etc. > > CCing Protesilaos. This discussion might be of interest for him. I think it makes sense to not override the background because otherwise the heading can look visually "broken". See attached screenshot for an example: it is called "demo-org-heading-with-background.png". In that screenshot I include an overline for the heading, to show how this is not limited to the background colour but extends to all face attributes. To this end, I also attach "demo-org-heading-with-more-height.png" which shows how the date is not scaling to match the heading's increased text height. All the best, Protesilaos (or simply "Prot") -- Protesilaos Stavrou https://protesilaos.com
Re: [PATCH] Define new face for the contents of #+RESULTS drawers
> From: Ihor Radchenko > Date: Sat, 16 Sep 2023 12:44:37 + > [... 79 lines elided] > I am still not 100% sure what exactly you want to achieve - just > highlight evaluation results that are _also_ fixed-width or all kinds of > evaluation results. The goal is to make all kinds of evaluation results distinct from their manually written counterparts. This is for users who read/interact with a document and are given basic instructions on what to do while still not knowing everything Org has to offer. Though I understand now that there are more cases involved than I had anticipated. I will need to review everything on offer. Let's abort this effort for now. Thank you for your time! -- Protesilaos Stavrou https://protesilaos.com
Re: [PATCH] Define new face for the contents of #+RESULTS drawers
> From: Ihor Radchenko > Date: Sat, 16 Sep 2023 09:49:50 + > [... 9 lines elided] >> +(defface org-code-results '((t :inherit org-code)) >> + "Face for the contents of #+RESULTS drawers." >> + :group 'org-faces >> + :version "30.1") > > I think there is some misunderstanding here. > #+RESULTS is not a drawer. A drawer would be > > :results: > ... > :end: Oh, I see. How do we describe it? A keyword, perhaps? > As for code evaluation results, it can be anything with #+results > keyword. Like > > #+results: > : fixed width > : text > > or > > #+results: > #+begin_example > ... > #+end_example > > or > > #+results: > Simple paragraph of text. > >>;; Code >> - '(org-activate-code (1 'org-code t)) >> + '(org-activate-code (1 'org-code-results t)) > > `org-activate-code' only affects fixed-width text > > : like > : this > : > : one > > It has no relation to code results, except that fixed width is often > (but not always) used as the default markup for results of evaluation. > > If what you are looking for is different formatting for code markup and > fixed-width markup, `org-fixed-width' would be a better face name. > > If you are looking for formatting of results of evaluation, it would > need to be a completely new, non-trivial, font-lock-keyword. Thank you for the explanation! The case I had in mind was indeed the one where the 'org-code' face now applies. I am interested in making the results display as distinct elements. The reason is that it can sometimes be hard to tell what was there before and what was generated by 'org-babel-execute-buffer' and related. You are right to point out that adding font-lock rules for all the possible #+results is not trivial. Better leave it as-is. -- Protesilaos Stavrou https://protesilaos.com
[PATCH] Define new face for the contents of #+RESULTS drawers
Hello folks! I propose the attached patch. It gives users/themes the opportunity to style the contents of #+RESULTS drawers differently than the face applied to ~code~ elements. To preserve the current style, I made the new face inherit 'org-code'. What do you think? All the best, Protesilaos (or simply "Prot") -- Protesilaos Stavrou https://protesilaos.com >From 1ecd64bfe88d06684a9ad97c1ee6df0bdd2c1eb2 Mon Sep 17 00:00:00 2001 Message-ID: <1ecd64bfe88d06684a9ad97c1ee6df0bdd2c1eb2.1694856985.git.i...@protesilaos.com> From: Protesilaos Stavrou Date: Sat, 16 Sep 2023 12:36:18 +0300 Subject: [PATCH] Define new face for the contents of #+RESULTS drawers * lisp/org-faces.el (org-code-results): Define new face. * lisp/org.el (org-set-font-lock-defaults): Use it instead of the generic 'org-code' face. --- lisp/org-faces.el | 5 + lisp/org.el | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/lisp/org-faces.el b/lisp/org-faces.el index 436552cb2..3d233eaff 100644 --- a/lisp/org-faces.el +++ b/lisp/org-faces.el @@ -409,6 +409,11 @@ (defface org-code '((t :inherit shadow)) :group 'org-faces :version "22.1") +(defface org-code-results '((t :inherit org-code)) + "Face for the contents of #+RESULTS drawers." + :group 'org-faces + :version "30.1") + (defface org-meta-line '((t :inherit font-lock-comment-face)) "Face for meta lines starting with \"#+\"." :group 'org-faces diff --git a/lisp/org.el b/lisp/org.el index 84ac87438..6fb099618 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5905,7 +5905,7 @@ (defun org-set-font-lock-defaults () '(org-fontify-entities) '(org-raise-scripts) ;; Code - '(org-activate-code (1 'org-code t)) + '(org-activate-code (1 'org-code-results t)) ;; COMMENT (list (format "^\\*+\\(?: +%s\\)?\\(?: +\\[#[A-Z0-9]\\]\\)? +\\(?9:%s\\)\\(?: \\|$\\)" -- 2.42.0
bug#52587: 29.0.50; Wrong block header/footer background in Org
On 2021-12-26, 22:04 +0100, Rudolf Adamkovič wrote: > Protesilaos Stavrou writes: > >> Do you get the same results? > > Oh, I do! That said, if I reverse last two steps, I do not: > >> - Create a file with demo content, such as ~/test-org-block.org >> - Execute 'emacs -Q' on the command-line. >> - M-x load-theme RET modus-operandi >> - C-x C-f test-org-block.org RET Gotcha! I can reproduce that. It is not a theme issue. I checked the Org code a bit. There is a function in org-compat.el called 'org--set-faces-extend' and in org.el we see it being used in the (define-derived-mode org-mode ... part. In other words, M-x org-mode wants those faces to have ':extend t'. I must investigate this further, though my first impression is that we need to notify the Org folks about it. -- Protesilaos Stavrou https://protesilaos.com
bug#52587: 29.0.50; Wrong block header/footer background in Org
On 2021-12-26, 11:22 +0100, Rudolf Adamkovič wrote: > Protesilaos Stavrou writes: > >> [ I will sync with emacs.git as soon as I publish the next tagged >> version (2.0.0). It is a big one and the change log will take some >> time to prepare... Maybe this week. ] > > I noticed "Update modus-themes to version 2.0.0" in the Git log. Yet, I > compiled Emacs today (2021-12-26), and the gray area extends > edge-to-edge while modus-themes-org-blocks equals nil. Perhaps I > misunderstood your intention? No, you did not misunderstand my intention. Maybe something else is going on, as I am getting the expected results. Check the attached screenshot. Steps to reproduce the screenshot: - Create a file with demo content, such as ~/test-org-block.org: * Testing This is a test #+begin_src emacs-lisp (message "Hello world") #+end_src * Test - Execute 'emacs -Q' on the command-line. - C-x C-f test-org-block.org RET - M-x load-theme RET modus-operandi Do you get the same results? -- Protesilaos Stavrou https://protesilaos.com
Re: [PATCH] Fontification for inline src blocks
On 2021-10-03, 17:09 +0800, Ihor Radchenko wrote:
> Timothy writes:
>
>> Ihor Radchenko writes:
>>
>>> Let me bump this thread again and mark it as a patch ;)
>>
>> Thanks for the bump. I'd like to get this working, but I don't know how best
>> to
>> deal with the "prettification" of {{{results(=value=)}}}, which is the major
>> blocker as I
>> see it.
>
> What about separating the src_{} fontification into separate patch? I
> think that part raised no objections.
>
> As for the results prettifications, I look at this and similar ideas as
> at Emacs themes. It looks nice on your screenshot with your fonts and
> colours, but may not be good for other people. Similar to org-bullets
> and co.
>
> I can see how some people (I am among those people) want to reduce the
> markup noise beyond hiding emphasis markers. However, some people
> prefer not to hide text in buffer under "bells and whistles". Maybe we
> can create some kind of "prettify-symbol themes" replacing different
> markup elements in bulk with nice symbols/svg (e.g. inline results,
> block headers/footers, uninteresting property drawers aka
> org-custom-properties, bullets, etc)?
> WDYT?
>
> Also, CCing Prot as it might be of interest for him.
Thank you!
I am monitoring the discussion in case there is something I would need
to do for my themes. Otherwise I have no technical insight to offer
about the substance of this feature.
With regard to the use of faces, I generally find that re-purposing
faces in an altogether different context than their original can create
constraints for users/themes. For example, and without having tried the
patch yet, we find this:[1]
(font-lock-append-text-property beg lang-end 'face 'org-block)
Is the text-to-be-propertised the same as an Org block or does it differ
in purpose/presentation? Because a user/theme may like their blocks to
e.g. have no background of their own, but also wish to maintain a
distinct background colour for inline constructs like org-verbatim,
org-code, and those discussed here. The rationale would be that blocks
are clear enough due to their innate spacing and indentation, whereas
inline constructs are surrounded by text.
This is not a hard requirement, of course, while too many overly
specific faces can also prove problematic for testing/maintenance. Just
something for you to bear in mind.
Finally, how does the use of 'org-block' in this context relate to
'org-src-block-faces'? Could there be undesired conflicts in styling or
whatnot?
All the best,
Prot
[1] <https://list.orgmode.org/87pmzf4bd0@gmail.com/>
--
Protesilaos Stavrou
https://protesilaos.com
Re: Elegant way to export org to Markdown ?
On 2021-10-02, 14:20 +0900, Jean-Christophe Helary wrote: > I'm trying to work with SourceHut (sr.ht) and right now they only > accept Markdown syntax for their readme/wiki files. > > Since I work in Emacs/org-mode to write my documents (and try to stick > to that), I'd like to know if there is an elegant way to export org > syntax to MarkDown. > > I was thinking that the export-dispatch had an option for Plain Text / > Markdown, but that doesn't seem to be the case. Hello Jean-Christophe, Have you tried the 'ox-md' which is part of Org? Like this: (require 'ox-md) (add-to-list 'org-export-backends 'md) The export dispatched should then have an "Export to Markdown" option bound to 'm'. There are more export backends as well. If you do M-x find-library and search for "ox-" you will find more options. All the best, Protesilaos (or simply "Prot") -- Protesilaos Stavrou https://protesilaos.com
Possible bug? Combine emphasis marker faces?
Hello everyone, I have noticed that it is not possible to combine org-emphasis-alist characters. When applying multiple types of emphasis, the face corresponding to the outermost pair overrides its innermost counterparts. For example, */emphasise/* will render with the 'bold' face, while /*emphasise*/ will use the 'italic' face. Looking at the code, this seems to be intentional or unavoidable, while I do not know of a way to blend faces dynamically. Is there a way to get composite styles? Such as bold and italic or verbatim and underline, etc.? All the best, Protesilaos (or simply "Prot") * * * M-x org-version: Org mode version 9.4.4 (release_9.4.4 @ /usr/share/emacs/28.0.50/lisp/org/) M-x emacs-version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4) of 2021-09-28 -- Protesilaos Stavrou https://protesilaos.com
Re: [PATCH] Add faces to improve contextuality of agenda views
On 2021-09-26, 10:45 +0200, Bastien wrote: >> The attached patch defines and implements a few new faces for the >> agenda. > > Applied, thank you very much for the thorough explanations and the > well-written patch and commit message. > > This deserves an entry in etc/ORG-NEWS for Org 9.5: would you be > willing to submit a patch for this? Hello again Bastien! Please find attached the entry for the ORG-NEWS. All the best, Protesilaos -- Protesilaos Stavrou https://protesilaos.com >From ac96612c9e1313ef40fef042c4e79771776423bd Mon Sep 17 00:00:00 2001 Message-Id: From: Protesilaos Stavrou Date: Sun, 26 Sep 2021 15:27:31 +0300 Subject: [PATCH] Document new agenda faces in the ORG-NEWS --- etc/ORG-NEWS | 38 ++ 1 file changed, 38 insertions(+) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 80a8bc388..f3cebd836 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -168,6 +168,44 @@ When specifying a custom agenda bulk option, you can now also specify a function which collects the arguments to be used with each call to the custom function. +*** New faces to improve the contextuality of Org agenda views + +Four new faces improve certain styles and offer more flexibility for +some Org agenda views: ~org-agenda-date-weekend-today~, +~org-imminent-deadline~, ~org-agenda-structure-secondary~, +~org-agenda-structure-filter~. They inherit from existing faces in +order to remain backward-compatible. + +Quoting from [[https://list.orgmode.org/87lf7q7gpq@protesilaos.com/][this thread]]: + +#+begin_quote ++ The 'org-imminent-deadline' is useful to disambiguate generic + warnings from deadlines. For example, a warning could be rendered + in a yellow colored text and have a bold weight, whereas a deadline + might be red and styled with italics. + ++ The 'org-agenda-structure-filter' applies to all tag/term filters + in agenda views that search for keywords or patterns. It is + designed to inherit from 'org-agenda-structure' in addition to the + 'org-warning' face that was present before (and removes the + generic 'warning' face from one place). This offers the benefit + of consistency, as, say, an increase in font height or a change in + font family in 'org-agenda-structure' will propagate to the filter + as well. The whole header line thus looks part of a singular + design. + ++ The 'org-agenda-structure-secondary' complements the above for those + same views where a description follows the header. For instance, the + tags view provides information to "Press N r" to filter by a + numbered tag. Themes/users may prefer to disambiguate this line + from the header above it, such as by using a less intense color or by + reducing its height relative to the 'org-agenda-structure'. + ++ The 'org-agenda-date-weekend-today' provides the option to + differentiate the current date on a weekend from the current date on + weekdays. +#+end_quote + *** New option ~org-clock-ask-before-exiting~ By default, a function is now added to ~kill-emacs-query-functions~ -- 2.33.0
Re: [PATCH] Add faces to improve contextuality of agenda views
On 2021-09-26, 10:45 +0200, Bastien wrote: >> The attached patch defines and implements a few new faces for the >> agenda. > > Applied, thank you very much for the thorough explanations and the > well-written patch and commit message. Thank you, Bastien (for this and for maintaining Org in general)! > This deserves an entry in etc/ORG-NEWS for Org 9.5: would you be > willing to submit a patch for this? Yes, I will prepare one, though I am committed to a task right now and will only be available again in ~3 hours. -- Protesilaos Stavrou https://protesilaos.com
Re: [PATCH] Add faces to improve contextuality of agenda views
On 2021-09-19, 21:23 +0800, Timothy wrote: > Hi Protesilaos, Hello Timothy, > Thanks for sending this patch in, and sorry it’s taken a while for you to hear > anything back. No worries. I understand this is a voluntary effort. > I see the utility of org-imminent-deadline, but am fairly indifferent > about the rest. I can provide examples in case someone needs them. The basic idea is to ensure consistency of styling. Right now, if you increase the height of the 'org-agenda-structure' and do something like M-x org-agenda followed by 'm' you will get a header that reads like: Headlines with TAGS match: admin The "admin" part is smaller than the rest. It is this sort of inconsistency that we wish to address. We do it in a manner that is backward-compatible, which means that themes do not have to be updated for users to benefit from the new design (though users/themes gain the option to control the presentation with greater precision). > Hopefully bumping this might prompt some others to give their thoughts on your > patch. I am happy to wait for as long as necessary and remain at your disposal for any further commentary or possible edits to the patch. Given this opportunity, thank you and the others for your contributions to Org. Best regards, Protesilaos -- Protesilaos Stavrou https://protesilaos.com
Re: Smart quotes for Greek (questions for a possible patch)
On 2021-08-16, 00:28 +0300, mvar wrote: > Juan Manuel Macías writes: > >> Hi, >> >> I would like to submit a patch to add smart quotes for Greek in >> `org-export-smart-quotes-alist', but I have a couple of questions. >> >> First of all, I am not a native speaker of Greek but of Spanish, so I >> would also like to have the opinion of some Greek native speaker, to see >> if my solutions are correct. >> >> The second question concerns the second-level quotation marks for Greek. >> The first level ones are the same as the Spanish or French quotes >> (without the extra space of French): «», so no problem. I follow here >> the rule that Yannis Haralambous explains in "From Unicode to >> Typography, a Case Study: the Greek Script" (1999, p. 20: >> http://web.archive.org/web/20120229131933/http://omega.enstb.org/yannis/pdf/boston99.pdf). >> >> According to Haralambous, on the second-level quotation marks (the >> emphases are mine): >> >> #+begin_quote >> >> Also interesting is the case of the second level quotes. Here, quotes of >> the size and shape of the English ones are used, but the opening quotes >> are inverted, similar in form to raised small round guillemets [...]. >> Fortunately these quotes are provided by the Unicode standard (*U+201F* >> and U+201D, the latter being the same closing double quotes as in >> English); *the author knows no other language in which this combination >> of double quotes might be used*. >> >> #+end_quote >> >> >> So the problem is in the character U+201F (assuming Haralambous is >> right). For the keywords `:utf8' and `html' no problem. But I don't know >> what to put in `:latex' or in `:texinfo': >> >> #+begin_src emacs-lisp >> (secondary-opening :utf-8 "‟" :html ";" :latex "??" :texinfo "??") >> #+end_src >> >> In fact, I think latex2e has no command or shorthand predefined for this >> character (see https://ibb.co/ZBGmwYP). There would be no problem with >> LuaTeX and XeTeX. But this character would be difficult to obtain in >> pdfTeX even using inputenc with the utf8 option. >> >> Best regards, >> >> Juan Manuel > > hi Juan, > > i can confirm the «» characters are the proper ones for the first level > of quoting..Now about second level, personally i haven't seen such nesting in > ages but IIRC they should be the ones (or *very* similar) in the linked image > you posted -> > \textquotedblleft and \textquotedblright. I've no idea how these > translate to UTF. Note that the standard greek keyboards & keymaps do not have > any of these characters mapped by default (not even «» ), most people use the > standard > english double/single quotes, at least in electronic writing (articles, > daily communication etc). > Protesilaos (cc) might have a better view on this matter. > > cheers, > Michalis Hello Michalis, Juan Manuel, [ I had no access to a computer and could not get to you sooner. Expect timely replies from now on. ] The first level quotes are indeed «». For the other two, I have to rely on what I have encountered before, namely, that the second level is denoted with double curly quotes “” and third with single curly quotes ‘’. I have come across those in EU documents. There is a style guide for the European Institutions.[1][2][3] I do not know latex notation to help you with the technicalities. Here are the unicode points: | « | U+00AB | | » | U+00BB | | “ | U+201C | | ” | U+201D | | ‘ | U+2018 | | ’ | U+2019 | All the best, Protesilaos [1] Quotes: <http://publications.europa.eu/code/el/el-4100107el.htm>. [2] General info: <http://publications.europa.eu/code/el/el-410.htm>. [3] Main portal: <http://publications.europa.eu/code/el/el-000100.htm>. -- Protesilaos Stavrou https://protesilaos.com
[PATCH] Add faces to improve contextuality of agenda views
Hello everyone! The attached patch defines and implements a few new faces for the agenda. Quoting from the commit message: These new faces are designed to improve the ability of themes/users to control the presentation of agenda views. They inherit from existing faces in order to remain backward-compatible. + The 'org-imminent-deadline' is useful to disambiguate generic warnings from deadlines. For example, a warning could be rendered in a yellow colored text and have a bold weight, whereas a deadline might be red and styled with italics. + The 'org-agenda-structure-filter' applies to all tag/term filters in agenda views that search for keywords or patterns. It is designed to inherit from 'org-agenda-structure' in addition to the 'org-warning' face that was present before (and removes the generic 'warning' face from one place). This offers the benefit of consistency, as, say, an increase in font height or a change in font family in 'org-agenda-structure' will propagate to the filter as well. The whole header line thus looks part of a singular design. + The 'org-agenda-structure-secondary' complements the above for those same views where a description follows the header. For instance, the tags view provides information to "Press N r" to filter by a numbered tag. Themes/users may prefer to disambiguate this line from the header above it, such as by using a less intense color or by reducing its height relative to the 'org-agenda-structure'. + The 'org-agenda-date-weekend-today' provides the option to differentiate the current date on a weekend from the current date on weekdays. Some more words about the motivation behind this patch, which are not included in the commit message: + The 'org-warning' is a generic face that should always convey a clear warning sign. It does that well. Deadlines also got styled with this by default, which meant that they could not be toned down a bit, or otherwise tweaked to meet the requirements of the agenda, without compromising the intended purpose of a prominent warning. Ultimately this is about choice: users/themes may not want to use intense styles for deadlines by default. - For some prior work on applying a bespoke face instead of 'org-warning', refer to commit 7ebb2d562 in org.git. + The 'org-agenda-date-weekend-today' complements the existing faces for differentiating weekdays from weekends. So the "current day" can now be adapted to this distinction, depending on the user's particular needs. What do you think? Is there something you would like to see done differently? I include Gustavo Barros in Cc, with whom we identified the potential for these changes and who helped me think about their design and test their implementation. This is done for communication purposes: any errors are exclusively my own. I have already assigned copyright to the FSF and have made such contributions before. All the best, Protesilaos or "Prot" -- Protesilaos Stavrou https://protesilaos.com >From b47af2b79c5ecfe0954dfd0bbe1bedd531b81417 Mon Sep 17 00:00:00 2001 Message-Id: From: Protesilaos Stavrou Date: Wed, 2 Jun 2021 12:51:07 +0300 Subject: [PATCH] Add faces to improve contextuality of agenda views * lisp/org-agenda.el (org-search-view) (org-agenda-propertize-selected-todo-keywords, org-todo-list) (org-tags-view): Implement new org-agenda-structure-filter and org-agenda-structure-secondary faces. (org-agenda-get-day-face): Add condition for rendering the current date heading in org-agenda-date-weekend-today. * lisp/org-faces.el (org-agenda-structure-secondary) (org-agenda-date-weekend-today, org-agenda-structure-filter) (org-imminent-deadline): Add new faces. (org-agenda-deadline-faces): Use the 'org-imminent-deadline' for current deadlines instead of the generic 'org-warning'. - These new faces are designed to improve the ability of themes/users to control the presentation of agenda views. They inherit from existing faces in order to remain backward-compatible. + The 'org-imminent-deadline' is useful to disambiguate generic warnings from deadlines. For example, a warning could be rendered in a yellow colored text and have a bold weight, whereas a deadline might be red and styled with italics. + The 'org-agenda-structure-filter' applies to all tag/term filters in agenda views that search for keywords or patterns. It is designed to inherit from 'org-agenda-structure' in addition to the 'org-warning' face that was present before (and removes the generic 'warning' face from one place). This offers the benefit of consistency, as, say, an increase in font height or a change in font family in 'org-agenda-structure' will propagate to the filter as well. The whole header line thus looks part of a singular design. + The 'org-agenda-structure
Re: [PATCH] Fixed-pitch tables and code blocks that do not break variable-pitch-mode
On 2021-04-27, 21:28 +0200, Bastien wrote: >> Please see the attached diff. An explanation is offered below. I have >> already assigned copyright to the FSF. > > Sorry it took so long to commit this, it is done in commit 667cb6f1a > in master, adding fixed-pitch for org-hide, org-verbatim and org-code > too. > > Thanks! Thank you Bastien for this and for every other contribution! -- Protesilaos Stavrou https://protesilaos.com
[PATCH] Review face for export dispatcher highlighted keys
The export dispatcher's active keys are highlighted using the 'org-warning' face. That face is applied in various contexts, including the agenda. Users who have difficulty reading the active keys of the export dispatcher are therefore forced to modify 'org-warning' throughout their setup, even though their problem is present only while viewing the dispatch UI (because highlighted keys are one or a few characters long). The attached patch is an attempt to address this issue by creating a new face that is specifically designed for the dispatch UI. For the background+foreground combinations, the selected values conform with the highest accessibility standard for colour contrast (WCAG AAA, else a minimum contrast ratio of 7:1). I limited my options to what 'M-x list-colors-display' provides. Best regards, Protesilaos -- Protesilaos Stavrou protesilaos.com >From 317eecf00b8c7d7112706b2438796f2aa4c48ecd Mon Sep 17 00:00:00 2001 From: Protesilaos Stavrou Date: Mon, 12 Oct 2020 12:41:31 +0300 Subject: [PATCH] Review face for export dispatcher highlighted keys * lisp/org-faces.el (org-dispatcher-highlight): Define new face. * lisp/ox.el (org-export--dispatch-ui): Apply org-dispatcher-highlight face. The intent is to decouple the dispatcher's interface from the generic org-warning face. The dispatcher's active keys are thus made easier to tell apart, without interfering with other applications of org-warning. --- lisp/org-faces.el | 14 ++ lisp/ox.el| 2 +- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/lisp/org-faces.el b/lisp/org-faces.el index c0556b8bb..94b283ad6 100644 --- a/lisp/org-faces.el +++ b/lisp/org-faces.el @@ -45,6 +45,20 @@ The foreground color of this face should be equal to the background color of the frame." :group 'org-faces) +(defface org-dispatcher-highlight + '((default :weight bold) +(((class color) (min-colors 88) (background dark)) + :background "gray20" :foreground "gold1") +(((class color) (min-colors 88) (background light)) + :background "SlateGray1" :foreground "DarkBlue") +(((class color) (min-colors 16) (background dark)) + :foreground "yellow") +(((class color) (min-colors 16) (background light)) + :foreground "blue") +(t :inverse-video t)) + "Face for highlighted keys in the dispatcher." + :group 'org-faces) + (defface org-level-1 '((t :inherit outline-1)) "Face used for level 1 headlines." :group 'org-faces) diff --git a/lisp/ox.el b/lisp/ox.el index 6dd2cd4a0..5ffd66816 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -6706,7 +6706,7 @@ back to standard interface." ;; on the first key, if any. A nil value means KEY will ;; only be activated at first level. (if (or (eq access-key t) (eq access-key first-key)) - (propertize key 'face 'org-warning) + (propertize key 'face 'org-dispatcher-highlight) key))) (fontify-value (lambda (value) -- 2.28.0
Re: Bug: org-priority face has extra space at the end starting from version 9.4 [9.4 (9.4-elpaplus @ /home/rrudakov/.emacs.d/elpa/org-plus-contrib-20200914/)]
On 2020-10-11, 02:40 -0400, Kyle Meyer wrote: > I'm wary of changing the regexp. Although the docstring does suggest > the space shouldn't be a part of the first group, the group has included > the space since org-priority-regex was introduced way back in 2008. And > making the suggested change results in a failing test > (test-org/entry-put). So at this point, I'd lean towards adjusting the > docstring. > > I've applied a different fix for the regression (b1de0c8e4). Thank you Kyle! I can confirm that the issue is no longer present on my end. -- Protesilaos Stavrou protesilaos.com
Re: [PATCH] Adaptive Org faces in headings?
On 2020-10-07, 00:20 -0400, Kyle Meyer wrote:
> Protesilaos Stavrou writes:
>
>> Sorry to re-open this issue. The following change extends Ihor's patch
>> to also cover checkbox statistics. Seems to work just fine on my end.
>> Thanks again!
>
> Thanks for the patch. Looks good on my end too.
>
> Would you mind adding a commit message and sending the git-format-patch
> output (details at <https://orgmode.org/worg/org-contribute.html>)?
Tried to format the patch. Please see the attached file. If it does
not work, feel free to dismiss it and just apply the change yourself.
--
Protesilaos Stavrou
protesilaos.com
>From 6fc8c6f2c5c81402e2d4a5416b68d8d595f7aaee Mon Sep 17 00:00:00 2001
From: Protesilaos Stavrou
Date: Wed, 7 Oct 2020 08:04:24 +0300
Subject: [PATCH] Make headline faces precede checkbox statistics
* lisp/org.el (org-set-font-lock-defaults): Apply `prepend' to
checkbox statistics. Affects `org-checkbox-statistics-done' and
`org-checkbox-statistics-todo'.
This builds on commit 979e82fc3: org-level-N faces are no longer
overridden by elements placed on top of them.
---
lisp/org.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 425e9391b..23c86ba0c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5684,7 +5684,7 @@ needs to be inserted at a specific position in the font-lock sequence.")
1 'org-checkbox prepend)
(when (cdr (assq 'checkbox org-list-automatic-rules))
'("\\[\\([0-9]*%\\)\\]\\|\\[\\([0-9]*\\)/\\([0-9]*\\)\\]"
- (0 (org-get-checkbox-statistics-face) t)))
+ (0 (org-get-checkbox-statistics-face) prepend)))
;; Description list items
'("^[ \t]*[-+*][ \t]+\\(.*?[ \t]+::\\)\\([ \t]+\\|$\\)"
1 'org-list-dt prepend)
--
2.28.0
Re: [PATCH] Adaptive Org faces in headings?
On 2020-09-26, 08:31 +0200, Bastien wrote:
> Bastien writes:
>
>> Ihor Radchenko writes:
>>
>>> The attached patch seems to fix the issue.
>>
>> Applied as 979e82fc3, thanks a lot!
>
> Also, marking the initial bug report as closed, thanks again.
Sorry to re-open this issue. The following change extends Ihor's patch
to also cover checkbox statistics. Seems to work just fine on my end.
Thanks again!
#+begin_src diff
lisp/org.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 425e9391b..23c86ba0c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5684,7 +5684,7 @@ needs to be inserted at a specific position in the
font-lock sequence.")
1 'org-checkbox prepend)
(when (cdr (assq 'checkbox org-list-automatic-rules))
'("\\[\\([0-9]*%\\)\\]\\|\\[\\([0-9]*\\)/\\([0-9]*\\)\\]"
- (0 (org-get-checkbox-statistics-face) t)))
+ (0 (org-get-checkbox-statistics-face) prepend)))
;; Description list items
'("^[ \t]*[-+*][ \t]+\\(.*?[ \t]+::\\)\\([ \t]+\\|$\\)"
1 'org-list-dt prepend)
#+end_src
--
Protesilaos Stavrou
protesilaos.com
Re: Bug: org-priority face has extra space at the end starting from version 9.4 [9.4 (9.4-elpaplus @ /home/rrudakov/.emacs.d/elpa/org-plus-contrib-20200914/)]
On 2020-09-29, 08:00 +, Roman Rudakov wrote: > "Protesilaos Stavrou" writes: > >> Roman Rudakov [2020-09-15, 18:50 +]: >> >>> I use theme which draw boxes around priority cookie. Before updating to >>> version 9.4 box was rendered just around square brackets, but since >>> version 9.4 it has additional space at the end. >>> >>> I think it's related to the fact that org-priority face definition used >>> to use separate regex which didn't include space, and now it uses >>> variable org-priority-regexp which does include additional space >>> character. >>> >>> [...] >> >> This issue is noticeable with any face properties for 'org-priority' >> such as box, background, underline, overline. >> >> Just to add a reproducible recipe for this case. >> >> On 'emacs -Q' running Org 9.4: >> >> + C-x C-f /tmp/test.org >> + Insert a heading, like: >> >> * TODO [#A] This is a test >> >> …see attached screenshot with "default" state. >> >> * Now evaluate the following expression: >> >> (set-face-attribute 'org-priority nil :underline t) >> >> …see attached screenshot with "edited" state. >> >> -- >> Protesilaos Stavrou >> protesilaos.com > > Hello, > > I think proper value for `org-priority-regex` should be > ".*?\\(\\[#\\([A-Z0-9]+\\)\\]\\) ?", extra space should be moved out of > the brackets, It won't break anything and face definition will be > correct. > > Best regards. This is to confirm that I and Ilja (in Cc) get the desired behaviour by evaluating the suggested regexp. Steps to quickly reproduce this on 'emacs -Q': + C-x C-f /tmp/test.org + Insert a heading with a priority cookie: - * TODO [#A] This is a test + Evaluate: (set-face-attribute 'org-priority nil :background "#ddd") - The background is just to visualise the extra blank to the right of the cookie's closing bracket. Same principle for underlines, overlines, boxes. + Eval: (setq org-priority-regexp ".*?\\(\\[#\\([A-Z0-9]+\\)\\]\\) ?") + M-x org-mode-restart + The extra space which was coloured before should no longer be affected by the face properties. The background we added must only cover the priority cookie's text. Best regards, Protesilaos -- Protesilaos Stavrou protesilaos.com
Re: [PATCH] Adaptive Org faces in headings?
Bastien [2020-09-23, 14:25 +0200]: > Ihor Radchenko writes: > >> The attached patch seems to fix the issue. > > Applied as 979e82fc3, thanks a lot! Good news! Thanks to everyone for their contributions! -- Protesilaos Stavrou protesilaos.com
Re: [PATCH] Adaptive Org faces in headings?
Ihor Radchenko [2020-09-17, 16:25 +0800]: > The attached patch seems to fix the issue. > Can anyone test? I just tried this using the standard faces of 'emacs -Q' as well as custom themes. In short, the patch fixes the issue on my side. I tested whether faces on the headline would correctly inherit any of the following properties: + :height + :weight + :background + :overline I also tested it with 'variable-pitch' headlines and, again, every construct that does not have a font family explicitly assigned to it will adapt to the underlying heading. Excellent! This is the kind of headline I tried: * TODO [#A] This is a test ~scaling-elements~ =faces-adapt= :good-stuff: Also added links to confirm my findings. Again, all good. -- Protesilaos Stavrou protesilaos.com
Re: Bug: org-priority face has extra space at the end starting from version 9.4 [9.4 (9.4-elpaplus @ /home/rrudakov/.emacs.d/elpa/org-plus-contrib-20200914/)]
Roman Rudakov [2020-09-15, 18:50 +]: > I use theme which draw boxes around priority cookie. Before updating to > version 9.4 box was rendered just around square brackets, but since > version 9.4 it has additional space at the end. > > I think it's related to the fact that org-priority face definition used > to use separate regex which didn't include space, and now it uses > variable org-priority-regexp which does include additional space > character. > > [...] This issue is noticeable with any face properties for 'org-priority' such as box, background, underline, overline. Just to add a reproducible recipe for this case. On 'emacs -Q' running Org 9.4: + C-x C-f /tmp/test.org + Insert a heading, like: * TODO [#A] This is a test …see attached screenshot with "default" state. * Now evaluate the following expression: (set-face-attribute 'org-priority nil :underline t) …see attached screenshot with "edited" state. -- Protesilaos Stavrou protesilaos.com
Re: Adaptive Org faces in headings?
Bastien [2020-09-09, 10:49 +0200]: > Protesilaos Stavrou writes: > >> Diego Zamboni [2020-09-05, 23:39 +0200]: >> >>> I had seen the same in my setup. I recently started using Doom Emacs >>> (https://github.com/hlissner/doom-emacs/) and was pleasantly surprised >>> to discover that todo and tag faces scale according to the headline in >>> which they are. I don't know precisely how this is done, but there are >>> some hints here, you might use it as a starting point: >>> https://github.com/hlissner/doom-emacs/blob/develop/modules/lang/org/config.el#L146-L175 >> >> I noticed that the doom-themes have some extra code to fontify Org.[0] >> It also has some opinionated extras that do not belong to the issue I >> raised. I am curious whether this was ever shared/discussed on this >> mailing list. > > I can't remember any such discussion. > > (In general, it would be good if downstream enhancements like these > could be shared upstream, we are generally quite grateful for help!) > > In any case, thanks for reporting this issue, I confirm we should > work on it for a future release. > > Patches welcome, Hello again! I am not sure I can help with the patch, but at least I can share some more user feedback. Please see the attached screenshots that could help improve our understanding of the issue. The gist is that Org already has working code that adapts some faces to the underlying heading style (in this case font height and weight). To reproduce this demo on emacs -Q: + Open an org-mode file, e.g. C-x C-f /tmp/test.org + Insert a level 1 heading: * TODO [#A] Do they adapt ~test-heading-faces~ and =another-test=? + Evaluate each of the expressions in the code block and notice how the heading's faces adapt to it: #+begin_src emacs-lisp (set-face-attribute 'org-level-1 nil :height 3.0 :weight 'normal) (set-face-attribute 'org-level-1 nil :weight 'bold) #+end_src This is in addition to what I noted in a previous message: https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00331.html Best regards, Protesilaos -- Protesilaos Stavrou protesilaos.com
variable-pitch-mode misaligns org-mode heading tags
1. Run 'emacs -Q' 2. Open a new Org file 'C-x C-f /tmp/test.org' 3. Insert the following contents: * TODO this is a test :tag: * TODO here is another test :tag: The tags should align to the right with the standard monospaced font. 4. Run 'M-x variable-pitch-mode'. 5. The tags are now misaligned. Please see attached screenshots for the before and after states of the 'variable-pitch-mode' activation. Running 'M-x describe-char' in the space between the heading's title and the tag informs us that the space's face is the same as the heading's (e.g. 'org-level-1'). I am also relaying the technical insight of Adam Spiers. Please see attached plain text document or visit the comment's URL: https://gitlab.com/protesilaos/modus-themes/-/issues/85#note_407147422 Overview of my setup: + GNU Emacs 27.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3) of 2020-08-14 + Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/) * * * This message was also posted on debbugs.gnu.org, bug#43272. -- Protesilaos Stavrou protesilaos.com I've investigated this and it's not nearly as easy as I had hoped. It turns out that the right alignment supported by display properties can only align space, not text. Something like this works as an experiment: ```lisp (with-current-buffer "org/TODO.org" (put-text-property (region-beginning) (region-end) 'display '(space :align-to (- right 10 ``` If a region of space characters is selected, the above will adjust the region's width so that its right hand side is 10 character widths in from the right margin. However if the region contains text, it will make that text invisible. This could be used to *left*-align the tags, but not *right*-align them, which doesn't really work because each heading's tags can be a different number of characters wide. So to get our desired behaviour of adjusting the space in between the heading and the tags correctly in order to right-align the tags to [the right margin specified by `org-tags-column`](https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00728.html), we'd first have to calculate the display width of the (proportionally spaced) tags text, and then subtract that from the right margin. In theory this width can be retrieved via `pos-visible-in-window-p` with the `PARTIALLY` argument set to `t`, but I haven't got that working yet, and even if I could, it would need to be done dynamically for each line and then the corresponding text property updated whenever that width changed (e.g. any of that line was edited, or when the window was scrolled to bring different headings into view). However that raises questions about how well this would perform, since it would be creating quite a lot of work to do on each redisplay. I suspect that the emacs gurus would say that support for right-alignment of variable pitch text would need to be added to emacs's internal display routines (the ones written in C, not Elisp). But that's only a vague guess. Hopefully I've underestimated what emacs can currently do here and there's an easier solution, but there's little chance of finding out either way without asking on the Org list, and then falling back to the `help-gnu-emacs` or `emacs-devel` list if it's even too difficult a question for any of the Org gurus.
Re: Adaptive Org faces in headings?
Hello Diego, Diego Zamboni [2020-09-05, 23:39 +0200]: > I had seen the same in my setup. I recently started using Doom Emacs > (https://github.com/hlissner/doom-emacs/) and was pleasantly surprised > to discover that todo and tag faces scale according to the headline in > which they are. I don't know precisely how this is done, but there are > some hints here, you might use it as a starting point: > https://github.com/hlissner/doom-emacs/blob/develop/modules/lang/org/config.el#L146-L175 I noticed that the doom-themes have some extra code to fontify Org.[0] It also has some opinionated extras that do not belong to the issue I raised. I am curious whether this was ever shared/discussed on this mailing list. It does not seem specific to Doom, so it be nice to have it for the benefit of every user mutatis mutandis. [0]: https://github.com/hlissner/emacs-doom-themes/blob/master/doom-themes-ext-org.el -- Protesilaos Stavrou protesilaos.com
Re: Adaptive Org faces in headings?
Hello Bastien! Bastien [2020-09-05, 16:47 +0200]: > Could you insert a small picture showing where faces customization > don't interact nicely, e.g. when using different heights for org-todo > org-level-1? Please see attached. This is on 'emacs -Q'. What I did: - C-x C-f test.org - C-x 2 - C-x b *scratch* - Insert and then evaluate each of: + (set-face-attribute 'org-level-1 nil :height 2.0) + (set-face-attribute 'org-level-2 nil :background "#e0e0e0" :height 1.5) - C-x o - Insert some headings: + * TODO [#A] This is a test :tag: + ** TODO [#A] This is a test :tag: + * [[https://www.gnu.org/][links also]] This is a test :tag: > It would help deciding whether this is an issue for Org or for > Emacs in general regarding faces interaction. The feedback I have received thus far suggests that it may have to do with how Org configures its font locking in org-set-font-lock-defaults. In particular: 1. The org-tag has an OVERRIDE argument in the form of 'prepend' https://code.orgmode.org/bzg/org-mode/src/5417e384ebab58e560fe6a80eee7bc58b1ef8645/lisp/org.el#L5625 So it is merged with the underlying face, as shown in the screenshot. 2. While keywords have a 't' argument which overrules the underlying face (it would behave the same as tags with 'prepend'): https://code.orgmode.org/bzg/org-mode/src/5417e384ebab58e560fe6a80eee7bc58b1ef8645/lisp/org.el#L5647 Not sure about priority cookies and links. This is what I have for now. Thank you for looking into this! My system details: - GNU Emacs 27.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3) of 2020-08-14 - Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/) Best regards Protesilaos -- Protesilaos Stavrou protesilaos.com
Adaptive Org faces in headings?
Dear all, I have noticed that Org faces that combine with headings do not adapt to their context. This applies to keywords, priority cookies, links, and possibly other elements as well. For example, a "todo" keyword (`org-todo' face) will not scale in size to match that of the heading level (`org-level-N' face) if the latter uses a `:height' property. Same principle for keywords not inheriting the heading's background, overline, etc. My expectation is to allow `org-level-N' to pass its attributes to any element on the same line, unless that element has conflicting face attributes of its own. So, in my example, the heading could pass its height to the "todo" keyword when the `org-todo' face does not define a `:height' of its own. Otherwise it would refrain from overriding that attribute. Does the community know of a solution to this issue? I am running: * Org mode version 9.3. * GNU Emacs 27.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.17, cairo version 1.17.3) of 2020-04-20. Best regards, Protesilaos -- Protesilaos Stavrou protesilaos.com
