Re: [O] Context of interaction vs. literal syntactic interpretation

[Jonathan Leech-Pepin]

Hello,

On 3 March 2014 11:09, Matt Lundin <address@hidden> wrote:

Bastien <address@hidden> 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