Re: [PATCH] Possibility of using alternative separators in macros
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
Re: [PATCH] Possibility of using alternative separators in macros
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
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
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/s7g...@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
Hi Juan, 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/s7g...@ciao.gmane.io/) Yes, probably -- feel free to propose a patch for this. Thanks! -- Bastien
Re: [PATCH] Possibility of using alternative separators in macros
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/s7g...@ciao.gmane.io/) Best regards, Juan Manuel
Re: [PATCH] Possibility of using alternative separators in macros
Hi Juan, Juan Manuel Macías 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
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
Hi Juan, Juan Manuel Macías 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
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
Here is the fixed version of the patch.
Best regards,
Juan Manuel
Eric S Fraga writes:
> Could you create a new patch so I can try this easily?
>
> gracias,
> eric
>From 4aae61c3600fba136dfa101d54011c0aef9169a3 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macías
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
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@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) ( $1 _) (progn (message "Getting constant
> %s" $1) (org-table-get-constant $1))) ("input-file" . "m.org")
> ("modification-time" . #f(compiled-function (arg1 arg2
> _) #)) ("keyword" lambda (arg1 _)
> (org-macro--find-keyword-value arg1)) ("n" lambda ( arg1 arg2
> _) (org-macro--counter-increment arg1 arg2)) ("property" lambda
> (arg1 arg2 _) (org-macro--get-property arg1 arg2))
> ("time" lambda (arg1 _) (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 () #))
> 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
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@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) ( $1 _) (progn (message "Getting constant %s" $1)
(org-table-get-constant $1))) ("input-file" . "m.org") ("modification-time" .
#f(compiled-function (arg1 arg2 _) #)) ("keyword" lambda (arg1 _)
(org-macro--find-keyword-value arg1)) ("n" lambda ( arg1 arg2 _)
(org-macro--counter-increment arg1 arg2)) ("property" lambda (arg1
arg2 _) (org-macro--get-property arg1 arg2)) ("time" lambda (arg1
_) (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 () #))
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
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:@@ :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 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
(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
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 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
Nicolas Goaziou 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
Nicolas Goaziou 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
Hello,
Bastien 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
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
