Re: [O] link interfering with brackets when abbreviated

[Bastien]

Hi Nicolas,

Nicolas Goaziou <address@hidden> writes:

> And all I got so far was drama.

Please: everyone is showing great respect for your work, it is not
helpful to dismiss our contributions as "drama".  Your time is highly
valuable and so is ours.  I don't think Michael, Yasushi or me would
care replying if it was just for drama.

Here is my use-case: I often use C-c C-o as a shortcut for C-c C-x
C-n C-c C-o -- that's 2.5 shorter.  This is convenient, and I would
need a good reason for removing something that convenient.

Now there are really two issues: this one above, which can easily be
fixed by making `org-open-at-point' more flexible.  And the general
issue of when and how Org features should rely on Org syntax, as
defined by the parser.

(Whether links in comments should be treated as links by C-c C-o
belongs to the second issue, this is what I'd like to discuss now.)

To my knowledge, the first raison d'être of the parser was to create
a stable and reliable infrastructure for the export engine.  In this
case, a parser is needed, because that's the only way to consistently
have a common denominator for all export backends.

Now the parser can also be used for other features.  You already
explained the reasons very well: features will be easier to maintain,
and the whole set of features relying on the parser will evolve more
smoothly.

That said, Org syntax is not the only valid representation of an
org-mode buffer.

It is the only useful one when exporting a buffer to a certain format,
because we need to map the structure of the original contents to the
structure of the target one.  But another representation of an org-mode
buffer is the one that a user has in mind when manipulating it, part
of this representation depends on Org syntax, part of it depends on
Emacs general facilities.

For example, Emacs and the user have a notion of `end-of-line', but
Org syntax does not.  Org syntax says whitespaces after an object
belong to the object but my immediate representation says they do not.
Or we do have a notion of visual indentation (with org-indent-mode
turned on), but this does not correspond to any real content, and /a
fortiori/ to an Org syntactic element, since this is just visual
sugar.

(At this point, I feel like I'm "lecturing" the list -- I am not,
I'm just trying to express myself clearly, because I really care about
removing emotional distortion from this thread, and would like to make
my point very simple, so please bare with me.)

There is a minimalistic view of Org as the combination of a syntax and
a set of features to manipulate this syntax.  There is a maximalistic
view of Org as a syntax, a set of features to manipulate it, and a set
of Emacs facilities to manipulate the mental representation of an Org
buffer, which will *never* be the same than the parser representation.

If Org were to be a Ruby gem, then the minimalistic view would be the
right one, because libraries need to stick to common denominator and
favor predictability.  For example, in such a library, we don't care
about "\n" characters by themselves in paragraphs, because the end of
lines is irrelevant here, syntactictly speaking.

But Org is no library: it's the Emacs way to manipulate Org files.
The users' representations of their Org buffer and the affordances
that are based on them are as important as the parser representation.

Hence the case for links in comment, for example: the user read them
as links, there is no value in preventing the users to open them with
C-c C-o, and it is convenient to allow them to do so.

Long story short: when users ask for to keep a feature they find
convenient, this is no drama or conservative position, this is the
expression that their interaction with an Org buffer will be less
smooth if they have to constrain their representation to that of the
parser.

Finding the correct balance here does not impact the value of the
parser at all, quite on the contrary.  The better the parser, the
easier it will be to draw the line between the minimalistic and the
maximalistic views, even in the code.  For example, a comment in
`org-open-at-point' can clearly explain why opening the next link on
the same line is allowed, even if it makes `org-open-at-point' unpure
syntactic-wise.

In a sense, the value of the parser grows with the number of functions
that depend on it, hence the temptation to use it everywhere possible.
But IMO this does not capture the whole truth: the value of the parser
also depends on the number of decisions it helps us make regarding
these minimalistic/maximalistic trade-offs.  It is a unvaluable tool
to clearly think about features, precisely because it empowers the
developers to think in terms of syntactic elements, and see where this
thinking comes short.

I'm done: please don't stop working on the parser just because the
parser is not the only way to think about feature, and please just
remember all participants on this thread are goodwilling users who
try to make a point.

Thanks,

-- 
 Bastien