Org-mode mailing list
 help / color / mirror / Atom feed
* [PATCH] Possibility of using alternative separators in macros
@ 2021-04-30 13:26 Juan Manuel Macías
  2021-05-01  8:30 ` Bastien
  2021-05-11 11:01 ` Eric S Fraga
  0 siblings, 2 replies; 12+ messages in thread
From: Juan Manuel Macías @ 2021-04-30 13:26 UTC (permalink / raw)
  To: orgmode

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
  2021-04-30 13:26 [PATCH] Possibility of using alternative separators in macros Juan Manuel Macías
@ 2021-05-01  8:30 ` Bastien
  2021-05-01 10:04   ` Nicolas Goaziou
  2021-05-11 11:01 ` Eric S Fraga
  1 sibling, 1 reply; 12+ messages in thread
From: Bastien @ 2021-05-01  8:30 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, mail

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
  2021-05-01  8:30 ` Bastien
@ 2021-05-01 10:04   ` Nicolas Goaziou
  2021-05-01 10:17     ` Bastien
                       ` (3 more replies)
  0 siblings, 4 replies; 12+ messages in thread
From: Nicolas Goaziou @ 2021-05-01 10:04 UTC (permalink / raw)
  To: Bastien; +Cc: Juan Manuel Macías, orgmode

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
  2021-05-01 10:04   ` Nicolas Goaziou
@ 2021-05-01 10:17     ` Bastien
  2021-05-01 10:18     ` Bastien
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 12+ messages in thread
From: Bastien @ 2021-05-01 10:17 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Juan Manuel Macías, orgmode

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
  2021-05-01 10:04   ` Nicolas Goaziou
  2021-05-01 10:17     ` Bastien
@ 2021-05-01 10:18     ` Bastien
  2021-05-01 21:50     ` Juan Manuel Macías
  2021-05-02 12:13     ` Eric S Fraga
  3 siblings, 0 replies; 12+ messages in thread
From: Bastien @ 2021-05-01 10:18 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Juan Manuel Macías, orgmode

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
  2021-05-01 10:04   ` Nicolas Goaziou
  2021-05-01 10:17     ` Bastien
  2021-05-01 10:18     ` Bastien
@ 2021-05-01 21:50     ` Juan Manuel Macías
  2021-05-02 21:08       ` Christian Moe
  2021-05-02 12:13     ` Eric S Fraga
  3 siblings, 1 reply; 12+ messages in thread
From: Juan Manuel Macías @ 2021-05-01 21:50 UTC (permalink / raw)
  To: Nicolas Goaziou, Bastien; +Cc: orgmode

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,



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
  2021-05-01 10:04   ` Nicolas Goaziou
                       ` (2 preceding siblings ...)
  2021-05-01 21:50     ` Juan Manuel Macías
@ 2021-05-02 12:13     ` Eric S Fraga
  3 siblings, 0 replies; 12+ messages in thread
From: Eric S Fraga @ 2021-05-02 12:13 UTC (permalink / raw)
  To: orgmode


(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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
  2021-05-01 21:50     ` Juan Manuel Macías
@ 2021-05-02 21:08       ` Christian Moe
  2021-05-12 11:49         ` Maxim Nikulin
  0 siblings, 1 reply; 12+ messages in thread
From: Christian Moe @ 2021-05-02 21:08 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Bastien, orgmode, Nicolas Goaziou


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,


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
  2021-04-30 13:26 [PATCH] Possibility of using alternative separators in macros Juan Manuel Macías
  2021-05-01  8:30 ` Bastien
@ 2021-05-11 11:01 ` Eric S Fraga
  2021-05-11 16:12   ` Juan Manuel Macías
  1 sibling, 1 reply; 12+ messages in thread
From: Eric S Fraga @ 2021-05-11 11:01 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
  2021-05-11 11:01 ` Eric S Fraga
@ 2021-05-11 16:12   ` Juan Manuel Macías
       [not found]     ` <87im3prvz8.fsf@ucl.ac.uk>
  0 siblings, 1 reply; 12+ messages in thread
From: Juan Manuel Macías @ 2021-05-11 16:12 UTC (permalink / raw)
  To: Eric S Fraga; +Cc: orgmode

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)



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
       [not found]     ` <87im3prvz8.fsf@ucl.ac.uk>
@ 2021-05-11 18:25       ` Juan Manuel Macías
  0 siblings, 0 replies; 12+ messages in thread
From: Juan Manuel Macías @ 2021-05-11 18:25 UTC (permalink / raw)
  To: Eric S Fraga; +Cc: orgmode

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Possibility of using alternative separators in macros
  2021-05-02 21:08       ` Christian Moe
@ 2021-05-12 11:49         ` Maxim Nikulin
  0 siblings, 0 replies; 12+ messages in thread
From: Maxim Nikulin @ 2021-05-12 11:49 UTC (permalink / raw)
  To: emacs-orgmode

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.



^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-05-12 11:50 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-30 13:26 [PATCH] Possibility of using alternative separators in macros Juan Manuel Macías
2021-05-01  8:30 ` Bastien
2021-05-01 10:04   ` Nicolas Goaziou
2021-05-01 10:17     ` Bastien
2021-05-01 10:18     ` Bastien
2021-05-01 21:50     ` Juan Manuel Macías
2021-05-02 21:08       ` Christian Moe
2021-05-12 11:49         ` Maxim Nikulin
2021-05-02 12:13     ` Eric S Fraga
2021-05-11 11:01 ` Eric S Fraga
2021-05-11 16:12   ` Juan Manuel Macías
     [not found]     ` <87im3prvz8.fsf@ucl.ac.uk>
2021-05-11 18:25       ` Juan Manuel Macías

Org-mode mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://orgmode.org/list/0 list/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 list list/ https://orgmode.org/list \
		emacs-orgmode@gnu.org
	public-inbox-index list

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.orgmode
	nntp://news.gmane.io/gmane.emacs.orgmode


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git