From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: refill paragraph but visually (like visual-line-mode)? Date: Mon, 15 Oct 2018 11:56:57 -0400 Message-ID: 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 1539618949 15458 195.159.176.226 (15 Oct 2018 15:55:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Oct 2018 15:55:49 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) 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:55:45 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 1gC5Dd-0003w5-6g for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Oct 2018 17:55:45 +0200 Original-Received: from localhost ([::1]:52910 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gC5Fj-0003Fr-Ho for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Oct 2018 11:57:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gC5FA-0003FS-MB for help-gnu-emacs@gnu.org; Mon, 15 Oct 2018 11:57:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gC5F2-0000Bv-Su for help-gnu-emacs@gnu.org; Mon, 15 Oct 2018 11:57:18 -0400 Original-Received: from [195.159.176.226] (port=33021 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gC5F1-00008o-MP for help-gnu-emacs@gnu.org; Mon, 15 Oct 2018 11:57:12 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gC5Cp-000364-8L for help-gnu-emacs@gnu.org; Mon, 15 Oct 2018 17:54:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 59 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:w+3hGS3aJYKokRTSxiuujvsh34A= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:118269 Archived-At: > The current problem of visual-line mode and why I almost never use is up > to three reasons: > > 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). > 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. You might like the visual-fill-column packaqe which widens the margin such that your 111-wide window only has 66-wide columns (sounds like a big waste to me: I'd rather make the window narrower and use the remaining space for something else, but to each his own). > 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. > 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? You might like the adaptive-wrap package for that. [ Here again, I'd suggest to shorten the source lines as a better solution, because long lines in source code are just an abomination, but admittedly if it's not your code adaptive-wrap-prefix-mode might be helpful. ] > 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. Maybe while filling > at fill-column behind the scenes. So I stop hitting M-q > (`fill-paragraph') repetedly while word-wrap is on (isn’t this what > word-wrap is supposed to stop?) to make text readable. I don't have a package to suggest here :-( Hopefully, one exists, tho. There's `refill-mode` which provides a related feature, but it just does the M-q for you while you edit the text, which won't help you if you're only reading the text. The main difficulty here is that to do a proper refill, you need to find the paragraph boundaries and there's no reliable rule for that (only heuristics and conventions), so doing it 100% automatically tends to come with warts and all (which is why refill-mode only performs the refill for the paragraphs which you do edit, for example). But I guess if you do it without modifying the buffer (i.e. only using features which affect the display but not the buffer's contents), the warts would at least be "harmless". Stefan