emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing redisplay-dont-pause


From: Vincenzo Pupillo
Subject: Re: Removing redisplay-dont-pause
Date: Thu, 19 Dec 2024 12:15:35 +0100

Ciao,
 
compilation fails with this merge. See bug#74968. 

[vincenzo@fedora emacs]$(master =) rg Qredisplay_dont_pause
src/xterm.c
6372:  specbind (Qredisplay_dont_pause, Qt);

src/xfns.c
9967:  specbind (Qredisplay_dont_pause, Qt);

src/pgtkterm.c
7635:  specbind (Qredisplay_dont_pause, Qt);

src/ChangeLog.9
8146:   * dispextern.h (Qredisplay_dont_pause): Declare extern.
8152:   * dispnew.c (Qredisplay_dont_pause): New variable.

src/pgtkfns.c
3672:  specbind (Qredisplay_dont_pause, Qt);

Vincenzo

In data giovedì 19 dicembre 2024 11:07:33 Ora standard dell’Europa centrale, 
Gerd Möllmann ha scritto:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> > Stefan Kangas <stefankangas@gmail.com> writes:
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>> So what do people think about removing this variable (and the code
> >>> supporting it) from Emacs?  In particular, does anyone use that
> >>> variable in a non-default nil value?
> >> 
> >> It seems like there are no objections to removing redisplay-dont-pause.
> >> 
> >> Should we go ahead with this change now?
> > 
> > To get something to master immediately or in the near future is a bit
> > difficult. Let me explain.
> > 
> > The necessary changes are in scratch/tty-child-frames and could be
> > resurrected by reverting these commits
> > 
> >   e7359fbbc40 Revert "Don't pause display for pending input"
> >   e5a2bc740dc Revert "Remove an unused parameter"
> > 
> > I reverted then because Eli complained that a feature branch should
> > contain only one feature and he wanted a discussion about the removal in
> > the first place.
> > 
> > The code in the branch that is affected by the removal of r-d-p is
> > different enough from master that removing r-d-p effectively means
> > implementing it again. And as a bonus that would lead to merge conflicts
> > in my Emacs, from where the changes originate, and where they are of
> > course not reverted. So that's no good.
> 
> This is now also on master.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]