> > > >> On Fri, Oct 23, 2015 at 8:57 PM, Rasmus 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. > >