all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Paul W. Rankin" <hello@paulwrankin.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Adding olivetti to GNU ELPA
Date: Thu, 09 May 2019 16:54:48 +1000	[thread overview]
Message-ID: <m27eb0w213.fsf@paulwrankin.com> (raw)
In-Reply-To: <83ftppii16.fsf@gnu.org>


On Wed, May 08 2019, Eli Zaretskii wrote:

>> From: "Paul W. Rankin" <hello@paulwrankin.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 08 May 2019 14:07:24 +1000
>> 
>> I'm sorry to say but this goes a bit over my head... From Emacs 24 - 
>> 27 
>> there seem to be three hooks that have shifting/overlapping 
>> capabilities. The hooks are:
>> 
>> - window-configuration-change-hook
>> - post-command-hook
>> - window-size-change-functions
>> 
>> When I first created the minor mode, window-configuration-change-hook 
>> was enough for all situations I encountered.

> I agree that we have a royal mess with these hooks.  And if you think
> the above 3 are all of it, then, unfortunately, they aren't: there are
> also pre-redisplay-functions and window-scroll-functions -- those may
> be necessary if your mode needs to pay attention to when the screen
> space used by line numbers changes, either because the buffer is
> scrolled past the point where the line numbers need more or less
> digits than before, or because the user customizes the line-number
> face in a way which changes the font used by the face, with your mode
> already active.
>
> I'd like to try to help you, but I'm not sure I understand the problem
> well enough.  Are you asking whether what you did could be simplified
> by using less hooks?  Or are you saying that the current code doesn't
> yet handle well some situations?  In the latter case, could you please
> describe those problematic situations?

I think there are three separate but perhaps related problems. At its 
most basic, olivetti is really just a single main function, which could 
be distilled to:

    (set-window-margins
      (current-window) (/ 2 (- (window-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.

For compatibility with changes in Emacs 25.x, we also reset the margins 
to 0 before any window splitting, to prevent the combined window width 
being too large to split.

So the three problems I'm running into are:

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.

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)

It would be nice to achieve consistency with these.

3. Issues scrolling with display-line-numbers-mode, but I don't mind 
about this.

>> I *think* what is needed is a way to apply the hooks contingent on 
>> emacs-major-version <= 24 and <= 25 or 26(?) and <= 27.
>
> Yes, and there's nothing wrong with that for a package that wants to
> support multiple Emacs versions.

My difficulty is that I don't understand enough how these hooks have 
changed from 24 -> 27. Stefan tried to explain it to me, but... I still 
didn't get it :(

-- 
https://www.paulwrankin.com



  reply	other threads:[~2019-05-09  6:54 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 [this message]
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
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

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

  git send-email \
    --in-reply-to=m27eb0w213.fsf@paulwrankin.com \
    --to=hello@paulwrankin.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.