unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: mark.lillibridge@hp.com
Cc: lekktu@gmail.com, drew.adams@oracle.com, markus.triska@gmx.at,
	emacs-devel@gnu.org
Subject: Re: Emacs's handling of line numbers  [from bug#5042]
Date: Sun, 11 Apr 2010 22:27:05 -0400	[thread overview]
Message-ID: <jwvr5mlwh2q.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <qmhochpy6hu.fsf@ts-rhel4.hpl.hp.com> (Mark Lillibridge's message of "Sun, 11 Apr 2010 15:22:21 -0700")

> 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	other threads:[~2010-04-12  2:27 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-15 18:47 Emacs's handling of line numbers [from bug#5042] Mark Lillibridge
     [not found] ` <jwvd4068dsr.fsf-monnier+emacs@gnu.org>
2010-04-11 22:22   ` Mark Lillibridge
2010-04-12  2:27     ` Stefan Monnier [this message]
2010-04-17  1:57       ` Mark Lillibridge
2010-04-17  7:29         ` Eli Zaretskii
2010-04-17 14:45           ` Stefan Monnier
2010-04-17 15:57             ` Eli Zaretskii
2010-04-17 19:51               ` Mark Lillibridge
2010-04-17 21:04                 ` Eli Zaretskii
2010-04-17 21:17                   ` Juanma Barranquero
2010-04-17 21:31                     ` Drew Adams
2010-04-18 18:15                       ` widen-one-level [was: Emacs's handling of line numbers] Drew Adams
2010-04-18 21:31                         ` Juri Linkov
2010-04-19  0:25                           ` Drew Adams
2010-04-18 23:30                         ` Davis Herring
2010-04-19 19:57                           ` Richard Stallman
2010-04-19 20:22                             ` Drew Adams
2010-04-19 22:52                             ` Juri Linkov
2010-04-19  1:56                         ` Leo
2010-04-19  2:04                           ` Drew Adams
2010-04-19 11:34                             ` Leo
2010-04-19 16:31                             ` Drew Adams
2010-04-19 17:57                               ` Leo
2010-04-19 22:56                                 ` Drew Adams
2010-04-22  9:59                                   ` Leo
2010-04-18  3:12                     ` Emacs's handling of line numbers [from bug#5042] Eli Zaretskii
2010-04-18  3:49                       ` Juanma Barranquero
2010-04-18  8:05                         ` Juri Linkov
2010-04-18 13:44                           ` Drew Adams
2010-04-18 13:50                             ` Lennart Borgman
2010-04-18 16:40                               ` Drew Adams
2010-04-18 14:03                             ` Juanma Barranquero
2010-04-18 14:14                               ` David Kastrup
2010-04-18 16:41                               ` Drew Adams
2010-04-18 17:03                                 ` Juanma Barranquero
2010-04-18 21:29                                   ` Juri Linkov
2010-04-18 13:45                           ` Drew Adams
2010-04-18 17:29                         ` Eli Zaretskii
2010-04-18 17:52                           ` Juanma Barranquero
2010-04-18 17:56                             ` Eli Zaretskii
2010-04-18 17:00                       ` Mark Lillibridge
2010-04-18 17:38                         ` Eli Zaretskii
2010-04-18 18:11                           ` Lennart Borgman
2010-04-22  2:17                           ` Mark Lillibridge
2010-04-22  8:06                             ` David Kastrup
2010-04-22  8:38                               ` Juri Linkov
2010-04-22  8:45                               ` Juanma Barranquero
2010-06-06 18:18                             ` Mark Lillibridge
2010-06-07  1:30                               ` Stefan Monnier
2010-06-07  1:41                                 ` Lennart Borgman
2010-06-07 13:45                                   ` Stefan Monnier
2010-06-09  2:20                                     ` Mark Lillibridge
2010-06-09  3:44                                       ` Miles Bader
2010-06-09  2:19                                 ` Mark Lillibridge
2010-06-09  6:37                                   ` Glenn Morris
2010-06-24  2:24                                     ` Mark Lillibridge

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=jwvr5mlwh2q.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=lekktu@gmail.com \
    --cc=mark.lillibridge@hp.com \
    --cc=markus.triska@gmx.at \
    /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).