From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Kitchin Subject: Re: [PATCH] org-id-goto doesn't work if buffer is narrowed. Date: Sat, 24 Oct 2015 07:33:54 -0400 Message-ID: References: <874mhh1u7s.fsf@gmx.us> <87oafpz65e.fsf@gmx.us> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d043c7fa46613a40522d81a8a Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zpx5A-00054I-Vf for emacs-orgmode@gnu.org; Sat, 24 Oct 2015 07:33:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zpx59-000802-KQ for emacs-orgmode@gnu.org; Sat, 24 Oct 2015 07:33:56 -0400 Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:37492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zpx59-0007zh-9o for emacs-orgmode@gnu.org; Sat, 24 Oct 2015 07:33:55 -0400 Received: by wicfv8 with SMTP id fv8so61281906wic.0 for ; Sat, 24 Oct 2015 04:33:54 -0700 (PDT) In-Reply-To: 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: Puneeth Chaganti Cc: emacs-orgmode , Rasmus --f46d043c7fa46613a40522d81a8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > >> On Fri, Oct 23, 2015 at 8:57 PM, Rasmus wrote: > >>> It's not obvious that org should change a=E2=80=94potentially=E2=80= =94carefully > selected > >>> narrowed region. > >> > >> I agree. But, am I not explicitly asking to jump to the specified > >> item. I don't mind the widening, at least when the call is > >> interactive. I agree with you when some other code is calling it, > >> though. > Maybe I am missing something here. I would expect org-id-goto to actually get to the id entry when it is used independent of narrowing. When used in a program, I would expect this behavior to be wrapped in save-restriction type macros, so it wouldn't change your restriction. But when used interactively, e.g. when I click on a link, I expect the point to end up on the id entry, with the buffer open in front of me, even if that means widening. Is there some other expectation that makes sense? I feel like it is up to me to decide if breaking the restriction is worth visiting the link, and only by clicking on the link or running an interactive command makes that happen. An alternative might be to check if a restriction is in place somehow, and make org-id-goto not work or warn you somehow if it has to remove the restriction. Is it possible to save a restriction in a variable? so that something like C-c & could restore it? the save-restriction macro must do something like that, but the code seems to be hidden in the C-source for me. > > > > I see your point, but I also remember being quite annoyed in the past > when > > I lost my narrow because of e.g. inserting a footnote. > > I see. > > >>> Perhaps you could mimic the way org-edit-special works for this case. > >> > >> You mean, display the entry in a new buffer, and any changes will be > >> applied onto the original entry too? > > > > Yeah, I would prefer that. Would that work for you or would still pref= er > > to have your buffer widened? > > I agree that widening a buffer that was narrowed on purpose can be > annoying, sometimes. Most times, I think I wouldn't mind the widening. > That said, I'm not quite sure what is the right fix for this. > > I find it weird to have a subtly different thing happening depending > on whether or not the target buffer is narrowed -- entry shown in > normal buffer when no narrowing vs. entry shown in a special/indirect > buffer. > > Also, given that no other part of org really uses indirect buffers, I > don't know if this function alone should make use of that feature. > > Let me know what you think. > > -- Puneeth > > PS: I've patched my org sources to do indirect buffers for this, and > will try it out for sometime to see how it feels. > > --f46d043c7fa46613a40522d81a8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>
>> On Fri, Oct 23, 2015 at 8:57 PM, Rasmus <rasmus@gmx.us> wrote:
>>> It's not obvious that org should change a=E2=80=94potentia= lly=E2=80=94carefully selected
>>> narrowed region.
>>
>> I agree. But, am I not explicitly asking to jump to the specified<= br> >> item. I don't mind the widening, at least when the call is
>> interactive. I agree with you when some other code is calling it,<= br> >> though.

Maybe I am miss= ing something here. I would expect org-id-goto to actually get to the id en= try when it is used independent of narrowing. When used in a program, I wou= ld expect this behavior to be wrapped in save-restriction type macros, so i= t wouldn't change your restriction. But when used interactively, e.g. w= hen I click on a link, I expect the point to end up on the id entry, with t= he buffer open in front of me, even if that means widening. Is there some o= ther expectation that makes sense? I feel like it is up to me to decide if = breaking the restriction is worth visiting the link, and only by clicking o= n the link or running an interactive command makes that happen.
<= br>
An alternative might be to check if a restriction is in place= somehow, and make org-id-goto not work or warn you somehow if it has to re= move the restriction.

Is it possible to save a res= triction in a variable? so that something like C-c & could restore it? = =C2=A0the save-restriction macro must do something like that, but the code = seems to be hidden in the C-source for me.
=C2=A0
>
> I see your point, but I also remember being quite annoyed in th= e past when
> I lost my narrow because of e.g. inserting a footnote.

I see.

>>> Perhaps you could mimic the way org-edit-special works for thi= s case.
>>
>> You mean, display the entry in a new buffer, and any changes will = be
>> applied onto the original entry too?
>
> Yeah, I would prefer that.=C2=A0 Would that work for you or wou= ld still prefer
> to have your buffer widened?

I agree that widening a buffer that was narrowed on purpose can be
annoying, sometimes. Most times, I think I wouldn't mind the widening.<= br> That said, I'm not quite sure what is the right fix for this.

I find it weird to have a subtly different thing happening depending
on whether or not the target buffer is narrowed -- entry shown in
normal buffer when no narrowing vs. entry shown in a special/indirect
buffer.

Also, given that no other part of org really uses indirect buffers, I
don't know if this function alone should make use of that feature.

Let me know what you think.

-- Puneeth

PS: I've patched my org sources to do indirect buffers for this, and will try it out for sometime to see how it feels.


--f46d043c7fa46613a40522d81a8a--