>
>> On Fri, Oct 23, 2015 at 8:57 PM, Rasmus <rasmus@gmx.us> wrote:
>>> It's not obvious that org should change a—potentially—carefully 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 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.
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.