Florian Beck 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.
Backward
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 w
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:$1@@
>
> This {{{hlt(information)}}} is important.
>
> I wondered whether we could reduce the number of
Nick Dokos 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
Nick Dokos writes:
> "Sebastien Vauban"
> 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 {}:
,-
"Sebastien Vauban"
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 wi
Hello Nick,
Nick Dokos wrote:
> "Sebastien Vauban" 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 alr
"Sebastien Vauban"
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.
>>
>> A
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-mak
"Sebastien Vauban"
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 "wil
Hi Bastien,
Bastien wrote:
> "Sebastien Vauban" writes:
>
>> This would be much more easy to read, IMO:
>>
>> This {hlt(information)} is important.
>
> But more prone to false positives.
Because of the grouping for sub/super-scripts?
>> Would this be possible? If so, would you want that as we
"Sebastien Vauban"
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 y
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-
13 matches
Mail list logo
