Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks

Ihor Radchenko writes: > Commits under similar names are: > > Suhail 96eb9f0b4 * piem/s/org-lint-add-function-to-removeJun6 org-lint: Add > function to remove checker(s) > ... > > I assume that 96eb9f0b4 is yours. > It has 9 LOC. Yes. > ~6LOC remaining until aproximate 15LOC limit we can

Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks

Ihor Radchenko writes: > AFAIU, your main point is that you want the patch to land on bugfix. It > will not, regardless whether we add :textarea support or not. While not the answer I had hoped for, I appreciate the clarification. > Next, if you are not interested in adding :textarea support,

Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks

Ihor Radchenko writes: > Your request, in its core, is asking to make treatment of verbatim > blocks more regular in ox-html. I would phrase it differently. Just to be clear, my concern isn't simply "verbatim blocks", and it isn't simply to make handling "more regular". Apologies for the

Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks

Ihor Radchenko writes: > Please address my concern about :textarea attribute. I do not see why > we should ignore it here. I don't understand your concern. Could you please elaborate on what you mean by "why we should ignore it here"? What is the "it" and what is the "here"? >From your email

Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks

Ihor Radchenko writes: >> Unlike example blocks, source code and fixed-width blocks don't support >> the attr_html keyword. Contrast these outputs: >> ... >> The attached patches are a straight-forward copy-paste of relevant code >> from org-html-example-block. It may be better to refactor

Re: [SUMMARY] #9 [[bbb:OrgMeetup]] on Wed, July 10, 19:00 UTC+3

"Thomas S. Dye" writes: > Aloha Suhail, Aloha! > From my perspective, the quote is confused about the concept of "ownership". > ... > > With the distinction between a right of property and a right of person > in mind, it is clear that FSF does not claim ownership. Thank you for sharing your

Re: [SUMMARY] #9 [[bbb:OrgMeetup]] on Wed, July 10, 19:00 UTC+3

Ihor Radchenko writes: > https://list.orgmode.org/orgmode/87ppydmigz@gmail.com/t/#u Thank you for that reference. I also found a reference on lwn.net: . The article made an interesting observation, and one that I didn't know to be true: #+begin_quote

Re: [SUMMARY] #9 [[bbb:OrgMeetup]] on Wed, July 10, 19:00 UTC+3

Ihor Radchenko writes: > - Aside, built-in ox-odt has quite a history > - Its original author is... (to say) no longer interested to deal > with FSF copyright assignment (it was quite a drama at some point) Out of curiosity, would you happen to have a reference to associated

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

Steven Allen writes: > The concern is that, e.g., there may b a function _marked_ as pure > that's not actually pure, leaks some information, and/or has a > security vulnerability (e.g., a C function exposed to lisp that's > marked as pure but internally has, e.g., a buffer overflow). Are there

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

Ihor Radchenko writes: > Yup. I only meant %(...) placeholder constructs. ("linkkey" > . REPLACE) where REPLACE is a function symbol will still be allowed. Thank you for confirming. Please ignore my previous response. -- Suhail

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

Steven Allen writes: > 1. While this feature no longer invokes completely arbitrary code, it > still allows an attacker to call any function marked as "pure" which > is a pretty large attack surface. I am struggling to assess this, because it's not clear to me what the threat model is. Could

Re: [POLL] Bug of Feature? Attack vector via deceiving link abbrevs

Ihor Radchenko writes: > On the other hand, I can totally see people making use of the current > behavior to have custom filters for existing link types. Yes, I use this currently for redirecting reddit links. It's certainly a feature in my opinion. -- Suhail

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

Ihor Radchenko writes: > If you are actively using #+LINK: keywords with %(...) placeholders or > have any objections to this feature removal, please let us know. I do not actively use this feature, however, removing it seems excessive. IIUC, it's a useful feature in situations when the tag

Re: [POLL] ob-R, ob-julia: Should we force-disable ess-ask-for-ess-directory?

Ihor Radchenko writes: > I'd like to hear from ob-R/ob-julia users whether the current behavior > is something they rely on. It's a (minor) nuisance, but one I'd be happy to have fixed. -- Suhail

[PATCH] [BUG] Support attr_html in source code and fixed-width blocks

Unlike example blocks, source code and fixed-width blocks don't support the attr_html keyword. Contrast these outputs: #+begin_src emacs-lisp :results value replace :wrap src html (require 'org) (require 'ox-html) (org-export-string-as "#+attr_html: :class foo ,#+begin_src sh

Re: ob-shell: possibly missing initiate-session functions?

Ihor Radchenko writes: > Fixed, on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5b366a731 #+begin_src diff (put fname 'definition-name 'org-babel-shell-initialize)) +(let ((fname (intern (concat "org-babel-prep-session:" name + (defalias

Re: ob-shell: possibly missing initiate-session functions?

Matt writes: > I agree, defining an alias within "org-babel-shell-initialize" seems > reasonable. However, it's important that "explicit-shell-file-name" > is set to the appropriate shell name. In your case, I suspect it's a > coincidence that aliasing "org-babel-sh-initiate-session" works. A

Re: ob-shell: async support in "shell" vs "bash"

Matt writes: > :async should work for all shell types. Thank you for confirming the expected behaviour. > Are you finding that it's not? No. However, on language-specific shell code blocks (e.g. "bash") org-lint reports warnings. > Regarding org-babel-header-args,

Feature request: support sessions in ob-emacs-lisp via IELM

IELM (M-x ielm) derives from comint-mode and provides a convenient interactive environment for evaluating lisp expressions. Some of the conveniences such as automatically evaluating expressions can make iterative development easier. Currently, ob-emacs-lisp does not support sessions. It would

[BUG] org-export: incorrect assignment of bind keywords [9.7.3 (9.7.3-2f1844 @ /home/user/.emacs.d/elpa/org-9.7.3/)]

Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list.

ob-shell: possibly missing initiate-session functions?

Currently (Org 9.7.3), org-babel-switch-to-session invokes org-babel-initiate-session which tries to invoke org-babel--initiate-session. On a related note, ob-shell defines org-babel-sh-initiate-session (and uses it within org-babel-execute:shell). However, there are no definitions for

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > Accidentally deleted newline here* Heading 2 Are there situations which result in such accidental newline deletions that are likely to not be immediately caught if not prompted by the checker? Or was the checker added preemptively? Perhaps the checker should simply be

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Suhail Singh writes: > Ihor Radchenko writes: > >> Oops. >> I amended the fix now. >> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6c862699a > > It's better, but not quite there. For instance, tangle the block below > into an org file

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > Oops. > I amended the fix now. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6c862699a It's better, but not quite there. For instance, tangle the block below into an org file and observe the reported warning. #+begin_src org :tangle

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > "Suhail Singh" writes: > >> When there is, say, an "example" result block that is indented (i.e., >> the entire block including the delimiters is indented) and it contains >> some asterisks in the middle, org-lint consid

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > Indeed. But I wanted to nudge you to do a bit better :) "Better" here is subjective and we have a difference in opinion, which is okay. While I am not motivated to submit such an alternative patch, I also am not aware of any common usecases that would become much more

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > This would work, but it modifies the checker list destructively. Yes, as does org-lint-add-checker. In the same vein, org-lint-remove-checker is intended to be able to undo the "effect" of one or more org-lint-add-checker invocations. > What about introducing some

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > There is currently no such way. Although, it would be nice to have such > a feature. Patches welcome! See attached. >From 7d7a240d82202fcb3323453648dd2d8b78d22a6f Mon Sep 17 00:00:00 2001 From: Suhail Date: Wed, 5 Jun 2024 11:55:10 -0400 Subject: [PATCH] org-lint: Add

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > Org mode has no idea which languages are intended to be executed, but > happen to not have their ob-lang.el backend loaded; and which > languages do not need execution. So, Org mode warns just in case. If the primary function of this check is to ensure that the user

[BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list.

[BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list.

Re: naming: Re: Experimental public branch for inline special blocks

Suhail Singh writes: > ... due to the similarity with "inline code blocks" (cf. "code > blocks") as well as "special blocks". .. due to the /relation/ with "inline code blocks" (cf. "code blocks") as well as "special blocks". &

Re: naming: Re: Experimental public branch for inline special blocks

Ihor Radchenko writes: > In my mind, "fragment" implies no nesting. FWIW, in the mind of this Org mode user as well. > But the point of the "inline special blocks" is to allow nesting as > needed. Yes, exactly! As "inline code blocks" are to "code blocks" so too are "inline special blocks"

Re: [proof of concept] inline language blocks

Juan Manuel Macías writes: > As I already said, in my local branch I have both elements created, > based on the same syntax: > > - language block: :lang{text} > > - special block {text} Why not &:lang{text} (and/or &:lang[options]{text}) instead? In fact, it might help (in that it may reduce

Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated

Ihor Radchenko writes: > Max Nikulin writes: > >> https://list.orgmode.org/87bl21vazj@posteo.net >> >> Likely should be modified a bit to support derived backends. > > I think we do not do this in any of the examples for :export link > property in WORG. I am actually not sure how to update

[BUG] M-x org-lint gives spurious warning when file contains a link with percent-encoded url [9.6.13 ( @ /home/user/.emacs.d/elpa/org-9.6.13/)]

Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list.

Re: [FR] A more general case than footnotes

Karl Fogel writes: > My original announcement post from a year ago [2] is a good place to get a > quick > overview of how oref.el works. > > ... > > [2] https://lists.gnu.org/archive/html/emacs-humanities/2022-10/msg9.html >From [2]: > Thus, in "jones-interview.org" you might have this: >

Re: What is the purpose of \\ in org-add-note?

Karthik Chikmagalur writes: > When I add a note to an entry (from Org agenda, say), it adds a \\ at > the end of the note line heading. > > What is its purpose? It ensures a line break (say, when the document is exported). From the [[info:org#Paragraphs][org#Paragraphs]] section in the manual:

Re: [FR] Make notion of "modification time" configurable during publishing

Ihor Radchenko writes: > But do you actually use one but not other in practice? As in, could users have a preference for one vs the other in practice? Yes, since the choice isn't without consequence, it's conceivable (generally speaking) that some would prefer one over the other. FWIW, in my

Re: [FR] Make notion of "modification time" configurable during publishing

Ihor Radchenko writes: > I am a bit confused. What do you mean by "git author date" and "git > commit date"? In the output of `git log --pretty=fuller`, there is AuthorDate which is distinct from CommitDate. In case unfamiliar, an elaboration on the distinction:

[FR] Make notion of "modification time" configurable during publishing

Ihor Radchenko writes: > - weary-traveler asked to add a new feature to Org publishing system. > > The use case is publishing using CI tasks, where a new, fresh image > is created every time a website is re-published. Such image does > not preserve the original modification times of the