Re: change headings to list but have a nested numeration?
> Uwe Brauer writes: > AFAIK, using "-" is hard-coded in org-toggle-item. > Also, 1.1 is not a valid list bullet. > So, you need to implement alternative bullet support yourself. > Patches are welcome! I see, several observations. 1. For headings there is a third party package called ‘org-outline-numbering.el’. Which provides a mode that display headings in such a numbering scheme, however using overlays, as far as I can see. 2. Headings are much more robust since the use an unique syntax in form of *, on the other hand list depend heavily on indentation. So, again, third party packages such as org-transform-tree-table/toggle transform trees to table and back, however if a table contain a list that looses its indentation when transforming from a table to tree. That is not really a concern for org vanilla but a sign that lists are more delicate since the depend on indentation. Regards Uwe Brauer -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine. smime.p7s Description: S/MIME cryptographic signature
Re: @string abbreviation in bib file not honored in (basic) org-cite [and a minimal working example with natbib]
alain.coch...@unistra.fr writes on Sat 9 Jul 2022 08:10:
> the examples I found on this mailing list did not work for me).
I think I now understand why this was so: because latexmk was not
installed on my system. In this case the docstring of
org-latex-pdf-process says that
Its value is ("%latex -interaction nonstopmode -output-directory %o
%f" "%latex -interaction nonstopmode -output-directory %o %f"
"%latex -interaction nonstopmode -output-directory %o %f")
(which does not include bibtex, hence the problem I had) while, if
latexmk is installed,
Its value is ("latexmk -f -pdf -%latex -interaction=nonstopmode
-output-directory=%o %f")
In other words, in the minimal example I provided earlier in the
thread, if latexmk is installed I only need (require 'oc-natbib) in
the emacs init file, in agreement with what others have proposed.
But now I wonder if this excerpt of the docstring:
Consider a smart LaTeX compiler such as ‘texi2dvi’ or ‘latexmk’,
which calls the "correct" combinations of auxiliary programs.
is appropriate. How understand it when latexmk _is_ installed? But
even when latexmk is not installed, I don't find the sentence helpful.
In fact, I had read this part but, as I did not know what latexmk was,
I did not know what to do with it. Perhaps I would have understood if
it had been explicit that the value of org-latex-pdf-process depends
on the existence of latexmk. (And I still don't understand the
relevance of the reference to texi2dvi.)
--
EOST (École et Observatoire des Sciences de la Terre)
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44
F-67084 Strasbourg Cedex, France | [ slot available for rent ]
Re: [External] : Re: missing a character / font in agenda?
Ihor Radchenko writes: >>> I think this should be considered a bug, since the glyph used (LEFTWARDS >>> TRIANGLE-HEADED ARROW / #2b60) is not present in most fonts. If that is true (I don't know) then maybe we should just use a more ubiquitous glyph? > The commit is supposed to fall back to ASCII symbol if the Unicode > variant is not available, but apparently the check failed for some > reason: [...] > Stefan, do you have any idea what can go wrong here? > > The only thing I can think about is warning in the char-displayable-p > docstring: > > >> On a multi-font display, the test is only whether there is an > >> appropriate font from the selected frame's fontset to display > >> CHAR's charset in general. Since fonts may be specified on a > >> per-character basis, this may not be accurate. I don't think we specify a particular font here, do we? So it seems like there might be a bug in Emacs here? I'm not an expert on this stuff by any means, but I would probably 'M-x report-emacs-bug' to find out why 'char-displayable-p' would say that a character is displayable when it's not.
Re: [External] : Re: missing a character / font in agenda?
Daniel Ortmann writes: > Ihor, > What are your thoughts? > > On 7/12/22 15:03, Juan Manuel Macías wrote: >> Juan Manuel Macías writes: >> >>> The most reasonable thing would be to use a more >>> common symbol. But I'm still intrigued by the origin of that symbol... >> It seems that the culprit is in line 1592 of org-agenda.el >> >> I think this should be considered a bug, since the glyph used (LEFTWARDS >> TRIANGLE-HEADED ARROW / #2b60) is not present in most fonts. The offending commit is 998a0aacd from Stefan. The commit is supposed to fall back to ASCII symbol if the Unicode variant is not available, but apparently the check failed for some reason: (defcustom org-agenda-current-time-string (if (and (display-graphic-p) (char-displayable-p ?⭠) (char-displayable-p ?─)) "⭠ now ───" "now - - - - - - - - - - - - - - - - - - - - - - - - -") "The string for the current time marker in the agenda." :group 'org-agenda-time-grid :version "29.1" :type 'string) Stefan, do you have any idea what can go wrong here? The only thing I can think about is warning in the char-displayable-p docstring: >> On a multi-font display, the test is only whether there is an >> appropriate font from the selected frame's fontset to display >> CHAR's charset in general. Since fonts may be specified on a >> per-character basis, this may not be accurate. Best, Ihor
Re: org-capture-templates failing
Sharon Kimble writes: > Can someone enlighten me as to why it isn't working? And how can I get them > all working properly please? Your appear to have "mixed" Org installation when part of Org is loaded from built-in Org distribution and part is loaded from your downloaded newer version. Please make sure that you set load-path pointing to the correct version of Org early in your config. Best, Ihor
Re: [External] : Re: missing a character / font in agenda?
Ihor, What are your thoughts? On 7/12/22 15:03, Juan Manuel Macías wrote: Juan Manuel Macías writes: The most reasonable thing would be to use a more common symbol. But I'm still intrigued by the origin of that symbol... It seems that the culprit is in line 1592 of org-agenda.el I think this should be considered a bug, since the glyph used (LEFTWARDS TRIANGLE-HEADED ARROW / #2b60) is not present in most fonts. Best regards, Juan Manuel
[PATCH] ; * lisp/org-refile.el (org-refile-targets): Fix typo.
The attached patch fixes a small typo I found in the `org-refile-targets' docstring. From fe1c6f69ffcd3dfdb04c728f92e63e2fb1e4b4c0 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Wed, 13 Jul 2022 00:22:20 +0200 Subject: [PATCH] ; * lisp/org-refile.el (org-refile-targets): Fix typo. --- lisp/org-refile.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-refile.el b/lisp/org-refile.el index af1932687..01f0dfa46 100644 --- a/lisp/org-refile.el +++ b/lisp/org-refile.el @@ -95,7 +95,7 @@ You can set the variable `org-refile-target-verify-function' to a function to verify each headline found by the simple criteria above. When this variable is nil, all top-level headlines in the current buffer -are used, equivalent to the value `((nil . (:level . 1))'." +are used, equivalent to the value `((nil . (:level . 1)))'." :group 'org-refile :type '(repeat (cons -- 2.30.2
Re: Confused about source code blocks evaluation when exporting
Fraga, Eric writes on Tue 12 Jul 2022 14:08: > On Tuesday, 12 Jul 2022 at 14:53, alain.coch...@unistra.fr wrote: > > So far so good. (Well almost: why does '#+RESULTS:' show 'bar' and > > not 'foo'? After all, I'm just setting 'my-var', I'm not asking to > > display its value. But that's incidental.) > > It's not incidental. By default, the results of a src block evaluation > is the value of the src block which is typically the value returned by > the last statement. I guess I didn't use 'incidental' correctly. I meant it as "not my main concern". Anyway, thank you; I could check that if I switch the 2 lines I indeed get '#+RESULTS:' to show foo'. > You can modify this by adding > > :results output > > for instance to the begin_src line. > > > (test 2) Same org file. If I do 'C-c C-e l o', no question is asked, > > no '#+RESULTS:' block is inserted, and the resulting pdf file shows: > > On export, the default is to export the code. If you want the results, > you need to add > > :exports results > > or if you want both code and results, > > :exports both Greg Minshall writes on Tue 12 Jul 2022 17:22: > maybe look in the org manual for ":results" (with "value" or > "output" as options) and ":exports" (with "code" or "results" or > "both" as options). Thank you both, I made progress; but the behavior is still very so unintuitive to me. For example, I haven't found a way to have this block: #+begin_src emacs-lisp (message "foo") (message "bar") #+END_SRC and have the following inserted during export: #+RESULTS: : foo : bar (after all, that is was goes into the *Messages* buffer upon evaluation with 'C-c C-c'...) Finally I still tend to consider that the sentence "Org evaluates source code blocks in an Org file during export" is confusing. But maybe that's just I who interpret this as "code evaluation is the default behavior upon export". Regards -- EOST (École et Observatoire des Sciences de la Terre) ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr 5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France | [ slot available for rent ]
Re: [External] : Re: missing a character / font in agenda?
Juan Manuel Macías writes: > The most reasonable thing would be to use a more > common symbol. But I'm still intrigued by the origin of that symbol... It seems that the culprit is in line 1592 of org-agenda.el I think this should be considered a bug, since the glyph used (LEFTWARDS TRIANGLE-HEADED ARROW / #2b60) is not present in most fonts. Best regards, Juan Manuel
Re: [External] : Re: missing a character / font in agenda?
Hi, Daniel, Daniel Ortmann writes: > – Would using the ASCII '<' character be a better solution? I've done a quick test and a few very popular (and more or less complete) fonts don't include a glyph for the LEFTWARDS TRIANGLE-HEADED ARROW #2b60 character: DejavuSans, Iosevka, Hack Source Code Pro, JuliaMono or Fira Code. It is a very rare symbol. > – Is anyone else seeing this issue and missing font? I haven't seen it, but I'm not using the Git version. > – Is that Symbola font, or equivalent, now a true dependency? Or is > there something more common which I should be using? (Perhaps I > have missed a normal configuration step?) I think Symbola should not be a dependency. I use this font just to be able to display unusual symbols, especially on web pages when I browse the web with eww-mode. The most reasonable thing would be to use a more common symbol. But I'm still intrigued by the origin of that symbol... Best regards, Juan Manuel
Re: [External] : Re: missing a character / font in agenda?
That odd new character just showed up after a normal daily org-mode 'git pull'. The Symbola.ttf font worked fine. I used this page for for instructions. https://linuxconfig.org/how-to-install-and-manage-fonts-on-linux After copying the font to ~/.local/share/font/ and running the 'fc-cache -vf' command ... The font appears after emacs + org-mode are restarted. (I did not need to run set-fontset-font.) Somewhere in there I also pulled fresh org-mode and emacs code and rebuilt; am not sure if that was needed. Here is how that screen now appears: * Would using the ASCII '<' character be a better solution? * Is anyone else seeing this issue and missing font? * What would allow that Symbola font to be available? * Is that Symbola font, or equivalent, now a true dependency? Or is there something more common which I should be using? (Perhaps I have missed a normal configuration step?) Thank you! On 7/12/22 12:58, Juan Manuel Macías wrote: Hi, Daniel Ortmann writes: Any clues where this particular symbol resides? A hint about the package name would wonderful. :-) To be able to display "unusual" symbols in Emacs, I usually use the symbola font: You can download it here: https://urldefense.com/v3/__https://fontlibrary.org/en/font/symbola__;!!ACWV5N9M2RV99hQ!LCWutd87ZOlNkSgFTjjR0zYsqhv6xP6ZBep63lyK7tIveH2MWiQ331YB8rJexEVU6gjcjT99EdYoJvFPvxABlZvT$ And then: (set-fontset-font t 'symbol (font-spec :family "Symbola")) But I think that what is interesting here is to know how that character has arrived. Could it be related to some new package you have installed lately? Best regards, Juan Manuel
Re: missing a character / font in agenda?
Hi, Daniel Ortmann writes: > Any clues where this particular symbol resides? A hint about the > package name would wonderful. :-) To be able to display "unusual" symbols in Emacs, I usually use the symbola font: You can download it here: https://fontlibrary.org/en/font/symbola And then: (set-fontset-font t 'symbol (font-spec :family "Symbola")) But I think that what is interesting here is to know how that character has arrived. Could it be related to some new package you have installed lately? Best regards, Juan Manuel
missing a character / font in agenda?
Hello,
During the past couple of weeks I have been seeing a new character in
the agenda when the log is on and I am displaying the time grid. I have
tried to find and install this character representation on Fedora-based
Linux but have not found the magic.
Any clues where this particular symbol resides? A hint about the
package name would wonderful. :-)
Thank you!
More information on that character:
position: 195 of 690 (28%), column: 26
character: ⭠ (displayed as ⭠) (codepoint 11104, #o25540,
#x2b60)
charset: unicode-bmp (Unicode Basic Multilingual Plane
(U+..U+))
code point in charset: 0x2B60
script: symbol
syntax: _ which means: symbol
category: .:Base
to input: type "C-x 8 RET 2b60" or "C-x 8 RET LEFTWARDS
TRIANGLE-HEADED ARROW"
buffer code: #xE2 #xAD #xA0
file code: #xE2 #xAD #xA0 (encoded by coding system utf-8-unix)
display: no font available
Character code properties: customize what to show
name: LEFTWARDS TRIANGLE-HEADED ARROW
general-category: So (Symbol, Other)
decomposition: (11104) ('⭠')
There are text properties here:
breadcrumbs nil
day 738348
dotime "12:11 "
duration nil
extra ""
face org-agenda-current-time
format [Show]
level ""
org-agenda-type agenda
org-category ""
org-day-cnt 1
org-heading t
org-last-args (nil 738348 day)
org-priority-highest 65
org-priority-lowest 67
org-redo-cmd (org-agenda-list 'nil 738348 'day nil)
org-series-cmd nil
tags nil
time "12:11 ┄ "
time-of-day 1211
txt [Show]
Re: org-cature-ref
Den tis 12 juli 2022 17:51Henrik Frisk skrev: > > > Den tors 7 juli 2022 kl 12:48 skrev Ihor Radchenko : > >> Henrik Frisk writes: >> >> > Ihor Radchenko recently mentioned org-capture-ref and I decided to try >> to >> > use it, but I'm having trouble getting it to work. I have org-protocl >> > working for me so I'm suspecting that it is the syntax of the >> bookmarklet >> > I'm using that is at fault. I merely changed the capture template key >> from >> > the example here: >> > >> > >> https://github.com/alphapapa/org-protocol-capture-html#org-protocol-instructions >> > >> > but that doesn't work (I get an empty buffer with what looks as the the >> > link contents as name). Apart from that I have just copied the template >> > from here: >> >> Do I understand correctly that you used the following bookmarklet: >> >> javascript:location.href = 'org-protocol://capture-html?template=w=... >> >> ? >> >> Is so, you probably need >> >> org-protocol://capture?template... >> instead of >> org-protocol://capture-html?template... >> >> Thanks, that was the issue and it works fine now. However, I can't seem > to get the org-capture-ref-get-bibtex-field to work by simply replacing > org-capture-ref-headline-format > with it. Not sure where the ":bibtex-string" should go in the template > which is probably why it doesn't work. > > /h > > Failed to reply to list. Sorry. > >
org-capture-templates failing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Using this template culled from the org-mode manual
- --8<---cut here---start->8---
#+BEGIN_SRC emacs-lisp
(setq org-capture-templates
'(("t" "Todo" entry (file+headline "~/.emacs.d/org/scratch.org" "Tasks")
"* TODO %?\n %i\n %a")
("o" "Journal" entry (file+datetree "~/.emacs.d/org/scratch.org")
"* %?\nEntered on %U\n %i\n %a")))
#+END_SRC
[2022-07-12 Tue 16:24]
- --8<---cut here---end--->8---
and selecting either of the 2 keys from my org-capture setup, this is displayed
in a debugger *backtrace*
- --8<---cut here---start->8---
Debugger entered--Lisp error: (error "Capture template ‘t’: Symbol’s value as
variable i...")
signal(error ("Capture template ‘t’: Symbol’s value as variable i..."))
error("Capture template `%s': %s" "t" "Symbol’s value as variable is void:
org-fold-core-...")
#f(compiled-function ( goto keys) "Capture
something.\n\\\nThis will let you select a template from
`org-capture-templates', and\nthen file the newly captured information. The
text is immediately\ninserted at the target location, and an indirect buffer is
shown where\nyou can edit it. Pressing `\\[org-capture-finalize]' brings you
back to the previous\nstate of Emacs, so that you can continue your
work.\n\nWhen called interactively with a `\\[universal-argument]' prefix
argument GOTO, don't\ncapture anything, just go to the file/headline where the
selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument]
\\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen
called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called
with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is
made.\n\nELisp programs can set KEYS to a string associated with a template\nin
`org-capture-templates'. In this case, interactive selection\nwill be
bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from
the\nagenda will use the date at point as the default date. Then, a\n`C-1'
prefix will tell the capture process to use the HH:MM time\nof the day at point
(if any) or the current HH:MM time." (interactive "P") #)(nil nil)
ad-Advice-org-capture(#f(compiled-function ( goto keys) "Capture
something.\n\\\nThis will let you select a template from
`org-capture-templates', and\nthen file the newly captured information. The
text is immediately\ninserted at the target location, and an indirect buffer is
shown where\nyou can edit it. Pressing `\\[org-capture-finalize]' brings you
back to the previous\nstate of Emacs, so that you can continue your
work.\n\nWhen called interactively with a `\\[universal-argument]' prefix
argument GOTO, don't\ncapture anything, just go to the file/headline where the
selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument]
\\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen
called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called
with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is
made.\n\nELisp programs can set KEYS to a string associated with a template\nin
`org-capture-templates'. In this case, interactive selection\nwill be
bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from
the\nagenda will use the date at point as the default date. Then, a\n`C-1'
prefix will tell the capture process to use the HH:MM time\nof the day at point
(if any) or the current HH:MM time." (interactive "P") #) nil)
apply(ad-Advice-org-capture #f(compiled-function ( goto keys)
"Capture something.\n\\\nThis will let you select a
template from `org-capture-templates', and\nthen file the newly captured
information. The text is immediately\ninserted at the target location, and an
indirect buffer is shown where\nyou can edit it. Pressing
`\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so
that you can continue your work.\n\nWhen called interactively with a
`\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go
to the file/headline where the selected\ntemplate stores its notes.\n\nWith a
`\\[universal-argument] \\[universal-argument]' prefix argument, go to the last
note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at
point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date
when\na datetree entry is made.\n\nELisp programs can set KEYS to a string
associated with a template\nin `org-capture-templates'. In this case,
interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is
non-nil, capturing from the\nagenda will use the date at point as the default
date. Then, a\n`C-1' prefix will tell the capture process to use the HH:MM
time\nof the day at point (if any) or the current HH:MM time."
Fallback fonts in LuaTeX via 'luaotfload.add_fallback' (was "Fontsets")
Today I discovered that luaotfload included in v. 3.12 a new
experimental function, luaotfload.add_fallback, to be able to add a list
of fallback fonts to a LuaTeX document, at a low level.
(More info on page 18 of the luaotfload manual, with some examples).
I've been experimenting a bit with this function. For example:
#+begin_src latex
\documentclass{article}
\usepackage{fontspec}
\directlua{
luaotfload.add_fallback ("fallbacktest",
{
"oldstandard:mode=harf;script=grek;color=FF;",
"oldstandard:mode=harf;script=cyrl;color=FF;",
"freeserif:mode=harf;script=arab;color=FF;",
"freeserif:mode=harf;script=dev2;color=FF;",
}
)
}
\setmainfont{latinmodernroman}[RawFeature={fallback=fallbacktest}]
\begin{document}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
hendrerit tempor tellus. Donec pretium posuere tellus.
Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲν
Ἀρταξέρξης, νεώτερος δὲ Κῦρος· ἐπεὶ δὲ ἠσθένει Δαρεῖος καὶ ὑπώπτευε
τελευτὴν τοῦ βίου, ἐβούλετο τὼ παῖδε ἀμφοτέρω παρεῖναι. ὁ μὲν οὖν
πρεσβύτερος παρὼν ἐτύγχανε· Κῦρον δὲ μεταπέμπεται ἀπὸ τῆς ἀρχῆς ἧς
αὐτὸν σατράπην ἐποίησε, καὶ στρατηγὸν δὲ αὐτὸν ἀπέδειξε πάντων ὅσοι ἐς
Καστωλοῦ πεδίον ἁθροίζονται.
Emacs написан на двух языках: C и Emacs Lisp (Elisp, диалект Лиспа).
При этом сам редактор является интерпретатором Elisp. По сути дела,
большая часть Emacs написана на языке Elisp, и её можно рассматривать
как расширение к основной программе. Пользователи могут сами создавать
части Emacs, от отдельных функций до новых основных режимов. При этом
можно переопределять любые Elisp-функции, в том числе и те, что
являются частью самого редактора, и модифицировать функциональность
Emacs, изменив соответствующим образом некоторые функции.
Native speakers of Arabic generally do not distinguish between Modern
Standard Arabic and Classical Arabic as separate languages; they refer
to both as al-ʻArabīyah al-Fuṣḥá (العربية الفصحى) meaning the pure
Arabic. They consider the two forms to be two registers of one
language. When the distinction is made, they are referred to as فصحى
العصر Fuṣḥá al-ʻAṣr (MSA) and فصحى التراث Fuṣḥá al-Turāth (CA)
respectively.
उदु ज्योतिरमृतं विश्वजन्यं विश्वानरः सविता देवो अश्रेत् ।\\
क्रत्वा देवानामजनिष्ट चक्षुराविरकर्भुवनं विश्वमुषाः ॥ १ ॥\\
प्र मे पन्था देवयाना अदृश्रन्नमर्धन्तो वसुभिरिष्कृतासः ।\\
अभूदु केतुरुषसः पुरस्तात्प्रतीच्यागादधि हर्म्येभ्यः ॥ २ ॥
\end{document}
#+end_src
The main drawback I've found to this (at least I don't know how to solve
it at the moment) is that the fallback feature cannot be added via
\defaultfontfeatures. That would avoid having to (re)define all the
main/sans/mono/math families.
Best regards,
Juan Manuel
Re: Confused about source code blocks evaluation when exporting
Alain, let's see. maybe look in the org manual for ":results" (with "value" or "output" as options) and ":exports" (with "code" or "results" or "both" as options). that might help? cheers, Greg
Re: Confused about source code blocks evaluation when exporting
On Tuesday, 12 Jul 2022 at 14:53, alain.coch...@unistra.fr wrote: > So far so good. (Well almost: why does '#+RESULTS:' show 'bar' and > not 'foo'? After all, I'm just setting 'my-var', I'm not asking to > display its value. But that's incidental.) It's not incidental. By default, the results of a src block evaluation is the value of the src block which is typically the value returned by the last statement. You can modify this by adding :results output for instance to the begin_src line. > (test 2) Same org file. If I do 'C-c C-e l o', no question is asked, > no '#+RESULTS:' block is inserted, and the resulting pdf file shows: On export, the default is to export the code. If you want the results, you need to add :exports results or if you want both code and results, :exports both -- : Eric S Fraga, with org release_9.5.4-613-gb3b17c in Emacs 29.0.50
Re: Recent folding issues
Jack Kamm writes: >> I cannot reproduce. Please, update your Org to the latest version, try >> to reproduce, and provide the detailed steps required to obtain the >> confusing behaviour you are seeing. > > I attach a couple files for a minimal reproducible example of both > issues. > > Steps to reproduce: Thanks! Can you try the attached patch set? Best, Ihor >From a79a742cbff01b7815cffba806c28ea45a4da63c Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Tue, 12 Jul 2022 15:05:45 +0800 Subject: [PATCH 1/3] Revert "org.el: Improve performance of deletion commands" This reverts commit 46df681336c83c826b367d2803f59560165bdeba. The optimization broke folding fragility checks. --- lisp/org.el | 74 ++--- 1 file changed, 36 insertions(+), 38 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 3d4de5b4f..d85b5818e 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16156,19 +16156,18 @@ (defun org-delete-backward-char (N) still be marked for re-alignment if the field did fill the entire column, because, in this case the deletion might narrow the column." (interactive "p") - (org-fold-core-ignore-modifications -(save-match-data - (org-fold-check-before-invisible-edit 'delete-backward) - (if (and (= N 1) - (not overwrite-mode) - (not (org-region-active-p)) - (not (eq (char-before) ?|)) - (save-excursion (skip-chars-backward " \t") (not (bolp))) - (looking-at-p ".*?|") - (org-at-table-p)) - (progn (forward-char -1) (org-delete-char 1)) -(backward-delete-char N) -(org-fix-tags-on-the-fly) + (save-match-data +(org-fold-check-before-invisible-edit 'delete-backward) +(if (and (= N 1) + (not overwrite-mode) + (not (org-region-active-p)) + (not (eq (char-before) ?|)) + (save-excursion (skip-chars-backward " \t") (not (bolp))) + (looking-at-p ".*?|") + (org-at-table-p)) + (progn (forward-char -1) (org-delete-char 1)) + (backward-delete-char N) + (org-fix-tags-on-the-fly (defun org-delete-char (N) "Like `delete-char', but insert whitespace at field end in tables. @@ -16177,31 +16176,30 @@ (defun org-delete-char (N) still be marked for re-alignment if the field did fill the entire column, because, in this case the deletion might narrow the column." (interactive "p") - (org-fold-core-ignore-modifications -(save-match-data - (org-fold-check-before-invisible-edit 'delete) - (cond - ((or (/= N 1) - (eq (char-after) ?|) - (save-excursion (skip-chars-backward " \t") (bolp)) - (not (org-at-table-p))) -(delete-char N) -(org-fix-tags-on-the-fly)) - ((looking-at ".\\(.*?\\)|") -(let* ((update? org-table-may-need-update) - (noalign (looking-at-p ".*? |"))) - (delete-char 1) - (org-table-with-shrunk-field - (save-excursion - ;; Last space is `org-table-separator-space', so insert - ;; a regular one before it instead. - (goto-char (- (match-end 0) 2)) - (insert " "))) - ;; If there were two spaces at the end, this field does not - ;; determine the width of the column. - (when noalign (setq org-table-may-need-update update? - (t -(delete-char N)) + (save-match-data +(org-fold-check-before-invisible-edit 'delete) +(cond + ((or (/= N 1) + (eq (char-after) ?|) + (save-excursion (skip-chars-backward " \t") (bolp)) + (not (org-at-table-p))) + (delete-char N) + (org-fix-tags-on-the-fly)) + ((looking-at ".\\(.*?\\)|") + (let* ((update? org-table-may-need-update) + (noalign (looking-at-p ".*? |"))) + (delete-char 1) + (org-table-with-shrunk-field + (save-excursion + ;; Last space is `org-table-separator-space', so insert + ;; a regular one before it instead. + (goto-char (- (match-end 0) 2)) + (insert " "))) + ;; If there were two spaces at the end, this field does not + ;; determine the width of the column. + (when noalign (setq org-table-may-need-update update? + (t + (delete-char N) ;; Make `delete-selection-mode' work with Org mode and Orgtbl mode (put 'org-self-insert-command 'delete-selection -- 2.35.1 >From f29ccf3161a51f700bb3375a16acab563baceb49 Mon Sep 17 00:00:00 2001 Message-Id: In-Reply-To: References: From: Ihor Radchenko Date: Tue, 12 Jul 2022 21:30:58 +0800 Subject: [PATCH 2/3] test-org-fold: Cover the issue fixed by previous commit * testing/lisp/test-org-fold.el (test-org-fold/org-fold-reveal-broken-structure): Test `org-delete-char' instead of `delete-char'. The former is the function used interactively. --- testing/lisp/test-org-fold.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testing/lisp/test-org-fold.el b/testing/lisp/test-org-fold.el index 40afe55ae..a26346175 100644 --- a/testing/lisp/test-org-fold.el +++ b/testing/lisp/test-org-fold.el @@ -410,7 +410,7 @@
Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi Ihor, On Tue, 12 Jul 2022 at 10:46, Ihor Radchenko wrote: Thanks for the detailed analysis! I thank you again for your continued interest in this little report. I dug through the old commits and found where this behaviour has been introduced: Commit 0bbf3a9bd message details the current behaviour and its caveats: Ah! this definetely clears up the intended purpose of the condition. Great dig! As you can see, the todayp condition is avoiding issues with weekly agenda when the same habit is displayed multiple times. The problem you observed is also noted and left unresolved. Ideas how to deal with the described are welcome! I can try to think this trough with you, if you'd like. Since I'm the reporter and bumper, it is fair that I start and try to build a base for it. The TL;DR for what follows is that I think `todayp' is ultimately the "wrong" condition to apply, but is a good *proxy*. Perhaps there's a chance to get to a more correct condition, but I'm not sure. But, even if not, I'd like to argue that the "occurrence at point" may be a better proxy, which would be the condition applied (as far as I can tell, which see) if the `todayp' condition were dropped. The long version: First a preliminary observation. I think the case "noted and left unresolved" in the commit message is somewhat different than the one reported here. Related, of course, but different. Let's consider a hypothetical agenda with the following characteristics: a weekly agenda starting on Monday (fixed), today is Tuesday. Unless stated otherwise, this is the scenario for the examples that follow. A daily repeating task, scheduled for today will appear in the agenda from Tuesday to Sunday. If we move point to the occurrence of that task on, say, Thursday, and mark it done then, we would have the case described in the commit message. I'm not sure it is "unlikely", but we could argue that this is "dubious user input". Now consider the case of a weekly repeating task scheduled for Thursday. This is the case reported here. And I think marking this entry done "ahead of schedule" is arguably more legitimate user input. For once, this entry only appears once in the given agenda view, there is no option to use any other. That said, let's try to be systematic. There are a number of reasons an entry may appear multiple times in an agenda view: A1) The entry is scheduled in a past date, and this past date is also visible in the agenda view. In the example agenda a task scheduled for Monday would appear both Monday, and today, Tuesday. A2) The entry has a deadline in a future date, this future date is visible in the agenda view, and the deadline warning settings are enough to be shown today as well. A task with a deadline for Thursday would appear today, Tuesday, and Thursday. B) The entry is scheduled (deadlined?) to a range of dates. For example, a task scheduled to a range from Thursday to Saturday this week would appear four times in the agenda view, once for the regular schedule and thrice for the range "(N/3)". C) The entry has a repeater whose frequency is higher than the span of the agenda view. A daily task on a weekly view, a weekly task on a monthly view, etc. Of course, a given entry may appear in the agenda multiple times for multiple of these reasons. That's all I can think of. Do you see any other cases? This is a critical question, because the soundness of the argument depends on this list being exhaustive. Anyway, pending on that, let me go on. Now, this bug only affects repeating tasks, because the problem arises only for them because their state in the underlying buffer does not correspond to the "todo change the user has just applied". Indeed, `org-agenda-headline-snapshot-before-repeat' is correspondingly just stored for them, as the name implies. Furthermore, reasons A1, A2 and B, are not specific to repeating tasks, though they affect them too, of course. Reason C is the only one specific to repeating tasks, and is really the only reason I think grants for the case considered in the commit message: Because the same line may be present in other lines in the same weekly agenda, we cannot simply update all lines related to this entry. Indeed, a non-repeating task which appears multiple times in the agenda view (A1, A2, or B), when marked done, is visually changed as such in all occurrences. The same does not happen for a repeating entry because, well, "there might be C (as well?)...". That's the nature of the problem, as far as I can see. And a real one at that. I don't know enough of the agenda machinery to know if among the metadata stored as text properties we would be able to distinguish "C" from the other reasons for a given occurrence of a given entry. It is probably fair to presume it is not possible to distinguish, otherwise Carsten might have leveraged that information. That given, `todayp'
Confused about source code blocks evaluation when exporting
Hello. The manual says: Org evaluates code in the following circumstances: _Source code blocks_ Org evaluates source code blocks in an Org file during export. Org also evaluates a source code block with the ‘C-c C-c’ key chord. NB: each test below is performed with a new 'emacs -Q' session. I have: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /home/cochard/usr/local/emacs-28.1/lisp/org/) (test 1) I have an org file which only contains #+BEGIN_SRC emacs-lisp (message "foo") (setq my-var 'bar) #+END_SRC If I do 'C-c C-c', I am asked the following Evaluate this emacs-lisp code block on your system? (yes or no) If I answer 'yes', the following block #+RESULTS: : bar is inserted below the source block; also I see, in the *Messages* buffer: executing Emacs-Lisp code block... foo Code block evaluation complete. and if if 'C-h v' for 'my-var', it says my-var’s value is ‘bar’ So far so good. (Well almost: why does '#+RESULTS:' show 'bar' and not 'foo'? After all, I'm just setting 'my-var', I'm not asking to display its value. But that's incidental.) (test 2) Same org file. If I do 'C-c C-e l o', no question is asked, no '#+RESULTS:' block is inserted, and the resulting pdf file shows: Contents (message "foo") (setq my-var ’bar) The *Messages* buffer shows org-babel-exp process emacs-lisp at position 1... Saving file /home/cochard/tmp/scr.tex... Wrote /home/cochard/tmp/scr.tex Processing LaTeX file scr.tex... PDF file produced. Running /usr/bin/xdg-open /home/cochard/tmp/scr.pdf...done and 'my-var' is not understood as a variable. So I don't understand. I can only conclude that the code is not evaluated, which seems to me contradictory with "Org evaluates source code blocks in an Org file during export". (test 3) Same code, except that I change the 1st line to #+BEGIN_SRC emacs-lisp :exports results If I do 'C-c C-e l o', I am asked the same question as in test 1: Evaluate this emacs-lisp code block on your system? (yes or no) but even if I answer 'yes', no '#+RESULTS:' block is inserted. The *Messages* buffer shows org-babel-exp process emacs-lisp at position 1... executing Emacs-Lisp code block... foo Code block evaluation complete. Saving file /home/cochard/tmp/scr.tex... Wrote /home/cochard/tmp/scr.tex Processing LaTeX file scr.tex... PDF file produced. and the pdf file shows: Contents bar and my-var is defined. So the code is evaluated this time, but I don't really understand the whole process either... For example, what should I do if I want the code to be evaluated, the '#+RESUTS:' block to be inserted in the org file, but nothing to be shown in the exported pdf? (i.e., neither the code nor its results) Same question for code evaluation but nothing related to this code inserted or exported. I've tried using the ':eval' header argument but it never worked as I expected. Thank you for you help. -- EOST (École et Observatoire des Sciences de la Terre) ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr 5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France | [ slot available for rent ]
Re: @string abbreviation in bib file not honored in (basic) org-cite [and a minimal working example with natbib]
On Tue, 12 Jul 2022 at 13:36, John Kitchin wrote: > Maybe it is still needed so the tooltip looks nice. currently, oc-basic.el contains the single activation (fontification) processor (called "basic") shipped with Org, the other oc-*.el files provide only export processors. best wishes, András >> OTOH, a small correction: as far as I can see, oc-natbib and >> oc-bibtex (and oc-biblatex) do not parse bib(la)tex files at all, >> since they simply transform Org citation and bibliography commands to >> their LaTeX equivalent. >> >> best wishes, >> András >> > -- > John > > --- > Professor John Kitchin (he/him/his) > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > https://kitchingroup.cheme.cmu.edu > https://pointbreezepubs.gumroad.com/ pycse bookstore >
Re: @string abbreviation in bib file not honored in (basic) org-cite [and a minimal working example with natbib]
Maybe it is still needed so the tooltip looks nice. On Tue, Jul 12, 2022 at 7:15 AM András Simonyi wrote: > Dear All, > > On Sun, 10 Jul 2022 at 09:17, Ihor Radchenko wrote: > > > AFAIU, oc-natbib/oc-bibtex also do not support @string because they also > > rely upon the built-in Emacs parser for bib files. > > > I have submitted a bug report to Emacs devs [1]. Hopefully it can be > > fixed on Emacs side without a need to switch the bibtex parser. > > Thanks Ihor for submitting the bug report, I think it will be useful > for Emacs to contain a built-in bibtex parser with proper @string > support. > OTOH, a small correction: as far as I can see, oc-natbib and > oc-bibtex (and oc-biblatex) do not parse bib(la)tex files at all, > since they simply transform Org citation and bibliography commands to > their LaTeX equivalent. > > best wishes, > András > > -- John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin https://kitchingroup.cheme.cmu.edu https://pointbreezepubs.gumroad.com/ pycse bookstore
Re: fontsets
Stefan Nobis writes:
> Hmmm... maybe add optional extra config/output option to the fontset,
> like so:
>
> ┌
> │ ;; Fonts
> │ ((myfonta . ((pdflatex . "etc.") (lualatex ...) (html ...) ...))
> │ (myfontb ...)
> │ ...)
> │ ;; Fontsets
> │ ((myfontset .
> │ ((sans . myfonta)
> │(serif . myfontb)
> │(mono . myfontc)
> │(extra . ((lualatex . "\\defaultfontfeatures{Scale=MatchLowercase}")
> │ (html "some CSS...")...))
> │...))
> │ ...)
> └
>
> This way it may be possible to build a fontset library of fonts that
> blend well together, including some necessary fine-tuning.
I think it's a good idea. And I definitely like Timothy's idea of
fontsets, but I still think that LuaLaTeX and XelaTeX should be unified
in some way.
Perhaps one or two default fontsets could be added.
It was commented in some previous message about the possibility of
checking if a font is present in the system. To add some extra
information, TeX live 2022 includes a lua script, luafindfont, which
runs luaotfload in the background. It is very useful because, in
addition to system fonts, it also returns results from TeX live fonts. I
use this script via helm, and I wrote this to extract a list of
candidates:
#+begin_src emacs-lisp
(defun build-luafindfont-candidates-list (candidate)
(interactive)
(let* ((query (shell-command-to-string (concat "luafindfont " candidate)))
(str (with-temp-buffer
(insert query)
(goto-char (point-min))
(let ((from
(save-excursion
(re-search-forward "1\\." nil t)
(beginning-of-line)
(point)))
(to
(save-excursion
(goto-char (point-max))
(point
(save-restriction
(narrow-to-region from to)
(buffer-string)
(str-clean (split-string
(with-temp-buffer
(insert str)
(replace "[[:digit:]]+\\.\s+" "")
(replace "\\(.+\\)\\(\\.otf\\|\\.ttf\\)\s+" "")
(replace "\s+" " -- ")
(buffer-string)) "\n" t)))
(setq luafindfont-list (mapcar 'identity
str-clean
#+end_src
On the other hand, fontspec includes the \IfFontExistsTF command.
According to the fontspec documentation:
--
\IfFontExistsTF{⟨font name⟩}{⟨true branch⟩}{⟨false branch⟩}
The conditional \IfFontExistsTF is provided to test whether the ⟨font name⟩
exists or
is loadable. If it is, the ⟨true branch⟩ code is executed; otherwise, the
⟨false branch⟩ code is.
This command can be slow since the engine may resort to scanning the filesystem
for a
missing font. Nonetheless, it has been a popular request for users who wish to
define ‘fallback
fonts’ for their documents for greater portability.
In this command, the syntax for the ⟨font name⟩ is a restricted/simplified
version of the
font loading syntax used for \fontspec and so on. Fonts to be loaded by
filename are detected
by the presence of an appropriate extension (.otf, etc.), and paths should be
included inline.
E.g.:
\IfFontExistsTF{cmr10}{T}{F}
\IfFontExistsTF{Times New Roman}{T}{F}
\IfFontExistsTF{texgyrepagella-regular.otf}{T}{F}
\IfFontExistsTF{/Users/will/Library/Fonts/CODE2000.TTF}{T}{F}
---
Best regards,
Juan Manuel
Re: @string abbreviation in bib file not honored in (basic) org-cite [and a minimal working example with natbib]
Dear All, On Sun, 10 Jul 2022 at 09:17, Ihor Radchenko wrote: > AFAIU, oc-natbib/oc-bibtex also do not support @string because they also > rely upon the built-in Emacs parser for bib files. > I have submitted a bug report to Emacs devs [1]. Hopefully it can be > fixed on Emacs side without a need to switch the bibtex parser. Thanks Ihor for submitting the bug report, I think it will be useful for Emacs to contain a built-in bibtex parser with proper @string support. OTOH, a small correction: as far as I can see, oc-natbib and oc-bibtex (and oc-biblatex) do not parse bib(la)tex files at all, since they simply transform Org citation and bibliography commands to their LaTeX equivalent. best wishes, András
Re: Can citeproc be installed without using MELPA? (was: @string abbreviation in bib file not honored in (basic) org-cite)
Dear All, On Mon, 11 Jul 2022 at 04:05, Ihor Radchenko wrote: > >> Then, I am wondering if parsebib can be added to ELPA or at least > >> non-GNU ELPA. The same can be said for all other dependencies of > >> citeproc.el and for citeproc itself. > non-GNU ELPA is also fine. The idea is to avoid asking users to add > extra package repo configuration. Since the dash library, which is heavily used in citeproc-el, has been added to GNU ELPA, if parsebib also becomes available in non-GNU ELPA then I don't so any serious problem with adding citeproc-el to the latter as well -- the use of the "s" string processing library would still need to be eliminated but this would require only relatively minor changes. best wishes, András
from org-table (with formulas) to csv and back (ods)
Hi As it was pointed out to me in https://github.com/kjambunathan/org-mode-ox-odt/issues/94 It is possible to start with a ods file then convert it to csv with formula to obtain something like this #+begin_src 3,6,"=SUM($A1:$B1)" 1,3,"=SUM($A2:$B2)" 1,2,"=SUM($A3:$B3)" #+end_src That can be relatively converted to a org-table with the correct formula #+begin_src | First | | | |---+---+-| | 3 | 6 | 9 | | 1 | 3 | 4 | | 1 | 2 | 3 | | 8 | 9 | 17 | ,#+TBLFM: $3=vsum($1..$2);f-2 #+end_src And furthermore modified. #+begin_src | First | | | |---+---+-| | 3 | 6 | 9 | | 1 | 3 | 4 | | 1 | 2 | 3 | | 8 | 9 | 17 | | 100 | 1 | 101 | ,#+TBLFM: $3=vsum($1..$2);f-2 #+end_src The question is how to convert back to csv? Manually the «correct table» would be #+begin_src | 3 | 6 | =SUM($A1:$B1) | | 1 | 3 | =SUM($A2:$B2) | | 1 | 2 | =SUM($A3:$B3) | | 100 | 1 | =SUM($A4:$B4) | #+end_src Which will then be converted to #+begin_src 3,6,=SUM($A1:$B1) 1,3,=SUM($A2:$B2) 1,2,=SUM($A3:$B3) 100,1,=SUM($A4:$B4) #+end_src So the question is: at least for simple formulas (no ifs for example) wouldn't it be good to implement a lisp function that does this conversion? regards Uwe Brauer -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine.
Re: fontsets
Juan Manuel Macías writes:
> [1] I have to add, by the way, that MatchLowercase is not always a
> panacea.
Hmmm... maybe add optional extra config/output option to the fontset,
like so:
┌
│ ;; Fonts
│ ((myfonta . ((pdflatex . "etc.") (lualatex ...) (html ...) ...))
│ (myfontb ...)
│ ...)
│ ;; Fontsets
│ ((myfontset .
│ ((sans . myfonta)
│(serif . myfontb)
│(mono . myfontc)
│(extra . ((lualatex . "\\defaultfontfeatures{Scale=MatchLowercase}")
│ (html "some CSS...")...))
│...))
│ ...)
└
This way it may be possible to build a fontset library of fonts that
blend well together, including some necessary fine-tuning.
--
Until the next mail...,
Stefan.
Re: Recent folding issues
Hi Ihor,
> May you provide the output of M-x org-version?
Org mode version 9.5.4 (release_9.5.4-623-gc66bdb @
/home/jack/dev/org-mode/lisp/)
I also updated org-mode to the most recent version (last commit 5
hours ago).
> I cannot reproduce. Please, update your Org to the latest version, try
> to reproduce, and provide the detailed steps required to obtain the
> confusing behaviour you are seeing.
I attach a couple files for a minimal reproducible example of both
issues.
Steps to reproduce:
0. Download the attached init.el and test.org. Edit the absolute path
of "test.org" in the capture template in "init.el" to the location
you downloaded it.
Then do "emacs -q --load init.el test.org"
test.org should look like this now:
> * Headline 1
> * 2021
> * 2022
> * Headline 4
1. Next, do "M-x org-capture". Then type "c". Then create the following note:
> Test entry 1
Then press C-c C-c. Buffer should look like this now:
> * Headline 1
> * 2021
> * 2022
>
> ** 2022-07 July
>
> *** 2022-07-11 Monday
>
> Test entry 1
>
> * Headline 4
2. Shift-TAB until all headlines are collapsed. Buffer should look like this:
> * Headline 1
> * 2021
> * 2022...
> * Headline 4
3. Capture a second note: do M-x org-capture, type "c", and create the entry:
> Test entry 2
And press C-c C-c.
Now, an error appears: I observe two headlines running into each other
on the last line, like so:
> * Headline 1
> * 2021
> * 2022...
> ** 2022-07 July...
> *** 2022-07-11 Monday...
> Test entry 2...* Headline 4
Now, to produce the other issue. Shift-tab until all headlines are
collapsed again. Doing this a couple times will also fix the above
error, and the buffer should look like this now:
> * Headline 1
> * 2021
> * 2022...
> * Headline 4
Put the pointer at the start of the line "* Headline 4". Then press Enter.
A newline is placed above "* Headline 4", but also, the preceding
headline "* 2022", has been expanded, so the buffer looks like this to me:
> * Headline 1
> * 2021
> * 2022
>
> ** 2022-07 July
>
> *** 2022-07-11 Monday
>
> Test entry 1
>
> Test entry 2
>
>
> * Headline 4
However, I would instead expect to see the following:
> * Headline 1
> * 2021
> * 2022...
>
> * Headline 4
Which is what I observe when org-fold-core-style is set to overlays.
Best,
Jack
(add-to-list 'load-path "~/dev/org-mode/lisp")
(customize-set-variable
'org-capture-templates
'(("c" "capture" entry (file+olp+datetree
"~/dev/orgmode-devel/220711-folding-issues/test.org")
"* %?"
:empty-lines 1 :jump-to-captured t)))
* Headline 1
* 2021
* 2022
* Headline 4
Re: Folded headlines with text showing where it shouldn't
William Denton writes:
>> Usually, the problem you are seeing is when something is interfering
>> with 'invisible text property of links/other folded text.
>>
>> Can you post the value of org-link-parameters on your system?
>
> This is a new variable to me! I've never done anything with it, but it's got
> a
> lot in it.
>
> Value:
> (("attachment" :follow org-attach-follow :complete org-attach-complete-link)
> ("eww" :follow org-eww-open :store org-eww-store-link)
> ..
This is the default value.
>> You may also put the cursor onto unexpectedly visible link and check the
>> output of M-x describe-text-properties. Then, put the cursor right after
>> the link and run M-x describe-text-properties again. Then, share the
>> output.
>
> Here's a screenshot of the problem I get:
>
> https://www.miskatonic.org/tmp/org-problem.png
>
> And here's the output of describe-text-properties when the pointer is in the
> link that shouldn't be there:
>
> Text content at position 56157:
> ...
> There are 3 overlays here:
> From 56151 to 56168
>evaporatet
>invisibleorg-link-description
>isearch-open-invisible ignore
>isearch-open-invisible-temporary ignore
>org-invisibleorg-link-description
>priority 2
This is curious. Did the problem reveal itself after you used isearch
(C-s)? Do you happen to use some non-standard search package (like
evil)?
If you happen to see this issue again, what is the value of
org-fold-core--isearch-overlays inside that buffer?
Best,
Ihor
