From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Garreau\, Alexandre" Newsgroups: gmane.emacs.help Subject: Re: refill paragraph but visually (like visual-line-mode)? Date: Wed, 17 Oct 2018 12:54:42 +0200 Message-ID: <87o9bsg7wt.fsf@portable.galex-713.eu> References: <87y3azpn61.fsf@portable.galex-713.eu> <83zhvfs0a0.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1539773588 26476 195.159.176.226 (17 Oct 2018 10:53:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2018 10:53:08 +0000 (UTC) User-Agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu) Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Oct 17 12:53:04 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 1gCjRn-0006n7-PC for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Oct 2018 12:53:03 +0200 Original-Received: from localhost ([::1]:35389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCjTt-0005ue-VO for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Oct 2018 06:55:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCjTS-0005uL-MS for help-gnu-emacs@gnu.org; Wed, 17 Oct 2018 06:54:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gCjTR-0006xc-J1 for help-gnu-emacs@gnu.org; Wed, 17 Oct 2018 06:54:46 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:41918) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gCjTR-0006vo-9w; Wed, 17 Oct 2018 06:54:45 -0400 Original-Received: from localhost ([::1] helo=portable.galex-713.eu) by portable.galex-713.eu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gCjTO-0004Oj-M5; Wed, 17 Oct 2018 12:54:42 +0200 X-GPG-FINGERPRINT: E109 9988 4197 D7CB B0BC 5C23 8DEB 24BA 867D 3F7F X-Accept-Language: fr, en, it, eo In-Reply-To: <83zhvfs0a0.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 15 Oct 2018 18:21:59 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:5884:8305::1 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:118302 Archived-At: On 2018-10-15 at 18:21, Eli Zaretskii wrote: >> From: "Garreau\, Alexandre" >> Date: Mon, 15 Oct 2018 11:35:50 +0200 >>=20 >> 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? No, I didn=E2=80=99t know of them, only of fringes, which I recalled could = be resized, but forgot how. visual-fill-column-mode is really great, it even centers text (I wouldn=E2=80=99t have hoped so). Then comes the other (now solved) problem= s: >> 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=E2=84=A2 should look at the relevant code an= d try > making it happen. Maybe we will be lucky. > > Wanna try it? isn=E2=80=99t it what visual-fill-column-mode does? >> 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=E2=80=99t there a way to put visual in= dent >> too? > > Could be, but again, Someone=E2=84=A2 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. I was only thinking about some sort of adaptive-wrap-prefix-mode that would use indentation of the first line as adaptive-prefix-wrap already does. Yet indeed, if all visual lines are actually from a single long continued hard line, that has to be really difficult as some special indentation should have to be stored invisible with the rest of logical line (ie. e.g. instruction line) so that to be used afterwards, lazily as it is currently done. >> And last but not least: if the text (usually human text) I=E2=80=99m rea= ding >> 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=E2=80=99d 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. Hence visual-fill-mode, with some improvement it might work terribly well everywhere in emacs. > Patches are welcome to implement any of these useful features. Patches? do you fill that would be relevant in main emacs? maybe keeping them as packages for a while before, so that to test them? At least visual-fill-mode needs some twiddling related to some modes (or maybe do modes need to specify when newlines (or any other character such as =E2=80=9C;=E2=80=9D (both C and lisp), or "\n\t" (python)) are of s= emantical relevance and should not be hidden, and when they=E2=80=99re not and should= be?) before, I=E2=80=99d say.