Re: Org ELPA: does not include 9.5 as expected, archives appear largely identical?
Ihor Radchenko writes: > FYI, Org ELPA is no longer used to distribute newer versions of Org. See Hmm. I missed that we promised Org 9.5 to be distributed via old channels. I confirm that Org 9.5 is missing from Org ELPA. Bastien, should we package Org 9.5 to Org ELPA? Best, Ihor
Re: [PATCH] Accept more :tangle-mode specification forms
> Timothy writes: > I would just accept two formats, both being strings with either "o400" > (or perhaps "#o400") and "u+rwx" symbolic form and anything else > generates an error (a hard error, not a warning i.e. stop processing, > don't tangle). +1. (i'm neutral w.r.t. "o400" vs. "#o400".) cheers, Greg
Re: Org ELPA: does not include 9.5 as expected, archives appear largely identical?
Damian writes: > https://www.orgmode.org/Changes.html indicates that the Org ELPA should > include 9.5, but currently that does not appear to be the case: > https://orgmode.org/elpa/ only has 9.4.6. Could 9.5 be included to match > the documentation? Or is there something I am missing? FYI, Org ELPA is no longer used to distribute newer versions of Org. See https://list.orgmode.org/87blb3epey@gnu.org/ or https://orgmode.org/Changes.html Please use GNU ELPA to update Org from now on (https://elpa.gnu.org/packages/org.html). Best, Ihor
Org ELPA: does not include 9.5 as expected, archives appear largely identical?
https://www.orgmode.org/Changes.html indicates that the Org ELPA should include 9.5, but currently that does not appear to be the case: https://orgmode.org/elpa/ only has 9.4.6. Could 9.5 be included to match the documentation? Or is there something I am missing? https://orgmode.org/elpa/ has archives from '20210726' to '20210920', but all of the files report the exact same size of 6461440. I examined 'org-20210726.tar' and 'org-20210920.tar', and their org.el files both indicate version '9.4.6', and most files are identical with the exception of 'org-keys.el', 'org-pkg.el', 'org-version.el', and 'orgcard.pdf' (only 'org-keys.el' has any functional changes). This seems suspicious, but I'm not familiar with org releases. Thanks, -Damian
Re: [PATCH] Accept more :tangle-mode specification forms
On Sat, Nov 20, 2021 at 03:31:16AM +1100, Tim Cross wrote: > > Timothy writes: > > > Hi All, > > > > I thought I’d checked for this, but I’ve just noticed that :tangle-mode 755 [...] > Thanks for your work on this. I am a little concerned we are making a > rod for our back by trying to make this overly clever in order to > provide as much convenience to the user as possible [...] That's my feeling too. At the beginning I was a fan of the octal variant (tradition), but I fear the interface, in its really good intent to "do- what-i-mean" becomes unpredictable. Because different people do mean different things. An unpredictable interface having security implications tends to be... interesting :) Cheers - t signature.asc Description: PGP signature
Re: [PATCH] c-csl : accept relative CSL filenames
Am Freitag, dem 19. November 2021 schrieb Nicolas Goaziou: > I think a better order for a relative file name would be: > > 1. relatively to `org-cite-csl-styles-dir', > 2. relatively to buffer's default directory, > 3. failure. > > WDYT? I would be fine with it. -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite Passau, Deutschland | kont...@guelker.eu| O<
Re: [PATCH] Accept more :tangle-mode specification forms
Timothy writes: > Hi All, > > I thought I’d checked for this, but I’ve just noticed that :tangle-mode 755 > doesn’t actually work as expected. I assumed 755 would be passed as a string > but > org-babel-parse-header-arguments actually turns it into an integer, just like > (identity #o755). Obviously 755 != #o755 and so this causes issues. > > As it stands “755” works, but that isn’t great (most importantly, it’s easy to > confuse). Since it’s easier to add than remove things like this, we could just > get rid of this for now, but a convenient octal notation was a large chunk of > the motivation here IIRC. > > We could also change the implementation to handle :tangle-mode o755, which > will > make org-babel-parse-header-arguments parse the argument as a string. > > I’m be keen to hear other people’s thoughts on this. > Thanks for your work on this. I am a little concerned we are making a rod for our back by trying to make this overly clever in order to provide as much convenience to the user as possible. As this setting does have significant security implications, I would favour a simple and easily testable option which is concise and unambiguous over convenience. I would drop the 'rwxrw-r--' format as it isn't typical, not allow base10 mode specifications and possibly even limit what can be set (i.e. no sticky bit etc, just read, write and execute). Security issues are more often than not, caused by complexity. Things become complex when we try to satisfy too many options. In this case, rather than being liberal in what we accept and precise in what we send/do, I think we need to be precise in what we accept and do. I would just accept two formats, both being strings with either "o400" (or perhaps "#o400") and "u+rwx" symbolic form and anything else generates an error (a hard error, not a warning i.e. stop processing, don't tangle). Making the octal version be "#o600" rather than just "o600" would possibly make interpretation easier as it would avoid "o600" and "o+r" - if it starts with "#o" interpret as octal, otherwise try to parse as symbolic names. this would mean there will be some edge cases where you cannot set the mode precisely to the value you want. However, these will be fringe cases and requiring the user to take additional/special steps in this case is IMO not too much to ask in exchange for reliability and correctness for the majority and avoiding dangerous corner cases.
Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
On 18/11/2021 05:44, Samuel Wales wrote: i think i found it useful, long ago, when it was ok/tolerated to change the var, and probably still, to /"do this"/ and /this,/. D. Knuth in "The TeXbook" put punctuation outside of emphasized text, however he mentioned that accordingly to old manuals semicolon should be typed in the same font as previous word. On 18/11/2021 19:25, Ihor Radchenko wrote: I updated the patch dropping your last suggested sentence in the docstring. I find it not very helpful for the user. We should either say nothing (as in the patch) or give a concrete reference how to "achieve the desired effect". I just have never tried to add custom decorations, so it is difficult for me to express it by a concise phrase. I even do not know if the following recipe could be recommended https://emacs.stackexchange.com/questions/35626/how-to-make-my-own-org-mode-text-emphasis-work-again From other messages I had an impression that it is still possible to create custom markup with new marker but actually it was broken years ago: https://list.orgmode.org/orgmode/can9dxh2xwf+9ggcprpxfetfumecrxuhtyjdudayg0z49fpa...@mail.gmail.com/T/#u Bug: org-emphasis-alist not fully applied [9.1.1 (9.1.1-1-g80cbf9-elpa @ x:/folder/user/.emacs.d/elpa/org-20170918/)] 2017-09-19 4:16 It makes details of implementation less important. To my taste fixed order of markers (:type list) is too rigid. If a user reordered a couple of items then multi-value customization form becomes single multiline input area. :set function might sort items, but I do not like such solution. Since I have not found a way to improve customization interface with reasonable efforts, I believe that the patch is acceptable. It should be an improvement, but not an outstanding one.
Re: [DISCUSSION] Refactoring fontification system
Ihor Radchenko writes: > Dear all, > > Recently, there have been multiple issues related to incorrect > fontification: > - https://list.orgmode.org/orgmode/23707.20428.546749.44...@frac.u-strasbg.fr/ > - https://list.orgmode.org/orgmode/87fsujp7mc@web.de/ > - https://list.orgmode.org/orgmode/87czvqxdn9@gmail.com/ > - > https://list.orgmode.org/8735nsv9qo@nicolasgoaziou.fr/T/#me1c44b6e493dd280cca4f042b833c24749ae4fe0 > > These issues keep appearing because our current fontification code is > based on regexps and only approximates the actual Org grammar elements. > It is largely a legacy from the times when org-element parser was not a > thing. > > Maybe it is a time to upgrade the fontification according to our > state-of-art parser? > > Instead of fontifying elements individually via regexps, we can leverage > org-element-map, org-element-parse-buffer, org-element-cache, and > jit-lock-mode. Each type of Org element/object can be assigned with a > fontification function accepting a single argument - the element datum. > > Also, the fontification code can be move to a separate library. > > WDYT? > Sounds like a better approach to me. In addition to being more accurate, this would mean we don't need to keep 2 separate definitions in sync or have confusing font locking where the regexp and element definitions are different. Should gives us increased consistency and less maintenance.
Re: [BUG] org-mode binds C-c C-TAB, which seems illegal [9.5 (9.5-g0a86ad @ /home/il/.config/emacs/elpa/org-9.5/)]
Ingo Lohmar [2021-11-17 Wed 21:19] wrote: > Can people actually enter "C-c C-TAB" into their emacs (how?), or has > everybody has just bound another key in their config? I've noticed it a couple of weeks ago; just rebound org-force-cycle-archived to (kbd "C-c C-") -- Daniel Fleischer
Re: Bug: org-fill-paragraph [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
Edrie Ddrie writes: > When using `org-fill-paragraph' on a part of a paragraph, e.g. with halve > the lines as active region, it still uses the unselected text around when > filling. > This works different than `fill-paragraph', `fill-region' and > `fill-region-as-paragraph' that fill only the selected part of a paragraph > WITHOUT effecting the text around. > I don't know if this is a real bug but it is confusing, and annoying > because org-mode overrides the default `C-q' key binding for > `fill-paragraph' so I have to invoke that command via M-x. Confirmed Best, Ihor
Re: [DISCUSSION] Refactoring fontification system
On Fri, Nov 19, 2021 at 9:11 AM Ihor Radchenko wrote: > WDYT? I don't understand all the technical details, but it sounds like a GREAT idea to me in general! Bruce
[DISCUSSION] Refactoring fontification system
Dear all, Recently, there have been multiple issues related to incorrect fontification: - https://list.orgmode.org/orgmode/23707.20428.546749.44...@frac.u-strasbg.fr/ - https://list.orgmode.org/orgmode/87fsujp7mc@web.de/ - https://list.orgmode.org/orgmode/87czvqxdn9@gmail.com/ - https://list.orgmode.org/8735nsv9qo@nicolasgoaziou.fr/T/#me1c44b6e493dd280cca4f042b833c24749ae4fe0 These issues keep appearing because our current fontification code is based on regexps and only approximates the actual Org grammar elements. It is largely a legacy from the times when org-element parser was not a thing. Maybe it is a time to upgrade the fontification according to our state-of-art parser? Instead of fontifying elements individually via regexps, we can leverage org-element-map, org-element-parse-buffer, org-element-cache, and jit-lock-mode. Each type of Org element/object can be assigned with a fontification function accepting a single argument - the element datum. Also, the fontification code can be move to a separate library. WDYT? Best, Ihor
Re: [PATCH] Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Nicolas Goaziou writes: >> +Sometimes, Org mode has difficulties recognising markup. It usually >> +happens when markup marker symbols are present inside verbatim or code >> +blocks: > > I disagree with the wording. Org mode has no difficulties recognizing > markup nor does it parses text incorrectly. This is similar to the well > known surprise: > > #+begin_example > * something > #+end_example > > Here, we are simply fooled by the fontification process. > > Otherwise, the patch looks good to me. I updated the patch. If you have no objections on the new wording, I will push it to main. >> + ;; Verify that we are at the right object. >> + (let ((object (save-excursion >> + (save-match-data >> + (goto-char (match-beginning 2)) >> + (org-element-context) >> + (and (memq (org-element-type object) >> +'(bold italic verbatim code strike-through)) >> + (eq (match-beginning 2) >> + (org-element-property :begin object)) > > I sympathize with the idea. As long as fontification does not rely on > the parser, we will face issues like the one at stake. So, ultimately, > Org will hopefully move in that direction. > > However, I'm not convinced making such local changes is going to help us > in the long run. It may be more fruitful to think this evolution > globally, as it involves a fair bit of rewriting of the fontification > process. For example, it may only be necessary to parse the part of the > Org document being fontified only once, and then apply all fontification > functions to the resulting tree rather than have each of them calling > the parser, like the above. > > In any case, I think fontification deserves a dedicated thread, in > addition to some love. Ok. I will create a new discussion thread on fontification. Best, Ihor >From a1a497a80578669ef1e96700aa592aadd8d0d7ec Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Fri, 19 Nov 2021 19:27:56 +0800 Subject: [PATCH] org-manual.org: Clarify how to handle markup ambiguity * doc/org-manual.org (Emphasis and Monospace): Advice users to insert zero width space when Org does not parse emphasized text correctly. --- doc/org-manual.org | 11 +++ 1 file changed, 11 insertions(+) diff --git a/doc/org-manual.org b/doc/org-manual.org index a38dbec4a..9615209a1 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -10818,6 +10818,17 @@ ** Emphasis and Monospace ~org-fontify-emphasized-text~ to ~nil~. To narrow down the list of available markup syntax, you can customize ~org-emphasis-alist~. +=*=, =/=, =_=, ===, and =~= symbols inside =verbatim= or ~code~ can +sometimes produce unexpected markup. For example, + +#+begin_example +/The whole line is supposed to be marked italic, but the following +~user/?variable~ contains italics =/= marker and confuses Org parser/. +#+end_example + +You can use zero width space to help Org sorting out the ambiguity. +See [[*Escape Character]] for more details. + ** Subscripts and Superscripts :PROPERTIES: :DESCRIPTION: Simple syntax for raising/lowering text. -- 2.32.0
[BUG] Re: when ellipsis are "removed", org-cycle doesn't work "correctly" on list
tony aldon writes: > This is my first communication on this mailing list and I hope I'll do > it well. Thanks for reporting and welcome to the mailing list! > 1) The "bug" (I'm not sure if it is a bug): > > When you modify the `buffer-invisibility-spec` replacing > `'(outline . t)` by `'outline` (in order to remove the `...` when > headlines, list, etc are collapsed) by evaluating the following form: > > (remove-from-invisibility-spec '(outline . t)) > (add-to-invisibility-spec 'outline) > > `org-cycle` stopped working "correctly" on lists. Confirmed Steps to reproduce: 1. emacs -Q 2. M-x org-mode 3. Insert - something - a - b - c - something else 4. M-: (remove-from-invisibility-spec '(outline . t)) 5. M-: (add-to-invisibility-spec '(outline)) 6. Move point to "something" 7. the item is folded but not unfolded The bug is triggered by incorrect result of org-list-struct. In org-list-struct with the above invisibility settings, current-indentation incorrectly returns 0 on "a", "b", and "c" items. I suspect Emacs bug. Best, Ihor
Re: [PATCH] c-csl : accept relative CSL filenames
Hello, Emmanuel Charpentier writes: > If a finename is not absolute, search : > 1. relatively to the buffer's default directory > 2. if 1. unsuccessfull, relatively to`org-cite-csl-styles-dir' > 3. if 2. unsuccessfull, relatively to emacs' default directory > (BTW : what is this ? How to retrieve it ?) There's no such thing. > 4. if 3. unsuccessfull, fail. I think `org-cite-csl-styles-dir' trumps buffer default directory as much as explicit trumps implicit. If you need to override the variable, you can still use an absolute file name. I think a better order for a relative file name would be: 1. relatively to `org-cite-csl-styles-dir', 2. relatively to buffer's default directory, 3. failure. WDYT? Regards, -- Nicolas Goaziou
surprising(?) interaction between agenda grid and default-duration
Hi all! I you specify a default duration of an event, say, (setq org-agenda-default-appointment-duration 60) and specify a time grid, say (setq org-agenda-time-grid '((today remove-match) (800 1000 1200 1400 1600 1800 2000) ".." "" )) Then setting the default duration overrides the grid appearance. I.E. (setq org-agenda-default-appointment-duration nil) (setq org-agenda-time-grid '((today remove-match) (800 1000 1200 1400 1600 1800 2000) ".." "" )) Friday 19 November 2021 8:00.. EDV: 9:30-10:00 Scheduled: TODO Stuff Job:10:00-12:30 Scheduled: PROJECT Book 12:00.. unsorted: 13:00-15:00 Scheduled: TODO other stuff 13:39.. now - - - - - - - - - - - - - - - - - - - - - - - - - 14:00.. 16:00.. 18:00.. 20:00.. as expected, but (setq org-agenda-default-appointment-duration 60) (setq org-agenda-time-grid '((today remove-match) (800 1000 1200 1400 1600 1800 2000) ".." "" )) Friday 19 November 2021 8:00-9:00 EDV: 9:30-10:00 Scheduled: TODO Stuff Job:10:00-12:30 Scheduled: PROJECT Book 12:00-13:00 unsorted: 13:00-15:00 Scheduled: TODO other stuff 13:40-14:40 now - - - - - - - - - - - - - - - - - - - - - - - - - 14:00-15:00 16:00-17:00 18:00-19:00 20:00-21:00 caught me by surprise. Even the 2 hour block length setting is overridden. If this should be considered a bug, I don't know. But maybe the manual should mention and describe the relationship between these settings? As the description of org-agenda-default-appointment-duration does not mention the grid at all, I would think the logical improvement would be to let the grid alone and use the default duration as advertised only. org-version 9.4.4 emacs-version 27.2 All the best Detlef
Re: Merging ox-texinfo+ into ox-texinfo
Hello, Jonas Bernoulli writes: > I recently talked to Bastien about this and he encouraged to bring up > the possibility of merging ox-texinfo+.el into ox-texinfo.el. > > ox-texinfo+ (https://github.com/tarsius/ox-texinfo-plus) has several > features but the one I would like to talk about now is the following. [...] > >Create `@deffn` and similar definition items by writing list >items in Org that look similar to what they will look like in >Info. To enable this, add: > >#+TEXINFO_DEFFN: t > >to your Org file. After doing that, you can create definition >items like so: > >- Command: magit-section-show > > Show the body of the current section. > >- Function: magit-git-exit-code args >- Macro: magit-insert-section args >- Variable: magit-display-buffer-noselect >- User Option: magit-display-buffer-function >- Key: q, magit-mode-bury-buffer > > I propose that we add this as an optional feature to ox-texinfo.el > itself. I like the idea, thank you for suggesting it. The chosen UI is rather odd however. I cannot think of another use of controlling export thhough "#+keyword: boolean" syntax. Usually, we extend the "options" keyword. It could become, for example: #+options: texinfo+:t Could it be possible to use that syntax instead? > It is possible to mix the two styles; you can use the ox-texinfo+.el > style for most or all definitions but use the additional flexibility of > ox-texinfo.el, when that is needed. How is it possible? Keywords are global. How do you change value locally? Regards, -- Nicolas Goaziou
Re: [PATCH] Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Hello, Ihor Radchenko writes: > * doc/org-manual.org (Emphasis and Monospace): Advice users to insert > zero width space when Org does not parse emphasized text correctly. > --- [...] > +Sometimes, Org mode has difficulties recognising markup. It usually > +happens when markup marker symbols are present inside verbatim or code > +blocks: I disagree with the wording. Org mode has no difficulties recognizing markup nor does it parses text incorrectly. This is similar to the well known surprise: #+begin_example * something #+end_example Here, we are simply fooled by the fontification process. Otherwise, the patch looks good to me. > + ;; Verify that we are at the right object. > + (let ((object (save-excursion > + (save-match-data > + (goto-char (match-beginning 2)) > + (org-element-context) > + (and (memq (org-element-type object) > +'(bold italic verbatim code strike-through)) > + (eq (match-beginning 2) > + (org-element-property :begin object)) I sympathize with the idea. As long as fontification does not rely on the parser, we will face issues like the one at stake. So, ultimately, Org will hopefully move in that direction. However, I'm not convinced making such local changes is going to help us in the long run. It may be more fruitful to think this evolution globally, as it involves a fair bit of rewriting of the fontification process. For example, it may only be necessary to parse the part of the Org document being fontified only once, and then apply all fontification functions to the resulting tree rather than have each of them calling the parser, like the above. In any case, I think fontification deserves a dedicated thread, in addition to some love. Regards, -- Nicolas Goaziou
can macro get context, e.g. indentation of the line?
Hello, I have an org macro that expands to more than one line of text. This unfortunately breaks the fragile interpretation of lists if used at the wrong point. Is there an easy way to get the amount of indentation for the current line from within a macro (using (eval...) I guess)? Thank you, eric -- : Eric S Fraga, with org release_9.5-230-g2bbac4 in Emacs 29.0.50 : Latest paper written in org: https://arxiv.org/abs/2106.05096
[PATCH] Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Nicolas Goaziou writes: > You can use a zero-width space to help Org sorting out the ambiguity, > for example (| denotes the zero-width space): > > /|A link [[https://orgmode.org/?oops=true][Org Mode]] > > /A code ~user|/?my-user-variable~ with slash/ Makes sense. Maybe we should also mention it in the Markup section of the manual? I attached a tentative patch. Also, part of the problem with /|A link [[https://orgmode.org/?oops=true][Org Mode]] is that the link is emphasised despite not being parser as a link by org-element. I attached a patch for our link/emphasis fontification that makes sure that fontification is always consistent with the parser. The patch might hit the performance slightly, but I do not see obvious slowdown using my 15Mb notes file. Best, Ihor >From 3b4a857582e848e9688a49c01b853ed577dd4935 Mon Sep 17 00:00:00 2001 Message-Id: <3b4a857582e848e9688a49c01b853ed577dd4935.1637321577.git.yanta...@gmail.com> From: Ihor Radchenko Date: Fri, 19 Nov 2021 19:27:56 +0800 Subject: [PATCH] org-manual.org: Clarify how to handle markup ambiguity * doc/org-manual.org (Emphasis and Monospace): Advice users to insert zero width space when Org does not parse emphasized text correctly. --- doc/org-manual.org | 12 1 file changed, 12 insertions(+) diff --git a/doc/org-manual.org b/doc/org-manual.org index a38dbec4a..1db993d3d 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -10818,6 +10818,18 @@ ** Emphasis and Monospace ~org-fontify-emphasized-text~ to ~nil~. To narrow down the list of available markup syntax, you can customize ~org-emphasis-alist~. +Sometimes, Org mode has difficulties recognising markup. It usually +happens when markup marker symbols are present inside verbatim or code +blocks: + +#+begin_example +/The whole line is supposed to be marked italic, but the following +~user/?variable~ contains italics =/= marker and confuses Org parser/. +#+end_example + +You can use zero width space to help Org sorting out the ambiguity. +See [[*Escape Character]] for more details. + ** Subscripts and Superscripts :PROPERTIES: :DESCRIPTION: Simple syntax for raising/lowering text. -- 2.32.0 >From d5413e772fe6aedb8a8aa094f98c96fc20b82d3a Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Fri, 19 Nov 2021 19:13:54 +0800 Subject: [PATCH] org.el: Make emphasis and link fontification consistent with parser * lisp/org.el (org-do-emphasis-faces): (org-activate-links): Do not fontify just based on approximate regexps. Make sure the current object is emphasis. --- lisp/org.el | 62 - 1 file changed, 33 insertions(+), 29 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index cb1b58c51..d9f073100 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5106,12 +5106,15 @@ (defun org-do-emphasis-faces (limit) (looking-at-p org-outline-regexp-bol ;; Match full emphasis markup regexp. (looking-at (if verbatim? org-verbatim-re org-emph-re)) - ;; Do not span over paragraph boundaries. - (not (string-match-p org-element-paragraph-separate - (match-string 2))) - ;; Do not span over cells in table rows. - (not (and (save-match-data (org-match-line "[ \t]*|")) - (string-match-p "|" (match-string 4)) + ;; Verify that we are at the right object. + (let ((object (save-excursion + (save-match-data + (goto-char (match-beginning 2)) + (org-element-context) + (and (memq (org-element-type object) +'(bold italic verbatim code strike-through)) + (eq (match-beginning 2) + (org-element-property :begin object)) (pcase-let ((`(,_ ,face ,_) (assoc marker org-emphasis-alist)) (m (if org-hide-emphasis-markers 4 2))) (font-lock-prepend-text-property @@ -5206,7 +5209,7 @@ (defun org-activate-links (limit) (eq 'org-tag face)) (let* ((link-object (save-excursion (goto-char start) -(save-match-data (org-element-link-parser +(save-match-data (org-element-context (link (org-element-property :raw-link link-object)) (type (org-element-property :type link-object)) (path (org-element-property :path link-object)) @@ -5229,29 +5232,30 @@ (defun org-activate-links (limit) ((and (pred functionp) f) (funcall f)) (_ `(:uri ,link))) 'font-lock-multiline t))) - (org-remove-flyspell-overlays-in start end) - (org-rear-nonsticky-at end) - (if (not (eq 'bracket style)) - (progn +(when (eq (org-element-type link-object) 'link) + (org-remove-flyspell-overlays-in start end) + (org-rear-nonsticky-at end) + (if (not (eq 'bracket style)) + (progn +(add-face-text-property start end face-property) +
Re: [BUG] Bug: Footnotes break iCalendar export [9.4.6 (9.4.6-g069bcb @ /home/msi/.emacs.d/straight/build/org/)]
Hello, msi writes: > When I make the function "org-icalendar-combine-agenda-files", all it's > ok. But, when I add a footnote, I have this in my .ics file : > > BEGIN:VEVENT. > DTSTAMP:2026T101642Z. > UID:SC-6a6cf716-f056-4116-a419-5f0e96b14fd9. > DTSTART;VALUE=DATE:20220516. > DTEND;VALUE=DATE:20220517. > SUMMARY:S: Prehistoric Kingdom. > CATEGORIES:5References(liensTextes),TODO. > END:VEVENT > > > > Footnotes > ─ > > a footnote > > another > END:VCALENDAR > > I think that is the same bug of this thread : > https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg01478.html Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Hello, Ihor Radchenko writes: > However, it is not clear then how to handle situations like > > /A link [[https://orgmode.org/?oops=true][Org Mode]] > or > /A code ~user/?my-user-variable~ with slash/ > or > /A verbatim =text/.= with slash/ You can use a zero-width space to help Org sorting out the ambiguity, for example (| denotes the zero-width space): /|A link [[https://orgmode.org/?oops=true][Org Mode]] /A code ~user|/?my-user-variable~ with slash/ > Should we modify the closing-re for emphasis? > >>> (seq (not space) >>> (group ,mark) >>> (or (any space ?- ?. ?, ?\; ?: ?! ?? ?' ?\" ?\) ?\} ?\\ ?\[) >>> line-end)) I don't think it is necessary. /word/? seems a valid sentence closing. Regards, -- Nicolas Goaziou
