emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs's handling of line numbers [from bug#5042]


From: Stefan Monnier
Subject: Re: Emacs's handling of line numbers [from bug#5042]
Date: Sun, 11 Apr 2010 22:27:05 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

> 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.

This does sound right.  And yes, it might introduce some "far" changes,
but hopefully it will still be fairly limited.

One visible change that's missing in the above is that we need to have
two forms of widening: whether we want to widen the current temporary
narrowing (if any), or we want to widen it all (i.e. not only the
temporary narrowing but the semantic one as well).

An important part of the design is to try and minimize the amount of
changes to the C code (which currently keeps track of BEG and Z which
are the widened limits of the buffer and BEGV and ZV which are the
current narrowed buffer limits).  So ideally, the distinction between
the two kinds of narrowing would only be visible to Elisp code.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]