From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joost Kremers Newsgroups: gmane.emacs.bugs Subject: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' Date: Tue, 01 Dec 2015 15:11:48 +0100 Message-ID: <87bnaaz2aj.fsf@fastmail.fm> References: <87io4qgrcg.fsf@fastmail.fm> <87lh9kw8bd.fsf@fastmail.fm> <56581423.6010607@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1448979217 31928 80.91.229.3 (1 Dec 2015 14:13:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Dec 2015 14:13:37 +0000 (UTC) Cc: 22009@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 01 15:13:22 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a3lg9-0006ME-5D for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Dec 2015 15:13:13 +0100 Original-Received: from localhost ([::1]:52842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3lg8-0000m5-C6 for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Dec 2015 09:13:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3lg3-0000lt-UQ for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2015 09:13:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3lfz-0007nD-5M for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2015 09:13:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3lfy-0007n8-Tc for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2015 09:13:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a3lfy-0007jQ-ER for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2015 09:13:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Joost Kremers Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Dec 2015 14:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22009 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22009-submit@debbugs.gnu.org id=B22009.144897913229656 (code B ref 22009); Tue, 01 Dec 2015 14:13:02 +0000 Original-Received: (at 22009) by debbugs.gnu.org; 1 Dec 2015 14:12:12 +0000 Original-Received: from localhost ([127.0.0.1]:33898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3lf9-0007iF-Vk for submit@debbugs.gnu.org; Tue, 01 Dec 2015 09:12:12 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:41057) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3leo-0007hV-Sx for 22009@debbugs.gnu.org; Tue, 01 Dec 2015 09:12:10 -0500 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1F67720D9D for <22009@debbugs.gnu.org>; Tue, 1 Dec 2015 09:11:50 -0500 (EST) Original-Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 01 Dec 2015 09:11:50 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=iLgbC37LiNY+X31zDoT3SH6bnDM=; b=L6Wm7K wVEbS/qPx8gRnhmzdGrePTDvxWPILx2nEkvDa09K/fsaeaeLF09+UB5EtDwPKAHK 2eG0B9EkdUivrHmKYOLyyB3dJXtZgS2mgp/zEva74rLiDMp8NoflG10NZGH2FXjM r7pW+EXkvgJblWm/hD9IngKbqU2TLKApOcsZw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=iLgbC37LiNY+X31 zDoT3SH6bnDM=; b=NwVegQ8R+wHJPNMsbwQYMYhV/td2jq7w7SV5tKGtSxqWp1a 9g3j7ZqYQKfTuqB8hCfqRwJKyk87AZ8oCROGIBd5vR1Wa8LJ9BIYTRe6Claz+nA3 sNXH5LBP9MZK9Sn4ylgi7CzmXyqqhKQ+f9exGqaciVHPBfmcNwm6/aYX//5s= X-Sasl-enc: onwGYKarLqorUpOvqr+1NR9twrMXBN5pRAY9zzyloTNV 1448979109 Original-Received: from IdeaPad.messagingengine.com (eruc065.goemobile.de [134.76.38.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 5B9FDC0001C; Tue, 1 Dec 2015 09:11:49 -0500 (EST) User-agent: mu4e 0.9.13; emacs 24.5.50.1 In-reply-to: <56581423.6010607@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:109498 Archived-At: On Fr, Nov 27 2015, martin rudalics wrote: > > The point is that the margins may be used for two different kinds of > > purposes: > > > > (1) The margins can be used to display useful information, in which case > > they should be retained when the window is split. > > But ‘window-splittable-p’ is used in a context where usually we use the > new window to display another buffer than that of the original window. > To my knowledge nobody wants *help* or *completions* buffers to display > line numbers. But I'm talking about the original window, which is now narrower than it was before. If linum-mode is active in that buffer, it will still be active after the split and the window will need margins to accommodate the line numbers. > And if the original window has no margins but the new > window should display them, the current code won't help either. No, but the buffer displayed in the new window has a local value for `window-configuration-change-hook', which should take care of setting the margins (as it does in writeroom-mode). > > (2) The margins can be used to reduce the width of the text area. In > > this case, the margins are disposable. > > Let's specify the reason more explicitly: The margins are used to center > the text area in the window. Correct? Not necessarily, it's also possible that only one of the margins is widened. That is what visual-fill-column-mode does, another mode I wrote that mimics the effect of `fill-column' in buffers that use visual-line-mode. > > The only way to deal with both (1) and (2) correctly, and also with the > > case where different modes use the margins for (1) and (2) *at the same > > time*, would be to store information about the modes that use the > > margins and for which purpose. Then `window-splittable-p' could tell > > which part of the margins must be retained and which part is disposable. > > It would have to be clairvoyant wrt which kind of margins the buffer > displayed in the new window will have. ‘find-file’ can enable > ‘linum-mode’ in ‘find-file-hook’ but the real width of the margin needed > to display them will be known only when ‘linum-mode’ calculates it, that > is, _not_ at the time of splitting. Yes, of course, there's nothing to be done about that. `split-width-threshold' and/or `window-min-width' should be set up in such a way that the new window can comfortably display a buffer that has the margins that the user wants. But that's the user's responsibility. I'm only worried about the original window. Perhaps some clarification with screen shots is in order. Consider the following: http://wwwuser.gwdg.de/~jkremer/visual-fill-column1.png This is a buffer with a soft-wrapped text, with the right margin set to some large value so that the text is wrapped at `fill-column'. If I do `C-h f ' in such a window configuration, I get this: http://wwwuser.gwdg.de/~jkremer/visual-fill-column2.png which is odd, because there is so much "empty" space on the right. By using `window-total-width' in `window-splittable-p', I get this: http://wwwuser.gwdg.de/~jkremer/visual-fill-column3.png Much nicer, IMHO. (I'm not trying to defind my fix here, I know it's flawed. Just demonstrating what my use case is.) -- Joost Kremers Life has its moments