Re: [PATCH] org-lint: Fix invocation with C-u prefix argument
Nick Dokos writes: > `C-u M-x org-lint' was failing to run any checkers, no matter what > category was chosen, because the calculation of the list of checkers > always returned `nil'. LGTM! Is there any reason you did not push the patch upstream yourself? Best, Ihor
Re: [PATCH] ox: fix comment exported as a blank line
Le 01/06/2022 à 13:48, Max Nikulin wrote : On 01/06/2022 12:30, Phil Estival wrote: * lisp/ox.el (org-export--skip-p): no longer export single-line comments as blank lines which did break paragraphs in two. unfortunately, you took a wrong direction If you are interested in other cases when org paragraph is not the same as exported LaTeX one, see the following thread: Max Nikulin. Comments break up a paragraph when writing one-setence-per-line. Sun, 3 Oct 2021 18:34:10 +0700. https://list.orgmode.org/sjc4fk$76r$1...@ciao.gmane.io Max, Right, thanks for the clarifications. A hook at pre-export stage to filter out the line-comments is one correct way to get an output compliant with different backends. Yet the removal of comments may provide an AST different from the one of the emacs buffer. >> However there [are] users in this thread who >> expect that "# " or "#+latex:" should not be >> "element" and should be a part of surrounding >> paragraph. That's an interesting idea. This would add an attribute to the previous element. If we keep speculating on that, the rendering path would change. It would have to consider this property too when showing or hiding elements. And it would require additional function to reallocate this attribute like a node. And this would probably break some conceptual integrity. The org spec is correct to handle the comments the way it does. As I see it now, that's the only possible attempts to reconcile the behaviors of different backends. Still, the writing experience is much improved when comments are allowed inside paragraphs without disrupting the publication, and this definitely worth a few modifications. Phil
Re: [BUG] org-element--cache: Unregistered buffer [9.5.3 (9.5.3-g4dda0d @ c:/Users/scott/.emacs.d/straight/build/org/)]
Scott Otterson writes: > With straight.el, it's Org mode version 9.5.3. > > If I open the file with emacs -Q, I'm surprised to see that I get a > different warning message: > > File mode specification error: (void-variable org-fold-core-style) > > This is on emacs 28.1, which uses Org mode version 9.5.2 Clearly, something is strange on your side. Does the same happens on other Org files with emacs -Q? If not, is there anything like buffer-local of directory-local settings that might trigger the error? (there should not be, unless you somehow set them by yourself - Org should not touch these settings) Best, Ihor
Re: Allow Currency Symbols and Grouping Commas in Table Numbers
"Daniel E. Doherty" writes: > Again, thanks for your thoughts. All, however, ruin the look of the > tables. Could you, perhaps, point me to where in the vast org code, > strings are converted to numbers in preparation for sending to calc? org-table-eval-formula could be a good starting point to look into. Best, Ihor
[PATCH] org-lint: Fix invocation with C-u prefix argument
`C-u M-x org-lint' was failing to run any checkers, no matter what category was chosen, because the calculation of the list of checkers always returned `nil'. >From b55162adf1250980ad0f42423832aa1aa1045d30 Mon Sep 17 00:00:00 2001 From: Nick Dokos Date: Wed, 1 Jun 2022 12:28:23 -0400 Subject: [PATCH] org-lint: Fix invocation with C-u prefix argument * lisp/org-lint.el (org-lint): Fix the order of the arguments in the `assoc-string' call when calculating the list of checkers to invoke. `C-u M-x org-lint' was failing to run any checkers, no matter what category of checkers was chosen, because the calculation of the list of checkers always returned `nil'. --- lisp/org-lint.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-lint.el b/lisp/org-lint.el index cce6fddbd..62a245330 100644 --- a/lisp/org-lint.el +++ b/lisp/org-lint.el @@ -321,7 +321,7 @@ ARG can also be a list of checker names, as symbols, to run." nil t))) (cl-remove-if-not (lambda (c) - (assoc-string (org-lint-checker-categories c) category)) + (assoc-string category (org-lint-checker-categories c))) org-lint--checkers))) (`(16) (list -- 2.34.1 -- Nick
Re: Bug report
On Wednesday, 1 Jun 2022 at 23:24, Max Nikulin wrote: > > I think, it is org and #+begin_src is used to demonstrate a snippet of > org markup, so to reproduce the problem try it in a regular paragraph. Ah, sorry, missed the point entirely! -- : Eric S Fraga, with org release_9.5.3-520-g4dda0d in Emacs 29.0.50
Re: Bug report
On 01/06/2022 22:37, 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 You may use entities: \dollar 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 I think, it is org and #+begin_src is used to demonstrate a snippet of org markup, so to reproduce the problem try it in a regular paragraph.
Re: Bug report
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: [BUG] org-element-warnings when accidentially inserting "z" into timestamp [9.5.3 (release_9.5.3-471-gebbef7.dirty @ /home/grfz/src/org-mode/lisp/)]
Hi Ihor, * Ihor Radchenko [2022-05-31; 13:01]: > Gregor Zattler writes: > >> Now I realized, that even after quitting and restarting >> Emacs, I cannot insert a timestamp, I get the following >> error message: >> >> 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. >> >> It would be helpful, if the message contained the file name >> and probably even the line number. > > 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 test.org Description: application/org Thanks for looking into this. Ciao; Gregor
Bug report
* Bug report 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 This may look weird to an American viewer, but in Finland we place all units (including monetary units) after the quantity. Anyhow, org-mode interprets this as follows: #+begin_src A (14 G) B (6 G) #+end_src This is the documented behavior: single '$' characters are treated as math delimiters if 1. the enclosed text contains at most two line breaks (there are none). 2. the enclosed text is directly attached to the '$' characters with no whitespace in between (it is). 3. the closing '$' is followed by a whitespace, punctuation or a dash (it is). The standard trick of adding a zero-width space (``) after the first '$' (breaking rule 2 above) doesn't however work as expected: #+begin_src A (14 G$) B (6 G$) #+end_src is rendered as #+begin_src A (14 G) B (6 G$) #+end_src Changing the zero-width space to a visible space fixes the interpretation, but also visually moves the closing parenthesis. I believe zero-width space is incorrectly interpreted as a non-whitespace here. It does not seem to be an exporter bug as both LaTeX and HTML exporters are affected. Thanks, Topi
Re: [PATCH] Re: tangle option to not write a file with same contents?
Ihor, > The patch is attached. great -- thanks very much! this will be very helpful. cheers, Greg
Re: [PATCH] ox: fix comment exported as a blank line
On Wed, Jun 1, 2022 at 1:32 AM Phil Estival wrote: > > > * lisp/ox.el (org-export--skip-p): no longer export single-line > comments as blank lines which did break paragraphs in two. This is a pretty big breaking change. In your next PATCH email, I see that you are also modifying the test that ensures that a comment line gets parsed as a paragraph break.
Re: Emacs launched from Firefox
On 26/05/2022 09:59, Ihor Radchenko wrote: Samuel Wales writes: so idk why ff makes emacs not load .emacs or does an xterm. /usr/bin/emacs results in indeed emacs25 atm. Since you have not found a way to reproduce the issue in a month, I assume that you do not severely suffer from the problem. gnome and kde are too heavy for my computer, and they can't do everything fluxbox can, and fluxbox mostly wfm. An advantage of KDE is that with some tuning it may be made more lightweight, while Gnome is less configurable. I do not consider a 8 year old laptop with i5 CPU and integrated graphics adapter as a high performance unit (it never was it). While Gnome makes the fan annoyingly noisy, there is no such problem in KDE with disabled desktop effects. I admit that the laptop is neither a low end one, and I was lucky with a Chinese SSD put into modem slot, the cost of upgrade was less than $100 and it improved startup time significantly. Maybe you are overestimating hardware requirements of desktop environments. While sometimes it is hard to control precise behavior of DE, some features (hard to configure from scratch) works out of the box, so it is a trade-off. You may find https://wiki.gentoo.org/wiki/Default_applications useful. I also don't use desktop environment and had to setup defaults manually. I can not say that this page is enlightening. In particular I do not like that it does not describe mimeapps.list files in more details. Various tool actually update this file. I have not summarized my bookmarks and notes on MIME and scheme handlers, but the following link may be useful even when gnome specific stuff is ignored: https://help.gnome.org/admin/system-admin-guide/stable/mime-types-custom-user.html.en
Re: [PATCH] ox: fix comment exported as a blank line
On 01/06/2022 12:30, Phil Estival wrote: * lisp/ox.el (org-export--skip-p): no longer export single-line comments as blank lines which did break paragraphs in two. Phil, thank you for your attempt to improve handling of paragraph during export, there are enough various gotchas. Are the purpose of your patch the following? #+begin_src elisp (org-export-string-as "Line 1.\n# comment\nLine 2." 'latex t) #+end_src #+RESULTS: : Line 1. : Line 2. If so, unfortunately, you took a wrong direction, consider #+begin_src elisp (org-export-string-as "Paragraph 1.\n# comment\nParagraph 2." 'html t) #+end_src #+RESULTS: : : Paragraph 1. : : : Paragraph 2. So there are still 2 separate paragraphs. It is necessary to either modify org-element parser or to apply a filter before passing AST to exporters. Last time it was discussed in Ihor Radchenko. Merging paragraphs separated by comment lines during export (was: About 'inline special blocks') Thu, 26 May 2022 10:54:34 +0800. https://list.orgmode.org/875ylt6m1h.fsf@localhost Notice that accordingly to https://orgmode.org/worg/dev/org-syntax.html comment (that is "element") can not be a part of a paragraph. So current behavior is intentional. In your next patch fixing a test "Para1" and "Para2" are meaningful names assuming paragraphs. If behavior is changed "Line1" and "Line2" should be less confusing. If you are interested in other cases when org paragraph is not the same as exported LaTeX one, see the following thread: Max Nikulin. Comments break up a paragraph when writing one-setence-per-line. Sun, 3 Oct 2021 18:34:10 +0700. https://list.orgmode.org/sjc4fk$76r$1...@ciao.gmane.io
Re: Opening org-cite links with different application
> 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. As I wrote in a previous answer, right now I simply set up Citar to use Sioyek by default: (setq citar-file-open-function '(lambda (file) (call-process "sioyek" nil 0 nil file))) This is not a problem since, when opening a citation, I would most likely want to use Sioyek for it. However, you gave me nice ideas to further explore. I'll have a look at mailcap and see if the script is worth being set up. I'll let you know if I discover something useful! In any case, thanks for your answer! Alessandro
