From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Markus Triska Newsgroups: gmane.emacs.devel Subject: Re: something like linum.el ought to be added Date: Tue, 11 Sep 2007 20:15:04 +0200 Message-ID: References: <86hcm4rw70.fsf@macs.hw.ac.uk> <85642imgtp.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1189537589 7371 80.91.229.12 (11 Sep 2007 19:06:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 Sep 2007 19:06:29 +0000 (UTC) Cc: Joe Wells , rms@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 11 21:06:24 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IVB34-00036r-A8 for ged-emacs-devel@m.gmane.org; Tue, 11 Sep 2007 21:05:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IVB34-0000gR-9l for ged-emacs-devel@m.gmane.org; Tue, 11 Sep 2007 15:05:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IVAKR-0006qn-K2 for emacs-devel@gnu.org; Tue, 11 Sep 2007 14:19:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IVAKO-0006p4-Kl for emacs-devel@gnu.org; Tue, 11 Sep 2007 14:19:15 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IVAKO-0006ox-Fl for emacs-devel@gnu.org; Tue, 11 Sep 2007 14:19:12 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1IVAKN-0005yg-Uc for emacs-devel@gnu.org; Tue, 11 Sep 2007 14:19:12 -0400 Original-Received: (qmail invoked by alias); 11 Sep 2007 18:19:09 -0000 Original-Received: from chello062178240212.3.14.tuwien.teleweb.at (EHLO mt-computer.local) [62.178.240.212] by mail.gmx.net (mp035) with SMTP; 11 Sep 2007 20:19:09 +0200 X-Authenticated: #4064391 X-Provags-ID: V01U2FsdGVkX18MPKUsYBQMTAL/7VOOFSKGEaYHBkYxXxvVv2PnVC gc3xVEn/k4gbRy In-Reply-To: <85642imgtp.fsf@lola.goethe.zz> (David Kastrup's message of "Mon\, 10 Sep 2007 22\:00\:18 +0200") X-Y-GMX-Trusted: 0 X-Detected-Kernel: Linux 2.6, seldom 2.4 (older, 4) X-Mailman-Approved-At: Tue, 11 Sep 2007 15:05:17 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:78583 Archived-At: David Kastrup writes: > A large number of overlays is slowing down every operation in the > buffer. Having a set of 50 or so that is only adjusted upon redraw > should be the fastest option for that reason. I see what you mean; the main complication is that existing overlays can still be necessary in other windows that show the same buffer. So making all overlays available for (re-)consumption would entail walking all visible windows and adjusting (new or existing) overlays where necessary, which is not a clear improvement over the current approach (i.e., keeping overlays in place once they are created, and only changing those in the visible portion of the current window), in particular since the number of overlays seems to be no problem so far.