From: Drew Adams <drew.adams@oracle.com>
To: Phil Sainty <psainty@orcon.net.nz>, 16328@debbugs.gnu.org
Subject: bug#16328: 24.3.50; [PATCH] Enable narrowing to defun with function header comments also visible
Date: Fri, 3 Jan 2014 08:38:20 -0800 (PST) [thread overview]
Message-ID: <fc919014-81ff-4749-bbff-ff8df4460798@default> (raw)
In-Reply-To: <52C67B72.3010607@orcon.net.nz>
> 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.]
next prev parent reply other threads:[~2014-01-03 16:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 8:57 bug#16328: 24.3.50; [PATCH] Enable narrowing to defun with function header comments also visible Phil Sainty
2014-01-03 14:14 ` Phil Sainty
2014-01-03 16:38 ` Drew Adams [this message]
2014-01-04 8:41 ` Josh
2014-07-04 2:04 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc919014-81ff-4749-bbff-ff8df4460798@default \
--to=drew.adams@oracle.com \
--cc=16328@debbugs.gnu.org \
--cc=psainty@orcon.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).