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: visual-line-mode and line wrapping Date: Mon, 24 May 2010 16:26:44 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1274735567 8689 80.91.229.12 (24 May 2010 21:12:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 24 May 2010 21:12:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Leo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 24 23:12:45 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1OGex2-0003dm-UQ for ged-emacs-devel@m.gmane.org; Mon, 24 May 2010 23:12:45 +0200 Original-Received: from localhost ([127.0.0.1]:38800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGerz-00022L-UZ for ged-emacs-devel@m.gmane.org; Mon, 24 May 2010 17:07:31 -0400 Original-Received: from [140.186.70.92] (port=42242 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGeEg-0000y6-Kl for emacs-devel@gnu.org; Mon, 24 May 2010 16:26:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGeEX-00021O-SG for emacs-devel@gnu.org; Mon, 24 May 2010 16:26:54 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:48519 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGeEX-00020s-N1 for emacs-devel@gnu.org; Mon, 24 May 2010 16:26:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHp9+ktFpZMM/2dsb2JhbACeAHK/WoUTBIw/ X-IronPort-AV: E=Sophos;i="4.53,293,1272859200"; d="scan'208";a="64948390" Original-Received: from 69-165-147-12.dsl.teksavvy.com (HELO pastel.home) ([69.165.147.12]) by ironport2-out.pppoe.ca with ESMTP; 24 May 2010 16:26:44 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 08D938267; Mon, 24 May 2010 16:26:44 -0400 (EDT) In-Reply-To: (Leo's message of "Mon, 24 May 2010 20:18:46 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.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:125213 Archived-At: > There's clearly desire for it. Otherwise Lennart wouldn't have created > that wrap fill mode. Screens are getting wider so having lines of 200 > chars is painful to read. You're preaching to the choir here (why do you think we have an "80 columns max" limit on C and Elisp code?). But some people have been using >=1600 horizontal pixels for more than 10 years and that's not been a problem. The real problem is not that screens are getting larger, but that people don't have to pay real money for that real-estate any more, so they don't care about using it efficiently, and they end up suffering from their sloppiness. I think that adjusting margins is an absurd waste of screen real-estate, but at least (compared to your suggestion) it doesn't leave the fringe icons far away from the text, so I think it's a better solution than a wrap-width. Of course, splitting windows is an even better solution. > Using fringes or margins (now that I have tried it and I can imagine how > Lennart implement his mode) are all workarounds and they are not much > different than opening up a frame with the desired width but then it is > a waste of screen estate and it has impact on productivity. How would a wrap-width waste less screen estate or have less impact on productivity? >> You can also split the window to set its width as desired. That will let >> you use the extra horizontal space for something useful. > This is also another workaround, Not at all. And it's additionally a first step to working more efficiently. > The thing is very easy to lose the setup, C-x 1, switch buffer etc etc. Ah, now you're talking. Sadly for your two examples, sadly, I don't know what to tell you: - why would you do C-x 1 in a "whole screen" Emacs frame? - switch-to-buffer is not a problem as long as all your buffers use the same width. Hence the "80 columns" rule. But indeed window management is something that requires improvement. Better UI to access and manipulate window configurations might be a good solution. But also, we could introduce a buffer-local var "natural-width" which would be similar to wrap-width but would not directly control anything related to display: it would simply declare that the buffer's content was formatted with the intention of seeing/editing it in a buffer of that width. Then the window-management (via things like fit-window-to-buffer or by resizing margins if you so prefer) could better automatically resize windows, so that switch-to-buffer could DTRT when switching between buffers of different "natural-width". The only problem I have with that, is that there are very few good reasons to set natural-width to anything significantly different from 80 since it is related not so much to computer technology as to the human's vision system. Stefan