Re: [O] Context of interaction vs. literal syntactic interpretation
Hello, Bastien writes: > In the meantime, what do you think about the solution I propose? I think it is a sensible move. Regards, -- Nicolas Goaziou
Re: [O] Context of interaction vs. literal syntactic interpretation
Hi Nicolas, Nicolas Goaziou writes: >> let's finally close this thread, thanks all for your inputs. > > I'm still waiting for Carsten's input, as I need to know whether > introducing the parser in core functions is a goal for Org or not. In the meantime, what do you think about the solution I propose? -- Bastien
Re: [O] Context of interaction vs. literal syntactic interpretation
Hello, Bastien writes: > let's finally close this thread, thanks all for your inputs. I'm still waiting for Carsten's input, as I need to know whether introducing the parser in core functions is a goal for Org or not. Regards, -- Nicolas Goaziou
Re: [O] Context of interaction vs. literal syntactic interpretation
Hi all, let's finally close this thread, thanks all for your inputs. The solution I suggest is this: 1. implement multi-links opening when C-c C-o is called in a paragraph and there is no link at point (similar behavior than the one we have for links in headlines); 2. let `org-open-at-point' fall back on ffap so that raw links in comments and anywhere else can be open. (If needed, this behavior could be bound to an option.) 3. factor out `org-open-in-paragraph' and `org-open-in-headline' from `org-open-at-point' so that `org-open-at-point' does what its names says it should do. I will implement this in master. Thanks, -- Bastien
Re: [O] Context of interaction vs. literal syntactic interpretation
Matt Lundin wrote: > 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... > > * An example > : * Watch me > : <2014-03-03 Mon 9:00> FYI, I do have similar "problems" in a file (which is also part of org-agenda-files) where I have this (to explain how to use Org timestamps): --8<---cut here---start->8--- For example, a weekly report that must be filed during the following work week could be described with #+begin_src org ,SCHEDULED: <2014-03-20 Thu +1w/12d> #+end_src For ranges, you can try: #+begin_src org ,<2014-03-19 Wed 15:00-17:00 +1w>. #+end_src --8<---cut here---end--->8--- Both timestamps appear in my Org agenda when at the given date. Best regards, Seb -- Sebastien Vauban
Re: [O] Context of interaction vs. literal syntactic interpretation
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
Re: [O] Context of interaction vs. literal syntactic interpretation
Matt Lundin writes: > ... > 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). > ... I've been composing an email in my head that ran almost exactly along the lines you describe, although I doubt it would have been as clear. Thank you for sending this! Nick
Re: [O] Context of interaction vs. literal syntactic interpretation
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
[O] Context of interaction vs. literal syntactic interpretation (was: link interfering with brackets when abbreviated)
Hi Gustav, Josiah and Michael, thanks *a lot* for your feedback, it triggered an idea I want to turn into a proposal. I changed the subject of this thread to better frame the issue at stake, and explain my proposal. Emacs commands depend on their context: this is the modal approach we love. For example, M-; will behave differently whether we are in an org-mode buffer or in a html-mode buffer. The context of interaction is the relevant syntactic environment that Emacs needs to know about when a command is called. By essence, a parser is very strict about the inclusion model of syntactic elements: e.g., a tag cannot be part of a paragraph, a TODO keyword cannot be part of a timestamp, a timestamp cannot be part of a property value, a link cannot be part of a comment, etc. This is *good* to have such a strict parser and it must be as strict and consistent as possible -- we all agree on that. 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.) For handling comments, my suggestion is this to let the user decide if she wants to activate C-c C-o in comments by temporarily considering the contents of a comment as a paragraph. Something like (let ((comment-contents (org-element-property :value (org-element-context (with-temp-buffer (insert comment-contents) (org-open-at-point))) provided we preserve the relative point position. (Another route is to change the syntactic meaning of comments: they could contain paragraphs and be contained within subtrees.) Note that this suggestion does not deviate from what we already do: see the example of C-c C-o checking for a higher context when hit in headlines. So while I suggest a change for handling links in paragraphs (I do support Gustav suggestion) and in comments (see the proposal above), I don't suggest a change in the role the parser has: I only describe a frame in which what seems inconsistent is not anymore. For example, it may seem inconsistent to allow using S- to update a timestamp in a property drawer, since property drawers don't allow timestamps. But it is not inconsistent if S- is allowed to refer to a higher context (the subtree's content instead of the property drawer.) For sure, such flexibility should be the exception, not the norm, but considering it is very important in terms of user experience IMO. I hope this is clear enough and can help us moving forward. Thanks, -- Bastien
