From: Joost Kremers <joostkremers@fastmail.fm>
To: help-gnu-emacs@gnu.org
Subject: Re: Is it ok to use (redisplay), or should this be left to the experts?
Date: Tue, 12 Feb 2019 00:43:24 +0100 [thread overview]
Message-ID: <87tvh9gacj.fsf@fastmail.fm> (raw)
In-Reply-To: <83pnt3hd15.fsf@gnu.org>
On Fri, Jan 11 2019, Eli Zaretskii wrote:
>> It seems that a call to (redisplay) also does the trick, but
>> I'm
>> hesitant to add this, because, well, I'm not sure why, exactly,
>> it's just that I'm not entirely sure when, i.e., in what
>> circumstances, (redisplay) is meant to be used, what side
>> effects
>> to watch out for (in any), etc.
>
> There should be no problem with invoking 'redisplay', it just
> slows
> down the program a bit, especially if the code in question will
> or
> might be executed frequently.
It's only called once, when the relevant minor mode is activated
for the first time, so that shouldn't be an issue.
> However, sit-for is IMO better, because
> in some use cases you must allow for the window manager to
> respond to
> the full-screen request and for Emacs to receive a notification
> from
> the window manager. And that means waiting for some short time.
An unpredictable amount of time, I guess. Although it's unlikely
to be very long, if I handle the problem by introducing an
artificial delay, it would have to be long enough to handle the
slowest of slow computers. Which might be a noticeable delay,
which would inconvenience everyone else...
>> So I guess what I'm asking is whether someone can tell me
>> whether
>> (redisplay) is the right way to deal with this issue, or
>> whether
>> there is a better way. Or perhaps the user is SOL and needs to
>> do
>> some local configuration to get things to behave?
>
> I cannot answer this because it isn't clear to me who initiated
> full-screen: the user or the package. If it's the package, then
> the
> package should also accommodate these issues, perhaps only when
> the
> frame size changes significantly.
Yes, it's the package that initiates full-screen. And I suspect
that in most cases, it will be a significant size-change.
So I'm leaning toward Stefan's proposed solution, which is to use
`window-size-change-functions'...
Thanks,
--
Joost Kremers
Life has its moments
prev parent reply other threads:[~2019-02-11 23:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 20:43 Is it ok to use (redisplay), or should this be left to the experts? Joost Kremers
2019-01-10 22:02 ` Stefan Monnier
2019-02-11 23:27 ` Joost Kremers
2019-02-12 3:58 ` Stefan Monnier
2019-02-12 8:06 ` Joost Kremers
2019-02-12 14:45 ` Stefan Monnier
2019-01-11 7:24 ` Eli Zaretskii
2019-02-11 23:43 ` Joost Kremers [this message]
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=87tvh9gacj.fsf@fastmail.fm \
--to=joostkremers@fastmail.fm \
--cc=help-gnu-emacs@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.