GNU bug report logs - #17831
24.4.50; bad default value for `Man-width'

Previous Next

Full log

Message #45 received at 17831 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, 17831 <at> debbugs.gnu.org, sdl.web <at> gmail.com
Subject: Re: bug#17831: 24.4.50; bad default value for `Man-width'
Date: Tue, 24 Jun 2014 20:59:08 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: rudalics <at> gmx.at,  17831 <at> debbugs.gnu.org,  sdl.web <at> gmail.com
> Date: Tue, 24 Jun 2014 13:33:50 -0400
> 
> > By contrast, in the *Completions* use case the code that formats the
> > text runs synchronously, so having in place some protocol that would
> > allow to query about the dimensions of the window display-buffer
> > etc. _will_ get, and then immediately use these dimensions to format
> > the candidate list, is probably all we need.  The alternative you
> > favor is IMO worse: it will momentarily flash incorrect display, which
> > I think will look un-professional.
> 
> In the *Completions* case the empty buffer won't be temporarily
> displayed (because there's no redisplay going on before it's filled).

Are you sure? what about echo-area messages, which might trigger
redisplay?

But if you are right, then this is just another case of what I
suggested, i.e. being able to query Emacs about the dimensions before
actually displaying.

> The unprofessionalism doesn't bother me too much for M-x man, especially
> since the current behavior is broken IMNSHO: it pops up a window
> asynchronously, i.e. at a time you might be doing something else and not
> expecting this disruption.

So perhaps TRT is simply to get rid of the asynchronous operation in
the first place.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.