Re: [O] [RFC] Syntax for macros
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:
Would this be possible? If so, would you want that as well?
Reducing to {{...}} could be better, but I'm not sure this is
what will make your friends happy :)
Not entirely, no! But I think that'd be already a good
simplification.
Added to my will-silently-see-if-this-makes-progress list :)
--
Bastien
Re: [O] [RFC] Syntax for macros
Bastien wrote:
Sebastien Vauban writes:
Bastien wrote:
Reducing to {{...}} could be better, but I'm not sure this is
what will make your friends happy :)
Not entirely, no! But I think that'd be already a good
simplification.
Added to my will-silently-see-if-this-makes-progress list :)
Isn't it just changing those occurrences?
--8---cut here---start-8---
./org-element.el:3177:(looking-at {{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\(([
\t\n]*\\([^\000]*?\\))\\)?}}})
./org-element.el:3217: {{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\(([
\t\n]*\\([^\000]*?\\))\\)?}}}
./org-macro.el:35:;; {{{time(format-string)}}}, {{{property(node-property)}}},
./org-macro.el:36:;; {{{input-file}}} and
{{{modification-time(format-string)}}}.
./org-macro.el:38:;; Upon exporting, ox.el will also provide {{{author}}},
{{{date}}},
./org-macro.el:39:;; {{{email}}} and {{{title}}} macros.
./org-macro.el:165: (while (re-search-forward {{{[-A-Za-z0-9_] nil t)
./org.el:6263: '({{{.+?}}} (0 'org-macro t))
./ox.el:3092:;; Expand export-specific set of macros: {{{author}}},
./ox.el:3093:;; {{{date}}}, {{{email}}} and {{{title}}}. It must be done
--8---cut here---end---8---
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [RFC] Syntax for macros
Sebastien Vauban sva-n...@mygooglest.com
writes:
Bastien wrote:
Sebastien Vauban writes:
Bastien wrote:
Reducing to {{...}} could be better, but I'm not sure this is
what will make your friends happy :)
Not entirely, no! But I think that'd be already a good
simplification.
Added to my will-silently-see-if-this-makes-progress list :)
Isn't it just changing those occurrences?
./org-element.el:3177:(looking-at {{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\(([
\t\n]*\\([^\000]*?\\))\\)?}}})
./org-element.el:3217: {{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\(([
\t\n]*\\([^\000]*?\\))\\)?}}}
./org-macro.el:35:;; {{{time(format-string)}}}, {{{property(node-property)}}},
./org-macro.el:36:;; {{{input-file}}} and
{{{modification-time(format-string)}}}.
./org-macro.el:38:;; Upon exporting, ox.el will also provide {{{author}}},
{{{date}}},
./org-macro.el:39:;; {{{email}}} and {{{title}}} macros.
./org-macro.el:165: (while (re-search-forward {{{[-A-Za-z0-9_] nil t)
./org.el:6263: '({{{.+?}}} (0 'org-macro t))
./ox.el:3092: ;; Expand export-specific set of macros: {{{author}}},
./ox.el:3093: ;; {{{date}}}, {{{email}}} and {{{title}}}. It must be done
Best regards,
Seb
There is also backwards compatibility to consider.
--
Nick
Re: [O] [RFC] Syntax for macros
Sebastien Vauban sva-n...@mygooglest.com
writes:
There is also backwards compatibility to consider.
How? You know, when many, many, many keywords or options changed
between Org 7.9 and Org 8.0, there was nothing to support backward
compatibility: much too complex, I guess.
Yes, indeed: OTOH there was widespread recognition that the ad-hoc
nature of certain things and creeping featuritis in org-mode was causing
problems and there was a consensus (at least on the list) that having
the pain concentrated in one (major) release was the way to go. I think
in general org-mode is better because of the changes, but that does not
mean that there have not been problems, as you no doubt have noticed.
That does not mean that we can push changes that break peoples'
workflows (yes, I know: http://xkcd.com/1172/ ) willy nilly. They either
have to come at major releases with plenty of warning, or they have to
be backwards compatible or there has to be widespread consensus that
that is a desirable course of action - and I'd raise the bar very high
on this last case.
Are you advocating that the macro syntax should be changed without
worrying about backwards compatibility? That might work if almost nobody
uses macros currently[fn:1], but my impression is that they are used fairly
widely.
Add a variable org-support-old-macro-syntax seems overkill to me. But,
yes, I know, that's something that will have to be clearly mentioned in
the NEWS as something that did change, and as some consequences.
No: I'm saying that if this change is implemented, {{{foo}}} should be
deprecated (probably raising a deprecation warning when encountered) and
that both {{foo}} and {{{foo}}} should work identically, at least until
the next major release (we can debate whether that's 8.3 or 8.4 or
9.0). At that point and forever after, the old syntax starts raising
errors instead of warnings.
Footnotes:
[fn:1] E.g. QUOTE was an example of a change that could go through,
precisely because nobody was using it. COMMENT could not go
quietly into oblivion in the same way however: it was used
widely.
--
Nick
Re: [O] [RFC] Syntax for macros
Nick Dokos ndo...@gmail.com writes:
Sebastien Vauban sva-n...@mygooglest.com
writes:
There is also backwards compatibility to consider.
Not only that, probability of false positives matters
too. E.g. inserting text snippets in PicoLisp Wiki Syntax into an Org
file could easily cause errors given the frequent use of {}:
,---
| 1{Contrived Example}
|
| In /{picolisp-wiki-mode} braces are !{very} important, and in PicoLisp
| itself Database objects are identified like this:
|
| :{{36}}
|
| denotes Object 36.
|
| Here is a list of objects in the DB:
|
|
| *{
|-{{11}}
|-{{36}}
|-{{45}}
| }
`---
This might be contrived, but is actually not that exotic.
--
cheers,
Thorsten
Re: [O] [RFC] Syntax for macros
Nick Dokos ndo...@gmail.com writes:
No: I'm saying that if this change is implemented, {{{foo}}} should be
deprecated (probably raising a deprecation warning when encountered) and
that both {{foo}} and {{{foo}}} should work identically, at least until
the next major release (we can debate whether that's 8.3 or 8.4 or
9.0). At that point and forever after, the old syntax starts raising
errors instead of warnings.
Agreed. Also, the whole issue is not that important IMO.
If the {{{...}}} are visually annoying, we can as well rely
on text properties to hide them and on faces to display
them in a different way (as we do already.)
--
Bastien
Re: [O] [RFC] Syntax for macros
Sebastien Vauban writes:
When trying to convince colleagues and friends to use macros, I get
kind of allergic reactions because of the many accolades.
Example:
#+MACRO: hlt @@html:span style=background-color: yellow;$1/span@@
This {{{hlt(information)}}} is important.
I wondered whether we could reduce the number of accolades to 2 or 1?
Why not just fontify them away entirely? I'm not too enamored with
these three braces in and out myself, but anything less is going to
cause trouble elsewhere, I'd think.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] [RFC] Syntax for macros
On 30.01.2014 17:59, Nick Dokos wrote:
Are you advocating that the macro syntax should be changed without
worrying about backwards compatibility? That might work if almost nobody
uses macros currently[fn:1], but my impression is that they are used fairly
widely.
The main problem is that this will affect org files in weeks, months or
years in the future, which then mysteriously fail to work as expected. I
agree, however, with Sebastien that the current syntax is a bit heavy.
Two brackets would be better, but still ugly.
A couple of alternative ideas:
1. How about using unicode characters? This would solve the problem of
false positives and allow for light markup. E.g.:
(looking-at \\(?:「\\|{{{\\)\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\(([ \t\n]*
\\([^\000]*?\\))\\)?\\(?:」\\|}}}\\))
2. On the other hand a function to insert a macro might be all we need,
e.g.:
(defun org-macro-insert ()
(interactive)
(let* ((macros (org-macro--collect-macros))
(macro (completing-read Insert macro: (mapcar 'car macros)))
(args (string-match $[[:digit:]] (cdr (assoc macro macros
pos)
(insert (format {{{%s macro))
(when args (insert () (setq pos (point)) (insert )))
(insert }}})
(when pos (goto-char pos
Maybe even hide the brackets during fontification?
3. Of course, since macros are only relevant when exporting, it should
be easy to write an export filter that translates arbitrary chars to
brackets.
--
Florian Beck
Re: [O] [RFC] Syntax for macros
Florian Beck f...@miszellen.de writes: 3. Of course, since macros are only relevant when exporting, it should be easy to write an export filter that translates arbitrary chars to brackets. I think this might be the way forward for Org mode users who don't like the look of the current macro syntax. Backwards compatibility is an issue for my work with Org mode. I'm happy to track changes that result from enhanced capabilities, but unhappy to track changes that are cosmetic, like this suggestion to change the syntax for macros. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[O] [RFC] Syntax for macros
Hello,
I know this question can be a sensible one, but I wonder whether we
couldn't remove some fat from the macro call syntax?
When trying to convince colleagues and friends to use macros, I get
kind of allergic reactions because of the many accolades.
Example:
--8---cut here---start-8---
#+MACRO: hlt @@html:span style=background-color: yellow;$1/span@@
This {{{hlt(information)}}} is important.
--8---cut here---end---8---
I wondered whether we could reduce the number of accolades to 2 or 1?
This would be much more easy to read, IMO:
--8---cut here---start-8---
This {hlt(information)} is important.
--8---cut here---end---8---
Would this be possible? If so, would you want that as well?
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [RFC] Syntax for macros
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:
This would be much more easy to read, IMO:
This {hlt(information)} is important.
But more prone to false positives.
Would this be possible? If so, would you want that as well?
Reducing to {{...}} could be better, but I'm not sure this is
what will make your friends happy :)
--
Bastien
