From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Leech-Pepin Subject: Re: Context of interaction vs. literal syntactic interpretation Date: Mon, 3 Mar 2014 13:13:06 -0500 Message-ID: References: <87lhwxswby.fsf@gmail.com> <87ha7lsu5o.fsf@gmail.com> <8761o1n63t.fsf@bzg.ath.cx> <8738j5snms.fsf@gmail.com> <87vbw11o3q.fsf@bzg.ath.cx> <87ppm8rgrf.fsf@gmail.com> <87lhwwgqe4.fsf@bzg.ath.cx> <878uswqfzc.fsf@gmail.com> <87zjl9vjw4.wl@dns1.atmark-techno.com> <87ha7hpt6l.fsf@gmail.com> <87wqgdv48n.wl@dns1.atmark-techno.com> <87mwh9nf6h.fsf@gmail.com> <87wqgcka56.fsf@bzg.ath.cx> <87y50sn09o.fsf@gmail.com> <878ussk3c7.fsf@bzg.ath.cx> <87siqzhapq.fsf@bzg.ath.cx> <87wqgbtiff.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1133dee66e187204f3b7be55 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKXMo-0003Wl-AZ for emacs-orgmode@gnu.org; Mon, 03 Mar 2014 13:13:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKXMk-0005ze-Vs for emacs-orgmode@gnu.org; Mon, 03 Mar 2014 13:13:30 -0500 Received: from mail-qc0-x232.google.com ([2607:f8b0:400d:c01::232]:64340) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKXMk-0005zN-QN for emacs-orgmode@gnu.org; Mon, 03 Mar 2014 13:13:26 -0500 Received: by mail-qc0-f178.google.com with SMTP id i8so4149568qcq.37 for ; Mon, 03 Mar 2014 10:13:26 -0800 (PST) In-Reply-To: <87wqgbtiff.fsf@fastmail.fm> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Matt Lundin Cc: Bastien , Michael Brand , Org Mode , Nicolas Goaziou --001a1133dee66e187204f3b7be55 Content-Type: text/plain; charset=UTF-8 Hello, On 3 March 2014 11:09, Matt Lundin wrote: > Bastien 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 --001a1133dee66e187204f3b7be55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

On 3 March 2014 11:09, Matt Lundin <<= a href=3D"mailto:mdl@imapmail.org" target=3D"_blank">mdl@imapmail.org&g= t; 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<= br> > is a tag, from the parser's view.)
>
> For some commands, another higher context can also be relevant: e.g.,<= br> > when the point is on a heading and the user hit C-c C-o, Org needs to<= br> > know whether we are on a link (in this case it will open the link). = =C2=A0If
> 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 go= od 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
: =C2=A0<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 th= e
beginning "org-open" implies a broad, fuzzy scope (i.e., it is no= t 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 &q= uot;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' o= pion 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<= br>context and acts on it accordingly:

- If object at point can be o= pened, opened it
- If in a paragraph, find all actionable[1] items and o= ffer them for
=C2=A0 selection
- If on a headline, find all actionable[1] items and of= fer them for
=C2=A0 selection

[1] Footnotes and links In my opini= on you wouldn't want it to also
include timestamps (for paragraphs a= nd headlines) and tags (for
headlines) because those are agenda commands rather than navigation
comm= ands.

If I'm on a timestamp or tag, opening it makes sense.=C2= =A0 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.=C2=A0 Or have it customizable
as= a set of alists that map what should be collected at what level.
For ex= ample:

#+begin_src emacs-lisp
=C2=A0 (setq org-open-context '((point . = 'org-open-at-point)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (footnote . 'nil)
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (sourceb= lock . 'nil)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 (table . 'nil)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (paragraph . 'org-open-collect-links)
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (headline . &#= 39;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
lea= st some of the reinvention of similar facilities in the various
function= s, 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
def= ine what behaviour any given meta-command has at each context level
to b= est fit their workflow and desired logic.

Regards,
Jonathan
--001a1133dee66e187204f3b7be55--