I like the idea too. I worked out a partial solution for id links here: http://kitchingroup.cheme.cmu.edu/blog/2015/10/24/Saving-the-current-restriction-and-restoring-it-while-following-links/ using the idea for saving and restoring the restriction. John ----------------------------------- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Sat, Oct 24, 2015 at 8:47 AM, Rasmus wrote: > John Kitchin writes: > > > 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. > > I prefer the behavior of C-c C-c on a footnote in a narrowed buffer. > I.e. throw an error. > > > > 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 thought about that. I sort of like, but I also think it’s a potentially > big change... > > A poor man’s solution might be: > > (when (buffer-narrowed-p) (cons (point-min) (point-max))) > > Rasmus > > -- > When the facts change, I change my mind. What do you do, sir? > > >