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

[Suhail Singh]

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 accept without
> copyright assignment.

Noted, thanks.  With comments, documentation etc. this will go over the
limit, so I won't be sending any revisions to the patch.

>> 2. When implementing such refactoring changes, which lines are counted?
>
> More or less all lines, except things like blank lines, query replace,
> or copy-pasted code (or, in other words, trivial changes)

Understood.

>> From a feasibility perspective, I suspect it might be better for you (or
>> someone else who's signed the FSF copyright assignment paperwork) to
>> take on the work of applying changes that are similar in spirit to the
>> patch.
>
> Maybe, but that's a subject of my time and priorities.
> This particular bug/feature request will not be high in the priority
> list. Unless we get more users jumping to this thread and asking for
> #+ATTR_HTML support.

Understandable.

-- 
Suhail

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

[Suhail Singh]

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, it is
> OK. Adding #+ATTR_HTML support for code blocks and fixed width elements
> will still be a welcome improvement (I was just hoping to push you to
> contribute a bit more ;))
>
> Now, back to your original patch.
> May you please factor out adding attributes into a separate function, so
> that we avoid duplicating the code? And please announce the change in
> the news - people aware of the current behavior might need to know about
> the change.

Given that I already have some contributions in Org mode and I don't, at
present, intend to do the copyright assignment to FSF, could you please
confirm:

1. How many lines worth of changes I can still introduce without going
   over the limit?

2. When implementing such refactoring changes, which lines are counted?

>From a feasibility perspective, I suspect it might be better for you (or
someone else who's signed the FSF copyright assignment paperwork) to
take on the work of applying changes that are similar in spirit to the
patch.

-- 
Suhail

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

[Suhail Singh]

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
innacuracy in the subject line which may have led to the confusion.

My concern is that when exporting to HTML, for some HTML elements that
are generated there is no straightforward way to add HTML attributes
(e.g. "class", "style" etc).  It is the inability to do so for some AST
nodes that I consider a bug.  Importantly, my concern isn't the handling
of things that are NOT HTML attributes such as `:textarea'.  Also,
notably, my concern extends to possibly other blocks that aren't
verbatim that lack the appropriate handling of #+ATTR_HTML keyword.

> So, if we start allowing arbitrary attributes in more blocks, may as
> well include specially handled attributes like :textarea.

Yes, it is possible to address my concern while also extending support
for non-HTML attributes like :textarea.  However, they still are
distinct things.  For instance, it's possible that extending support for
:textarea is considered a feature request (as opposed to a bug), and
thus that support is added to the main branch as opposed to bugfix.

> As a bonus, it will be possible to factor out common code handling
> attributes (including :textarea) into a new internal function that can
> then be reused.

No disagreement here.

> Yup. But since you are asking to add new features to ox-html, we may
> as well do it in full (support all attributes, including special
> attributes).

I believe, that's perhaps the core of the disagreement.  To me the
request isn't about adding new features (though it's /related/ to a more
general feature request that you seem to be considering), but about
resolving what I consider a buggy behaviour.

>> Additionally, I consider the absence of such support to be a bug.
>
> Since we do not promise it anywhere, it is not necessarily a bug.

We also don't, as far as I am aware, mention that support for
#+ATTR_HTML is ONLY available for some AST nodes and NOT others.  Given
that for the treatment of :textarea we are very clear on this point, the
fact that we don't for #+ATTR_HTML suggested to me that this was a bug.
I suppose it's debatable, however, whether it's a bug in the
documentation or the code.  But, given most (all?) HTML elements support
attributes, it would be odd if the intent of ox-html was to provide a
way to support it via #+ATTR_HTML while simultaneously /intentionally/
restricting its use to only a few nodes. Since `:textarea' is a "custom"
attribute with special signifance, it makes sense that support for it
may be limited in scope.

Do you still consider this to be a feature request instead of a bug?

-- 
Suhail

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

[Suhail Singh]

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 on 18th June:

> I am not sure if we want to add all the attributes to every transcoded
> element. At least in some cases, we do discard them
> (`org-html--textarea-block').

>From the manual:

#+CAPTION: [[info:org#Text areas in HTML export][org#Text areas in HTML export]]
#+begin_quote
 The HTML export backend can create such text areas.  It requires an
  ‘#+ATTR_HTML’ line as shown in the example below with the ‘:textarea’
  option.  This must be followed by either an example or a source code
  block.  Other Org block types do not honor the ‘:textarea’ option.
#+end_quote

The current processing of :textarea does special handling for width and
height attributes and discards the rest (based on my understanding of
the code in `org-html--textarea-block').  Said support for :textarea
attribute exists in `org-html-src-block' and `org-html-example-block'
which is consistent with the manual.

The patches I shared did not interfere with the handling of :textarea in
the blocks that support it.

In order to make the code more robust, one may wish to remove :textarea
from the list of attributes (or issue a user-error or warning if it's
present) in blocks that were never intended to support it (such as
`org-html-fixed-width').  I do not have any opinion on this matter.

Similarly, one may wish to add additional error checking based on the
specifics of the transcoded element.  I do not believe this to be
worthwhile (HTML validation often has errors, and if a user is so
interested they always have the option of validating the generated
HTML).

There is an open question regarding what attributes to support in
`org-html--textarea-block' (i.e., in the presence of `:textarea'
option).  I believe the "correct" thing would be to filter out `:width'
and `:height' (since, if present, they are translated into `rows' and
`cols' attributes in the generated HTML) and include the rest "as is" in
the generated HTML

Regardless of the specifics above regd. :textarea, I believe support for
#+ATTR_HTML ought to be added for most blocks to allow for CSS class
and/or inline style to be specified when exporting to HTML.
Additionally, I consider the absence of such support to be a bug.

-- 
Suhail

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

[Suhail Singh]

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 this logic
>> and ensure that it is applied on all relevant AST nodes (others are
>> probably affected as well).
>
> Sounds reasonable.
> Timothy, may you have a look?

Any updates on this?

-- 
Suhail

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

[Suhail Singh]

"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 thoughts.  I am not a lawyer, but I agree
with your assessment.

Regardless, the copyright holder does enjoy some rights.  For instance,
the right to publish (at least in some jurisdictions).  The fact that
such rights aren't simply restricted to code that has been merged into
the VCS or shared over a mailing list etc., but also extend to code that
may have never been publicly shared was surprising to me.

-- 
Suhail

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

[Suhail Singh]

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
  But anybody who has signed such agreement might want to be aware that
  the FSF thinks it owns their changes, regardless of whether they have
  been publicly posted or explicitly submitted for inclusion. One could
  argue that entirely private changes made by a signatory to that
  agreement are, despite being seen by nobody else, owned by the
  FSF. Even an entirely separate function written in Emacs Lisp —
  something which is not necessarily a derived work based on Emacs and
  which thus might not be required to be distributed under the GPL —
  might be subject to a claim of ownership by the FSF, at least until
  Richard has a chance to "think about" the situation. That may be a bit
  more than some signatories thought they were agreeing to.
#+end_quote

This may be off-topic, but I figured readers of this mailing list might
find the above interesting (assuming it is still FSF's stance on the
topic).

-- 
Suhail

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

[Suhail Singh]

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
discussion in case it happened on a public mailing list?  I am curious
as to the reasons.

>   - Oh well. ~org-sbe~ is a hack (on top of
> ~org-babel-execute-src-block~) in reality and not a properly
> designed API
>   - One day we need to implement something better
>   - Patches welcome! At least, it is a good idea to start a discussion
> on the mailing list. See https://orgmode.org/manual/Feedback.html#Feedback

Could you please elaborate on what about ~org-sbe~ makes it a "hack"?
On a related note, what would "something better" look like?

-- 
Suhail

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

[Suhail Singh]

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 any functions marked as pure, by default?

> 1. Allow them in both #+LINK: lines and the global
> org-link-abbrev-alist.
>
> 2. Allow them in org-link-abbrev-alist only.
>
> 3. Remove them entirely.

If no functions are marked as pure by default, 1 seems reasonable to me.
If some functions are marked as pure by default (by Emacs / Org mode),
then 2 seems reasonable.  I believe 3 is excessive.

-- 
Suhail

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

[Suhail Singh]

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

[Suhail Singh]

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 you please elaborate?  How are the attacker and
potential victim interacting; what is the attack vector(s); who are the
threat agents and what is their goal that we are trying to guard
against, etc?

> You can, of course, write that function; but then you might as well
> use org-link-abbrev-alist instead of defining a local #+LINK.

Perhaps I misunderstood, I thought the thing being polled was whether or
not to allow org-link-abbrev-alist to have REPLACE (per its docstring)
be a function.  I.e., if %(my-function) is removed, so too would the
ability to have a function in the REPLACE position in
org-link-abbrev-alist.  Did I misunderstand?

-- 
Suhail

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

[Suhail Singh]

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

[Suhail Singh]

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 may
require deterministic, yet non-trivial manipulation.  The current
mechanism of restricting this to functions marked safe by user seems
sufficient.

Am I missing something?  Is the threat model such that it can only be
adequately addressed by removing the feature altogether?

-- 
Suhail

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

[Suhail Singh]

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

[Suhail Singh]

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 :exports code
pwd
  ,#+end_src"
   'html t)
#+end_src

#+RESULTS:
#+begin_src html

pwd


#+end_src

#+begin_src emacs-lisp :results value replace :wrap src html
  (require 'org)
  (require 'ox-html)

  (org-export-string-as
   "#+attr_html: :class foo
  ,#+RESULTS:
  : blah"
   'html t)
#+end_src

#+RESULTS:
#+begin_src html

blah

#+end_src


With the output for example blocks:

#+begin_src emacs-lisp :results value replace :wrap src html
  (require 'org)
  (require 'ox-html)

  (org-export-string-as
   "#+attr_html: :class foo
  ,#+begin_example
hello world!
  ,#+end_example"
   'html t)
#+end_src

#+RESULTS:
#+begin_src html

hello world!

#+end_src


The attached patches are a straight-forward copy-paste of relevant code
from org-html-example-block.  It may be better to refactor this logic
and ensure that it is applied on all relevant AST nodes (others are
probably affected as well).

>From 7a61bb6a7c7e1122199232a1c01885fb270dd370 Mon Sep 17 00:00:00 2001
From: Suhail 
Date: Mon, 17 Jun 2024 21:04:18 -0400
Subject: [PATCH 1/2] ox-html: Add support for attr_html for source code blocks

* lisp/ox-html.el (org-html-src-block): Handle attr_html in a manner
similar to example blocks.

TINYCHANGE
---
 lisp/ox-html.el | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index d1687cf5a..675d85ffe 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -3667,14 +3667,24 @@ (defun org-html-src-block
 contextual information."
   (if (org-export-read-attribute :attr_html src-block :textarea)
   (org-html--textarea-block src-block)
-(let* ((lang (org-element-property :language src-block))
+(let* ((attributes (org-export-read-attribute :attr_html src-block))
+   (lang (org-element-property :language src-block))
 	   (code (org-html-format-code src-block info))
 	   (label (let ((lbl (org-html--reference src-block info t)))
 		(if lbl (format " id=\"%s\"" lbl) "")))
 	   (klipsify  (and  (plist-get info :html-klipsify-src)
 (member lang '("javascript" "js"
 	   "ruby" "scheme" "clojure" "php" "html")
-  (format "\n%s%s\n"
+  (if-let ((class-val (plist-get attributes :class)))
+  (setq attributes (plist-put attributes :class (concat "org-src-container " class-val)))
+(setq attributes (plist-put attributes :class "org-src-container")))
+  (format "\n%s%s\n"
+  (let* ((reference (org-html--reference src-block info))
+		 (a (org-html--make-attribute-string
+			 (if (or (not reference) (plist-member attributes :id))
+			 attributes
+			   (plist-put attributes :id reference)
+		(if (org-string-nw-p a) (concat " " a) ""))
 	  ;; Build caption.
 	  (let ((caption (org-export-get-caption src-block)))
 		(if (not caption) ""
-- 
2.45.2

>From 5d4fa5c3e0a7933d10d8f1ece3e368d35e4838ad Mon Sep 17 00:00:00 2001
From: Suhail 
Date: Mon, 17 Jun 2024 22:00:35 -0400
Subject: [PATCH 2/2] ox-html: Add support for attr_html in fixed-width blocks

* lisp/ox-html.el (org-html-fixed-width): Handle attr_html in a manner
similar to example blocks.

TINYCHANGE
---
 lisp/ox-html.el | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 675d85ffe..848017f1d 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2728,13 +2728,23 @@ (defun org-html-export-block
 
  Fixed Width
 
-(defun org-html-fixed-width (fixed-width _contents _info)
+(defun org-html-fixed-width (fixed-width _contents info)
   "Transcode a FIXED-WIDTH element from Org to HTML.
 CONTENTS is nil.  INFO is a plist holding contextual information."
-  (format "\n%s"
-	  (org-html-do-format-code
-	   (org-remove-indentation
-	(org-element-property :value fixed-width)
+  (let ((attributes (org-export-read-attribute :attr_html fixed-width)))
+(if-let ((class-val (plist-get attributes :class)))
+(setq attributes (plist-put attributes :class (concat "example " class-val)))
+  (setq attributes (plist-put attributes :class "example")))
+(format "\n%s"
+(let* ((reference (org-html--reference fixed-width info))
+		   (a (org-html--make-attribute-string
+		   (if (or (not reference) (plist-member attributes :id))
+			   attributes
+			 (plist-put attributes :id reference)
+	  (if (org-string-nw-p a) (concat " " a) ""))
+	(org-html-do-format-code
+	 (org-remove-indentation
+	  (org-element-property :value fixed-width))
 
  Footnote Reference
 
-- 
2.45.2



Suhail (2):
  ox-html: Add support for attr_html for source code blocks
  ox-html: Add support for attr_html in 

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

[Suhail Singh]

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 fname
  +(lambda (session params)
  +   (:documentation
  +   (format "Prepare %s SESSION according to the header arguments 
specified in PARAMS." name))
  +   (let ((explicit-shell-file-name name)
  +(shell-file-name name))
  + (org-babel-prep-session:shell session params
  +  (put fname 'definition-name 'org-babel-shell-initialize))
  +(let ((fname (intern (format "org-babel-%s-initiate-session" name
  +  (defalias fname
  +(lambda (session _params)
  +   (:documentation
  +   (format "Initiate %s session named SESSION." name))
  +   (let ((explicit-shell-file-name name)
  +(shell-file-name name))
  + (org-babel-sh-initiate-session session
  +  (put fname 'definition-name 'org-babel-shell-initialize))
#+end_src

Am I mistaken, or does something still need to be done about
org-babel-shell-initiate-session ?

-- 
Suhail

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

[Suhail Singh]

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
> "shell" block defaults to "explicit-shell-file-name".  This, I
> suspect, is "bash" in your case, yet may be something different on
> another system.

In my case, explicit-shell-file-name has the default value of nil.
However, shell-file-name (which is initialized from $SHELL) is
"/bin/bash".

> The alias would need to close over "explicit-shell-file-name" like is
> done with "org-babel-execute:name".

And what should be done in the case of org-babel-shell-initiate-session?
Should shell-file-name and explicit-shell-file-name remain unaltered
from their existing settings in that case?

I'm happy to send a patch, though it may be simpler for you to do so
yourself in case you have write-access.  Please let me know.

-- 
Suhail

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

[Suhail Singh]

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, "org-babel-header-args:shell" is
> explicitly set to '((async . ((yes no, it seems, to quiet the
> linter

Indeed, it does.  For "shell" source blocks, but not for specific
language blocks such as "bash".

> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=40d1352b

I believe there's a bug in that commit.  Specifically, the commit
message states:

#+begin_quote
  Propagate base `org-babel-header-args:shell'
  to`org-babel-header-args:'.
#+end_quote

However, the code initializes org-babel-header-args: to nil,
instead.

> For other languages, such as "org-babel-header-args:bash", it's set to
> nil.  AFAICT, what you see are simply the default values.

Indeed.  It seems to me that the appropriate default for
org-babel-header-args: should be the same as that for
org-babel-header-args:shell , yet it's not.

> I'm curious, what caused you to notice this inconsistency?

Org-lint (in my specific case, I have it configured to run on save via
flycheck).

-- 
Suhail

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

[Suhail Singh]

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 be nice if
support of sessions was added to ob-emacs-lisp such that the session
buffer is an ielm-mode buffer.

-- 
Suhail

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

[Suhail Singh]

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.


In Org 9.7.3, the variables bound using the =#+BIND= keyword have values that
are nested.  E.g., when a string value is provided, the value actually gets set
to a singleton list containing said string.  This can be observed using the
snippet:

#+name: bugs/org/9.7/bind-vars
#+header: :tangle /tmp/ox-bind-variable-mre.el
#+begin_src emacs-lisp :lexical t
  ;; -*- lexical-binding: t; no-byte-compile: nil; -*-

  (require 'ox)
  (require 'ox-org)

  (let ((org-export-allow-bind-keywords t)
(org-confirm-babel-evaluate nil))
(princ (format "%s\n" (org-version)))
(princ (format "%s"
   (org-export-string-as "#+BIND: my/bug/ox/foo \"foo\"
  ,#+BIND: my/bug/ox/bar

  ,#+begin_src emacs-lisp :exports results :results output
(princ (format \"%s = '%s' :: %s\n\" \"my/bug/ox/foo\" my/bug/ox/foo 
(type-of my/bug/ox/foo)))
(princ (format \"%s = '%s' :: %s\n\" \"my/bug/ox/bar\" my/bug/ox/bar 
(type-of my/bug/ox/bar)))
  ,#+end_src"
 'org
 t
#+end_src

#+RESULTS: bugs/org/9.7/bind-vars
: #+bind: my/bug/ox/foo "foo"
: #+bind: my/bug/ox/bar
: 
: #+results: 
: : my/bug/ox/foo = '(foo)' :: cons
: : my/bug/ox/bar = 'nil' :: symbol

The bug is in the definition of ~org-export--set-variables~.  By fixing the
issue in ~org-export--set-variables~ we get the expected values set:

#+begin_src emacs-lisp :lexical t :noweb yes
  ;; -*- lexical-binding: t; no-byte-compile: nil; -*-
  (require 'org)
  (require 'ox)

  (defun org-export--set-variables (variable-alist)
"Set buffer-local variables according to VARIABLE-ALIST in current buffer."
(pcase-dolist (`(,var . ,val) variable-alist)
  (set (make-local-variable var) (car val

  <>
#+end_src

#+RESULTS:
: #+bind: my/bug/ox/foo "foo"
: #+bind: my/bug/ox/bar
: 
: #+results: 
: : my/bug/ox/foo = 'foo' :: string
: : my/bug/ox/bar = 'nil' :: symbol


The patch is attached below.
>From c92105507d97159a7ba7c1af02c4a3a517ccdf6a Mon Sep 17 00:00:00 2001
From: Suhail 
Date: Tue, 11 Jun 2024 20:05:22 -0400
Subject: [PATCH] org-export: Fix assignment of bind keywords

* lisp/ox.el (org-export--set-variables): The value of the variable
corresponds to the cadr of the entry and not the cdr.

TINYCHANGE
---
 lisp/ox.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 1c52ca290..f8a763bc7 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2585,7 +2585,7 @@ (defun org-export-install-filters
 (defun org-export--set-variables (variable-alist)
   "Set buffer-local variables according to VARIABLE-ALIST in current buffer."
   (pcase-dolist (`(,var . ,val) variable-alist)
-(set (make-local-variable var) val)))
+(set (make-local-variable var) (car val
 
 (cl-defun org-export-copy-buffer ( to-buffer drop-visibility
drop-narrowing drop-contents

base-commit: 3e4c89e55649f95cffbf70fcf64dcbc69760f96f
-- 
2.45.2



Emacs  : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41, 
cairo version 1.18.0)
Package: Org mode version 9.7.3 (9.7.3-2f1844 @ 
/home/user/.emacs.d/elpa/org-9.7.3/)

-- 
Suhail

ob-shell: possibly missing initiate-session functions?

[Suhail Singh]

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 org-babel-shell-initiate-session
nor org-babel-bash-initiate-session etc.  This means that trying to use
org-metadown (which invokes org-babel-switch-to-session) on shell and
bash language session blocks results in the following errors
respectively:

#+begin_comment
  org-babel-initiate-session: No org-babel-initiate-session function for shell!
  org-babel-initiate-session: No org-babel-initiate-session function for bash!
#+end_comment

Is this a bug?  If so, does org-babel-shell-initialize need to be
patched to set up function aliases pointing to
org-babel-sh-initiate-session ?

FWIW, I have been using such aliases in my personal config for bash and
shell language blocks and they seem to behave as expected.

-- 
Suhail

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]

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 limited to headline, paragraph and
select other node types where an asterisk could not occur.

-- 
Suhail

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]

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 and observe the reported warning.
>
> #+begin_src org :tangle /tmp/misplaced-heading-mre-2.org
>   - Some words
> ,#+RESULTS:
> : this is a line with asterisks** in the middle
>
> #+end_src

Thinking some more about it, I am of the opinion that instead of
allowing some select elements (as is currently done for comment-block,
example-block, export-block, src-block), it might be better to *only*
trigger the warning for select elements from org-element-all-elements.
E.g., paragraph.  For instance, it seems silly to trigger the warning in
a table-row, or a babel-call etc.

#+begin_src org :tangle /tmp/misplaced-heading-mre-3.org
  | Blah | Hello** world |
  |  |   |

  #+call: blah :var foo="hello** world"
#+end_src

On a related note, what specific situation(s) was this checker intended
to help the user in?  I.e., what are the situations that could result in
misplaced headings?

While the checker seems to be similar to the 'misplaced-planning-info
checker in spirit, the difference (in reality) is that the regular
expression to detect possibly misplaced headings is much easier to get
false positives for.

-- 
Suhail

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]

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 /tmp/misplaced-heading-mre-2.org
  - Some words
,#+RESULTS:
: this is a line with asterisks** in the middle

#+end_src

-- 
Suhail

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]

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 considers it to be a possible
>> case of misplaced-heading.  Case in point:
>>
>> #+begin_src org
>>   - Some words
>> ,#+begin_example
>>   this is a line with asterisks** in the middle
>> ,#+end_example
>> #+end_src
>>
>> The lint check should guard against occurrences that happen within code
>> blocks.
>
> Makes sense.
> Fixed, on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b8497aa7f

This doesn't seem fixed as of 9.7.3 (the MRE above still shows spurious
warning).  It seems that org-at-block-p returns nil when point is within
the block.

-- 
Suhail

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/)]

[Suhail Singh]

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
complicated as a result of it.

> Further, the distant goal is to implement integration of org-lint into
> flycheck/flymake. And we do need user-level config for which checkers
> should be enabled for "full" org-lint check and for "quick" check on
> the fly then.

I am unfamiliar with flymake, but since flycheck checkers run in a
different Emacs process, the patch I sent is sufficient.  FWIW, I have
been using an org-lint flycheck checker for several months now.  The
code for the checker, if curious, is adapted from
.  If flymake doesn't
use a different Emacs process and your goal is to be able to support it
easily, it makes sense to extend the current API in a manner similar to
what you proposed.

-- 
Suhail

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/)]

[Suhail Singh]

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 kind of selector variable instead?

That could also work; there is more than one way to achieve the end.
However, I am not convinced that it's the "better" approach.  It's
altering an existing API for, what I deem to be, little value.

-- 
Suhail

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/)]

[Suhail Singh]

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 function to remove checker(s)

* lisp/org-lint.el (org-lint-remove-checker): Remove one or more
checkers from org-lint--checkers.

TINYCHANGE
---
 lisp/org-lint.el | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lisp/org-lint.el b/lisp/org-lint.el
index aed774ee2..ec28f5255 100644
--- a/lisp/org-lint.el
+++ b/lisp/org-lint.el
@@ -159,6 +159,16 @@ (defun org-lint-add-checker
   (seq-remove (lambda (c) (eq name (org-lint-checker-name c)))
   org-lint--checkers
 
+;;;###autoload
+(defun org-lint-remove-checker (name  names)
+  "Remove checker(s) from linter.
+NAME is the unique check identifier, as a non-nil symbol.  NAMES
+are additional check identifiers to be removed."
+  (let ((removelist (cons name names)))
+(setq org-lint--checkers
+  (seq-remove (lambda (c) (memq (org-lint-checker-name c) removelist))
+  org-lint--checkers
+
 
 ;;; Reports UI
 

base-commit: bb633b67400de67b37317b6ae0741034c196c8d9
-- 
2.45.1


> Thanks! It is indeed a good idea.
> I added this check on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=51aea4946

Thank you!

-- 
Suhail

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/)]

[Suhail Singh]

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 isn't
missing an ob-lang.el requirement, then I propose that the check be
renamed to something specific to babel.  Perhaps
'suspcious-babel-language-in-src-block ?

> You can always ignore this warning.

I presently update (via setq) org-lint--checker after filtering out this
checker.  Is there a better way (i.e., one that doesn't rely on an
internal variable) for non-interactive use?  Perhaps an
#'org-lint-remove-checker could be added to org-lint.el.  For context, I
have code that non-interactively invokes org-lint and reports the
warnings.  As such, ignoring by pressing "i" in the *Org Lint* buffer
isn't an option.

> (If you have better ideas about how to approach the problem of
> misspelled language names, feel free to share them)

I don't have a recommendation specific to the languages that only
support code execution, however, for languages in general wouldn't it be
better to consult something like the output of #'org-src-get-lang-mode
and see if that mode is either defined or can be loaded (depending on
whether or not we require the user to ensure whether the feature
representing the mode is already loaded or simply that it be possible to
be loaded)?

-- 
Suhail

[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/)]

[Suhail Singh]

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.


Any code block in a language that isn't intended to be executed results in a
warning from 'suspicious-language-in-src-block checker.  For instance:

#+begin_src conf
  [Unit]
  Description=Blah
#+end_src

In the above example, conf-mode exists and is used by Org to provide
syntax highlighting and yet, org-lint reports a warning.

Emacs  : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41, 
cairo version 1.18.0)
Package: Org mode version 9.7.2 (release_N/A-N/A-88dd2c @ 
/home/user/.emacs.d/elpa/org-9.7.2/)
-- 
Suhail

[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]

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.


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 considers it to be a possible
case of misplaced-heading.  Case in point:

#+begin_src org
  - Some words
,#+begin_example
  this is a line with asterisks** in the middle
,#+end_example
#+end_src

The lint check should guard against occurrences that happen within code
blocks.

Emacs  : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41, 
cairo version 1.18.0)
Package: Org mode version 9.7.2 (release_N/A-N/A-88dd2c @ 
/home/user/.emacs.d/elpa/org-9.7.2/)
-- 
Suhail

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

[Suhail Singh]

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".

> But if it were to, I do hope the names of other similar syntactic
> terms are similarly updated.

But if it were to, I do hope the names of other /related/ syntactic
terms are similarly updated.

-- 
Suhail

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

[Suhail Singh]

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" to "special blocks".

I generally try and abstain from bike-shedding, but as a data point, the
intent of "inline special blocks" was quite clear to me based on the
name alone.  This was, in no small part, due to the similarity with
"inline code blocks" (cf. "code blocks") as well as "special blocks".

I hope the name of this "syntactic object", when incorporated into Org
mode, doesn't change.  But if it were to, I do hope the names of other
similar syntactic terms are similarly updated.

-- 
Suhail

Re: [proof of concept] inline language blocks

[Suhail Singh]

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 the need for escaping within the
"text") if the syntax was &:type{text} with "lang" being one of the
possible type (as opposed to the type being ":lang").

-- 
Suhail

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

[Suhail Singh Canary]

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 things to work
> for derived backends as well.
>
>> The following package might be mentioned:
>>
>> Colours section in org-special-block-extras
>> https://alhassy.com/org-special-block-extras/#Colours
>
> Agree.
> https://git.sr.ht/~bzg/worg/commit/5edf3ab0

For what it's worth, org-special-block-extras doesn't work well with
derived backends yet, either [1].

[1]: 

-- 
Suhail

[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/)]

[Suhail Singh]

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.


Running M-x org-lint on an org file with below contents results in a
spurious "Link escaped with obsolete percent-encoding syntax" warning.

#+begin_src org
* org-lint url percent-encoding syntax warning
[[https://www.example.com?param=hello%20world][test url]]
#+end_src

I would expect the above org file to not yield any warnings.

Emacs  : GNU Emacs 29.1 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.38, 
cairo version 1.18.0)
Package: Org mode version 9.6.13 ( @ /home/user/.emacs.d/elpa/org-9.6.13/)

-- 
Suhail

Re: [FR] A more general case than footnotes

[Suhail Singh]

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:
>
> Blah blah blah and then she said that the rockets had reached speeds
> of .3c in testing scenarios on a few occasions.  [ref:1c3a90a9]

Is it intended to be [ref:1c3a90a9] or is it supposed to be
[[ref:1c3a90a9]] (i.e., a regular link without description)?

On a related note, how are the references exported?

-- 
Suhail

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

[Suhail Singh]

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:

#+begin_quote
Paragraphs are separated by at least one empty line.  If you need to
enforce a line break within a paragraph, use ‘\\’ at the end of a line.
#+end_quote

-- 
Suhail

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

[Suhail Singh]

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 specific case, I use CommitDate, but I am not convinced it's "the
right thing" in all situations.

Not having conducted a survey, I also cannot comment on the frequency
with which users have a desired preference for one vs the other. I am
also not aware of general rules where users would necessarily prefer one
over the other, but it's possible they may exist. My point was to simply
point out that there is more than one interpretation of
"vc-modification-time".

> It should not be too hard to add buffer hash calculation there.

No disagreement there.

> It will only work for files without includes and force us to use
> exactly the same hash algorithm.

I don't follow. I was stating that the concept of a "file hash" could be
obtained in more than way. I.e., in addition to it being calculated "by
hand" it would also be possible to query an oracle (the VCS in this
case) for it. This is distinct and orthogonal from the decision of how a
"file with includes" is handled.

If I understand you correctly, the logic you have in mind, would be
something like this:

- during publish, compare the file hash of the file being published as
  well as all included files
- if the values for all are the same as in the cache, don't publish (if
  user has signalled such intent via the equivalent of
  org-publish-use-timestamps-flag)
- if the value of any one is different, re-publish and update cache with
  the updated file hashes

It doesn't matter how the specific file hash is obtained, as long as the
mechanism is being used consistently and the file hash of the included
files are also being consulted in an appropriate way.

-- 
Suhail

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

[Suhail Singh]

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: .

> I think that we should use an alternative approach. Both "git time" and
> "fs time" are only an approximation. The true decision to re-publish an
> article should be triggered by article text being modified. So, we may
> better decide based on the file text hash, not the modification times.

For it to work, the "file text hash" would have to also take into
account the "file text hash" of included files, or the decision to
re-publish would have to be predicated on the hash of included files as
well. I.e., the equivalent of this logic in
org-publish-cache-file-needs-publishing :

(let ((mtime (org-publish-cache-mtime-of-src filename)))
  (or (time-less-p pstamp mtime)
  (cl-some (lambda (ct) (time-less-p mtime ct))
   included-files-mtime)))

But assuming the existence of equivalent logic, yes something like a
file hash would work. In fact, at least in the case of git, the VCS
could even be queried for it (via git hash-object).

-- 
Suhail

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

[Suhail Singh]

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 source Org
>   files, making Org publish re-generate everything every single time.
>
>   The new suggested feature is (optionally) using last git commit time
>   instead of file modification time.

>   - Conclusion: the feature request is to be submitted to mailing list
> for more detailed discussion.

The requested feature is for the notion of "modification time" to be
configurable by the user. Even in the specific situation quoted above,
different users may desire different alternative notions of
"modification time". For instance,

- the value of the DATE keyword
- if using git as vc, the "git author date"
- if using git as vc, the "git commit date"

It would help for the notion of "modification time" (currently
hard-coded as file-attribute-modification-time ) to be configurable in
the following functions:

- org-publish-cache-mtime-of-src: this is used to decide whether or not
  a particular file needs to be republished. I.e., the function at the
  heart of the motivating situation discussed during the meetup.
  
- org-publish-find-date: this is used during the publishing of sitemaps
  where the modification time is used as the default value (for
  directories the filesystem modification time is the only value ever
  used).

The user-supplied "modification time" function would take the FILE as an
input and its output would be in the style of `current-time'.  A default
value could be provided for above cases which preserves current
semantics.  Additional inputs to such a "modification time" function
that may be helpful (though may not be necessary) are the PROJECT-PLIST
and the PUB-DIR.

>   - Org already has somewhat similar functionality in a form of
> ={{{modification-time ...}}}= macro. See
> [[info:org#Macro Replacement][org#Macro Replacement]] section
> of Org manual.

I believe the modification-time macro for git uses the "author date".
This may not always be the desirable "vc-modification-time" notion.
However, when it's not, the user has the freedom to create (and use)
their own macro.

>   - Also, several other places in Org are relying on file modification
> time and might need to be considered.

org-html-format-spec is one such place that may additionally benefit.
However, in that case it may be sufficient to simply mirror what's done
for the modification-time macro. I.e., consider only one notion of
"vc-modification-time" and have it be the "author date" semantics.

-- 
Suhail