[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] link interfering with brackets when abbreviated

From: Bastien
Subject: Re: [O] link interfering with brackets when abbreviated
Date: Thu, 27 Feb 2014 12:04:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Hi Nicolas,

Nicolas Goaziou <address@hidden> 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

>>   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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]