* link interfering with brackets when abbreviated
@ 2013-10-03 12:11 Michael Brand
2014-02-26 15:10 ` Michael Brand
0 siblings, 1 reply; 46+ messages in thread
From: Michael Brand @ 2013-10-03 12:11 UTC (permalink / raw)
To: Org Mode
Hi all
The recent bug report below reminds me of a comparable situation with
a bug that I wanted to report at some time:
--------------------------------
#+LINK: link-abbreviation http://www.orgmode.org/#
1) [ ] [[http://www.orgmode.org/#docs]]
2) [[link-abbreviation:docs]]
3) [ ] [[link-abbreviation:docs]]
1 bla bla [ ] [[http://www.orgmode.org/#docs]]
2 bla bla [[link-abbreviation:docs]]
3 bla bla [ ] [[link-abbreviation:docs]]
| 1 | [ ] | [[http://www.orgmode.org/#docs]] |
| 2 | | [[link-abbreviation:docs]] |
| 3 | [ ] | [[link-abbreviation:docs]] |
--------------------------------
C-c C-o with point on "1" or "2" opens the browser, on "3" I expect
the same but an error happens.
Michael
On Thu, Oct 3, 2013 at 12:56 PM, Christoph LANGE
<math.semantic.web@gmail.com> wrote:
subject: C-c C-c doesn't tick check box when pressed on a hyperlink in a
list item
> this is a bug in Org 8.2 on Emacs 24.3. I can't use
> org-submit-bug-report right now (see previous mail), so let me try this way.
>
> I have a check list like this
>
> * [X] item
> * [ ] item
>
> and some of the items contain hyperlinks. When I am on one such
> hyperlink and press C-c C-c it doesn't tick the check box but says "C-c
> C-c can do nothing useful at this location".
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: link interfering with brackets when abbreviated 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 17:42 ` Bastien 0 siblings, 2 replies; 46+ messages in thread From: Michael Brand @ 2014-02-26 15:10 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org Mode Hi Nicolas There is a recent regression that I hope I can use to revive an old unanswered thread that, as it seems to me, is perfectly related. On Thu, Oct 3, 2013 at 2:11 PM, Michael Brand <michael.ch.brand@gmail.com> wrote: > Hi all > > The recent bug report below reminds me of a comparable situation with > a bug that I wanted to report at some time: > > -------------------------------- > #+LINK: link-abbreviation http://www.orgmode.org/# > > 1) [ ] [[http://www.orgmode.org/#docs]] > 2) [[link-abbreviation:docs]] > 3) [ ] [[link-abbreviation:docs]] > > 1 bla bla [ ] [[http://www.orgmode.org/#docs]] > > 2 bla bla [[link-abbreviation:docs]] > > 3 bla bla [ ] [[link-abbreviation:docs]] > > | 1 | [ ] | [[http://www.orgmode.org/#docs]] | > | 2 | | [[link-abbreviation:docs]] | > | 3 | [ ] | [[link-abbreviation:docs]] | > -------------------------------- > > C-c C-o with point on "1" or "2" opens the browser, on "3" I expect > the same but an error happens. > > Michael > > On Thu, Oct 3, 2013 at 12:56 PM, Christoph LANGE > <math.semantic.web@gmail.com> wrote: > subject: C-c C-c doesn't tick check box when pressed on a hyperlink in a > list item >> this is a bug in Org 8.2 on Emacs 24.3. I can't use >> org-submit-bug-report right now (see previous mail), so let me try this way. >> >> I have a check list like this >> >> * [X] item >> * [ ] item >> >> and some of the items contain hyperlinks. When I am on one such >> hyperlink and press C-c C-c it doesn't tick the check box but says "C-c >> C-c can do nothing useful at this location". The above old issue with "3" remains the same on release_8.2.5h-645-g3f55b45. The recent regression is from release_8.2.5h-647-gfc9ce86 commit fc9ce86cfc1ecf7e86028027a12875a26500e774 Author: Nicolas Goaziou <n.goaziou@gmail.com> Date: Sun Feb 23 11:35:34 2014 +0100 Rewrite `org-open-at-point' using Elements and leads to the error "No link found", on all of "1", "2" and "3". And once again thank you for your work in reimplementing more and more by using org-element. Michael ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 15:10 ` Michael Brand @ 2014-02-26 15:25 ` Nicolas Goaziou 2014-02-26 15:44 ` Michael Brand 2014-02-26 17:42 ` Bastien 1 sibling, 1 reply; 46+ messages in thread From: Nicolas Goaziou @ 2014-02-26 15:25 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode Hello, Michael Brand <michael.ch.brand@gmail.com> writes: > The above old issue with "3" remains the same on > release_8.2.5h-645-g3f55b45. > > The recent regression is from release_8.2.5h-647-gfc9ce86 > > commit fc9ce86cfc1ecf7e86028027a12875a26500e774 > Author: Nicolas Goaziou <n.goaziou@gmail.com> > Date: Sun Feb 23 11:35:34 2014 +0100 > > Rewrite `org-open-at-point' using Elements > > and leads to the error "No link found", on all of "1", "2" and "3". With the following Org document: --8<---------------cut here---------------start------------->8--- #+LINK: link-abbreviation http://www.orgmode.org/# 1) [ ] [[http://www.orgmode.org/#docs]] 2) [[link-abbreviation:docs]] 3) [ ] [[link-abbreviation:docs]] 1 bla bla [ ] [[http://www.orgmode.org/#docs]] 2 bla bla [[link-abbreviation:docs]] 3 bla bla [ ] [[link-abbreviation:docs]] | 1 | [ ] | [[http://www.orgmode.org/#docs]] | | 2 | | [[link-abbreviation:docs]] | | 3 | [ ] | [[link-abbreviation:docs]] | --8<---------------cut here---------------end--------------->8--- I do not get any error, i.e, every link is opened in the browser. Did you refresh your local set-up with C-c C-c on the LINK keyword? Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 15:25 ` Nicolas Goaziou @ 2014-02-26 15:44 ` Michael Brand 2014-02-26 15:54 ` Nicolas Goaziou 0 siblings, 1 reply; 46+ messages in thread From: Michael Brand @ 2014-02-26 15:44 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org Mode Hi Nicolas On Wed, Feb 26, 2014 at 4:25 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote: > I do not get any error, i.e, every link is opened in the browser. With point exactly on all variants of "1", "2" and "3"? _On_ is also important to see the difference of "1" and "2" vs. "3" for the old issue in release_8.2.5h-645-g3f55b45, please check that too. > Did you refresh your local set-up with C-c C-c on the LINK keyword? Yes, also with C-c C-c. Anyway I used git checkout master && git pull && make cleanall uncompiled && \\ /x/arch/emacs/src/emacs -Q -L /x/git/org-mode/lisp /z/x.org with GNU Emacs 24.3.2 and now also 24.1.1 and 23.4.1. Michael ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 15:44 ` Michael Brand @ 2014-02-26 15:54 ` Nicolas Goaziou 2014-02-26 16:22 ` Michael Brand 0 siblings, 1 reply; 46+ messages in thread From: Nicolas Goaziou @ 2014-02-26 15:54 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode Michael Brand <michael.ch.brand@gmail.com> writes: > With point exactly on all variants of "1", "2" and "3"? _On_ is also > important to see the difference of "1" and "2" vs. "3" for the old > issue in release_8.2.5h-645-g3f55b45, please check that too. I don't understand. Using C-c C-o on "1" "2" or "3" will not open any link since point is not on a link anyway. So you will consistently get "No link found". Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 15:54 ` Nicolas Goaziou @ 2014-02-26 16:22 ` Michael Brand 2014-02-26 16:41 ` Nicolas Goaziou 0 siblings, 1 reply; 46+ messages in thread From: Michael Brand @ 2014-02-26 16:22 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org Mode Hi Nicolas On Wed, Feb 26, 2014 at 4:54 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote: > I don't understand. Using C-c C-o on "1" "2" or "3" will not open any > link since point is not on a link anyway. So you will consistently get > "No link found". Aha, now as I see that you removed the following from the docstring of org-open-at-point I start to get it: If there is no link at point, this function will search forward up to the end of the current line. Before I found it _very_ useful that after I navigated to the right line at last, I didn't have to navigate further within this line. That the position of point within a line with an Org list item matters for structure editing I can follow. But for org-open-at-point I do not yet understand this requirement. What is the benefit of removing the search on the same line? Michael ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 16:22 ` Michael Brand @ 2014-02-26 16:41 ` Nicolas Goaziou 2014-02-26 17:03 ` Michael Brand 0 siblings, 1 reply; 46+ messages in thread From: Nicolas Goaziou @ 2014-02-26 16:41 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode Hello, Michael Brand <michael.ch.brand@gmail.com> writes: > What is the benefit of removing the search on the same line? `org-element-context' returns the context under point, not on the other side of the line. Your are on a link, C-c C-o opens it, otherwise, it doesn't. I find it very predictable. The "feature" you are missing probably made sense in the previous implementation, since it already searched forward for a link, but it would be confusing (and more costly) in the new one. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 16:41 ` Nicolas Goaziou @ 2014-02-26 17:03 ` Michael Brand 2014-02-26 17:20 ` Bastien 0 siblings, 1 reply; 46+ messages in thread From: Michael Brand @ 2014-02-26 17:03 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org Mode Hi Nicolas On Wed, Feb 26, 2014 at 5:41 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote: > > Michael Brand <michael.ch.brand@gmail.com> writes: > >> What is the benefit of removing the search on the same line? > > `org-element-context' returns the context under point, not on the other > side of the line. Your are on a link, C-c C-o opens it, otherwise, it > doesn't. I find it very predictable. > > The "feature" you are missing probably made sense in the previous > implementation, since it already searched forward for a link, but it > would be confusing (and more costly) in the new one. I expect some users to go through the same surprise than me. Maybe that there will be enough voices to get the searching on the same line for "C-c C-o" (org-open-at-point) back. Michael ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 17:03 ` Michael Brand @ 2014-02-26 17:20 ` Bastien 2014-02-26 19:02 ` Nicolas Goaziou 0 siblings, 1 reply; 46+ messages in thread From: Bastien @ 2014-02-26 17:20 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode, Nicolas Goaziou Hi Michael, Michael Brand <michael.ch.brand@gmail.com> writes: > I expect some users to go through the same surprise than me. Maybe > that there will be enough voices to get the searching on the same line > for "C-c C-o" (org-open-at-point) back. Count me in -- this is a regression that needs to be fixed. Nicolas, any stronger objection than the one your already expressed? -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 17:20 ` Bastien @ 2014-02-26 19:02 ` Nicolas Goaziou 2014-02-26 22:54 ` Bastien 0 siblings, 1 reply; 46+ messages in thread From: Nicolas Goaziou @ 2014-02-26 19:02 UTC (permalink / raw) To: Bastien; +Cc: Michael Brand, Org Mode Hello, Bastien <bzg@gnu.org> writes: > Count me in -- this is a regression that needs to be fixed. > > Nicolas, any stronger objection than the one your already > expressed? As I said, the "end of line" is not a structural unit. Implementing that "feature", which, I must admit, I find cheesy, back will be fragile and confusing. For example, white spaces after an object still belong to an object. So in the following case: [[http://orgmode.org]] [[http://duckduckgo.com]] using C-c C-o between the two links will open the first one, but there: [[http://orgmode.org]] and [[http://duckduckgo.com]] C-c C-o on the "and" will open the second one. Also in the following example: [fn:1] This is some text [[http://orgmode.org]] C-c C-o on "some" currently triggers `org-footnote-action' since point is in a footnote definition. But with the behaviour you describe, it would be hard to predict whether it should move to the link or still open the footnote. There are many other examples. This "convenient feature" is unpredictable and not worth implementing back (not counting the fact that it wouldn't be totally trivial to do properly). Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 19:02 ` Nicolas Goaziou @ 2014-02-26 22:54 ` Bastien 2014-02-27 10:28 ` Nicolas Goaziou 0 siblings, 1 reply; 46+ messages in thread From: Bastien @ 2014-02-26 22:54 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Michael Brand, Org Mode Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > As I said, the "end of line" is not a structural unit. Implementing that > "feature", which, I must admit, I find cheesy, back will be fragile and > confusing. > > For example, white spaces after an object still belong to an > object. Well, this is counterintuitive. > So in the following case: > > [[http://orgmode.org]] [[http://duckduckgo.com]] > > using C-c C-o between the two links will open the first one, but there: > > [[http://orgmode.org]] and [[http://duckduckgo.com]] > > C-c C-o on the "and" will open the second one. This current behavior is surprising too here, and only predictable for users who know that whitespaces are part of the previous object -- i.e. nobody. > Also in the following example: > > [fn:1] This is some text [[http://orgmode.org]] > > C-c C-o on "some" currently triggers `org-footnote-action' since point > is in a footnote definition. Which is counterintuitive too! > But with the behaviour you describe, it would be hard to predict > whether it should move to the link or still open the footnote. Let me describe the behavior I favor: C-c C-o opens the link at point (i.e. "the link that the cursor is visibly on") or the next link on the same line. When on a headline and if there are several links on the same line, prompt the user for which one she wants to visit. I find it very simple and predictable. > There are many other examples. This "convenient feature" is > unpredictable and not worth implementing back (not counting the fact > that it wouldn't be totally trivial to do properly). Sorry, but the current behavior feels just too wrong. -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 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 0 siblings, 2 replies; 46+ messages in thread From: Nicolas Goaziou @ 2014-02-27 10:28 UTC (permalink / raw) To: Bastien; +Cc: Michael Brand, Org Mode Hello, Bastien <bzg@gnu.org> writes: >> For example, white spaces after an object still belong to an >> object. > > Well, this is counterintuitive. So they should belong to the next object? I don't find it more intuitive. Anyway, it's an internal representation for white spaces so it doesn't matter here. See next answer. >> So in the following case: >> >> [[http://orgmode.org]] [[http://duckduckgo.com]] >> >> using C-c C-o between the two links will open the first one, but there: >> >> [[http://orgmode.org]] and [[http://duckduckgo.com]] >> >> C-c C-o on the "and" will open the second one. > > This current behavior is surprising too here, and only predictable for > users who know that whitespaces are part of the previous object -- i.e. > nobody. That's not a problem, it is easy to remove this. C-c C-o will do nothing on white spaces after an object. >> Also in the following example: >> >> [fn:1] This is some text [[http://orgmode.org]] >> >> C-c C-o on "some" currently triggers `org-footnote-action' since point >> is in a footnote definition. > > Which is counterintuitive too! It was part of the specs of the _previous_ implementation. I didn't change anything here. But it can be removed. >> But with the behaviour you describe, it would be hard to predict >> whether it should move to the link or still open the footnote. > > Let me describe the behavior I favor: > > C-c C-o opens the link at point (i.e. "the link that the cursor is > visibly on") This is already the case (minus the trailing spaces situation) > or the next link on the same line. Not really possible, as explained before. And not intuitive, IMO. > When on a headline This is the case. > and if there are several links on the same line, prompt the user for > which one she wants to visit. Come on. This wasn't done even in the previous implementation. > I find it very simple and predictable. The only really predictable behaviour is: "open the link under point". Everything else is arguable. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-27 10:28 ` Nicolas Goaziou @ 2014-02-27 11:04 ` Bastien 2014-02-27 20:01 ` Michael Brand 1 sibling, 0 replies; 46+ messages in thread From: Bastien @ 2014-02-27 11:04 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Michael Brand, Org Mode Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > So they should belong to the next object? I don't find it more > intuitive. Anyway, it's an internal representation for white spaces so > it doesn't matter here. See next answer. I've no problem with this internal representation. > That's not a problem, it is easy to remove this. C-c C-o will do nothing > on white spaces after an object. Yes, I think that would be better. >>> Also in the following example: >>> >>> [fn:1] This is some text [[http://orgmode.org]] >>> >>> C-c C-o on "some" currently triggers `org-footnote-action' since point >>> is in a footnote definition. >> >> Which is counterintuitive too! > > It was part of the specs of the _previous_ implementation. I didn't > change anything here. Yes. There was an inconsistency in the previous implementation (as just tested from the maint branch): when point is in between two non-footnote links, C-c C-o opens the one on the right, while between [fn:1] and a http:// link, C-c C-o calls org-footnote-action iff point is within the footnote... > But it can be removed. Yes, this should be removed IMO. >>> But with the behaviour you describe, it would be hard to predict >>> whether it should move to the link or still open the footnote. >> >> Let me describe the behavior I favor: >> >> C-c C-o opens the link at point (i.e. "the link that the cursor is >> visibly on") > > This is already the case (minus the trailing spaces situation) > >> or the next link on the same line. > > Not really possible, as explained before. And not intuitive, IMO. I don't understand why this is not possible. The fact that the end of the line is not a structural element from Org's parser point of view should not prevent features that rely on some notion of "end of the line". >> When on a headline > > This is the case. > >> and if there are several links on the same line, prompt the user for >> which one she wants to visit. > > Come on. This wasn't done even in the previous implementation. When I meant is this: * Visit http://orgmode.org and http://www.gnu.org ^ When point is on the headline, the current implementation in maint is to prompt the user whether he wants to visit one of the two links. The new implementation does this too, I mentioned it for the sake of completeness -- so maybe there is a misunderstanding. >> I find it very simple and predictable. > > The only really predictable behaviour is: "open the link under point". > Everything else is arguable. Then I argue that the previous behavior, which is to open the next link on the same line, is very convenient and very human-predictable when encoutered at least once. If I'm alone in thinking this, I'm fine surrending, but I hope we can give this another chance :) -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 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 1 sibling, 1 reply; 46+ messages in thread From: Michael Brand @ 2014-02-27 20:01 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Bastien, Org Mode Hi Nicolas On Thu, Feb 27, 2014 at 11:28 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote: > The only really predictable behaviour is: "open the link under point". > Everything else is arguable. What for me is a conflict between ... 1) There are arguments to change - as you recently did in master - org-open-at-point to open only if there is a link _at point_. Just as its function name tells. 2) As a user I would like to have the possibility to open a link between point and end of line without having to navigate to the exact column. Also in modes other than Org. ... I solve for myself with the following function bound to "C-c o" (not "C-c C-o"). It moves to and opens the first link between point and end of line by simply trying point by point until it works the current org-open-at-point from master that opens only when point is on a link: #+BEGIN_SRC emacs-lisp (defun f-open-link-between-point-and-eol () "Move to and open first link between point and end of line. As long as not yet at end of line and as long as `org-open-at-point' or `browse-url-at-point' gives an error advance point by one character. For Org and other major modes." (interactive) (let ((p (point)) (err t)) (while (and (not (eolp)) (setq err (not (ignore-errors (or (cond ;; Org mode ((eq major-mode 'org-mode) (org-open-at-point)) ;; Maybe more major modes here ;; [...] ;; All other major modes (t (browse-url-at-point))) t))))) (forward-char)) (when err (goto-char p) (user-error "No link between point and end of line")))) #+END_SRC The above function does not only work for Org link and URL in Org mode but also for URL in any other major mode. The definition of what should be the alternative link when there is no link at the starting point is simply delegated to org-open-at-point and browse-url-at-point. This simplification makes it slow for links towards the end or not present in long lines. There is plenty of room for a better implementation than I did with this very simple first approach. In the case that, depending on user feedback, even "C-c C-o" itself should move to the first link between point and end of line - or whatever other link - also when there is no link at the starting point, I suggest to keep org-open-at-point to open only when point is on a link and to wrap this move into a new function, named e. g. org-open-between-point-and-eol to be bound to "C-c C-o". The simplified solution with f-open-link-between-point-and-eol already covers all my use cases of the old org-open-at-point. The predictability of what will be the alternative link remains arguable. I find its predictability at least better than with the old org-open-at-point. And last but not least also the original issue #+LINK: link-abbreviation http://www.orgmode.org/# 1) [ ] [[http://www.orgmode.org/#docs]] 2) [[link-abbreviation:docs]] 3) [ ] [[link-abbreviation:docs]] of this thread with point on the character "3" is of course solved for me. Michael ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-27 20:01 ` Michael Brand @ 2014-02-27 22:08 ` Bastien 2014-02-27 23:43 ` Nicolas Goaziou 0 siblings, 1 reply; 46+ messages in thread From: Bastien @ 2014-02-27 22:08 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode, Nicolas Goaziou Hi Nicolas, you just updated `org-open-at-point' without reimplementing the previous behavior -- is this work in progress? If it is not, I suggest to discuss the change before implementing it. Nobody ever complained about the previous behavior, and both Michael and me are suppporting it. Thanks for considering this, -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-27 22:08 ` Bastien @ 2014-02-27 23:43 ` Nicolas Goaziou 2014-03-01 18:44 ` Yasushi SHOJI 2014-03-01 18:44 ` link interfering with brackets when abbreviated Yasushi SHOJI 0 siblings, 2 replies; 46+ messages in thread From: Nicolas Goaziou @ 2014-02-27 23:43 UTC (permalink / raw) To: Bastien; +Cc: Michael Brand, Org Mode Hello, Bastien <bzg@altern.org> writes: > you just updated `org-open-at-point' without reimplementing the > previous behavior -- is this work in progress? No, it isn't. I fixed the bugs we discussed, and one reported on the ML. > If it is not, I suggest to discuss the change before implementing it. > Nobody ever complained about the previous behavior, and both Michael > and me are suppporting it. I didn't remove that non-essential feature for my pleasure, but because it didn't fit in the new internal model. As I already said, implementing it back is a bit of work and will probably not be very clean. Why bother? Anyway, I don't understand why there is so much fuss about this. As you well know, Org provides `org-next-link' (which is bound to C-c C-x C-n), and Emacs provides incremental search. Do you, or Michael, honestly open so many links that an additional C-s ... RET to move on each of them is too much? There is also `org-open-at-point-functions', which can probably be used here. I think that the coolness of the feature eludes me for all I can see is a crude hack. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-27 23:43 ` Nicolas Goaziou @ 2014-03-01 18:44 ` Yasushi SHOJI 2014-03-01 20:20 ` Nicolas Goaziou 2014-03-01 18:44 ` link interfering with brackets when abbreviated Yasushi SHOJI 1 sibling, 1 reply; 46+ messages in thread From: Yasushi SHOJI @ 2014-03-01 18:44 UTC (permalink / raw) To: n.goaziou; +Cc: bzg, michael.ch.brand, emacs-orgmode Hi Nicolas, At Fri, 28 Feb 2014 00:43:19 +0100, Nicolas Goaziou wrote: > > Bastien <bzg@altern.org> writes: > > > If it is not, I suggest to discuss the change before implementing it. > > Nobody ever complained about the previous behavior, and both Michael > > and me are suppporting it. > > I didn't remove that non-essential feature for my pleasure, but because > it didn't fit in the new internal model. As I already said, implementing > it back is a bit of work and will probably not be very clean. Why > bother? Let's separate those internal parser thing and interactive commands, while we discus. I agree to Nicolas that parser and internal functions should NOT be ambiguous nor confusing. However, we humans are not machines nor slave of computers. We tell computers what we want, or even, we want to make computers think and do what we are thinking. That's the reason why we, these days, have *-dwim commands. We don't want to make our users to adopt how computers work. > Anyway, I don't understand why there is so much fuss about this. That's because a) the commands have been working, b) many other commands _do_ work even if it's not right on the elements. ie. S-right right after a timestamp, C-c C-c on checkbox list. Are you planning to remove these features, too? > I think that the coolness of the feature eludes me for all I can see is > a crude hack. What if we create org-open-at-point-dwim and map to C-c C-o. Nicolas, do you object? Anyway, thank you Nicolas for your work. We all appreciate your great work. Thanks, -- yashi ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-01 18:44 ` Yasushi SHOJI @ 2014-03-01 20:20 ` Nicolas Goaziou 2014-03-01 20:54 ` Bastien 2014-03-02 0:22 ` Yasushi SHOJI 0 siblings, 2 replies; 46+ messages in thread From: Nicolas Goaziou @ 2014-03-01 20:20 UTC (permalink / raw) To: Yasushi SHOJI; +Cc: bzg, michael.ch.brand, emacs-orgmode Hello, Yasushi SHOJI <yashi@atmark-techno.com> writes: > However, we humans are not machines nor slave of computers. We tell > computers what we want, or even, we want to make computers think and > do what we are thinking. That's the reason why we, these days, have > *-dwim commands. We don't want to make our users to adopt how > computers work. This is one of the things that annoy me: opening next link on the same line is not, IMO, "dwim". See below. >> Anyway, I don't understand why there is so much fuss about this. > > That's because a) the commands have been working This is not a sufficient reason. We are discussing a minor feature. Removing it doesn't remove any functionality to Org, as the "thing" just saves a few keystrokes, on a good day. While re-implementing the function, it appears that the feature just doesn't fit. So this is a good time to ponder about its real usefulness, and, if it is worth bending the new function to add it back. I think it isn't. As I already said, opening the next link in the same line is dubious. In the following example, with point between the links, the previous behaviour was to open "link2": [[link1]] [[link2]] Now consider the following case, where point is before the "a": [[link1]] a very ... very long line of text [[link2]] The previous behaviour implied to also open "link2". This is not really straightforward. Worse, if `visual-line-mode' is on, [[link2]] can be many lines below. In the following case, with point still before the first "a", opening [[link2]] is just odd: [[link1]] a very ... very long line which spans over many visual lines of text [[link2]]. It is odd because in the same situation, without `visual-line-mode' but with `auto-fill-mode' on, C-c C-o will report "No link found". So, why do we care about the same line? We could as well open the next link in the same paragraph (or verse block, table cell). I'm not arguing for the latter, but I insist on the fact that opening "next link on the same line" is arbitrary and not really "dwim". OTOH, I'm sure Emacs users know (beginners aside, but they'll learn soon) how to move quickly point wherever they want, without even thinking about it. > b) many other commands _do_ work even if it's not right on the > elements. ie. S-right right after a timestamp, C-c C-c on checkbox > list. Are you planning to remove these features, too? C-c C-c already uses Elements. I'll leave S-right for another day. >> I think that the coolness of the feature eludes me for all I can see is >> a crude hack. > > What if we create org-open-at-point-dwim and map to C-c C-o. Nicolas, > do you object? Implementing it in `org-open-at-point' or `org-open-at-point-whatever' is still implementing it in Org. I still think it's not worth it. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 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-02 0:22 ` Yasushi SHOJI 1 sibling, 2 replies; 46+ messages in thread From: Bastien @ 2014-03-01 20:54 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: michael.ch.brand, emacs-orgmode, Yasushi SHOJI Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > I insist on the fact that opening "next link on the > same line" is arbitrary and not really "dwim". And we insist on keeping the previous behavior, please trust us. Right now the speedy command `o' is broken. This is a pattern I use very frequently: use `n' to navigate to the next headline, then `o' to open the link there. Also `org-agenda-open-link' is now broken. Can you have a look and fix this later issue? I will then re-add the previous behavior on `org-open-at-point'. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-01 20:54 ` Bastien @ 2014-03-01 20:57 ` Bastien 2014-03-01 21:35 ` Nicolas Goaziou 1 sibling, 0 replies; 46+ messages in thread From: Bastien @ 2014-03-01 20:57 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: michael.ch.brand, emacs-orgmode, Yasushi SHOJI Hi again, Bastien <bzg@gnu.org> writes: > Right now the speedy command `o' is broken. This is a pattern I > use very frequently: use `n' to navigate to the next headline, > then `o' to open the link there. Forget about this -- some draft code of mine interfered. > Also `org-agenda-open-link' is now broken. This one is really broken. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 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 1 sibling, 1 reply; 46+ messages in thread From: Nicolas Goaziou @ 2014-03-01 21:35 UTC (permalink / raw) To: Bastien; +Cc: michael.ch.brand, emacs-orgmode, Yasushi SHOJI Bastien <bzg@gnu.org> writes: > And we insist on keeping the previous behavior, please trust us. This is not a matter of trust. I asked about use-cases to understand why this feature was needed, and all I got was "because it was here". > Also `org-agenda-open-link' is now broken. > > Can you have a look and fix this later issue? Would you mind elaborating a bit about it? > I will then re-add the previous behavior on `org-open-at-point'. I guess that closes the discussion then. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-01 21:35 ` Nicolas Goaziou @ 2014-03-01 21:50 ` Bastien 2014-03-01 22:14 ` Nicolas Goaziou 0 siblings, 1 reply; 46+ messages in thread From: Bastien @ 2014-03-01 21:50 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: michael.ch.brand, emacs-orgmode, Yasushi SHOJI Nicolas Goaziou <n.goaziou@gmail.com> writes: > Bastien <bzg@gnu.org> writes: > >> And we insist on keeping the previous behavior, please trust us. > > This is not a matter of trust. I asked about use-cases to understand why > this feature was needed, and all I got was "because it was here". More precisely, the answer was: because we use it and find it useful. >> Also `org-agenda-open-link' is now broken. >> >> Can you have a look and fix this later issue? > > Would you mind elaborating a bit about it? C-c C-o throws a "No link found" message when hit on a link in an agenda view. >> I will then re-add the previous behavior on `org-open-at-point'. > > I guess that closes the discussion then. We can raise again the discussion about suppressing this feature any time but I personally think this is a waste of time. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-01 21:50 ` Bastien @ 2014-03-01 22:14 ` Nicolas Goaziou 2014-03-02 13:35 ` Bastien 0 siblings, 1 reply; 46+ messages in thread From: Nicolas Goaziou @ 2014-03-01 22:14 UTC (permalink / raw) To: Bastien; +Cc: michael.ch.brand, emacs-orgmode, Yasushi SHOJI Bastien <bzg@gnu.org> writes: >> This is not a matter of trust. I asked about use-cases to understand why >> this feature was needed, and all I got was "because it was here". > > More precisely, the answer was: because we use it and find it useful. Thank you for the precision. Now, what about caring to give me one (or more) use case? >>> Also `org-agenda-open-link' is now broken. >>> >>> Can you have a look and fix this later issue? >> >> Would you mind elaborating a bit about it? > > C-c C-o throws a "No link found" message when hit on a link in an > agenda view. Sorry for not being clear. I did try, I didn't get any error. My dummy entry was: * TODO [[http://orgmode.org]] in a block agenda and * [[http://orgmode.org]] DEADLINE: <2014-03-01 sam.> in regular agenda. Both times, I could open the link. So, could you send me a dummy entry where the bug can be reproduced? It will save me a lot of time. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-01 22:14 ` Nicolas Goaziou @ 2014-03-02 13:35 ` Bastien 2014-03-03 14:12 ` Matt Lundin 0 siblings, 1 reply; 46+ messages in thread From: Bastien @ 2014-03-02 13:35 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: michael.ch.brand, emacs-orgmode, Yasushi SHOJI Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > Sorry for not being clear. I did try, I didn't get any error. My dummy > entry was: > > * TODO [[http://orgmode.org]] > > in a block agenda and > > * [[http://orgmode.org]] > DEADLINE: <2014-03-01 sam.> > > in regular agenda. > > Both times, I could open the link. So, could you send me a dummy entry > where the bug can be reproduced? It will save me a lot of time. Sorry, all my time has been swallowed by my rant, I will try to provide a reproducible recipe later on -- but the error is real. It works for small files I tested, but not for my real agenda files. I suspect maybe the lazy parsing of open-but-not-yet-visible agenda files somehow prevents the links to get opened. Maybe someone else can also report if C-c C-o works on his agendas. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-02 13:35 ` Bastien @ 2014-03-03 14:12 ` Matt Lundin 0 siblings, 0 replies; 46+ messages in thread From: Matt Lundin @ 2014-03-03 14:12 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode, michael.ch.brand, Nicolas Goaziou, Yasushi SHOJI Bastien <bzg@gnu.org> writes: > Hi Nicolas, > > Nicolas Goaziou <n.goaziou@gmail.com> writes: > >> Sorry for not being clear. I did try, I didn't get any error. My dummy >> entry was: >> >> * TODO [[http://orgmode.org]] >> >> in a block agenda and >> >> * [[http://orgmode.org]] >> DEADLINE: <2014-03-01 sam.> >> >> in regular agenda. >> >> Both times, I could open the link. So, could you send me a dummy entry >> where the bug can be reproduced? It will save me a lot of time. > > Sorry, all my time has been swallowed by my rant, I will try to > provide a reproducible recipe later on -- but the error is real. > > It works for small files I tested, but not for my real agenda files. > I suspect maybe the lazy parsing of open-but-not-yet-visible agenda > files somehow prevents the links to get opened. > > Maybe someone else can also report if C-c C-o works on his agendas. I cannot reproduce this (though I do have trouble opening escaped links -- see bug report in another thread). Matt ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-01 20:20 ` Nicolas Goaziou 2014-03-01 20:54 ` Bastien @ 2014-03-02 0:22 ` Yasushi SHOJI 2014-03-02 9:05 ` Nicolas Goaziou 1 sibling, 1 reply; 46+ messages in thread From: Yasushi SHOJI @ 2014-03-02 0:22 UTC (permalink / raw) To: n.goaziou; +Cc: bzg, michael.ch.brand, emacs-orgmode Hi Nicolas, Thanks for your time. At Sat, 01 Mar 2014 21:20:18 +0100, Nicolas Goaziou wrote: > > >> Anyway, I don't understand why there is so much fuss about this. > > > > That's because a) the commands have been working > > This is not a sufficient reason. We are discussing a minor feature. > Removing it doesn't remove any functionality to Org, as the "thing" just > saves a few keystrokes, on a good day. Ok. If this is yet another bickshed, I'll drop from the discussion. > While re-implementing the function, it appears that the feature just > doesn't fit. So this is a good time to ponder about its real usefulness, > and, if it is worth bending the new function to add it back. I think it > isn't. > > As I already said, opening the next link in the same line is dubious. In > the following example, with point between the links, the previous > behaviour was to open "link2": > > [[link1]] [[link2]] > > Now consider the following case, where point is before the "a": > > [[link1]] a very ... very long line of text [[link2]] > > The previous behaviour implied to also open "link2". This is not > really straightforward. If the point is before the "a", that means the point is right after the link, it should open `link1' instead of `link2', IMNSHO. This isn't even the previous behavior, I admit, but if you move the pointer to the end of the line (that's right after the link2), it _opened_ links2. This behavior works quite well with Emacs' cursor movement. ;; uga, `forward-word' doesn't work as I expected on ;; [[http://google.com][google]]. It stops at the first `o'. > Worse, if `visual-line-mode' is on, > [[link2]] can be many lines below. In the following case, with point > still before the first "a", opening [[link2]] is just odd: > > [[link1]] a very ... very long line > which spans over many visual lines > of text [[link2]]. > > It is odd because in the same situation, without `visual-line-mode' but > with `auto-fill-mode' on, C-c C-o will report "No link found". Both should report "No link found". `org-end-of-line' takes care of `visual-line-mode', why not `org-open-at-link'? -- yashi ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-02 0:22 ` Yasushi SHOJI @ 2014-03-02 9:05 ` Nicolas Goaziou 2014-03-02 13:22 ` Bastien 0 siblings, 1 reply; 46+ messages in thread From: Nicolas Goaziou @ 2014-03-02 9:05 UTC (permalink / raw) To: Yasushi SHOJI; +Cc: bzg, michael.ch.brand, emacs-orgmode Hello, Yasushi SHOJI <yashi@atmark-techno.com> writes: > At Sat, 01 Mar 2014 21:20:18 +0100, > Nicolas Goaziou wrote: >> >> This is not a sufficient reason. We are discussing a minor feature. >> Removing it doesn't remove any functionality to Org, as the "thing" just >> saves a few keystrokes, on a good day. > > Ok. If this is yet another bickshed, I'll drop from the discussion. This whole thread is about bikeshedding, no "if" involved. Though, I'm struggling to get a constructive discussion. I asked a couple of times already in what cases that feature was useful, in order to understand what some users were missing. I even gave examples about the inconsistencies in the previous implementation. And all I got so far was drama. >> Now consider the following case, where point is before the "a": >> >> [[link1]] a very ... very long line of text [[link2]] >> >> The previous behaviour implied to also open "link2". This is not >> really straightforward. > > If the point is before the "a", that means the point is right after > the link, it should open `link1' instead of `link2', IMNSHO. This > isn't even the previous behavior, I admit, ... which is my point: the previous behaviour was wrong. > but if you move the pointer to the end of the line (that's right after > the link2), it _opened_ links2. This behavior works quite well with > Emacs' cursor movement. The rewrite did it a few commits ago, but then I was asked to ignore white spaces after a link, which include the first position after the link. I agree I should make a special case here. > ;; uga, `forward-word' doesn't work as I expected on > ;; [[http://google.com][google]]. It stops at the first `o'. I do not understand this. >> Worse, if `visual-line-mode' is on, >> [[link2]] can be many lines below. In the following case, with point >> still before the first "a", opening [[link2]] is just odd: >> >> [[link1]] a very ... very long line >> which spans over many visual lines >> of text [[link2]]. >> >> It is odd because in the same situation, without `visual-line-mode' but >> with `auto-fill-mode' on, C-c C-o will report "No link found". > > Both should report "No link found". `org-end-of-line' takes care of > `visual-line-mode', why not `org-open-at-link'? I don't know. I just remark that the previous implementation didn't take care of `visual-line-mode'. Again, I'm asking to think again the "feature" because it is ill-defined and doesn't make sense at the moment. Without a correct specification, it is not worth re-implementing. With examples, I could understand the real scope involved (even though your message gives me indications about it) and the type of links we're talking about (it is easy and quite cheap to find the next link of a given type, much expensive to look after every possible type). Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-02 9:05 ` Nicolas Goaziou @ 2014-03-02 13:22 ` Bastien 2014-03-02 14:27 ` Nicolas Goaziou 0 siblings, 1 reply; 46+ messages in thread From: Bastien @ 2014-03-02 13:22 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: michael.ch.brand, emacs-orgmode, Yasushi SHOJI Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > And all I got so far was drama. Please: everyone is showing great respect for your work, it is not helpful to dismiss our contributions as "drama". Your time is highly valuable and so is ours. I don't think Michael, Yasushi or me would care replying if it was just for drama. Here is my use-case: I often use C-c C-o as a shortcut for C-c C-x C-n C-c C-o -- that's 2.5 shorter. This is convenient, and I would need a good reason for removing something that convenient. Now there are really two issues: this one above, which can easily be fixed by making `org-open-at-point' more flexible. And the general issue of when and how Org features should rely on Org syntax, as defined by the parser. (Whether links in comments should be treated as links by C-c C-o belongs to the second issue, this is what I'd like to discuss now.) To my knowledge, the first raison d'être of the parser was to create a stable and reliable infrastructure for the export engine. In this case, a parser is needed, because that's the only way to consistently have a common denominator for all export backends. Now the parser can also be used for other features. You already explained the reasons very well: features will be easier to maintain, and the whole set of features relying on the parser will evolve more smoothly. That said, Org syntax is not the only valid representation of an org-mode buffer. It is the only useful one when exporting a buffer to a certain format, because we need to map the structure of the original contents to the structure of the target one. But another representation of an org-mode buffer is the one that a user has in mind when manipulating it, part of this representation depends on Org syntax, part of it depends on Emacs general facilities. For example, Emacs and the user have a notion of `end-of-line', but Org syntax does not. Org syntax says whitespaces after an object belong to the object but my immediate representation says they do not. Or we do have a notion of visual indentation (with org-indent-mode turned on), but this does not correspond to any real content, and /a fortiori/ to an Org syntactic element, since this is just visual sugar. (At this point, I feel like I'm "lecturing" the list -- I am not, I'm just trying to express myself clearly, because I really care about removing emotional distortion from this thread, and would like to make my point very simple, so please bare with me.) There is a minimalistic view of Org as the combination of a syntax and a set of features to manipulate this syntax. There is a maximalistic view of Org as a syntax, a set of features to manipulate it, and a set of Emacs facilities to manipulate the mental representation of an Org buffer, which will *never* be the same than the parser representation. If Org were to be a Ruby gem, then the minimalistic view would be the right one, because libraries need to stick to common denominator and favor predictability. For example, in such a library, we don't care about "\n" characters by themselves in paragraphs, because the end of lines is irrelevant here, syntactictly speaking. But Org is no library: it's the Emacs way to manipulate Org files. The users' representations of their Org buffer and the affordances that are based on them are as important as the parser representation. Hence the case for links in comment, for example: the user read them as links, there is no value in preventing the users to open them with C-c C-o, and it is convenient to allow them to do so. Long story short: when users ask for to keep a feature they find convenient, this is no drama or conservative position, this is the expression that their interaction with an Org buffer will be less smooth if they have to constrain their representation to that of the parser. Finding the correct balance here does not impact the value of the parser at all, quite on the contrary. The better the parser, the easier it will be to draw the line between the minimalistic and the maximalistic views, even in the code. For example, a comment in `org-open-at-point' can clearly explain why opening the next link on the same line is allowed, even if it makes `org-open-at-point' unpure syntactic-wise. In a sense, the value of the parser grows with the number of functions that depend on it, hence the temptation to use it everywhere possible. But IMO this does not capture the whole truth: the value of the parser also depends on the number of decisions it helps us make regarding these minimalistic/maximalistic trade-offs. It is a unvaluable tool to clearly think about features, precisely because it empowers the developers to think in terms of syntactic elements, and see where this thinking comes short. I'm done: please don't stop working on the parser just because the parser is not the only way to think about feature, and please just remember all participants on this thread are goodwilling users who try to make a point. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-02 13:22 ` Bastien @ 2014-03-02 14:27 ` Nicolas Goaziou 2014-03-02 15:49 ` Bastien 0 siblings, 1 reply; 46+ messages in thread From: Nicolas Goaziou @ 2014-03-02 14:27 UTC (permalink / raw) To: Bastien; +Cc: michael.ch.brand, emacs-orgmode, Yasushi SHOJI Bastien <bzg@gnu.org> writes: > Here is my use-case: I often use C-c C-o as a shortcut for C-c C-x > C-n C-c C-o -- that's 2.5 shorter. This is convenient, and I would > need a good reason for removing something that convenient. This is not a use case. A use case would explain me why (or, better, where) you need to use C-c C-x C-n C-c C-o. No worries, though, as I do not expect to get an answer anymore. > Now there are really two issues: this one above, which can easily be > fixed by making `org-open-at-point' more flexible. And the general > issue of when and how Org features should rely on Org syntax, as > defined by the parser. > > (Whether links in comments should be treated as links by C-c C-o > belongs to the second issue, this is what I'd like to discuss now.) > > To my knowledge, the first raison d'être of the parser was to create > a stable and reliable infrastructure for the export engine. In this > case, a parser is needed, because that's the only way to consistently > have a common denominator for all export backends. The goal of the parser was to define properly Org syntax, by merging concepts from different parts of Org. The exporter was only a proof of concept for the parser, and also a way to exercise the choices made in the syntax. > Now the parser can also be used for other features. You already > explained the reasons very well: features will be easier to maintain, > and the whole set of features relying on the parser will evolve more > smoothly. > > That said, Org syntax is not the only valid representation of an > org-mode buffer. It should be, or the whole concept is moot. If "Org syntax" is only valid during export, if fontification interprets Org differently, if users see Org differently too, there is no point in defining a syntax. Just let everyone implement its own private Org. Note that this is what happened recently. One would like to use UTF-8 characters instead of stars for headlines. Another one would like to use ## for emphasis... > It is the only useful one when exporting a buffer to a certain format, > because we need to map the structure of the original contents to the > structure of the target one. Again, this will not work if we do not agree on the structure. This will raise questions like "How come that my document is exported this way, even though I interpret it that way?". > But another representation of an org-mode buffer is the one that > a user has in mind when manipulating it, part of this representation > depends on Org syntax, part of it depends on Emacs general facilities. > > For example, Emacs and the user have a notion of `end-of-line', but > Org syntax does not. Org syntax says whitespaces after an object > belong to the object but my immediate representation says they do not. > Or we do have a notion of visual indentation (with org-indent-mode > turned on), but this does not correspond to any real content, and /a > fortiori/ to an Org syntactic element, since this is just visual > sugar. You are mixing subjects here. For example, `org-end-of-line' is backed up with Elements already. This has nothing to do with Org syntax. > There is a minimalistic view of Org as the combination of a syntax and > a set of features to manipulate this syntax. There is a maximalistic > view of Org as a syntax, a set of features to manipulate it, and a set > of Emacs facilities to manipulate the mental representation of an Org > buffer, which will *never* be the same than the parser representation. Of course, but the "maximalistic" view can only be a superset of the "minimalistic" one. The former can see more than the latter, but it cannot disagree on what the latter sees. > But Org is no library: it's the Emacs way to manipulate Org files. And Org files are expressed in an Org format. Org syntax tries to define it. > The users' representations of their Org buffer and the affordances > that are based on them are as important as the parser representation. Their Org buffer is still expressed in the Org format. > Hence the case for links in comment, for example: the user read them > as links, there is no value in preventing the users to open them with > C-c C-o, and it is convenient to allow them to do so. Sorry, this is not convenient. This is just nonsense. For example, Org prevents a user from inserting a footnote reference in a comment (for good reasons), but links should be allowed? Can't every part of Org agree? AFAICT, a comment is a comment, and it is to be expected that comments only contain raw text. According to the manual: Lines starting with zero or more whitespace characters followed by one '#' and a whitespace are treated as comments and will never be exported. Note that "are treated as comments" is different from "will never be exported" since we write both. The parser simply treats comments as comments. Until recently, some parts of Org were careless and didn't treat them as such. This is a fix. [...] > I'm done: please don't stop working on the parser just because the > parser is not the only way to think about feature, and please just > remember all participants on this thread are goodwilling users who > try to make a point. IMO, there is a single representation for the Org format, and it must be defined clearly. Org syntax is an attempt to do so (but I never said it was definitive) and Org elements implements it. I started to work on the parser because it was high time to give Org one. From the beginning, I wanted all core functions to rely on it, for reasons I already explained. And for the same reasons, anything less is not worthy, as it would become yet another part of Org interpreting Org its own way. I never pretended to think or act otherwise. Some users apparently don't want a parser, i.e. a global consistent definition of Org syntax, for reasons that I cannot understand. I think it is a major mistake, but I'm fine with it. So, there is no middle path. Either the project continues towards its goal, or it stops here. Obviously, I'd rather have the maintainer's opinion on this. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-03-02 14:27 ` Nicolas Goaziou @ 2014-03-02 15:49 ` Bastien 2014-03-02 16:32 ` Thorsten Jolitz ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Bastien @ 2014-03-02 15:49 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: michael.ch.brand, emacs-orgmode, Yasushi SHOJI Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: >> That said, Org syntax is not the only valid representation of an >> org-mode buffer. > > It should be, or the whole concept is moot. If "Org syntax" is only > valid during export, if fontification interprets Org differently, if > users see Org differently too, there is no point in defining a syntax. > Just let everyone implement its own private Org. You are pushing things to the extreme. Even if the syntax is used for 57% of the functions, there is a point in defining one, and there would be no point for all users to define their own. >> It is the only useful one when exporting a buffer to a certain format, >> because we need to map the structure of the original contents to the >> structure of the target one. > > Again, this will not work if we do not agree on the structure. This will > raise questions like "How come that my document is exported this way, > even though I interpret it that way?". We agree here: a proper syntax is needed for exporting. >> But another representation of an org-mode buffer is the one that >> a user has in mind when manipulating it, part of this representation >> depends on Org syntax, part of it depends on Emacs general facilities. >> >> For example, Emacs and the user have a notion of `end-of-line', but >> Org syntax does not. Org syntax says whitespaces after an object >> belong to the object but my immediate representation says they do not. >> Or we do have a notion of visual indentation (with org-indent-mode >> turned on), but this does not correspond to any real content, and /a >> fortiori/ to an Org syntactic element, since this is just visual >> sugar. > > You are mixing subjects here. For example, `org-end-of-line' is backed > up with Elements already. This has nothing to do with Org syntax. I'm sorry you don't see the point: `org-end-of-line' being backed by Org syntax does not mean "the end of a line" has a meaning for the Org parser. My point is: it does not have a meaning for the parser while is has one for the user. This illustrates the fact there are several representations, which I need for my reasoning: if there was a unique representation, there would be no point in trying to balance several of them when defining features. >> There is a minimalistic view of Org as the combination of a syntax and >> a set of features to manipulate this syntax. There is a maximalistic >> view of Org as a syntax, a set of features to manipulate it, and a set >> of Emacs facilities to manipulate the mental representation of an Org >> buffer, which will *never* be the same than the parser representation. > > Of course, but the "maximalistic" view can only be a superset of the > "minimalistic" one. The former can see more than the latter, but it > cannot disagree on what the latter sees. Ideally, yes. >> But Org is no library: it's the Emacs way to manipulate Org files. > > And Org files are expressed in an Org format. Org syntax tries to define > it. Agreed. >> Hence the case for links in comment, for example: the user read them >> as links, there is no value in preventing the users to open them with >> C-c C-o, and it is convenient to allow them to do so. > > Sorry, this is not convenient. This is just nonsense. Let's ping the users about this particular nonsense. > For example, Org prevents a user from inserting a footnote reference in > a comment (for good reasons), but links should be allowed? Can't every > part of Org agree? > > AFAICT, a comment is a comment Er.. shall I quote Alice in Wonderland here? You seem to consider Org comments as comments in programming languages. But Org is not a programming language, it is used for any kind of text. > IMO, there is a single representation for the Org format, and it must be > defined clearly. Org syntax is an attempt to do so (but I never said it > was definitive) and Org elements implements it. > > I started to work on the parser because it was high time to give Org > one. From the beginning, I wanted all core functions to rely on it, for > reasons I already explained. And for the same reasons, anything less is > not worthy, as it would become yet another part of Org interpreting Org > its own way. I never pretended to think or act otherwise. This is not a all-or-nothing issue, and all-or-less is still different than all-or-nothing. > Some users apparently don't want a parser, i.e. a global consistent > definition of Org syntax, for reasons that I cannot understand. Nobody ever said anything coming close to that. > So, there is no middle path. I can see plenty of them! > Either the project continues towards its goal, or it stops > here. Obviously, I'd rather have the maintainer's opinion on this. Yes. In the meantime, other users' voices can help us step back and see things differently. -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 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 2 siblings, 0 replies; 46+ messages in thread From: Thorsten Jolitz @ 2014-03-02 16:32 UTC (permalink / raw) To: emacs-orgmode Bastien <bzg@gnu.org> writes: > Yes. In the meantime, other users' voices can help us step back and > see things differently. I used to have outcommented (w3m-browse-url ...) links in my init.el file, and I could evaluate them when I wanted to look-up something although they were outcommented: #+begin_src emacs-lisp ;; *** Package Manager ;; (w3m-browse-url "https://github.com/dimitri/el-get#readme") [...] #+end_src So, although I understand Nicolas reasoning very well and agree with him for the most part, from a practical point of view I would like links to work even when commented out (like Bastien and others). But if the price for this would be Nicolas abandoning the parser/exporter development I would say that this would be a VERY BAD DEAL for Org-mode. Just my 2c -- cheers, Thorsten ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 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 2 siblings, 0 replies; 46+ messages in thread From: Josiah Schwab @ 2014-03-03 3:41 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode, michael.ch.brand, Nicolas Goaziou, Yasushi SHOJI Hi All, > Yes. In the meantime, other users' voices can help us step back and > see things differently. (For reference: I have been using org-mode -- for TODO lists and note taking -- for a few years now, but have not contributed code.) I imagine myself as a naive user (which does not take too much) who does not know the internal structure of org and its syntax. If I execute org-open-at-point at the start of a line with a link and get the message "No link at point", I think "Ah, I need to move point onto the link." I do and all is good. So I find myself in Nicholas' camp in regards to the discussion of org-open-at-point. I think any pains -- which seem to be quite minor -- associated with the change in behavior are worth the gains in uniformity and clarity. And here I am thinking here not only about my day-to-day use of org-mode, but also of my (slow) journey towards understanding more about how it works. But if my point is on a link in a comment, and I do org-open-at-point, and get the message "No link at point", then I think, "But why? I am on something that looks like a link". So in regards to the discussion of links in comments, I see more clearly the argument Bastien, Michael, etc. are making. But I am unsure here how to judge whether the benefits outweigh the costs. Perhaps that is helpful; perhaps not! Best Regards, Josiah ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 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 2 siblings, 1 reply; 46+ messages in thread From: Michael Brand @ 2014-03-03 5:54 UTC (permalink / raw) To: Nicolas Goaziou, Bastien; +Cc: Org Mode Hi all On Sun, Mar 2, 2014 at 4:49 PM, Bastien <bzg@gnu.org> wrote: > In the meantime, other users' voices can help us step back and > see things differently. May I ask at least Nicolas and Bastien: When you carefully reread my last post (Thursday) http://lists.gnu.org/archive/html/emacs-orgmode/2014-02/msg00991.html of this thread: Is it clear that when point is after the character "x" - x y [2014-03-03 Mon] z t http://orgmode.org I want to keep "M-x org-open-at-point" to result in the error "No link found", in any case? The other reason for this post is an update of my function f-open-link-between-point-and-eol to deal with links in Org mode that occur in a place that is not a link according to Org syntax (currently two cases in discussion). I bind this function still to "C-c o". Not to "C-c C-o", because I want to use f-open-link-between-point-and-eol also outside of Org and because I want to have the possibility to use "C-c C-o" to find out on which point not and on which point org-open-at-point results in the error "No link found", for example to learn more about Org syntax and how to better cooperate with it. #+BEGIN_SRC emacs-lisp (defun f-open-link-between-point-and-eol () "Move to and open first link between point and end of line. As long as not yet at end of line and as long as `org-open-at-point' and `browse-url-at-point' result in an error advance point by one character. For Org and other major modes." (interactive) (let ((p (point)) opened) (while (not (or (eolp) (progn (ignore-errors (cond ;; Org mode ((eq major-mode 'org-mode) (org-open-at-point) (setq opened 'org-open-at-point)) ;; Maybe more major modes that have an ;; open function specific to their ;; syntax )) (unless opened (ignore-errors (browse-url-at-point) (setq opened 'browse-url-at-point))) opened))) (forward-char)) (if opened (message "Link opened with %s" opened) (goto-char p) (user-error "No link between point and end of line")))) #+END_SRC Here f-open-link-between-point-and-eol is with "(org-open-at-point)" but actually I'm using "(org-open-at-point 1)" instead. Michael ^ permalink raw reply [flat|nested] 46+ messages in thread
* Context of interaction vs. literal syntactic interpretation (was: link interfering with brackets when abbreviated) 2014-03-03 5:54 ` Michael Brand @ 2014-03-03 9:50 ` Bastien 2014-03-03 16:09 ` Context of interaction vs. literal syntactic interpretation Matt Lundin 0 siblings, 1 reply; 46+ messages in thread From: Bastien @ 2014-03-03 9:50 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode, Nicolas Goaziou 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-<right> to update a timestamp in a property drawer, since property drawers don't allow timestamps. But it is not inconsistent if S-<right> 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Context of interaction vs. literal syntactic interpretation 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 ` Matt Lundin 2014-03-03 18:00 ` Nick Dokos ` (3 more replies) 0 siblings, 4 replies; 46+ messages in thread From: Matt Lundin @ 2014-03-03 16:09 UTC (permalink / raw) To: Bastien; +Cc: Nicolas Goaziou, Michael Brand, Org Mode 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Context of interaction vs. literal syntactic interpretation 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 ` (2 subsequent siblings) 3 siblings, 0 replies; 46+ messages in thread From: Nick Dokos @ 2014-03-03 18:00 UTC (permalink / raw) To: emacs-orgmode Matt Lundin <mdl@imapmail.org> 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Context of interaction vs. literal syntactic interpretation 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 2014-03-14 13:46 ` Sebastien Vauban 2014-03-21 8:44 ` Bastien 3 siblings, 0 replies; 46+ messages in thread From: Jonathan Leech-Pepin @ 2014-03-03 18:13 UTC (permalink / raw) To: Matt Lundin; +Cc: Bastien, Michael Brand, Org Mode, Nicolas Goaziou [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Context of interaction vs. literal syntactic interpretation 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 @ 2014-03-14 13:46 ` Sebastien Vauban 2014-03-21 8:44 ` Bastien 3 siblings, 0 replies; 46+ messages in thread From: Sebastien Vauban @ 2014-03-14 13:46 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Context of interaction vs. literal syntactic interpretation 2014-03-03 16:09 ` Context of interaction vs. literal syntactic interpretation Matt Lundin ` (2 preceding siblings ...) 2014-03-14 13:46 ` Sebastien Vauban @ 2014-03-21 8:44 ` Bastien 2014-03-21 13:17 ` Nicolas Goaziou 3 siblings, 1 reply; 46+ messages in thread From: Bastien @ 2014-03-21 8:44 UTC (permalink / raw) To: Matt Lundin; +Cc: Org Mode, Michael Brand, Nicolas Goaziou 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Context of interaction vs. literal syntactic interpretation 2014-03-21 8:44 ` Bastien @ 2014-03-21 13:17 ` Nicolas Goaziou 2014-03-23 22:51 ` Bastien 0 siblings, 1 reply; 46+ messages in thread From: Nicolas Goaziou @ 2014-03-21 13:17 UTC (permalink / raw) To: Bastien; +Cc: Michael Brand, Matt Lundin, Org Mode Hello, Bastien <bzg@gnu.org> 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Context of interaction vs. literal syntactic interpretation 2014-03-21 13:17 ` Nicolas Goaziou @ 2014-03-23 22:51 ` Bastien 2014-03-24 13:12 ` Nicolas Goaziou 0 siblings, 1 reply; 46+ messages in thread From: Bastien @ 2014-03-23 22:51 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Michael Brand, Matt Lundin, Org Mode Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Context of interaction vs. literal syntactic interpretation 2014-03-23 22:51 ` Bastien @ 2014-03-24 13:12 ` Nicolas Goaziou 0 siblings, 0 replies; 46+ messages in thread From: Nicolas Goaziou @ 2014-03-24 13:12 UTC (permalink / raw) To: Bastien; +Cc: Michael Brand, Matt Lundin, Org Mode Hello, Bastien <bzg@gnu.org> writes: > In the meantime, what do you think about the solution I propose? I think it is a sensible move. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-27 23:43 ` Nicolas Goaziou 2014-03-01 18:44 ` Yasushi SHOJI @ 2014-03-01 18:44 ` Yasushi SHOJI 1 sibling, 0 replies; 46+ messages in thread From: Yasushi SHOJI @ 2014-03-01 18:44 UTC (permalink / raw) To: n.goaziou; +Cc: bzg, michael.ch.brand, emacs-orgmode Hi Nicolas, At Fri, 28 Feb 2014 00:43:19 +0100, Nicolas Goaziou wrote: > > Bastien <bzg@altern.org> writes: > > > If it is not, I suggest to discuss the change before implementing it. > > Nobody ever complained about the previous behavior, and both Michael > > and me are suppporting it. > > I didn't remove that non-essential feature for my pleasure, but because > it didn't fit in the new internal model. As I already said, implementing > it back is a bit of work and will probably not be very clean. Why > bother? Let's separate those internal parser thing and interactive commands, while we discus. I agree to Nicolas that parser and internal functions should NOT be ambiguous nor confusing. However, we humans are not machines nor slave of computers. We tell computers what we want, or even, we want to make computers think and do what we are thinking. That's the reason why we, these days, have *-dwim commands. We don't want to make our users to adopt how computers work. > Anyway, I don't understand why there is so much fuss about this. That's because a) the commands have been working, b) many other commands _do_ work even if it's not right on the elements. ie. S-right right after a timestamp, C-c C-c on checkbox list. Are you planning to remove these features, too? > I think that the coolness of the feature eludes me for all I can see is > a crude hack. What if we create org-open-at-point-dwim and map to C-c C-o. Nicolas, do you object? Anyway, thank you Nicolas for your work. We all appreciate your great work. Thanks, -- yashi ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 15:10 ` Michael Brand 2014-02-26 15:25 ` Nicolas Goaziou @ 2014-02-26 17:42 ` Bastien 2014-02-26 21:15 ` Nicolas Goaziou 1 sibling, 1 reply; 46+ messages in thread From: Bastien @ 2014-02-26 17:42 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode, Nicolas Goaziou Hi Michael and Nicolas, Michael Brand <michael.ch.brand@gmail.com> writes: > And once again thank you for your work in reimplementing more and more > by using org-element. A quick note on this. Here are the reasons why we *want* to rewrite some functions using org-element: - *bug fixing*: the rewrite fixes bugs. - *speed*: the rewrite provides a faster implementation; - *predictability*: the rewrite provides a more predictable implementation; - *completeness*: the rewrite covers more use-cases than the previous /ad hoc/ implementation. Now here are the reasons why we *don't want* to use org-element: - *high ceiling*: if the rewrite is less readable for potential developers. - *complexity*: if the rewritten version is more complex. - *rigidity*: if the rewritten version adds unwanted constraints. Of course, the decision is always a trade-off. I'm particularily sensitive to the "high ceiling" point above: we don't want all contributors to learn about Org elements before they can submit a patch -- of course, many will do, and we can encourage them to do so, but let's not close too many doors. IOW, even though org-element.el is great (and I hope my comments above will not be taken as criticism), "rewriting using org-element" is not a goal /per se/, just one great possibility to use when needed. -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 17:42 ` Bastien @ 2014-02-26 21:15 ` Nicolas Goaziou 2014-02-26 22:21 ` Bastien 0 siblings, 1 reply; 46+ messages in thread From: Nicolas Goaziou @ 2014-02-26 21:15 UTC (permalink / raw) To: Bastien; +Cc: Michael Brand, Org Mode Bastien <bzg@gnu.org> writes: > Here are the reasons why we *want* to rewrite some functions using > org-element: I don't know who "we" is. Apparently, I'm not in. > - *bug fixing*: the rewrite fixes bugs. > > - *speed*: the rewrite provides a faster implementation; > > - *predictability*: the rewrite provides a more predictable > implementation; > > - *completeness*: the rewrite covers more use-cases than the > previous /ad hoc/ implementation. > > Now here are the reasons why we *don't want* to use org-element: > > - *high ceiling*: if the rewrite is less readable for potential > developers. > > - *complexity*: if the rewritten version is more complex. > > - *rigidity*: if the rewritten version adds unwanted constraints. > > Of course, the decision is always a trade-off. > > I'm particularily sensitive to the "high ceiling" point above: we > don't want all contributors to learn about Org elements before they > can submit a patch -- of course, many will do, and we can encourage > them to do so, but let's not close too many doors. > > IOW, even though org-element.el is great (and I hope my comments above > will not be taken as criticism), "rewriting using org-element" is not > a goal /per se/, just one great possibility to use when needed. I think at least one of us is missing the point. I do not "rewrite using Elements" for any of the reasons above. But before I explain my reasons, I will comment "we"'s a bit. I cannot talk about bug fixing and completeness as it depends on the function rewritten. Though, don't hold your breath, implementation with Elements will /always/ be slower than the current one. I'm working on the cache to make that fact bearable, but I don't possess pixie dust. Also, I'm pretty sure it will never be less rigid. A parser is inherently very rigid. But this will sure make it more predictable. Moreover, learning about "org-element.el" is not that hard. There are 4 major functions: `org-element-at-point', `org-element-context', `org-element-property' and `org-element-type'. Of course, it can help to also know about properties attached to each element type. That's documented in Worg and pretty explicit in "org-element.el". Anyway, back to my reasons to "rewrite using Elements". Org consists of mostly (but not totally) independent parts, each one implementing its own Org parser, similar to the others, but sometimes slightly different. This is, to say the least, highly inefficient. It is also a potential source of bugs. Worse, it can impede further improvements. Indeed, I doubt that anyone knows Org's full code base. So any slight change to syntax could break some unknown parts of Org. Therefore, basically no structural improvement can happen today without tremendous efforts and pain (for the very same reasons, no new export back-end could be created yesterday). A function rewritten using Elements shares the same knowledge about Org syntax with other rewritten functions. If we improve Elements, all of them benefit from the improvement. If we modify it, all of them get the modification. I'm exaggerating it a bit, but I'm sure you get the idea. It is no panacea, but IMO, Org will be a better place when all of its parts agree on a common, unambiguous, syntax. So, in a nutshell, rewriting using org-element is almost a goal /per se/. It comes with a price, which is that a re-implementation is not a perfect copy of the original function, but the reward is higher. If "we" disagree with that, then it would nice be if "we" could let me know. Better late than sorry, I guess. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: link interfering with brackets when abbreviated 2014-02-26 21:15 ` Nicolas Goaziou @ 2014-02-26 22:21 ` Bastien 0 siblings, 0 replies; 46+ messages in thread From: Bastien @ 2014-02-26 22:21 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Michael Brand, Org Mode Hi Nicolas, "we" was short for "we, Org contributors", and it was a request for comment, so I'm glad you did. I understand your point very well: structural consistency favors ease of maintainance and evolutivity. The new export engine is a perfect example of this: without a clean parser, it would not exist. But this is also a perfect example of what I want to insist on: the benefit of relying on the parser has to be very clear. It is not something you can systematically and blindly taken for granted. For example, if we were to rely on the parser for fontification now, it would be certainly too slow, and the cost for the user would be too high. I know this rewrite is somewhere on the roadmap, and I know you will consider it only when the cost of the slowdown will not be too high -- so the trade-off strategy I was describing is something I guess we (as in "you and me") agree on. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2014-03-24 13:19 UTC | newest] Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).