Hello, Bastien <b...@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
