From: Nicolas Goaziou <firstname.lastname@example.org>
To: Anders Waldenborg <email@example.com>
Subject: Re: PATCH Make org-open-at-point only ask once
Date: Mon, 29 Aug 2011 13:25:01 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <20110829105345.GU5700@0x63.nu> (Anders Waldenborg's message of "Mon, 29 Aug 2011 12:53:45 +0200")
Anders Waldenborg <email@example.com> writes:
> On Mon, Aug 29, 2011 at 11:36:19AM +0200, Nicolas Goaziou wrote:
>> Maybe we should define a consistent link search: ignore the narrowing
>> but first search in current sub-tree, if that fails (any error, I guess)
>> search in current tree and if that one fails too, search in the whole
> So something with the same semantics as this:
> (defun find-nearest-heading-named (l)
> (unless (find-heading-in-current-subtree l)
> (find-nearest-heading-named l)))
Recursively, yes. And enclosing this with (org-with-wide-buffer ...)
> i.e find the target with its parent headings list sharing the longest
> prefix with current point's.
> * A
> ** B
> * C
> ** B
> ** D
> *** B
> *** E
> A link to B inside E would go to C/D/B because (C D B) shares longer
> prefix with (C D E) than (C B) and (A B) does.
To be sure we understand it the same way:
1. Go to E and search from there: failure.
2. Go to D and search from there: success.
And if there's a link to D in A/B:
1. Search from B: failure.
2. Search from A: failure.
3. Search from (point-min): success.
Also, I would use "hierarchically" (or the like) instead of "nearest",
which can be confusing, as in this example:
Linking F from B should point to **** F instead of ** F while the latter
is nearer if considered distance is positive difference between buffer
What do you (or anyone reading this) think?
next prev parent reply other threads:[~2011-08-29 11:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-28 20:05 PATCH Make org-open-at-point only ask once Anders Waldenborg
2011-08-29 7:14 ` Nicolas Goaziou
2011-08-29 9:21 ` Anders Waldenborg
2011-08-29 9:36 ` Nicolas Goaziou
2011-08-29 10:53 ` Anders Waldenborg
2011-08-29 11:25 ` Nicolas Goaziou [this message]
2011-10-06 8:00 ` Carsten Dominik
2011-10-06 8:43 ` Anders Waldenborg
2011-10-06 8:54 ` Carsten Dominik
2011-10-06 9:51 ` Anders Waldenborg
2011-10-06 9:57 ` Carsten Dominik
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).