From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: redisplay - very long lines Date: Tue, 17 Feb 2009 21:26:25 -0500 Message-ID: References: <3FEE1ADD-7471-4EA4-AE55-9175C9218B6E@gmail.com> <4AC07B50-75B6-4A68-9E01-A228BA64BDAE@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1234924030 15967 80.91.229.12 (18 Feb 2009 02:27:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Feb 2009 02:27:10 +0000 (UTC) Cc: david.reitter@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 18 03:28:26 2009 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 1LZcAj-0006Vk-QN for ged-emacs-devel@m.gmane.org; Wed, 18 Feb 2009 03:28:26 +0100 Original-Received: from localhost ([127.0.0.1]:52705 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZc9P-0003L6-Jq for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2009 21:27:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZc8s-00036M-Dt for emacs-devel@gnu.org; Tue, 17 Feb 2009 21:26:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZc8q-00035G-PG for emacs-devel@gnu.org; Tue, 17 Feb 2009 21:26:29 -0500 Original-Received: from [199.232.76.173] (port=43449 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZc8q-000358-LG for emacs-devel@gnu.org; Tue, 17 Feb 2009 21:26:28 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:65044) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZc8o-0000NJ-T4; Tue, 17 Feb 2009 21:26:27 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEABoAm0lMCpTK/2dsb2JhbACBbtF/hBMGgzU X-IronPort-AV: E=Sophos;i="4.38,225,1233550800"; d="scan'208";a="34013767" Original-Received: from 76-10-148-202.dsl.teksavvy.com (HELO ceviche.home) ([76.10.148.202]) by ironport2-out.teksavvy.com with ESMTP; 17 Feb 2009 21:26:26 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id BF32CB4123; Tue, 17 Feb 2009 21:26:25 -0500 (EST) In-Reply-To: (Eli Zaretskii's message of "Tue, 17 Feb 2009 21:41:36 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:109158 Archived-At: >> This would only happen with truncated lines, not with wrapped >> lines, right? > If by ``wrapped lines'' you mean continuation lines, then (AFAIK) we Yes, I meant "overly long, but not truncated". Whether the wrapping is done at a word boundary or at a char boundary shouldn't make much difference in this respect. > still need to walk to the end of a line before we are able to display > it and all the lines after it. In the above, when you say "line" do you mean "visual line" or "textual line"? IIUC we need to walk till the end of the visual line, but not till the end of the textual line, so that shouldn't cause a slowdown proportional to the length of the textual line. >> [ Also, I'd much rather see occasional jumping than unbearably >> slow display. In many cases (e.g. unibyte fundamental-mode for binary >> files), the likelihood of varying line height is pretty low. ] > [How come you are suddenly in favor of unibyte operations?] I'm not in favor of it, but binary files seem to be the most common example of data where lines can grow to insane length. And these are better handled in unibyte buffers. > FWIW, I think editing binary files other than via hexl is playing with > fire, anyway. But that's me. Agreed, but if the file is sufficiently large (as is common for binary files), hexl is impractical. Stefan