From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: refill paragraph but visually (like visual-line-mode)? Date: Mon, 15 Oct 2018 18:21:59 +0300 Message-ID: <83zhvfs0a0.fsf@gnu.org> References: <87y3azpn61.fsf@portable.galex-713.eu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1539616819 20022 195.159.176.226 (15 Oct 2018 15:20:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Oct 2018 15:20:19 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Oct 15 17:20:15 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gC4fD-000537-HD for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Oct 2018 17:20:12 +0200 Original-Received: from localhost ([::1]:52798 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gC4hJ-0001Ra-KB for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Oct 2018 11:22:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gC4gs-0001RK-Re for help-gnu-emacs@gnu.org; Mon, 15 Oct 2018 11:21:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gC4gp-0005ij-NW for help-gnu-emacs@gnu.org; Mon, 15 Oct 2018 11:21:54 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gC4gn-0005gK-OC for help-gnu-emacs@gnu.org; Mon, 15 Oct 2018 11:21:51 -0400 Original-Received: from [176.228.60.248] (port=2382 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gC4gn-0004GC-DK for help-gnu-emacs@gnu.org; Mon, 15 Oct 2018 11:21:49 -0400 In-reply-to: <87y3azpn61.fsf@portable.galex-713.eu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:118268 Archived-At: > From: "Garreau\, Alexandre" > Date: Mon, 15 Oct 2018 11:35:50 +0200 > > First of all, the text ends wrapped at the right edge of window, even if > that means quite long lines (such as more than 66 columns: 111 is the > default with my default current font), which is more a pain of reading > (eye must move more, stuff to see are more distant from each others). Did you try to enlarge the window's display margins? > Oddly I found nor in searching variables/functions nor in documentation > anything to limit automatic visual word-wrapping to something such as > 66, 72, or something more comfortable. Such options don't exist. You need to keep in mind that visual-line-mode (or "word wrap", as this feature is known in the internals) is just a semi-kludgey hack: we tweak the line-continuation code to start the continuation line on whitespace characters. Other than that, it's still the same continuation line, and uses the same code to detect when it's time to wrap the line. And even this relatively simple tweak makes the line-wrapping code devilishly complicated and hard to wrap your head around. It is possible that making the wrap coordinate controllable by users is not too hard, but Someone™ should look at the relevant code and try making it happen. Maybe we will be lucky. Wanna try it? > In second stance, when reading source code, and this is normally the > case I’d find word-wrap the most useful, the wrap just happens to > continue the logical line from the *beginning* of the next visual line. Right, see above. > So indentation is broken, and it hard to correctly read afterwards. I > guess this may be complicated to implement, but as emacs auto indent > works most of time, wouldn’t there a way to put visual indent too? Could be, but again, Someone™ should work on this. One potential obstacle to negotiate is that, unlike the existing indentation functions, which traverse the buffer in order to find out the indentation of surrounding lines, the display code cannot easily do that, because the display routines are expected to be able to be called with a buffer position from which to start display, and be able to lay out a single screen line without knowing anything about the neighboring lines. Some algorithm is needed to calculate the right indentation in those cases. > And last but not least: if the text (usually human text) I’m reading is > already wrapped, by fill-paragraph for instance, I end up with pairs of > filled long-lines + very short lines (lines end) which is really ugly: > word-wrap only wraps, but not refill. I’d like an option or mode that > puts at the end of the visual line the beginning of the next logical > line, just as fill-paragraph do, but only visually, and keeping an > (invisible) trace of the original/logical newlines. This should be possible by hiding newlines behind display properties or overlays. Patches are welcome to implement any of these useful features. Thanks.