From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: PATCH Make org-open-at-point only ask once Date: Mon, 29 Aug 2011 11:36:19 +0200 Message-ID: <87d3folfu4.fsf@gmail.com> References: <20110828200542.GS5700@0x63.nu> <87liuclmey.fsf@gmail.com> <20110829092146.GT5700@0x63.nu> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:36258) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QxyH4-0006qf-De for emacs-orgmode@gnu.org; Mon, 29 Aug 2011 05:36:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QxyH3-0005nJ-B7 for emacs-orgmode@gnu.org; Mon, 29 Aug 2011 05:36:58 -0400 Received: from mail-ww0-f49.google.com ([74.125.82.49]:37879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QxyH3-0005nB-2g for emacs-orgmode@gnu.org; Mon, 29 Aug 2011 05:36:57 -0400 Received: by wwf10 with SMTP id 10so4312413wwf.30 for ; Mon, 29 Aug 2011 02:36:56 -0700 (PDT) In-Reply-To: <20110829092146.GT5700@0x63.nu> (Anders Waldenborg's message of "Mon, 29 Aug 2011 11:21:46 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Anders Waldenborg Cc: emacs-orgmode@gnu.org Anders Waldenborg writes: > But for org links, I'm not 100% sure - consider this org-file: > > * Notes > * Some topic > [[Notes]] > ** Notes > > If buffer is widen, the link goes to the toplevel header, but if I > narrow to "Some topic" the link suddenly starts going to the > subheader. And I think that totally makes sense. If the user bothered narrowing buffer to a sub-tree, he probably wants to focus on the Notes relative to that sub-tree. Now, you're right, that search behaviour won't be consistent as long as it will rely on narrowing. 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 buffer. > Thanks for the review, I'll look into it soon. Np. Regards, -- Nicolas Goaziou