Subject: RE: bug#16328: 24.3.50; [PATCH] Enable narrowing to defun with function header comments also visible

From: Drew Adams <[email-masked]>
Date: Fri, 3 Jan 2014 08:38:20 -0800 (PST)

> For languages where the programmer must resort to function header
> comments to describe a function, I've always found it frustrating
> that `narrow-to-defun' cuts out this often-critical information.
> 
> This patch provides a new function `narrow-to-defun-including-
> comments' to keep these comments visible when narrowing.
> 
> As there may be multiple per-line comments instead of a single block
> comment, I'm skipping back past ALL preceding comments. That seemed
> reasonable instead of trying to guess how the author has structured
> their comments. Stopping at an empty line would *probably* be okay,
> but in the end I figured that potentially showing too much seemed
> better than showing too little.
> 
> (I've included a check for page breaks within the comments, however,
> as I was confident about excluding anything before one of those.)
> 
> I didn't think it was wise to encourage users to modify the
> behaviour of `narrow-to-defun' itself (I certainly have programmatic
> uses for that), so instead I've indicated the way to remap the
> interactive bindings for users who wish to use this as standard.

Hi Phil.  I wonder whether we couldn't just modify `narrow-to-defun',
changing to (interactive "P") and using the unused argument as prefix
arg to get this behavior?

Perhaps someone knows more about the history of that argument.
Grepping the Emacs sources, at least, I see no programmatic uses of
`narrow-to-defun' that pass an argument.  And anyway, the argument
is ignored.

But presumably we would have kept the unused argument to allow
`narrow-to-defun' to be used as a functional argument in a context
where it might receive an argument?  If there were such uses then
perhaps passing the prefix arg could prove problematic.  Dunno.

Anyway, seems reasonable to try, or at least to investigate.
`C-u C-x n d' would then already be one key binding for this.

[BTW, I didn't check your code, but if it doesn't already, it could
perhaps use code similar to that of `reposition-window', to determine
the starting point for the narrowing.  That command (`C-M-l') is
somewhat similar.]