unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 7822@debbugs.gnu.org, 7822-done@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)	[thread overview]
Message-ID: <2b22f309-880c-44e3-a37a-a334b2f18c27@default> (raw)
In-Reply-To: <jwvvbofwiz9.fsf-monnier+bug#7822@gnu.org>

> > 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.





  reply	other threads:[~2014-09-22 20:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-14 22:46 bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows Themba Fletcher
2008-11-15  9:40 ` Eli Zaretskii
2008-11-15 10:04   ` Eli Zaretskii
2008-11-15 14:12     ` martin rudalics
2008-11-17 20:50   ` Themba Fletcher
2008-11-18 13:03     ` martin rudalics
2014-09-21 18:02 ` martin rudalics
2014-09-22  8:32   ` bug#456: menu-bar does not resize window martin rudalics
2014-09-22  9:02   ` bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account martin rudalics
2014-09-22 14:02     ` Drew Adams
2014-09-22 17:42       ` martin rudalics
2014-09-22 18:24         ` Drew Adams
2014-09-22 19:31           ` Stefan Monnier
2014-09-22 20:24             ` Drew Adams [this message]
2014-09-22 20:54               ` Stefan Monnier
2014-09-22 21:04                 ` Drew Adams
2014-09-22  9:07   ` bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session martin rudalics
2014-09-22  9:26   ` bug#203: Maximize frame does not work at startup martin rudalics
  -- strict thread matches above, loose matches on Subject: below --
2011-01-11  0:21 bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account Drew Adams
2011-01-11  4:40 ` Lennart Borgman
2011-01-12  2:14   ` Lennart Borgman
2011-01-12  3:16     ` Drew Adams
2011-01-12 10:40       ` Lennart Borgman
2011-01-12 11:33         ` Lennart Borgman
2011-01-12 15:11           ` Drew Adams
2011-01-12 17:55             ` Lennart Borgman
2011-01-12 18:24               ` Drew Adams

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=2b22f309-880c-44e3-a37a-a334b2f18c27@default \
    --to=drew.adams@oracle.com \
    --cc=7822-done@debbugs.gnu.org \
    --cc=7822@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).