unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jonas Bernoulli <jonas@bernoul.li>
To: emacs-devel@gnu.org
Subject: size hints and tiling window managers
Date: Thu, 06 Dec 2012 19:55:30 +0100	[thread overview]
Message-ID: <87zk1r104d.fsf@bernoul.li> (raw)

Hello

On X11 Emacs provides size hints to the window manager, which the latter
may choose to ignore.  When that happens Emacs paints the extra space at
the right and/or bottom with the background color of the default face.

There are legitimate reasons why a window manager chooses to ignore size
hints.  E.g. tiling window managers (dwm, awesome, xmonad, wmii, i3...)
place windows next to each using all available space and without any
window covering part of another window.

In other words tiling wms arrange (X11) windows as Emacs arranges
(Emacs) windows in an (Emacs) frame.

A tiling wm has several options how to deal with windows that provide
size hints.

1. Respect the hints and make the borders thicker, so that the window +
   the borders fill up the intended space.  Ugly.

2. Respect the hints, draw the border around it, and fill the space that
   is left using some "in between windows" color.  Also quite ugly.

3. Ignore the hints leaving it to the client to do something with the
   extra space.  This is what most tiling wms do, because the result
   *usually* looks good enough.

4. Respect the size hints and paint the extra space using some color
   instead of letting the client do it.  I am not aware of a wm that
   does this (it might have to use different colors for different
   clients).

When a terminal emulators is forced to paint some extra space because
the wm does not respect the size hints it does so using the background
color.

Emacs does the same thing: it paints the extra space using the
background color of the default face.  The problem is that Emacs frames
may also have fringes which usually don't have the same background
color.  As a result Emacs draws a "line" with the same color as *the*
background color to the right of the right fringe (and below the echo
area).

To work around the resulting ugliness I just did not use a right fringe,
but I don't want to do that any longer.

There are at least two better ways in which Emacs could deal with wms
not respecting size hints:

1. A quick (and not so bad) work-around would be to make the color used
   to paint the extra space independent of the background color of the
   default face.  This way users of tiling wms could just set it to the
   background color of the fringe instead.  Currently the following does
   not work:

   (set-frame-parameter (selected-frame)
                        'background-color
                        (face-attribute 'fringe :background))

   as it also changes the default background.

2. However I think it would be better if Emacs would just use any window
   size without having to paint some extra space to the right and below
   of the "actual" content.  One way of doing that could be to
   dynamically adjust the width of the fringes (and the height of the
   minibuffer/echo area).

I understand that implementing the latter probably isn't easy to do, so
I am already happy if someone could separate the default and "extra
space" backgrounds as suggested first.

But please also consider the second suggestion.  Since buffers can
contain text that have a different width than that of the default face
relying on size hints does not guarantee that text is never cut of in
the middle of a character.  And keep in mind that you would be doing
this for the benefit of tiling wms - the Emacsen among the window
managers :-)

  Best regards,
  Jonas



             reply	other threads:[~2012-12-06 18:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-06 18:55 Jonas Bernoulli [this message]
2012-12-07 10:35 ` size hints and tiling window managers martin rudalics
2012-12-07 10:45   ` Eli Zaretskii
2012-12-08  1:42   ` James Cloos
2012-12-08  9:01     ` Eli Zaretskii
2012-12-09 19:23       ` Jonas Bernoulli
2012-12-09 19:36         ` Eli Zaretskii
2012-12-15 23:33           ` Jonas Bernoulli
2012-12-16  4:42             ` Eli Zaretskii
2012-12-11  8:07       ` Giorgos Keramidas
2012-12-11  8:10         ` Eli Zaretskii
2012-12-08  9:15     ` Jan Djärv

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=87zk1r104d.fsf@bernoul.li \
    --to=jonas@bernoul.li \
    --cc=emacs-devel@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 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).