[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs's handling of line numbers [from bug#5042]
From: |
Mark Lillibridge |
Subject: |
Re: Emacs's handling of line numbers [from bug#5042] |
Date: |
Sun, 11 Apr 2010 15:22:21 -0700 |
[sorry for the delay replying]
Stefan wrote:
> Mark wrote:
> > (defcustom restart-numbering-restriction nil
> > "If true, lines inside a restriction are numbered starting from 1.
> > If false, line numbers correspond to position inside the buffer."
> > :group 'editing-basics
> > :type 'boolean)
>
> The problem is not one of line-numbers but of narrowing/restriction only
> (which in turn has impacts on line-numbering among other things).
> So I don't think "number" deserves to be part of the name.
>
> While implementing it, please try and merge it with (AKA have it replace)
> font-lock-dont-widen.
>
> Of course, a better approach would distinguish the two kinds of
> narrowing not on a buffer-basis but on a narrowing-basis, so that if you
> interactively narrow to a portion of a page in an Info buffer, you
> can still get line-numbers starting at the beginning of the page
> (even if it's outside the narrowed portion).
Hmmm. I think some more design may be in order before implementing.
Let me try and sketch an idea based on the above:
* There are two (optional) levels of restriction: "semantic" and
"temporary". (better names anyone?)
* The temporary restriction is always contained in or the same as the
semantic one.
* font-lock always uses the semantic restriction (font-lock-dont-widen
goes away)
* By default, line numbering is also based on the semantic restriction
* a global option allows switching this behavior to use the temporary
restriction for line numbering.
* Rmail, Info, and the like, use the semantic restriction because the
restricted-to-unit is effectively an independent buffer (semantic
unit)
* The default narrowing commands available to users use the temporary
restriction.
Does this sort of approach make sense? Do people like it? It is a more
global change than I was originally envisioning.
- Mark
- Re: Emacs's handling of line numbers [from bug#5042],
Mark Lillibridge <=
- Re: Emacs's handling of line numbers [from bug#5042], Stefan Monnier, 2010/04/11
- Re: Emacs's handling of line numbers [from bug#5042], Mark Lillibridge, 2010/04/17
- Re: Emacs's handling of line numbers [from bug#5042], Eli Zaretskii, 2010/04/17
- Re: Emacs's handling of line numbers [from bug#5042], Stefan Monnier, 2010/04/17
- Re: Emacs's handling of line numbers [from bug#5042], Eli Zaretskii, 2010/04/17
- Re: Emacs's handling of line numbers [from bug#5042], Mark Lillibridge, 2010/04/17
- Re: Emacs's handling of line numbers [from bug#5042], Eli Zaretskii, 2010/04/17
- Re: Emacs's handling of line numbers [from bug#5042], Juanma Barranquero, 2010/04/17
- RE: Emacs's handling of line numbers [from bug#5042], Drew Adams, 2010/04/17
- widen-one-level [was: Emacs's handling of line numbers], Drew Adams, 2010/04/18