unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Paul W. Rankin" <hello@paulwrankin.com>
To: martin rudalics <rudalics@gmx.at>
Cc: Eli Zaretskii <eliz@gnu.org>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	emacs-devel@gnu.org
Subject: Re: Adding olivetti to GNU ELPA
Date: Tue, 14 May 2019 15:16:48 +1000	[thread overview]
Message-ID: <m2sgth39a7.fsf@paulwrankin.com> (raw)
In-Reply-To: <875d1b0c-7f44-ba5d-4660-84637533b8f3@gmx.at>

Sorry for my delayed reply...

On Thu, May 09 2019, martin rudalics wrote:

>>     (set-window-margins
>>       (current-window) (/ 2 (- (window-width) olivetti-body-width)))
>
> What is 'current-window' and how does it relate to 'selected-window'?

Sorry, this should be selected-window, and also window-width -> 
window-total-width.

i.e. The kernel of the minor mode should just be computing when to run 
this:

    (set-window-margins
     (selected-window) (/ 2 (- (window-total-width)
                               olivetti-body-width)))

>> There are some other ancillary functions, but really it's just a
>> case of running this function in all windows displaying the current
>> buffer when olivetti-body-width changes or when the window width
>> changes.
>
> What does "current buffer" refer to here?  I suppose you want to run
> "this function" whenever the body width of a window showing a buffer
> with olivetti mode enabled changes.  So with Emacs 27 it should
> suffice to add your function to `window-size-change-functions' for
> each buffer where olivetti mode is enabled

I was thinking that current buffer is just the result of function 
current-buffer, but yes, your description is accurate.

>> 1. Some users have complained of lagging input, which seems to be
>> due to olivetti setting the margins too often, i.e. on too many
>> hooks. So using the minimal number of hooks is preferable.
>
> 'set-window-margins' doesn't do much when margins don't change.  So I
> suppose that for some reason olivetti mode wants margins to change too
> often.  If so, could you try to find out why?

The problem I ran into was with Emacs 25 the window splitting code 
changed such that windows with large margins would calculate as being 
too small to split and result in an error. So I needed to make olivetti 
first cycle through all "olivetti-ized windows" and reset all the 
margins to 0, then allow the desired window splitting to occur, then 
cycle through and set up the margins again.

But also, the scenarios in which window-configuration-change-hook ran 
seemed to change too, so on Eli's recommendation I added the above 
function to post-command-hook (Eli, sorry again for my poor and 
argumentative communication back then).

>> 2. But I've experienced olivetti failing to set the margins during a 
>> few common cases, e.g.:
>>   - splitting window with icomplete "*Completions*" buffer
>>   - splitting window with ispell-word "*Choices*" buffer
>>   - splitting window with magit-status
>>   - splitting window vertically with any buffers in a side-window in 
>>   the  same frame (which results in window being too large to split 
>>   -- I  think this is a separate issue)
>
> Too _large_ to split?

Sorry, what I wrote was incorrect. I think this issue is wholly 
separate. It occurs when:

1. olivetti is active in two windows, split above/below
2. a call is made to display-buffer-in-side-window

I've stepped through what's happening here and it seems to be when 
display-buffer-in-side-window calls split-window-no-error, which I think 
has something to do with olivetti wanting split-window or 
split-window-sensibly.

But this is reaching the extent of my skills/knowledge.

>> It would be nice to achieve consistency with these.
>
> Are these failures due to the fact that a releated hook is not run or
> are there other issues?

I am pretty sure it's because the right hook is not being called; from 
Stefan:

> The old window-size-change-functions was fundamentally broken for your 
> use-case because it wasn't run in all cases where you needed it.

> More specifically there were several different "missing" cases 
> (typically creation of new windows as well as changes in size that are 
> consequences of resizing *other* windows). So in Emacs<27, you need to 
> use the *global* part of window-size-change-functions (to react to 
> resizing in other windows) as well as (the local part of) 
> window-configuration-change-hook (to detect window creation) to cover 
> all relevant cases, AFAIK.

> But with the changes in Emacs-27 the local part of 
> window-size-change-functions should be all you need in your case. [ 
> And in Emacs<27 you should be able to replace the use of 
> post-command-hook by the use of (the part of 
> window-configuration-change-hook). ]

Stefan, sorry to be so dense, but I'm not exactly sure what you mean be 
the global/local distinction above. Does this refer to:

    olivetti--set-margins           ;; <- global?
    olivetti--set-window-margins    ;; <- local?

As you've all said, for Emacs 27 it appears that this all should be 
solved with just window-size-change-functions, but the minor mode is 
supposed to be compatible with Emacs >= 24.5, so I think something like 
the following is needed:

    (cond ((<= emacs-major-version 24)
           (add-hook 'window-configuration-change-hook
                     'olivetti--??? t t))
          ((<= emacs-major-version 26)
           (add-hook 'window-configuration-change-hook
                     'olivetti--??? t t)
           (add-hook 'window-size-change-functions
                     'olivetti--??? t t))
          ((<= 27 emacs-major-version)
           (add-hook 'window-size-change-functions
                     'olivetti--??? t t)))

But I'm not sure which of olivetti--set-margins or 
olivetti--set-window-margins should be used in every case, or the best 
solution for Emacs <= 26 (e.g. if window-configuration-change-hook 
should be replaced with post-command-hook there).

Sorry for the lengthy email, and thanks for all your help :)

--
https://www.paulwrankin.com



  parent reply	other threads:[~2019-05-14  5:16 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25  8:32 Adding olivetti to GNU ELPA Paul W. Rankin
2019-04-25  8:56 ` Eli Zaretskii
2019-04-25 12:32   ` Paul W. Rankin
2019-04-25 12:43     ` Eli Zaretskii
2019-04-25 13:01       ` Paul W. Rankin
2019-04-25 14:30         ` Eli Zaretskii
2019-05-08  4:07           ` Paul W. Rankin
2019-05-08  6:20             ` Eli Zaretskii
2019-05-09  6:54               ` Paul W. Rankin
2019-05-09  7:53                 ` Eli Zaretskii
2019-05-09  8:14                 ` martin rudalics
2019-05-09 13:30                   ` Stefan Monnier
2019-05-10  8:00                     ` martin rudalics
2019-05-14  5:16                   ` Paul W. Rankin [this message]
2019-05-14  7:04                     ` Paul W. Rankin
2019-05-14 12:22                     ` Stefan Monnier
2019-05-15  8:26                       ` Paul W. Rankin
2019-05-14 16:05                     ` Joost Kremers
2019-05-14 16:50                       ` Stefan Monnier
2019-05-14 21:56                         ` Joost Kremers
2019-05-15  1:29                           ` Stefan Monnier
2019-05-20  8:24                     ` martin rudalics
2019-05-20 13:14                       ` Paul W. Rankin
2019-05-21  7:32                         ` martin rudalics
2019-05-21  7:38                           ` Paul W. Rankin
2019-05-21  7:45                             ` martin rudalics
2019-05-21  9:05                               ` Paul W. Rankin
2019-05-21 10:04                                 ` martin rudalics
2019-05-22  1:47                                   ` Paul W. Rankin
2019-05-22  8:32                                     ` martin rudalics
2019-05-22  9:14                                       ` Paul W. Rankin
2019-05-08 14:07             ` Stefan Monnier
2019-05-08 15:45             ` Stephen Leake
2019-05-08 17:50               ` Eli Zaretskii
2019-04-26  1:17   ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2sgth39a7.fsf@paulwrankin.com \
    --to=hello@paulwrankin.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).