From: Bastien <bzg@altern.org>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Michael Brand <michael.ch.brand@gmail.com>,
Org Mode <emacs-orgmode@gnu.org>
Subject: Re: link interfering with brackets when abbreviated
Date: Thu, 27 Feb 2014 12:04:13 +0100 [thread overview]
Message-ID: <87d2i8x1ea.fsf@bzg.ath.cx> (raw)
In-Reply-To: <87ppm8rgrf.fsf@gmail.com> (Nicolas Goaziou's message of "Thu, 27 Feb 2014 11:28:52 +0100")
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
next prev parent reply other threads:[~2014-02-27 11:04 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2014-03-02 21:16 Gustav Wikström
2014-03-03 1:30 ` Ista Zahn
2014-03-03 19:33 ` Samuel Wales
2014-03-03 19:46 ` Samuel Wales
2014-03-03 22:18 ` Sebastien Vauban
2014-03-03 22:33 ` Samuel Wales
[not found] ` <CAJcAo8vh0F0tqgX4=gUhJoWFcAsTiwfyi7Fp=spQeoaBog1OMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-04 12:16 ` Sebastien Vauban
2014-03-04 20:06 ` Samuel Wales
2014-03-19 11:19 ` Bastien
2014-03-03 10:58 ` Christian Moe
2014-03-03 16:11 ` Sebastien Vauban
2014-03-03 23:16 ` Robert Horn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d2i8x1ea.fsf@bzg.ath.cx \
--to=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
--cc=michael.ch.brand@gmail.com \
--cc=n.goaziou@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).