Hello, This uses the standard Emacs function `split-window-sensibly` to split a window horizontally or vertically depending on space when opening a message in tree view. By default, split-width-threshold is 160 columns (and -height- is nil), so screens wider than 160 will be split horizontally. This is based on an older proposal [1] which manually did the calculation of width. The main issues there were (1) lack of configurability and (2) lack of testing. I don't have an answer for testing, but this allows users to configure two thresholds using built-in variables, an improvement. Also, should I update the NEWS file? I see its latest changes are in November and there's been user-visible changes since. Thanks, Radu [1]: http://notmuch.198994.n3.nabble.com/emacs-Split-wide-window-vertically-for-tree-mode-message-pane-td4039070.html The original patch email follows: From 1ce4789b11007b46619faed7bf14f54686ca3538 Mon Sep 17 00:00:00 2001 From: Radu Butoi <rbutoi@gmail.com> Subject: [PATCH] emacs: split-window-sensibly in tree mode with open message When showing messages in tree-mode, this will split the window horizontally or vertically depending on the split-{width,height}-threshold. --- emacs/notmuch-tree.el | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el index 254664c4..353700a1 100644 --- a/emacs/notmuch-tree.el +++ b/emacs/notmuch-tree.el @@ -524,8 +524,7 @@ NOT change the database." ;; We close and reopen the window to kill off un-needed buffers ;; this might cause flickering but seems ok. (notmuch-tree-close-message-window) - (setq notmuch-tree-message-window - (split-window-vertically (/ (window-height) 4))) + (setq notmuch-tree-message-window (split-window-sensibly)) (with-selected-window notmuch-tree-message-window ;; Since we are only displaying one message do not indent. (let ((notmuch-show-indent-messages-width 0) -- 2.26.2
Radu Butoi <rbutoi@gmail.com> writes:
> Also, should I update the NEWS file? I see its latest changes are in
> November and there's been user-visible changes since.
We seem to have got into the habit of updating the NEWS file right
before release. This seems to work OK, and avoids some conflicts between
patch series.
d
Hi David,
David Bremner <david@tethera.net> writes:
> We seem to have got into the habit of updating the NEWS file right
> before release. This seems to work OK, and avoids some conflicts between
> patch series.
Makes sense, probably something like:
When opening message pane in tree-mode, split window horizontally or vertically depending on available space, set by split-{width,height}-threshold.
Otherwise, does the patch look good? split-window-sensibly seems to be a drop-in replacement for split-window-*.
Best,
Radu
[-- Attachment #1.1: Type: text/plain, Size: 1184 bytes --] On Sat 2020-05-02 20:11:09 -0400, Radu Butoi wrote: > This uses the standard Emacs function `split-window-sensibly` to split a > window horizontally or vertically depending on space when opening a > message in tree view. By default, split-width-threshold is 160 columns > (and -height- is nil), so screens wider than 160 will be split > horizontally. > > This is based on an older proposal [1] which manually did the > calculation of width. The main issues there were (1) lack of > configurability and (2) lack of testing. I don't have an answer for > testing, but this allows users to configure two thresholds using > built-in variables, an improvement. I like this proposal, and the simplification that it gives to the notmuch-emacs codebase. However, this thread is the first place i've learned about split-window-sensibly, so i'm probably not eligible to really judge the merits here. As far as testing goes, a test would be nice -- is this something you could add to test/T460-emacs-tree.sh ? Testing UI/UX issues is always pretty tough though, and it's not clear to me that we're actually already testing the existing "(/ (window-height) 4)" business anyway. --dkg [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 227 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --]
Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes: > I like this proposal, and the simplification that it gives to the > notmuch-emacs codebase. However, this thread is the first place i've > learned about split-window-sensibly, so i'm probably not eligible to > really judge the merits here. For some historical context, split-window-sensibly was introduced in 2009 [1] and the (split-window-vertically (/ (window-height) 4)) code in 2012 [2]. The two functions seem pretty interchangeable. > As far as testing goes, a test would be nice -- is this something you > could add to test/T460-emacs-tree.sh ? Testing UI/UX issues is always > pretty tough though, and it's not clear to me that we're actually > already testing the existing "(/ (window-height) 4)" business anyway. I did look at that file, and there is no tests for the current split functionality. All of the tests use the test-output function which outputs the contents of a buffer -- we need the whole frame. This might need to be done at a layer above Emacs and may complicate the test. I took a "screenshot" by copying my terminal contents with tmux, but I'm not sure how that would look like in a test. If I manually do the split on the test case [3], the fourth line does cut off some of the text since it goes beyond 160 columns, the default threshold. It is still viewable by pressing C-e, like anything too long. So I agree that testing would be nice but it seems to be an existing problem here. I'm not sure how, or if, other Emacs packages do character-perfect tests like these. -Radu [1]: git.savannah.gnu.org/cgit/emacs.git/commit/?id=8b10a2d19895041340296a703ba956c77541ec88 [2]: git.notmuchmail.org/git?p=notmuch;a=commit;h=3d92a257c8adbb36615bc61be9e668c8188006dc [3]: https://gist.githubusercontent.com/rbutoi/78c5b30fc5e64585bda18abbc5bf1fbf/raw/cba7df184f3cd534c92a6fb9bf39aa121c19ecd7/gistfile1.txt
Hi
> For some historical context, split-window-sensibly was introduced in 2009 [1] and the (split-window-vertically (/ (window-height) 4)) code in 2012 [2]. The two functions seem pretty interchangeable.
As far as I can see the split-window-sensibly version splits the window into two equal parts, whereas the split-window-vertically version (deliberately) makes the message pane bigger than the thread pane.
I definitely prefer the current version (unsurprising as I chose the split back in 2012), but others may disagree.
Best wishes
Mark
[-- Attachment #1.1: Type: text/plain, Size: 416 bytes --] On Fri 2020-05-22 19:58:19 +0100, Mark Walters wrote: > As far as I can see the split-window-sensibly version splits the > window into two equal parts, whereas the split-window-vertically > version (deliberately) makes the message pane bigger than the thread > pane. I find this argument compelling. When i've used split-pane MUAs, i pretty much always want the tree view smaller than the message pane. --dkg [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 227 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --]
Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
> I find this argument compelling. When i've used split-pane MUAs, i
> pretty much always want the tree view smaller than the message pane.
Fair enough. I realized after these responses that my own settings were getting in the way -- I make all my windows equally sized using advice.
Thanks for considering my patch.