*doc/org-manual.org: Fix the description for "Internal Link" in the org-mode manual
Hi,
When I try to export follow org document to html, there is an error message:
Unable to resolve link: "Test".
The foot script in section "Internal Link" of org-mode manual says:
> When targeting a ‘NAME’ keyword, the ‘CAPTION’ keyword is mandatory in order
> to get proper numbering
Adding a CAPTION not work, but adding the 'PROPERTY' before name does work.
So the attached patch try to correct the description in the foot script.
#+begin_src python :results table
return 1
#+end_src
#+PROPERTY:
#+NAME: Test
#+RESULTS:
|1|
[[Test]]
From 9b473024a5f1e19e00f198d97b1be13789062c82 Mon Sep 17 00:00:00 2001
From: Lin Sun
Date: Wed, 1 Jun 2022 00:01:07 +
Subject: [PATCH] manual: Fix the internal-link document for it depends on the
PROPERTY
* doc/org-manual.org: The internal-link acctually depends on PROPERTY
than CAPTION
---
doc/org-manual.org | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 9094f81..a2c9df2 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21922,8 +21922,8 @@ can be used. Just type a star followed by a few optional letters into
the buffer and press {{{kbd(M-TAB)}}}. All headlines in the current
buffer are offered as completions.
-[fn:26] When targeting a =NAME= keyword, the =CAPTION= keyword is
-mandatory in order to get proper numbering (see [[*Captions]]).
+[fn:26] When targeting a =NAME= keyword, the =PROPERTY= keyword is
+mandatory in order to get proper numbering (see [[*Property Syntax]]).
[fn:27] The actual behavior of the search depends on the value of the
variable ~org-link-search-must-match-exact-headline~. If its value is
--
2.7.0
Re: *doc/org-manual.org: Fix the description for "Internal Link" in the org-mode manual
Lin Sun writes: > When I try to export follow org document to html, there is an error message: > Unable to resolve link: "Test". > > The foot script in section "Internal Link" of org-mode manual says: > >> When targeting a ‘NAME’ keyword, the ‘CAPTION’ keyword is mandatory in order >> to get proper numbering > > Adding a CAPTION not work, but adding the 'PROPERTY' before name does work. Confirmed. This should not happen, AFAIU. Instead of suggesting unintuitive workarounds in the manual, we need to fix the original problem. Best, Ihor
Re: *doc/org-manual.org: Fix the description for "Internal Link" in the org-mode manual
Ihor Radchenko writes: > This should not happen, AFAIU. Instead of suggesting unintuitive > workarounds in the manual, we need to fix the original problem. I looked into this further. Org actually behaves correctly in your example. Please refer to 16.7 Exporting Code Blocks. Basically, the default Org behavior when exporting blocks is :export code. Org removes all the results of evaluation. If you have - #+begin_src python :results table return 1 #+end_src #+NAME: Test #+RESULTS: |1| [[Test]] - then Org removes the result on export and you end up with: - #+begin_src python :results table return 1 #+end_src #+NAME: Test [[Test]] - The link becomes invalid because the result block disappears and there will be nothing to refer to. So, you need to keep in mind that naming source block results is not a good idea to start with. They are meant to change as you execute the source block and the fact the your #+name: attribute was not removed when you execute the code block manually is just a coincidence. The right way to reference code blocks would be - #+NAME: Test #+begin_src python :results table return 1 #+end_src #+RESULTS: Test | 1 | [[Test]] - Note that Org automatically assigns the correct name to results. It has different syntax. In summary, there is no _bug_ on Org side here. However, the behavior is indeed not very intuitive. This kind of scenario should probably be added to org-lint, so that users can be warned about assigning attributes to src block results. Best, Ihor
Re: Bug report
Looks like I was trying to be too clever. :) I used org-mode to write the bug report. The problem isn't that the formatting fails in source code blocks. I put it in one so that it would appear verbatim. If you copy the contents of the block into a normal paragraph, you should be able to see the problem. I'm running Emacs 29.0.50 (from git) and org 9.5.3. Sent with Proton Mail secure email. --- Original Message --- On Wednesday, June 1st, 2022 at 6:37 PM, Eric S Fraga wrote: > On Wednesday, 1 Jun 2022 at 07:53, Topi Mäenpää wrote: > > > I have trouble escaping a dollar sign in org-mode documents. I > > tried to enter the following: > > > > #+begin_src > > A (14 G$) B (6 G$) > > #+end_src > > > I have no problem with this. What version of org are you using? > > Out of curiosity, what language is this? I ask because #+begin_src > expects a language argument normally. Otherwise, I would use an example > block, e.g.: > > #+begin_example > A (14 G$) B (6 G$) > #+end_example > > which may also help with your problem. > > -- > : Eric S Fraga, with org release_9.5.3-520-g4dda0d in Emacs 29.0.50
Re: Opening org-cite links with different application
On 01/06/2022 17:33, Alessandro Bertulli wrote: > P.S. Alessandro, could you, please, response to mails using "reply" > button. You messages lack of In-Reply-To and References headers, so at > least thunderbird does not group messages into a thread. Sure, no problem. I usually use vanilla compose-mail to answer, probably that's the problem. I am now trying directly with Gmail, let me know if it's working now. I do not use Emacs as MUA for a couple of reasons, but I am sure that it should be possible to properly reply without switching to web UI. `compose-mail' has an argument that allows to pass extra arguments. Commands like `message-reply' or `rmail-reply' should be more convenient for such purpose.
Re: [PATCH] ox: fix comment exported as a blank line
On 02/06/2022 12:02, Phil Estival wrote:
Still, the writing experience is much improved
when comments are allowed inside paragraphs
without disrupting the publication, and this
definitely worth a few modifications.
There are at least a couple of workarounds for inline comments, however
some care is required to not add a spurious blank line (I think,
ox-latex should strip blank lines from paragraphs).
Maxim Nikulin. Re: Comments break up a paragraph when writing
one-setence-per-line. Sun, 18 Jul 2021 15:21:39 +0700.
https://list.orgmode.org/sd0oak$k5h$1...@ciao.gmane.io
#+macro: comment
Another test
{{{comment(some text
)}}} with macro comment.
or
Export snippets
@@c: a comment
@@ may be used with any non-existing backend name.
I believe that comments breaking paragraphs is an unnecessary pitfall.
While comments are not passed to exporters there are should be no great
problems besides users who rely on current behavior. I am unsure how
many of them do it intentionally. Attributes and other keywords are more
tricky case, but rather independent of comments.
Re: *doc/org-manual.org: Fix the description for "Internal Link" in the org-mode manual
Hi Ihor, Thank you for the investigation, verify insight, I'll avoid this snapshot from my org files. And changing the "CAPTION" to "PROPERTY" in the foot script, is it correctly? Thanks B.R. Lin
[PATCH] org.el: Use `call-process' to launch external viewers (was: Re: [BUG] org-open-file immediately termininates when calling xdg-open that calls emacsclient)
On 27/05/2022 22:18, Ihor Radchenko wrote: Max Nikulin writes: With this exact init.el, trying to run (let ((process-connection-type nil)) (start-process-shell-command "1" nil "xdg-open ~/.bashrc")) Does it mean that you can not reproduce it with emacsclient instead of xdg-open? Anyway I can not reproduce it with Emacs-27.1 from Ubuntu-20.04. I have reported this to Emacs. The more precise steps are in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55672 As expected, nobody wishes to dig into obscure X11 issue. You may try the attached patch. I do not consider it as unambiguous improvement since almost all errors are swallowed due to requirement to interpret viewer command using shell. The same approach settled on `browse-url' after several fixes, but there at least wrong executable name may be reported. I suspect that you faced the bug working on another issue, so you do not really suffer from it.From 01c5625d4c9b47573b1b3c8fb9d5672ff87b6696 Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Thu, 2 Jun 2022 23:55:09 +0700 Subject: [PATCH] org.el: Use `call-process' to launch external viewers lisp/org.el (org-open-file): Another attempt to make launching of viewers more reliable by using approach from `browse-url' with hope to alleviate (bug#55672). Unfortunately any errors are silently ignored. --- lisp/org.el | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 95dff27ad..2cc122f5f 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -8015,16 +8015,19 @@ If the file does not exist, throw an error." (save-window-excursion (message "Running %s...done" cmd) -;; Handlers such as "gio open" and kde-open5 start viewer in background -;; and exit immediately. Use pipe connection type instead of pty to -;; avoid killing children processes with SIGHUP when temporary terminal -;; session is finished. -;; -;; TODO: Once minimum Emacs version is 25.1 or above, consider using -;; the `make-process' invocation from 5db61eb0f929 to get more helpful -;; error messages. -(let ((process-connection-type nil)) - (start-process-shell-command cmd nil cmd)) +;; Handlers such as "gio open" and kde-open5 start viewer in +;; background and exit immediately. As a result +;; `start-shell-process' with default pty +;; `process-connection-type', children processes are killed +;; with SIGHUP when temporary terminal session is finished. +;; Pipe processes have other set of problems, see (bug#55672), +;; (bug#12972) message 47. Shoot and forget method borrowed +;; from `browse-url-xdg-open' has an advantage that launched +;; viewer may run after quitting from Emacs. It is hard to +;; avoid shell here since it is required by mailcap +;; specification, but with shell all errors are silently +;; ignored. +(call-process shell-file-name nil 0 nil shell-command-switch cmd) (and (boundp 'org-wait) (numberp org-wait) (sit-for org-wait ((or (stringp cmd) (eq cmd 'emacs)) -- 2.25.1
Error with org-agenda with 9.5.3
I just updated org-mode using package.el and got release 9.5.3 Now I get an error in `org-at-timestamp-p` (OATP), which is invoked when calling `org-agenda`. I checked the repository and the problem is in commit 1f617727f1, which added to this function the following code block: ``` - (let* ((regexp (if extended - (if (eq extended 'agenda) - org-element--timestamp-regexp - org-ts-regexp3) - org-ts-regexp2)) + (let* ((regexp + (if extended + (if (eq extended 'agenda) + (rx (or (regexp org-ts-regexp3) + (regexp org-element--timestamp-regexp))) + org-ts-regexp3) +org-ts-regexp2)) ``` The issue arises where OATP uses `rx` to process a regex stored in `org-ts-regexp3`: ``` (rx (or (regexp org-ts-regexp3) ; here (regexp org-element--timestamp-regexp))) ``` This fails because `rx-check` checks the sub-expression `(regexp org-ts-regexp3)` to make sure that `org-ts-regexp3` is a string, but `org-ts-regexp3` is not evaluated, and the *symbol* `org-ts-regexp3` is not a string (it's a symbol), even though it's *value* is a string. I'm not sure whether this is a bug in org-mode proper (I would have thought this would be caught before release) or perhaps org-mode expects some version of `rx.el` that I do not have. Unfortunately, I don't see a version number in `rx.el`, only a copyright date. I am running Emacs 25 (Aquamacs). So, maybe this code requires Emacs 26? If so, it would be nice if org-mode 9.5.3 was tagged as incompatible with Emacs 25? (It would also be nice if package mode supported roll-back, but that's OT here!)
Re: Folded headlines with text showing where it shouldn't
On 31 May 2022, Ihor Radchenko wrote: For me, this looks like either a mixed installation (please post the output of M-x org-version) or some third-party package misbehaving. M-x org-version says: Org mode version 9.5.3 (release_9.5.3-511-g8e69ad @ /usr/local/src/org-mode/lisp/) Can you try to open that file from emacs -Q? See https://orgmode.org/manual/Feedback.html It's not just that file, it's been happening recently with almost all my Org files, now and then. I'll try with -Q and work on a file for a while and see if I can recreate the problem. Is there anything from all your excellent folding work that would let me check some value or variable that would be helpful when I see such a problem? Some way of inspecting the state of something that might be useful? Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
[BUG, confirmed] org-clock-in calling org-clock-sum fails leaving incomplete CLOCK line when encountering existing malformed CLOCK lines
Gregor Zattler writes: >>> org-parse-time-string: Not an Org time string: [20zznn22-05-30 Mo 11:34] >>> >>> And then there is a dangling >>> >>> CLOCK: >>> >>> line without timestamps at the expected line in my org file. >>> >>> It took a while till I realized that there was a corrupted >>> timestamp in my org file a few clock lines below. >> >> Could you please create an example file and detail the steps how you got >> the error? > > Please see the attached test.org and call Emacs like so: > > > /usr/local/bin/emacs-29.0.50 -Q -L ~/src/org-mode/lisp /tmp/test.org --eval > '(switch-to-buffer "test.org")' -f org-clock-in Thanks! Confirmed using the described steps. This is an omission in org-clock-sum. When parsing clock lines (which org-clock-sum considers as any line starting from word CLOCK:), org-clock-sum calls org-parse-time-string. The latter throws the error you are seeing. The problem have been present at lest since Org 9.1.9. An easy fix would be catching the error and ignoring erroneous headline. An alternative could be also throwing a warning or more informative error. Another alternative could be using org-element and only parsing real clock objects + adding org-lint checker for malformed clock lines. org-lint checker will be useful in any case though. I do not consider this as a pressing issue, so I am just leaving the possible solutions above. And patches are welcome :) Best, Ihor
Re: *doc/org-manual.org: Fix the description for "Internal Link" in the org-mode manual
Lin Sun writes: > And changing the "CAPTION" to "PROPERTY" in the foot script, is it correctly? > Thanks Adding PROPERTY works by accident. (I am wondering what is the logic behind this idea - there is no meaningful semantic meaning for PROPERTY keyword in this context) When you have - #+begin_src python :results table return 1 #+end_src #+PROPERTY: #+NAME: Test #+RESULTS: |1| [[Test]] - The buffer AST is roughly the following (you can reproduce by calling M-: (org-element-parse-buffer)): (org-data (...) ... (src-block (...)) (keyword (:key "PROPERTY" ...)) (table (:name "Test" :results ""...)) (paragraph (...) (link (... When org-babel searches for results of evaluation, it is looking at the immediate[1] element following the src-block. That element must have :results property (because of #+RESUTLS: affiliated keyword). When you add #+PROPERTY: line in front of the results, you are adding a new keyword element right after the src-block (#+PROPERTY: is not an allowed affiliated keyword and it is thus recognized as an independent element). So, when org-babel tries to search and remove the results of evaluation during export, it is not able to find any because the following element is just a keyword, not an element with :results property. Hence, your export appears to be "fixed". Best, Ihor [1] Strictly speaking, not just immediate. When the src-block has :name property, org-babel searches further for another following element with the same :results property.
Re: Error with org-agenda with 9.5.3
Robert Goldman writes: > I just updated org-mode using package.el and got release 9.5.3 > > Now I get an error in `org-at-timestamp-p` (OATP), which is invoked when > calling `org-agenda`. > ``` > (rx (or (regexp org-ts-regexp3) ; here > (regexp org-element--timestamp-regexp))) > ``` > > I am running Emacs 25 (Aquamacs). So, maybe this code requires Emacs 26? > If so, it would be nice if org-mode 9.5.3 was tagged as incompatible > with Emacs 25? (It would also be nice if package mode supported > roll-back, but that's OT here!) Thanks for reporting! This has been fixed on our bugfix branch, but not yet on ELPA. Bastien, can we bump the Org version to 9.5.4 and trigger ELPA update? You mentioned that Org 9.5.4 is intended for Emacs 28.2, but I don't know any way other than bumping the version to update the package on ELPA stable. Best, Ihor
Re: Folded headlines with text showing where it shouldn't
William Denton writes: >> For me, this looks like either a mixed installation (please post the >> output of M-x org-version) or some third-party package misbehaving. > > M-x org-version says: > > Org mode version 9.5.3 (release_9.5.3-511-g8e69ad @ > /usr/local/src/org-mode/lisp/) Is /usr/local/src/org-mode/lisp/ the folder where you installed the latest Org version? (If not, this is likely the problem or part of the problem). >> Can you try to open that file from emacs -Q? See >> https://orgmode.org/manual/Feedback.html > > It's not just that file, it's been happening recently with almost all my Org > files, now and then. I'll try with -Q and work on a file for a while and see > if > I can recreate the problem. Does it happen with a specific link type? All the links? For context, your problem is certainly not reproducible on my side, so it is likely something about your installation/packages. > Is there anything from all your excellent folding work that would let me > check > some value or variable that would be helpful when I see such a problem? Some > way of inspecting the state of something that might be useful? 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? 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. If you don't have time to dig into the problem, you can also set org-fold-core-style to 'overlays in your config to activate legacy folding support. It will most likely solve the immediate issue on your side and let you work on more pressing things involving your Org workflow. Best, Ihor
