Re: [Emacs-diffs] master abd1825: Ensure that we can find definitions when buffer is narrowed

[Charles A. Roelli]

> Date: Sun, 10 Dec 2017 09:54:23 -0500 (EST)
> From: address@hidden (Wilfred Hughes)
> 
> branch: master
> commit abd18254aec76b26e86ae27e91d2c916ec20cc46
> Author: Wilfred Hughes <address@hidden>
> Commit: Wilfred Hughes <address@hidden>
> 
>     Ensure that we can find definitions when buffer is narrowed
>     
>     find-function-search-for-symbol will reuse the existing buffer if
>     we've already opened the file that contains this symbol. However, if
>     the user has narrowed that buffer, we can't find definitions outside
>     the narrowed area.
>     
>     Instead, search the whole file to find definitions, and teach the help
>     buttons to widen if necessary.
>     
>     * lisp/emacs-lisp/find-func.el (find-function-search-for-symbol):
>       Search the whole buffer for the target symbol.
>     
>     * lisp/help-mode.el: Help buttons now widen the target buffer, if
>       narrowing is in effect and the target position is not in that range.
> ---
>  lisp/emacs-lisp/find-func.el | 46 
> +++++++++++++++++++++++---------------------
>  lisp/help-mode.el            | 45 ++++++++++++++++++++++++++++++-------------
>  2 files changed, 56 insertions(+), 35 deletions(-)

Thanks for fixing this.  If I may suggest it, it might also be useful
for these functions to respect `widen-automatically':

  widen-automatically is a variable defined in ‘simple.el’.
  Its value is t

  Documentation:
  Non-nil means it is ok for commands to call ‘widen’ when they want to.
  Some commands will do this in order to go to positions outside
  the current accessible part of the buffer.

  If ‘widen-automatically’ is nil, these commands will do something else
  as a fallback, and won’t change the buffer bounds.

Also, I wonder if it would be worth the trouble to define a
buffer-local ring of narrowings, so that a user could return to a
previous narrowing after executing a command that changes to a
different one.