[PATCH] Possibility of using alternative separators in macros

[PATCH] Possibility of using alternative separators in macros

[Juan Manuel Macías]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

Hi all,

I would like to propose (patch attached) the possibility of using an
alternate character for separate arguments in replacement macros,
following a suggestion from Nicolas Goaziou in this (closed) thread:
https://orgmode.org/list/87o8ead42u.fsf@nicolasgoaziou.fr/

The idea would be to explicitly indicate the separator just before the
parentheses. The allowed characters are any character other than a
letter, a number, a space, a dash, a low line or a parenthesis.

A new property `:sep' is added to `org-element-macro-parser', whose
default value is a comma.

Example of use. Suppose we define this macro:

#+MACRO: foo (eval (format "%s and %s" $1 $2))

Under normal conditions, the expected separator will be the comma:

{{{foo(x,z\, y)}}}

=> x and z, y

But we can also do this:

{{{foo@(x@z, y \@)}}}

=> x and z, y @

I think sometimes it may be preferable to separate the arguments by an
alternative character. For example, let's imagine we define a macro
(named 'lg') for LaTeX export, which admits two arguments, exactly the
same args as the Babel (LaTeX) macro \foreignlanguage{lang}{short-text}:
{{{lg(lang,short-text)}}}.

It would be much more comfortable something like:

{{{lg|(latin|trado, tradidi, traditur)}}}

instead of having to escape commas in:

{{{lg(latin,trado\, tradidi\, traditur)}}}

Best regards,

Juan Manuel 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Alternative-args-separator-for-replacement-macros.patch --]
[-- Type: text/x-patch, Size: 2967 bytes --]

From 400d5779508fd7206a353bdb444c3cba382b8f01 Mon Sep 17 00:00:00 2001
From: juanmanuel <maciaschain@posteo.net>
Date: Fri, 30 Apr 2021 14:45:54 +0200
Subject: [PATCH] Alternative args separator for replacement macros

---
 lisp/org-element.el | 9 +++++++--
 lisp/org-macro.el   | 9 +++++----
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index a675bf512..34a9b880a 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3279,21 +3279,25 @@ CONTENTS is the contents of the object, or nil."
   "Parse macro at point, if any.
 
 When at a macro, return a list whose car is `macro' and cdr
-a plist with `:key', `:args', `:begin', `:end', `:value' and
+a plist with `:key', `:args', `:begin', `:end', `:sep', `:value' and
 `:post-blank' as keywords.  Otherwise, return nil.
 
 Assume point is at the macro."
   (save-excursion
-    (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\((\\([^\000]*?\\))\\)?}}}")
+    (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\([^a-zA-Z\s()]*[^-a-zA-Z0-9_\s]*\\)\\((\\([^\000]*?\\))\\)?}}}")
       (let ((begin (point))
 	    (key (downcase (match-string-no-properties 1)))
 	    (value (match-string-no-properties 0))
 	    (post-blank (progn (goto-char (match-end 0))
 			       (skip-chars-forward " \t")))
 	    (end (point))
+            (sep (if (not (equal (match-string-no-properties 2) ""))
+		      (match-string-no-properties 2)
+		    ","))
 	    (args (pcase (match-string-no-properties 3)
 		    (`nil nil)
 		    (a (org-macro-extract-arguments
+                        sep
 			(replace-regexp-in-string
 			 "[ \t\r\n]+" " " (org-trim a)))))))
 	(list 'macro
@@ -3302,6 +3306,7 @@ Assume point is at the macro."
 		    :args args
 		    :begin begin
 		    :end end
+                    :sep sep
 		    :post-blank post-blank))))))
 
 (defun org-element-macro-interpreter (macro _)
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 29c403658..e047cd78e 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -294,20 +294,21 @@ of `org-macro-extract-arguments'."
 	      nil t)
 	     s)))))
 
-(defun org-macro-extract-arguments (s)
+(defun org-macro-extract-arguments (sep s)
   "Extract macro arguments from string S.
 S is a string containing comma separated values properly escaped.
-Return a list of arguments, as strings.  This is the opposite of
+SEP is the character used to separate arguments.  Return a list
+of arguments, as strings.  This is the opposite of
 `org-macro-escape-arguments'."
   ;; Do not use `org-split-string' since empty strings are
   ;; meaningful here.
   (split-string
    (replace-regexp-in-string
-    "\\(\\\\*\\),"
+    (format "\\(\\\\*\\)%s" sep)
     (lambda (str)
       (let ((len (length (match-string 1 str))))
 	(concat (make-string (/ len 2) ?\\)
-		(if (zerop (mod len 2)) "\000" ","))))
+		(if (zerop (mod len 2)) "\000" (format "%s" sep)))))
     s nil t)
    "\000"))
 
-- 
2.26.0

Re: [PATCH] Possibility of using alternative separators in macros

[Bastien]

Hi Juan,

thank you for the patch.  I understand the general idea, but I think
we should be careful not to overload the macro syntax - escaping the
coma seems okay to me.  I'm closing this suggestion.

I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
course insist on rejecting it.

Thanks,

-- 
 Bastien

Re: [PATCH] Possibility of using alternative separators in macros

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> thank you for the patch.  I understand the general idea, but I think
> we should be careful not to overload the macro syntax - escaping the
> coma seems okay to me.  I'm closing this suggestion.
>
> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
> course insist on rejecting it.

This is a followup to a previous discussion in this mailing list, in
which Juan Manuel explained his use-case for a different argument
separator in macros. I noticed then that there was an opening for
a backward compatible syntax extension for it. As I was also not certain
it would be a good idea overall, I suggested him to start a new, more
visible, thread with the proposal, and collect feedback.

So, maybe it is a bit early to close it.

BTW, I would like to amend the proposed syntax, so as to limit friction
with the rest of Org. What would be more reasonable is the following:

   {{{macroname·(...)}}}

where · is either nothing or a _single_ printable non-alphanumeric
non-space non-parenthesis character that isn't already meaningful in
Org. For example, if for some reason, we limit ourselves to ASCII
characters only, the set of allowed separators would be:

                       !   %   &   ,   ;   ?   `

So, again, I'm not saying we should do this. TBH, I'm not convinced by
the idea of duplicate syntax (comma-escaping and alternate characters)
for the same thing. But hard-core macro users may have a word to say
about it.

WDYT?

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] Possibility of using alternative separators in macros

[Bastien]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> So, maybe it is a bit early to close it.

Okay, thanks for the heads up, I'm reopening then.

-- 
 Bastien

Re: [PATCH] Possibility of using alternative separators in macros

[Bastien]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> So, again, I'm not saying we should do this. TBH, I'm not convinced by
> the idea of duplicate syntax (comma-escaping and alternate characters)
> for the same thing. But hard-core macro users may have a word to say
> about it.

FWIW I'm not convinced too but I'd also love to hear from other macro
users here, and I'll definitely follow your call here.

-- 
 Bastien

Re: [PATCH] Possibility of using alternative separators in macros

[Juan Manuel Macías]

Hi all,

Thanks for your comments, Bastien and Nicolas.

I think macros can work out of the box as a perfect 'backend' for those
LaTeX commands that include at least one argument with textual content.
In my case they are very useful to 'extend' the markup language. Apart
from the LaTeX example that I put previously
(\foreignlanguage{lang}{short-text}), there are commands like
\textsc{text in small caps}, \textcolor{color}{text}, and so on. When
one of the arguments consists of textual content, even if it is a short
text, it can be tedious to escape constantly commas[1]. Anyway, I
understand that my use case may not be that of the rest of the users,
and what is a 'problem' for me, it may not be seen as a problem by other
users; therefore, I fully understand Bastien's warnings about making a
modification to something that already works fine, and has been working
fine since always.

Nicolas's suggestion seemed the most reasonable, or the least
destructive, in the hypothetical scenario that there would be a great
demand among users of an alternative separator. Now I see unlikely,
however, that such a demand exists ;-) So, if my use case is a minority,
of course I agree with give up this proposal...

[1] To mitigate 'comma issue' I wrote a function that escapes commas
when saving document :-D

Best regards,

Juan Manuel 

Nicolas Goaziou writes:

> Hello,
>
> Bastien <bzg@gnu.org> writes:
>
>> thank you for the patch.  I understand the general idea, but I think
>> we should be careful not to overload the macro syntax - escaping the
>> coma seems okay to me.  I'm closing this suggestion.
>>
>> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
>> course insist on rejecting it.
>
> This is a followup to a previous discussion in this mailing list, in
> which Juan Manuel explained his use-case for a different argument
> separator in macros. I noticed then that there was an opening for
> a backward compatible syntax extension for it. As I was also not certain
> it would be a good idea overall, I suggested him to start a new, more
> visible, thread with the proposal, and collect feedback.
>
> So, maybe it is a bit early to close it.
>
> BTW, I would like to amend the proposed syntax, so as to limit friction
> with the rest of Org. What would be more reasonable is the following:
>
>    {{{macroname·(...)}}}
>
> where · is either nothing or a _single_ printable non-alphanumeric
> non-space non-parenthesis character that isn't already meaningful in
> Org. For example, if for some reason, we limit ourselves to ASCII
> characters only, the set of allowed separators would be:
>
>                        !   %   &   ,   ;   ?   `
>
> So, again, I'm not saying we should do this. TBH, I'm not convinced by
> the idea of duplicate syntax (comma-escaping and alternate characters)
> for the same thing. But hard-core macro users may have a word to say
> about it.
>
> WDYT?
>
> Regards,

Re: [PATCH] Possibility of using alternative separators in macros

[Eric S Fraga]

(resent: some receiving server complained about multiple recipients blah
blah so I am testing with just the org mode mailing list as the
recipient; apologies for noise if you receive this twice)

On Saturday,  1 May 2021 at 12:04, Nicolas Goaziou wrote:
> BTW, I would like to amend the proposed syntax, so as to limit friction
> with the rest of Org. What would be more reasonable is the following:
>
>    {{{macroname·(...)}}}

I will chime in to say that I would actually like this.  One of my
frequent uses of macros is for acknowledgements in a presentation, where
I use:

#+macro: cite [[$2][@@latex:\vfill\Citation{$1}@@]]

with a typical usage being

   {{{cite(EF\, JM\, et al.\, 2021, http:...)}}}

which would benefit from being able to type:

   {{{cite;(EF, JM, et al., 2021 ; http:...)}}}

but it's not a killer lack of feature, to be fair.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-405-g0a689b

Re: [PATCH] Possibility of using alternative separators in macros

[Christian Moe]

I frequently need to escape commas in macros, which is a bit of a pain
and easy to forget. My most frequent use case is a macro that expands in
ODT export to a margin comment (like #+begin_annotation does, but
without causing a line break). It takes one argument which typically
consists of several lines of text with commas in them. If I forget to
escape a comma, the rest of the comment is silently lost to the reader.

So a backwards-compatible remedy would be nice. Juan's/Nicholas's
solution is smart, but I'm not sure if it's exactly what I've been
waiting for. It saves escaping every comma, but I'd still have to
remember to add the separator character every time I *invoke* a macro,
and remembering is the tricky part. I don't know if you've already
considered the option of instead specifying a different separator in the
macro *definition*, say something like

  #+macro: comment @@html:<!-- $1 -->@@ :sep "&"

Another point: Something that would help, without adding new syntax, is
making macro expansion smart enough to *ignore* separators when the
macro definition contains only *one* argument anyway, as in the cases
above. That behavior would also be safely backwards-compatible, I
think. It would not help with macros with more than one arg, like Juan's
example, but it would solve most of my problems, for example.

Yours,
Christian


Juan Manuel Macías writes:

> Hi all,
>
> Thanks for your comments, Bastien and Nicolas.
>
> I think macros can work out of the box as a perfect 'backend' for those
> LaTeX commands that include at least one argument with textual content.
> In my case they are very useful to 'extend' the markup language. Apart
> from the LaTeX example that I put previously
> (\foreignlanguage{lang}{short-text}), there are commands like
> \textsc{text in small caps}, \textcolor{color}{text}, and so on. When
> one of the arguments consists of textual content, even if it is a short
> text, it can be tedious to escape constantly commas[1]. Anyway, I
> understand that my use case may not be that of the rest of the users,
> and what is a 'problem' for me, it may not be seen as a problem by other
> users; therefore, I fully understand Bastien's warnings about making a
> modification to something that already works fine, and has been working
> fine since always.
>
> Nicolas's suggestion seemed the most reasonable, or the least
> destructive, in the hypothetical scenario that there would be a great
> demand among users of an alternative separator. Now I see unlikely,
> however, that such a demand exists ;-) So, if my use case is a minority,
> of course I agree with give up this proposal...
>
> [1] To mitigate 'comma issue' I wrote a function that escapes commas
> when saving document :-D
>
> Best regards,
>
> Juan Manuel
>
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Bastien <bzg@gnu.org> writes:
>>
>>> thank you for the patch.  I understand the general idea, but I think
>>> we should be careful not to overload the macro syntax - escaping the
>>> coma seems okay to me.  I'm closing this suggestion.
>>>
>>> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
>>> course insist on rejecting it.
>>
>> This is a followup to a previous discussion in this mailing list, in
>> which Juan Manuel explained his use-case for a different argument
>> separator in macros. I noticed then that there was an opening for
>> a backward compatible syntax extension for it. As I was also not certain
>> it would be a good idea overall, I suggested him to start a new, more
>> visible, thread with the proposal, and collect feedback.
>>
>> So, maybe it is a bit early to close it.
>>
>> BTW, I would like to amend the proposed syntax, so as to limit friction
>> with the rest of Org. What would be more reasonable is the following:
>>
>>    {{{macroname·(...)}}}
>>
>> where · is either nothing or a _single_ printable non-alphanumeric
>> non-space non-parenthesis character that isn't already meaningful in
>> Org. For example, if for some reason, we limit ourselves to ASCII
>> characters only, the set of allowed separators would be:
>>
>>                        !   %   &   ,   ;   ?   `
>>
>> So, again, I'm not saying we should do this. TBH, I'm not convinced by
>> the idea of duplicate syntax (comma-escaping and alternate characters)
>> for the same thing. But hard-core macro users may have a word to say
>> about it.
>>
>> WDYT?
>>
>> Regards,

Re: [PATCH] Possibility of using alternative separators in macros

[Eric S Fraga]

Hello Juan,

On Friday, 30 Apr 2021 at 13:26, Juan Manuel Macías wrote:
> Hi all,
>
> I would like to propose (patch attached) the possibility of using an
> alternate character for separate arguments in replacement macros,
> following a suggestion from Nicolas Goaziou in this (closed) thread:
> https://orgmode.org/list/87o8ead42u.fsf@nicolasgoaziou.fr/

I finally got around to trying this out, applying the patch just now to
the latest org from the git repository.  I get the following when I try
to export:

Debugger entered--Lisp error: (void-variable sep)
  org-element-macro-parser()
  org-element--object-lex((bold code entity export-snippet footnote-reference inline-babel-call inline-src-block italic line-break latex-fragment link macro radio-target statistics-cookie strike-through subscript superscript target timestamp underline verbatim))
  org-element-context()
  org-macro-replace-all((("date" . "") ("title" . "The title") ("email" . "") ("author" . "Professor Eric S Fraga") ("lastchange" . "2021.03.31 15:03") ("calc" . "@@latex:{\\color{green!50!black}\\texttt{ $1 }}@@") ("cite" . "[[$2][@@latex:\\vfill\\Citation{$1}@@]]") ("overlay" . "@@latex:\\begin{textblock}{$4}($2,$3)@@[[file:$1]]@...") ("parameter" . "src_elisp[:results value raw :var $1=(esf/get-para...") ("constant" closure (t) (&optional $1 &rest _) (progn (message "Getting constant %s" $1) (org-table-get-constant $1))) ("input-file" . "m.org") ("modification-time" . #f(compiled-function (arg1 &optional arg2 &rest _) #<bytecode 0x1a91bc3b547f3a1c>)) ("keyword" lambda (arg1 &rest _) (org-macro--find-keyword-value arg1)) ("n" lambda (&optional arg1 arg2 &rest _) (org-macro--counter-increment arg1 arg2)) ("property" lambda (arg1 &optional arg2 &rest _) (org-macro--get-property arg1 arg2)) ("time" lambda (arg1 &rest _) (format-time-string arg1))) ("DESCRIPTION" "KEYWORDS" "SUBTITLE" "DATE" "TITLE" "DATE" "AUTHOR"))
  org-export-as(latex nil nil nil nil)
  org-export-to-buffer(latex "*Org LATEX Export*" nil nil nil nil nil #f(compiled-function () #<bytecode 0xbb0539acd91d>))
  org-latex-export-as-latex(nil nil nil nil)
  org-export-dispatch(nil)
  funcall-interactively(org-export-dispatch nil)
  command-execute(org-export-dispatch)

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-534-g8f03cd.dirty

Re: [PATCH] Possibility of using alternative separators in macros

[Juan Manuel Macías]

Hello Eric,

It's a typo, sorry: I forgot, when I made the patch, to add the asterisk
to the `let' expression in org-element-macro-parser, therefore the `sep'
variable was not recognized.

The correct function is:

(defun org-element-macro-parser ()
    "Parse macro at point, if any.

  When at a macro, return a list whose car is `macro' and cdr
  a plist with `:key', `:args', `:begin', `:end', `:value', `:sep' and
  `:post-blank' as keywords.  Otherwise, return nil.

  Assume point is at the macro."
    (save-excursion
      (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\([^a-zA-Z\s()]?[^-a-zA-Z0-9_\s]?\\)\\((\\([^\000]*?\\))\\)?}}}")
	(let* ((begin (point)) ;; <==== missing asterisk :-(
	       (key (downcase (match-string-no-properties 1)))
	       (value (match-string-no-properties 0))
	       (post-blank (progn (goto-char (match-end 0))
				  (skip-chars-forward " \t")))
	       (end (point))
	       (sep (if (not (equal (match-string-no-properties 2) ""))
			(match-string-no-properties 2)
		      ","))
	       (args (pcase (match-string-no-properties 4)
		       (`nil nil)
		       (a (org-macro-extract-arguments
			   sep
			   (replace-regexp-in-string
			    "[ \t\r\n]+" " " (org-trim a)))))))
	  (list 'macro
		(list :key key
		      :value value
		      :args args
		      :begin begin
		      :end end
		      :sep sep
		      :post-blank post-blank))))))

Eric S Fraga writes:

> Hello Juan,
>
> On Friday, 30 Apr 2021 at 13:26, Juan Manuel Macías wrote:
>> Hi all,
>>
>> I would like to propose (patch attached) the possibility of using an
>> alternate character for separate arguments in replacement macros,
>> following a suggestion from Nicolas Goaziou in this (closed) thread:
>> https://orgmode.org/list/87o8ead42u.fsf@nicolasgoaziou.fr/
>
> I finally got around to trying this out, applying the patch just now to
> the latest org from the git repository.  I get the following when I try
> to export:
>
> Debugger entered--Lisp error: (void-variable sep)
>   org-element-macro-parser()
>   org-element--object-lex((bold code entity export-snippet
> footnote-reference inline-babel-call inline-src-block italic
> line-break latex-fragment link macro radio-target statistics-cookie
> strike-through subscript superscript target timestamp underline
> verbatim))
>   org-element-context()
>   org-macro-replace-all((("date" . "") ("title" . "The title")
> ("email" . "") ("author" . "Professor Eric S Fraga") ("lastchange" .
> "2021.03.31 15:03") ("calc" .
> "@@latex:{\\color{green!50!black}\\texttt{ $1 }}@@") ("cite" .
> "[[$2][@@latex:\\vfill\\Citation{$1}@@]]") ("overlay" .
> "@@latex:\\begin{textblock}{$4}($2,$3)@@[[file:$1]]@...") ("parameter"
> . "src_elisp[:results value raw :var $1=(esf/get-para...") ("constant"
> closure (t) (&optional $1 &rest _) (progn (message "Getting constant
> %s" $1) (org-table-get-constant $1))) ("input-file" . "m.org")
> ("modification-time" . #f(compiled-function (arg1 &optional arg2 &rest
> _) #<bytecode 0x1a91bc3b547f3a1c>)) ("keyword" lambda (arg1 &rest _)
> (org-macro--find-keyword-value arg1)) ("n" lambda (&optional arg1 arg2
> &rest _) (org-macro--counter-increment arg1 arg2)) ("property" lambda
> (arg1 &optional arg2 &rest _) (org-macro--get-property arg1 arg2))
> ("time" lambda (arg1 &rest _) (format-time-string arg1)))
> ("DESCRIPTION" "KEYWORDS" "SUBTITLE" "DATE" "TITLE" "DATE" "AUTHOR"))
>   org-export-as(latex nil nil nil nil)
>   org-export-to-buffer(latex "*Org LATEX Export*" nil nil nil nil nil #f(compiled-function () #<bytecode 0xbb0539acd91d>))
>   org-latex-export-as-latex(nil nil nil nil)
>   org-export-dispatch(nil)
>   funcall-interactively(org-export-dispatch nil)
>   command-execute(org-export-dispatch)

Re: [PATCH] Possibility of using alternative separators in macros

[Juan Manuel Macías]

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]

Here is the fixed version of the patch.

Best regards,

Juan Manuel

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Could you create a new patch so I can try this easily?
>
> gracias,
> eric


[-- Attachment #2: 0001-Alternative-args-separator-for-replacement-macros_fixed.patch --]
[-- Type: text/x-patch, Size: 3094 bytes --]

From 4aae61c3600fba136dfa101d54011c0aef9169a3 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macías <maciaschain@posteo.net>
Date: Tue, 11 May 2021 18:41:34 +0200
Subject: [PATCH] Alternative args separator for replacement macros

---
 lisp/org-element.el | 11 ++++++++---
 lisp/org-macro.el   |  9 +++++----
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index a675bf512..da4035689 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3279,21 +3279,25 @@ CONTENTS is the contents of the object, or nil."
   "Parse macro at point, if any.
 
 When at a macro, return a list whose car is `macro' and cdr
-a plist with `:key', `:args', `:begin', `:end', `:value' and
+a plist with `:key', `:args', `:begin', `:end', `:sep', `:value' and
 `:post-blank' as keywords.  Otherwise, return nil.
 
 Assume point is at the macro."
   (save-excursion
-    (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\((\\([^\000]*?\\))\\)?}}}")
-      (let ((begin (point))
+    (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\([^a-zA-Z\s()]*[^-a-zA-Z0-9_\s]*\\)\\((\\([^\000]*?\\))\\)?}}}")
+      (let* ((begin (point))
 	    (key (downcase (match-string-no-properties 1)))
 	    (value (match-string-no-properties 0))
 	    (post-blank (progn (goto-char (match-end 0))
 			       (skip-chars-forward " \t")))
 	    (end (point))
+            (sep (if (not (equal (match-string-no-properties 2) ""))
+		      (match-string-no-properties 2)
+		    ","))
 	    (args (pcase (match-string-no-properties 3)
 		    (`nil nil)
 		    (a (org-macro-extract-arguments
+                        sep
 			(replace-regexp-in-string
 			 "[ \t\r\n]+" " " (org-trim a)))))))
 	(list 'macro
@@ -3302,6 +3306,7 @@ Assume point is at the macro."
 		    :args args
 		    :begin begin
 		    :end end
+                    :sep sep
 		    :post-blank post-blank))))))
 
 (defun org-element-macro-interpreter (macro _)
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 29c403658..e047cd78e 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -294,20 +294,21 @@ of `org-macro-extract-arguments'."
 	      nil t)
 	     s)))))
 
-(defun org-macro-extract-arguments (s)
+(defun org-macro-extract-arguments (sep s)
   "Extract macro arguments from string S.
 S is a string containing comma separated values properly escaped.
-Return a list of arguments, as strings.  This is the opposite of
+SEP is the character used to separate arguments.  Return a list
+of arguments, as strings.  This is the opposite of
 `org-macro-escape-arguments'."
   ;; Do not use `org-split-string' since empty strings are
   ;; meaningful here.
   (split-string
    (replace-regexp-in-string
-    "\\(\\\\*\\),"
+    (format "\\(\\\\*\\)%s" sep)
     (lambda (str)
       (let ((len (length (match-string 1 str))))
 	(concat (make-string (/ len 2) ?\\)
-		(if (zerop (mod len 2)) "\000" ","))))
+		(if (zerop (mod len 2)) "\000" (format "%s" sep)))))
     s nil t)
    "\000"))
 
-- 
2.26.0

Re: [PATCH] Possibility of using alternative separators in macros

[Maxim Nikulin]

On 03/05/2021 04:08, Christian Moe wrote:
> 
> I frequently need to escape commas in macros, which is a bit of a pain
> and easy to forget.

Maybe it is not convenient, but if unescaped comma is a real pain, you 
could detect it and report an error

# single line may be wrapped by mailer
#+MACRO: extraerror (eval (if (not $2) (concat "*" $1 "*") (error 
(format "%s: unescaped comma %S" (line-number-at-pos) $2))))

{{{extraerror(valid)}}}
{{{extraerror(valid\, with escaped comma)}}}
{{{extraerror(missed, comma)}}}

Org gurus might suggest a recipe how to convert error into warning, that 
is easily noticeable but still not fatal, to get all problems after 
single export attempt. Preferably it should act similar to compiler 
errors allowing to jump between problem points.

Org 9.3 requires a bit different macro
#MACRO: extraerror (eval (if (equal "" $2) (concat "*" $1 "*") (error 
(format "%s: unescaped comma %S" (line-number-at-pos) $2))))

> Another point: Something that would help, without adding new syntax, is
> making macro expansion smart enough to *ignore* separators when the
> macro definition contains only *one* argument anyway, as in the cases
> above.

I think, this is an idea of the best approach. Unsure concerning precise 
form. Maybe e.g. "$_" could expand into all arguments greater than 
maximum referenced number. No promise of forward compatibility of the 
following hack since it relies on undocumented implementation details.

#+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat 
#'identity _ ",")))

{{{allargshack(one, two, three)}}}

I do not know if Eric can swap order of arguments of his credits macro. 
Extracting namely last argument requires a bit more lisp code.

Re: [PATCH] Possibility of using alternative separators in macros

[Bastien]

Hi Juan,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Here is the fixed version of the patch.

I'll let Eric test and comment, but in the meantime, I'm just 
noticing the patch breaks many tests in master.

If Nicolas thinks this change is good and Eric validate the patch,
please prepare one with a commit message, updating the tests too.

Thanks,

-- 
 Bastien

Re: [PATCH] Possibility of using alternative separators in macros

[Juan Manuel Macías]

Hi Bastien,

Bastien writes:

> I'll let Eric test and comment, but in the meantime, I'm just 
> noticing the patch breaks many tests in master.
>
> If Nicolas thinks this change is good and Eric validate the patch,
> please prepare one with a commit message, updating the tests too.

Ok, if necessary I will prepare an updated version of the patch, with
the updated tests, and with a commit message (a thousand apologies for
my continuous forgetting in commit messages...).

I have noticed certain bugs in my patch, especially within
org-element-macro-parser (a bad regexp and something else). That caused
macros with a single argument to be incorrectly interpreted (and it also
caused an error in one of the tests). If Eric (or someone else) wants
an updated version of the patch I could send it him.

Anyway, I admit that I have become somewhat skeptical about the
usefulness of my patch. Perhaps, as a patch, it is too premature and
perhaps it's better to leave the macros issue, for the moment, as it
is... What do you think?

Best regards,

Juan Manuel 

Re: [PATCH] Possibility of using alternative separators in macros

[Bastien]

Hi Juan,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Anyway, I admit that I have become somewhat skeptical about the
> usefulness of my patch. Perhaps, as a patch, it is too premature and
> perhaps it's better to leave the macros issue, for the moment, as it
> is... What do you think?

I'm skeptical too, so perhaps the best thing to do is to see if you
need it or not, and if proven useful after a while, repost a patch?

Thanks!

-- 
 Bastien

Re: [PATCH] Possibility of using alternative separators in macros

[Juan Manuel Macías]

Hi Bastien,

Bastien writes:

> I'm skeptical too, so perhaps the best thing to do is to see if you
> need it or not, and if proven useful after a while, repost a patch?

I totally agree. I will try these modifications for a while, if they are
really useful. Anyway, as Nicolas commented in a previous post, it seems
that the natural habitat of macros consists of short lengths of text. I
am exploring now other interesting alternatives (ie.
org-link-set-parameters).

(On the other hand, maybe better than an alternate separator, some kind of
warning for unescaped commas might be more useful, as Maxim commented
here: https://orgmode.org/list/s7gfc6@ciao.gmane.io/)

Best regards,

Juan Manuel 

Re: [PATCH] Possibility of using alternative separators in macros

[Bastien]

Hi Juan,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> (On the other hand, maybe better than an alternate separator, some kind of
> warning for unescaped commas might be more useful, as Maxim commented
> here: https://orgmode.org/list/s7gfc6@ciao.gmane.io/)

Yes, probably -- feel free to propose a patch for this.  Thanks!

-- 
 Bastien

Re: [PATCH] Possibility of using alternative separators in macros

[Maxim Nikulin]

On 16/05/2021 19:17, Bastien wrote:
> 
> Juan Manuel Macías writes:
> 
>> (On the other hand, maybe better than an alternate separator, some kind of
>> warning for unescaped commas might be more useful, as Maxim commented
>> here: https://orgmode.org/list/s7gfc6@ciao.gmane.io/)
> 
> Yes, probably -- feel free to propose a patch for this.  Thanks!

Such warnings should be property of particular macros. Sometimes 
ignoring of arguments may be handy. So no patch is required. The trick 
could be documented somewhere, but I am unsure concerning proper place. 
Actually, I do not think, fatal error is user-friendly behavior. I am 
not aware if export already have convenient facilities to report 
warnings. Currently I do not feel I am ready to implement such feature 
if it does not exist yet.

However the point of that message was that extra commas may be made 
"transparent" for macros by introducing additional substitution, e.g. 
"$_" that expands into "rest" arguments. I consider "$@" or "$*" as 
worse variant since it rather mean "all arguments", so it is less 
flexible. For "eval" lisp macros, it is just replacing "_" by "$_" in 
argument list. Simple text macros require a bit more work but it is 
still comparable with documenting the feature.

We need a decision if "rest arguments" feature should be introduced. 
Once added, it will be harder to discard it due to compatibility issues.

Re: [PATCH] Possibility of using alternative separators in macros

[Christian Moe]

Maxim Nikulin writes:

> On 03/05/2021 04:08, Christian Moe wrote:
[snip]
>> Something that would help, without adding new syntax, is
>> making macro expansion smart enough to *ignore* separators when the
>> macro definition contains only *one* argument anyway, as in the cases
>> above.
>
> I think, this is an idea of the best approach. Unsure concerning
> precise form. Maybe e.g. "$_" could expand into all arguments greater
> than maximum referenced number. No promise of forward compatibility of
> the following hack since it relies on undocumented implementation
> details.
>
> #+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
> #'identity _ ",")))
>
> {{{allargshack(one, two, three)}}}
>
> I do not know if Eric can swap order of arguments of his credits
> macro. Extracting namely last argument requires a bit more lisp code.


Yes, I didn't think that far. This would provide a comprehensive
backwards-compatible solution to the comma-escaping problem, though
perhaps not the most newbie-friendly one. It would also make macros more
flexible and powerful in the bargain (I'm sure people will think of
other uses for this than commas).

Yours,
Christian

Re: [PATCH] Possibility of using alternative separators in macros

[Maxim Nikulin]

On 17/05/2021 02:21, Christian Moe wrote:
> Maxim Nikulin writes:
>> On 03/05/2021 04:08, Christian Moe wrote:
> [snip]
>> #+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
>> #'identity _ ",")))
>>
>> {{{allargshack(one, two, three)}}}
>>
>> I do not know if Eric can swap order of arguments of his credits
>> macro. Extracting namely last argument requires a bit more lisp code.
> 
> Yes, I didn't think that far. This would provide a comprehensive
> backwards-compatible solution to the comma-escaping problem, though
> perhaps not the most newbie-friendly one. It would also make macros more
> flexible and powerful in the bargain (I'm sure people will think of
> other uses for this than commas).

I agree that it would abuse arguments syntax, but I expect that namely 
newbies would not bother since it would "just work":

#+MACRO definition  - $1 ::$_

{{{definition(one, two, three}}}

It is more experienced users who may be confused why it works.

Re: [PATCH] Possibility of using alternative separators in macros

[Christian Moe]

Maxim Nikulin writes:

> On 17/05/2021 02:21, Christian Moe wrote:
>> Maxim Nikulin writes:
>>> On 03/05/2021 04:08, Christian Moe wrote:
>> [snip]
>>> #+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
>>> #'identity _ ",")))
>>>
>>> {{{allargshack(one, two, three)}}}
>>>
>>> I do not know if Eric can swap order of arguments of his credits
>>> macro. Extracting namely last argument requires a bit more lisp code.
>>
>> Yes, I didn't think that far. This would provide a comprehensive
>> backwards-compatible solution to the comma-escaping problem, though
>> perhaps not the most newbie-friendly one. It would also make macros more
>> flexible and powerful in the bargain (I'm sure people will think of
>> other uses for this than commas).
>
> I agree that it would abuse arguments syntax, but I expect that namely
> newbies would not bother since it would "just work":
>
> #+MACRO definition  - $1 ::$_
>
> {{{definition(one, two, three}}}
>
> It is more experienced users who may be confused why it works.


That's not what I was trying to say. I don't think your suggestion
abuses the argument syntax - it would extend it, in a way that is likely
to prove helpful for multiple purposes.

When I said it was probably not the most newbie-friendly solution for
the comma-escaping problem, I thought that it required including a bit
of lisp in their macros to add the commas back in (the mapconcat
expression in your "allargshack" example above).

But if the "definition" macro above "just works", I suppose that in your
solution, the list of arguments $_ would by default expand to the same
string as the mapconcat expression would, i.e. the commas would be added
back in. That makes sense. The mapconcat expression would not even be
needed, then, unless one wants the macro to do anything else than
preserve commas. Or am I misunderstanding something?

Yours,
Christian