From: Bastien <bzg@gnu.org>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: michael.ch.brand@gmail.com, emacs-orgmode@gnu.org,
Yasushi SHOJI <yashi@atmark-techno.com>
Subject: Re: link interfering with brackets when abbreviated
Date: Sun, 02 Mar 2014 14:22:45 +0100 [thread overview]
Message-ID: <87wqgcka56.fsf@bzg.ath.cx> (raw)
In-Reply-To: <87mwh9nf6h.fsf@gmail.com> (Nicolas Goaziou's message of "Sun, 02 Mar 2014 10:05:42 +0100")
Hi Nicolas,
Nicolas Goaziou <n.goaziou@gmail.com> 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
next prev parent reply other threads:[~2014-03-02 13:23 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-03 12:11 link interfering with brackets when abbreviated Michael Brand
2014-02-26 15:10 ` Michael Brand
2014-02-26 15:25 ` Nicolas Goaziou
2014-02-26 15:44 ` Michael Brand
2014-02-26 15:54 ` Nicolas Goaziou
2014-02-26 16:22 ` Michael Brand
2014-02-26 16:41 ` Nicolas Goaziou
2014-02-26 17:03 ` Michael Brand
2014-02-26 17:20 ` Bastien
2014-02-26 19:02 ` Nicolas Goaziou
2014-02-26 22:54 ` Bastien
2014-02-27 10:28 ` Nicolas Goaziou
2014-02-27 11:04 ` Bastien
2014-02-27 20:01 ` Michael Brand
2014-02-27 22:08 ` Bastien
2014-02-27 23:43 ` Nicolas Goaziou
2014-03-01 18:44 ` Yasushi SHOJI
2014-03-01 20:20 ` Nicolas Goaziou
2014-03-01 20:54 ` Bastien
2014-03-01 20:57 ` Bastien
2014-03-01 21:35 ` Nicolas Goaziou
2014-03-01 21:50 ` Bastien
2014-03-01 22:14 ` Nicolas Goaziou
2014-03-02 13:35 ` Bastien
2014-03-03 14:12 ` Matt Lundin
2014-03-02 0:22 ` Yasushi SHOJI
2014-03-02 9:05 ` Nicolas Goaziou
2014-03-02 13:22 ` Bastien [this message]
2014-03-02 14:27 ` Nicolas Goaziou
2014-03-02 15:49 ` Bastien
2014-03-02 16:32 ` Thorsten Jolitz
2014-03-03 3:41 ` Josiah Schwab
2014-03-03 5:54 ` Michael Brand
2014-03-03 9:50 ` Context of interaction vs. literal syntactic interpretation (was: link interfering with brackets when abbreviated) Bastien
2014-03-03 16:09 ` Context of interaction vs. literal syntactic interpretation Matt Lundin
2014-03-03 18:00 ` Nick Dokos
2014-03-03 18:13 ` Jonathan Leech-Pepin
2014-03-14 13:46 ` Sebastien Vauban
2014-03-21 8:44 ` Bastien
2014-03-21 13:17 ` Nicolas Goaziou
2014-03-23 22:51 ` Bastien
2014-03-24 13:12 ` Nicolas Goaziou
2014-03-01 18:44 ` link interfering with brackets when abbreviated Yasushi SHOJI
2014-02-26 17:42 ` Bastien
2014-02-26 21:15 ` Nicolas Goaziou
2014-02-26 22:21 ` Bastien
-- strict thread matches above, loose matches on Subject: below --
2014-03-02 21:16 Gustav Wikström
2014-03-03 1:30 ` Ista Zahn
2014-03-03 19:33 ` Samuel Wales
2014-03-03 19:46 ` Samuel Wales
2014-03-03 22:18 ` Sebastien Vauban
2014-03-03 22:33 ` Samuel Wales
[not found] ` <CAJcAo8vh0F0tqgX4=gUhJoWFcAsTiwfyi7Fp=spQeoaBog1OMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-04 12:16 ` Sebastien Vauban
2014-03-04 20:06 ` Samuel Wales
2014-03-19 11:19 ` Bastien
2014-03-03 10:58 ` Christian Moe
2014-03-03 16:11 ` Sebastien Vauban
2014-03-03 23:16 ` Robert Horn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wqgcka56.fsf@bzg.ath.cx \
--to=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=michael.ch.brand@gmail.com \
--cc=n.goaziou@gmail.com \
--cc=yashi@atmark-techno.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).