From: Jonathan Leech-Pepin <jonathan.leechpepin@gmail.com>
To: Matt Lundin <mdl@imapmail.org>
Cc: Bastien <bzg@altern.org>,
Michael Brand <michael.ch.brand@gmail.com>,
Org Mode <emacs-orgmode@gnu.org>,
Nicolas Goaziou <n.goaziou@gmail.com>
Subject: Re: Context of interaction vs. literal syntactic interpretation
Date: Mon, 3 Mar 2014 13:13:06 -0500 [thread overview]
Message-ID: <CAEWDx5e1OFJfr_of_A9g8oNQo4MWLptgmqA3B6T77-AaY5F8BA@mail.gmail.com> (raw)
In-Reply-To: <87wqgbtiff.fsf@fastmail.fm>
[-- Attachment #1: Type: text/plain, Size: 5466 bytes --]
Hello,
On 3 March 2014 11:09, Matt Lundin <mdl@imapmail.org> wrote:
> Bastien <bzg@altern.org> writes:
> >
> > For most commands, the first literal syntactic interpretation is the
> > only relevant context of interaction: e.g., it would not make sense to
> > try updating a tag outside of a headline (i.e. outside of where a tag
> > is a tag, from the parser's view.)
> >
> > For some commands, another higher context can also be relevant: e.g.,
> > when the point is on a heading and the user hit C-c C-o, Org needs to
> > know whether we are on a link (in this case it will open the link). If
> > not, it checks for a higher context: when we are on a heading, it will
> > look for multiple links and prompt the user for which one to open.
> >
> > (A generalization of this "links-in-a-heading" behavior for something
> > like "links-in-a-paragraph", as suggested by Gustav, is a good idea.)
>
> Is the question here perhaps a simple one of refactoring?
>
> Nicolas is doing amazing work at making org file parsing more
> systematic, precise, and predictable. (Thank you!) And I agree with him
> that a function named org-open-link-at-point should, for the sake of
> precision and consistency, only open a link at the point.
>
> I also agree that such a function should do nothing in the context of a
> comment, which should simply be a string. FWIW, it seems to me that
> there are still several places in the source code that could be cleaned
> up in this way. For instance, org-mode code examples designated for
> export have unwanted effects in the agenda. Try putting this in an
> agenda file...
>
> --8<---------------cut here---------------start------------->8---
> * An example
> : * Watch me
> : <2014-03-03 Mon 9:00>
> --8<---------------cut here---------------end--------------->8---
>
> The problem, it seems to me, is that org-open-at-point is ambiguously
> named. The last bit, "at-point", suggests a precise scope, but the
> beginning "org-open" implies a broad, fuzzy scope (i.e., it is not clear
> what is being opened). The problem is that org-open-at-point doubles as
> a meta function and a more precise function to open links at the point
> --- i.e., it implements within itself all the internals this more
> precise task.
>
> Org, of course, has a lot of helpful "dwim" functions (e.g.,
> org-meta-return, org-cycle, etc.). I would not want to lose these. As
> Bastien suggested, these functions are precisely what make org-mode so
> easy and intuitive to use. However, org has historically implemented
> many of its internals in an ad-hoc fashion within very large functions.
> This has led to some redundancy and opacity. This is especially true for
> a function like org-open-at-point, which is both precise and broad. This
> is where org-mode stands a lot to gain from refactoring the code base
> around Nicolas's parser.
>
> My view is that precision and usability need not be mutually exclusive.
> Might we have a bunch of precise, modular functions that rely on the new
> parser? E.g., something like org-open-link-at-point. This would do
> exactly what it says -- i.e., open a link if one is at the point. Then,
> on top of these function s we could rebuild fuzzier "meta" and "dwim"
> functions (e.g., org-open-links-in-paragraph, org-open-links-in-entry,
> org-meta-open, org-open-at-point,... whatever).
>
> In short, I am excited by the potential that the parser provides to make
> the code base more transparent, granular, and precise.
>
> Matt
I have to agree with Nicolas' opion and Matt's take on how it could be
implemented.
Have org-open-at-point do exactly what it says, act on what is at
point (be it a link, a timestamp, a footnote definition, etc).
Then have C-c C-o be a one of the meta overloaded functions that finds
context and acts on it accordingly:
- If object at point can be opened, opened it
- If in a paragraph, find all actionable[1] items and offer them for
selection
- If on a headline, find all actionable[1] items and offer them for
selection
[1] Footnotes and links In my opinion you wouldn't want it to also
include timestamps (for paragraphs and headlines) and tags (for
headlines) because those are agenda commands rather than navigation
commands.
If I'm on a timestamp or tag, opening it makes sense. If I'm trying
to open from a headline/paragraph, I'm likely looking for links (which
can include footnotes since they link to another portion of the
document) so wouldn't want agenda commands. Or have it customizable
as a set of alists that map what should be collected at what level.
For example:
#+begin_src emacs-lisp
(setq org-open-context '((point . 'org-open-at-point)
(footnote . 'nil)
(sourceblock . 'nil)
(table . 'nil)
(paragraph . 'org-open-collect-links)
(headline . 'org-open-collect-links)))
#+end_src
If something of this sort is then implemented on all the various
overloaded commands (M-Ret, C-Ret, C-c C-c, etc) it should reduce at
least some of the reinvention of similar facilities in the various
functions, with the meta-commands all configured to test for context,
then pick the appropriate behaviour based on context.
This will also allow for more customization by allowing users to
define what behaviour any given meta-command has at each context level
to best fit their workflow and desired logic.
Regards,
Jonathan
[-- Attachment #2: Type: text/html, Size: 6621 bytes --]
next prev parent reply other threads:[~2014-03-03 18:13 UTC|newest]
Thread overview: 46+ 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
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 [this message]
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
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=CAEWDx5e1OFJfr_of_A9g8oNQo4MWLptgmqA3B6T77-AaY5F8BA@mail.gmail.com \
--to=jonathan.leechpepin@gmail.com \
--cc=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
--cc=mdl@imapmail.org \
--cc=michael.ch.brand@gmail.com \
--cc=n.goaziou@gmail.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).