Re: [PATCH v2] Add new entity \-- serving as markup separator/escape symbol

[Ihor Radchenko <yantar92@gmail.com>]

Samuel Wales <samologist@gmail.com> writes:

> i am not in a position to judge \-- but i like the idea of not having
> zws be used, and expect you have thought it out.
>
>
> just an idea: something approximately like this might work, or
> something like john kitchen's poc implementation of it might.  this is
> called extensible syntax.  one of the goals of es is to reduce the
> proliferation of org syntax and other stuff.
>
> es was proposed long ago, but i was unable to sufficiently follow up
> for unrelated reasons.  i have lots of replies and lots of further
> work on it but that's neither here nor there in this case.
>
> [other stuff includes but is not limited to increase reusability and
> reliability of code to implement things you want to do with syntax
> such as whether to show it, add a subfeature, export it variantly in
> different exporters, escape it, quote it, pretty-print it, etc.; allow
> user to do this so org is not burdened by it; etc.  terms to look up
> in the mailing list archives include extensible syntax, parsing risk,
> and id markers.]
>
>   $[emphasis :position beg :type bold :display "*"]bold text$[emphasis
> :position end :type bold :display "*"]

This is similar to another recent idea about inline special blocks.
Among other things, we discussed supplying parameters to such inline
special blocks. This suggestion is essentially equivalent, except you
give a slightly different syntax.

> alternatively:
>
>   $()...
>
> other than the basics, such as sexp, i do NOT care about the details
> of the $[] low level syntax in general OR the arglist details in this
> particular case.  those can change according to consensus or
> implementation needs etc.  instead, it is getting the concept across
> that matters to me.  one key thing about es is that when we want a new
> feature, we do not need new org syntax for that new feature.  OR for
> new subfeatures.  we just do something like this:
>
>   $[extended-timestamp :whatever yes :displays-as interval]
>
> or whatever.  this has nothing to do with bold emphasis.  it is an
> unrelated feature, using the same outer syntax.  another completely
> unrelated feature i'd strongly like, for emacs in general, is id
> markers.  that too can be done with this syntax.

I feel like generalizing syntax to arbitrary inline object types is a
bit too much **at this point of time**. Yes, we can do this, but a lot
of places in Org codebase depend on the existing syntax. It is not easy
to extend, for example, the code dealing with timestamps, to work with
arbitrary timestamp-like objects. Too many things are hard-coded -
changing them will be a humongous amount of work.

> merely saying that once implemented, could solve this problem and ALSO
> later problems.  in fact, we discussed coloring of text using this
> syntax.  although with various understandings of it.  that's kinda
> similar to emphasis.

Colouring was also one of the things I thought of when discussing inline
special blocks. Also, authored comments where we need to keep the author
metadata.

> i am not doing well so i am unlikely to be able to respond much or at
> all to queries.  please take it easy on me if this rubs you the wrong
> way.  it is just an idea and it does not have to be the answer.

Sorry to hear this now and recently. I am hoping that you get better
soon.

Best,
Ihor