emacs-devel
[Top][All Lists]
Advanced

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

Re: setnu-mode and Emacs 21.


From: Juanma Barranquero
Subject: Re: setnu-mode and Emacs 21.
Date: Thu, 15 Nov 2001 09:05:55 +0100

On 15 Nov 2001 10:01:12 +0900, Miles Bader <address@hidden> wrote:

> True, but I'm saying that, in general, a design that tries to put an
> overlay for _every line_ of the file is going to be a dog, no matter how
> fast overlays are.

Just because overlays aren't fast. If you routinely manage files of
several hundreds of thousands of lines with Emacs, I bet you'll have
some performance problems whether you use overlays or not. But
currently putting an overlay on each line can be a dog even if the
file has just a few hundreds or thousands of lines. What kind of file
you think is more usual?

> I think it's much better to think about how such
> designs can be avoided (for instance, in the line-numbering case, using
> jit-lock to add overlays only to displayed lines).

Yes, I agree, but if it is so frequent a problem, perhaps we need a
more generic answer (for font-locking, setnu.el, and other new ideas
that will eventually pop) that jit-lock, which, AFAICS, is just for
font-locking.

> I said nothing about the margin.

You're right. I'm mixing both things because I really think the margin
could be put to good use... if only the interface to it where easier
to use.

> It seems that you think I was saying overlays are bad -- I was not.
> 
> I think overlays are a _good_ way to do things like display line
> numbers;

That's were we disagree, I believe. Of course I don't think overlays
are bad, either. But if I cannot put a few thousands of them in a
buffer, I have no use for them, and there's nothing inherent in the
concept of overlay that precludes having lots of them... is an
implementation issue. If overlays included some kind of semi-automatic
"jit-lock" and didn't depend on markers having to be reassigned for
every buffer change (as opossed to just when they interact with
redisplay), it'd be perfectly fine to have as many of them as needed.

OTOH, I don't think they're a good way to show info in the margin,
because, as I said in my previous message, I see margin information as
being line oriented (perhaps I have too narrow a view of margins :)

> what I think is _bad_ is a design that requires _every_ line of
> the file to have an overlay (even if never display or modified), rather
> than somehow adding overlays on a more `as needed' basis.

What if you just add them as each fragment of the buffer is being
displayed, but you don't want to delete them afterwards (perhaps they
store relevant information)?

                                                           /L/e/k/t/u




reply via email to

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