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