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: Mark Lillibridge
Subject: Re: Emacs's handling of line numbers [from bug#5042]
Date: Fri, 16 Apr 2010 18:57:26 -0700

Stefan wrote:
>  Mark wrote:
>  > 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.

    What do other people think?  I'm reluctant to try and make such a
major change as thus without more input.

- Mark




reply via email to

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