GNU bug report logs - #7822
24.0.50; `fit-window-to-buffer': take display artefacts into account

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, 7822 <at> debbugs.gnu.org, 7822-done <at> debbugs.gnu.org
Subject: bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
Date: Mon, 22 Sep 2014 13:24:53 -0700 (PDT)

> > The ER is for that and more.  It asks that a user be able to
> > control "how much" it "takes display artefacts into account".
> > But just being able to tell it not to take any into account
> > would probably be acceptable.
> 
> Could we have at least some kind of motivating example for why one
> might want that kind of control?

1. He who can do more can do less.

2. That is what the function did before the ER.  Some users might
prefer that longstanding behavior generally.

3. Code might want to handle things differently than the current
automatic handling.  In particular, it might want to not take into
account some display artefacts, or to deal with them differently.

It is likely to be harder for code to compensate for automatic,
fancy fitting than it would be to add custom fitting behavior to
rudimentary-fit behavior.  Best would be as the ER suggested: be
able to choose just which display artefacts are to be taken into
account.

4. Providing also a simple, no-bells-and-whistles behavior lets
users roll their own fitting behavior (#3).  Providing only a
one-size-fits-all-do-everything behavior does not.  Keep our
options open.

5. What extra cost is there, to provide this flexibility?  (See
#1.)

6. Finally, that is what the ER explicitly requested (!).  It did
not ask for only do-it-all behavior.  It asked to allow users to
be able to obtain that behavior and to do without it - au choix.
The request stands, unless it has been realized.  Has it?

I might have had additional things explicitly in mind when I filed
the ER almost 4 years ago, but at least these simple motivations
come to mind immediately now.

I haven't seen where the code for this is (where is it?).  If this
was "fixed" in Lisp code then presumably it will be possible for
users to tease apart the various parts, in order to, in the end,
put together whatever behavior they need.  But if this was "fixed"
in C code then there is all the more need for explicit provision
for users to turn parts of it off.

Previous Next

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