Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

"G. Branden Robinson" writes: >> What about \fC\f[CR]Lorem\fP\fP? > > Unreliable. As onf pointed out, not only is the font selection not > backed up by a stack, but it the identity of "the previous font" is not > well-defined if you attempt to select a non-existent font (as either or > both of `

Re: Add org-src-is-fontify-buffer-p (patch attached)

Eglot was the first request cited. For python programmers that rely on per project/directory-local or per-buffer virtual environment set up, this can be heavier than needed just for fontification. I enable eglot manually, but I do use python virtual environments and would disable initialization in

Re: Add org-src-is-fontify-buffer-p (patch attached)

Yes, could do, and nothing needed by org-mode or markdown-mode. Could also test for buffer-file-name nil. Or test both. Let's recommend that simpler approach and I will rescind my markdown PR in favor of this simpler suggestion. On Sat, Jan 18, 2025 at 6:18 AM Ihor Radchenko wrote: > Ship Mints

Re: Add org-src-is-fontify-buffer-p (patch attached)

Ship Mints writes: > Makes sense. I'm not set up to contribute to WORG, perhaps you can do it, > if you don't mind? I can add it to my todo list. But that means not soon. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org develo

Re: Add org-src-is-fontify-buffer-p (patch attached)

Makes sense. I'm not set up to contribute to WORG, perhaps you can do it, if you don't mind? On Sat, Jan 18, 2025 at 7:39 AM Ihor Radchenko wrote: > Ship Mints writes: > > > This could be added to the org-mode documentation as a hint for those who > > use native fontification. Should I send a p

Re: Add org-src-is-fontify-buffer-p (patch attached)

Jens Schmidt writes: > Um, sorry for butting in, but I also have an interest of recognizing > Org's special source environments, see here: > > https://list.orgmode.org/9eaf7099554d488d921e64c4b2852...@vodafonemail.de/ > > That thread led to nowhere back then, but I think it still makes > sense

Re: Add org-src-is-fontify-buffer-p (patch attached)

On 2025-01-18 12:38, Ihor Radchenko wrote: > Ship Mints writes: > >> Yes, could do, and nothing needed by org-mode or markdown-mode. Could also >> test for buffer-file-name nil. Or test both. Let's recommend that simpler >> approach and I will rescind my markdown PR in favor of this simpler >> s

Re: Add org-src-is-fontify-buffer-p (patch attached)

Indeed if this is a valid use case for buffer identification, the approach in the patch seems trivial (to me, buffer locals are more appropriate than dynamic bindings), if overkill for the purpose I proposed. On Sat, Jan 18, 2025 at 7:16 AM Jens Schmidt wrote: > On 2025-01-18 12:38, Ihor Radche

Re: Add org-src-is-fontify-buffer-p (patch attached)

Ship Mints writes: > This could be added to the org-mode documentation as a hint for those who > use native fontification. Should I send a patch for that or trivial enough > you'd do it, if you agree? I am not sure if this problem is so common that we need to put it into the manual. I think cre

Re: Add org-src-is-fontify-buffer-p (patch attached)

Ship Mints writes: > Eglot was the first request cited. For python programmers that rely on per > project/directory-local or per-buffer virtual environment set up, this can > be heavier than needed just for fontification. I enable eglot manually, but > I do use python virtual environments and wou

Re: Add org-src-is-fontify-buffer-p (patch attached)

Ship Mints writes: > Yes, could do, and nothing needed by org-mode or markdown-mode. Could also > test for buffer-file-name nil. Or test both. Let's recommend that simpler > approach and I will rescind my markdown PR in favor of this simpler > suggestion. Well. Org or markdown should name the bu

Re: Add org-src-is-fontify-buffer-p (patch attached)

For the record, this is what I've recommended and what I will use: (defun my/XXX-mode-hook () (when (or buffer-file-name (not (string-prefix-p " " (buffer-name ;; do something expensive )) On Sat, Jan 18, 2025 at 6:36 AM Ihor Radchenko wrote: > Ship Mints wr

Re: Add org-src-is-fontify-buffer-p (patch attached)

This could be added to the org-mode documentation as a hint for those who use native fontification. Should I send a patch for that or trivial enough you'd do it, if you agree? On Sat, Jan 18, 2025 at 6:54 AM Ship Mints wrote: > For the record, this is what I've recommended and what I will use: >

Re: [BUG] Cannot tangle src block in capture buffer [9.7.6]

I'm still sorting out the copyright assignment, but I have another style question: It feels like I should move the `should' clauses closer to the checks so that I get a more concise report when something is wrong: (ert-deftest test-org-base-buffer-file-name () "Test `org-base-buffer-file-name'.

Re: [BUG] Cannot tangle src block in capture buffer [9.7.6]

Derek Chen-Becker writes: > I'm still sorting out the copyright assignment, but I have another style > question: It feels like I should move the `should' clauses closer to the > checks so that I get a more concise report when something is wrong: > ... > Is that OK? Yes, it is fine. Also, no need

Re: Link preview generation with new link preview property

Ihor Radchenko writes: > Björn Bidar writes: > >>> Both alignment and width are derived from LINK AST node. >>> I am not sure what is the problem. >>> AFAIU, Karthik is simply asking why you decided to calculate alignment >>> from LINK, but not width. >> >> My question was because the width is s

Re: Link preview generation with new link preview property

Björn Bidar writes: >> IMHO, it would be best to pass image file name/raw image data to >> `org-link-preview-image-data', not an image object and call >> `org--create-inline-image' from inside `org-link-preview-image-data'. >> That way, we can automatically obey Org customization wrt image >> ali

Re: New Heading Parsing and org-vcard

Jonas Damm writes: > Reading here: https://orgmode.org/Changes.html makes me believe breaking > changes in orgmode made the seemingly unmaintained org-vcard package not > work anymore. AFAIK, org-vcard is maintained at https://github.com/pinoaffe/org-vcard > So my question is: Can I maybe downg

New Heading Parsing and org-vcard

Reading here: https://orgmode.org/Changes.html makes me believe breaking changes in orgmode made the seemingly unmaintained org-vcard package not work anymore. > Internal structure of Org parse tree has been changed > > The code relying upon the previously used (TYPE PROPERTIES-PLIST > CONTENTS-L

[BUG] org-element-interpret-data does not preserve blank lines after elements

Hello, ``` GNU Emacs 30.0.93 Org mode version 9.7.16 ``` I'm reporting a potential bug in the `org-element-interpret-data` function of Org mode. *Description:* When using `org-element-interpret-data` as the reciprocal of `org-element- parse-buffer`, I've noticed that blank lines before element