Re: [O] [PATCH] org-id-goto doesn't work if buffer is narrowed.

[John Kitchin]

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 <address@hidden> wrote:

John Kitchin <address@hidden> 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?