all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dani Moncayo <dmoncayo@gmail.com>
To: Tassilo Horn <tassilo@member.fsf.org>
Cc: 7004@debbugs.gnu.org
Subject: bug#7004: 23.2; In fullscreen mode, the echo area takes too much vertical space
Date: Thu, 17 Mar 2011 19:43:05 +0100	[thread overview]
Message-ID: <AANLkTim9oPPkiXoWpbRYa3cn1+Q36fuA7zf6HBfVhyHU@mail.gmail.com> (raw)
In-Reply-To: <87aagueyp0.fsf@member.fsf.org>

On Thu, Mar 17, 2011 at 13:08, Tassilo Horn <tassilo@member.fsf.org> wrote:
>> When I put Emacs in fullscreen mode, it seems to me that the last line
>> (echo area/minibuffer) takes too much, unnecessary vertical space.
>
> What would you expect instead?

In short, I would expect Emacs to use _all_ the available space to
display content (as pointed out by Stefan previously).

I will try to develop this idea a little further:

0.- A bit of nomenclature, to avoid misunderstanding (disclaimer: I've
not found better names after a while of thinking! :) ):
0.1.- Let's call "GWindow" (after "graphical window") to a
"window-manager window", i.e., what is normally called "window" in the
context of a window manager or desktop environment.
0.2.- Let's call "ClientArea" to the rectangle of the GWindow intended
for application-specific drawing, i.e., the GWindow excluding title
bar, tool bars, menú bars, graphical borders, etc.

1.- When using Emacs in graphical mode, the user should be able to set
each Emacs' GWindow to any* desired _pixel_ size, regardless of
whether it is maximized or not.
(*): Maybe imposing lower limits.

2.- Given the desired (user-imposed) total size of the GWindow, Emacs
should ask the window manager for the size of its ClientArea (height
and width).

3.- Compute the total "remaining height", i.e., the leftover height if
only _complete_ lines were displayed in each currently visible window
(of course taking into account the font(s) associated with the text to
be displayed).

4.- Compute the "remaining width" analogously (i.e. repeat previous
step, replacing "height" with "width" and "lines" with "columns").

5.- At this point, Emacs could finally do the drawing this way:
5.1- Distribute the total remaining height among the currently visible
windows, in the form of partial lines displayed at the bottom of each
window. (This "distribution" may not be trivial, as pointed out
already in this thread...)
5.2- Similarly, distribute the total remaining width in the form of
partial columns displayed at the right of each window.


> Emacs issues size hints to the window manager, which tells it the width
> and height of how emacs wants to be painted.  These sizes are exactly
> divisible by the number of lines/columns emacs should display, which
> depends on font size and stuff like that.

With my previous approach, there would be no need for such hints.
Emacs should be able to adapt itself to any pixel size imposed by the
window manager (which in turn obeys to the user).


-- 
Dani Moncayo





  reply	other threads:[~2011-03-17 18:43 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-09 15:14 bug#7004: 23.2; In fullscreen mode, the echo area takes too much vertical space Dani Moncayo
2010-09-10  9:01 ` Jan Djärv
2010-09-10 12:39   ` Stefan Monnier
2010-09-10 14:14     ` Jan Djärv
2010-09-10 16:59       ` Andreas Schwab
2010-09-10 22:19         ` Jan Djärv
2010-09-10 22:46           ` Andreas Schwab
2010-09-11  7:37             ` Jan Djärv
2010-09-11  7:53               ` martin rudalics
2010-09-11  8:56               ` Andreas Schwab
2010-09-11 10:06                 ` Jan Djärv
2010-09-11  0:10           ` David De La Harpe Golden
2010-09-11  7:50             ` Jan Djärv
2010-09-13 12:37               ` Eli Zaretskii
2010-09-13 18:59                 ` Jan Djärv
2010-09-13 19:18                   ` Eli Zaretskii
2010-09-13 20:48                     ` Jan Djärv
2010-09-13 21:26                       ` Eli Zaretskii
2010-09-14  4:48                         ` Jan Djärv
2010-09-14  5:50                         ` Jan Djärv
2010-09-14  7:03                         ` martin rudalics
2010-09-14 17:32                           ` Eli Zaretskii
2010-09-15  7:00                             ` martin rudalics
2010-09-15 19:30                               ` Eli Zaretskii
2010-09-15 20:45                                 ` Jan Djärv
2010-09-16  4:06                                   ` Eli Zaretskii
2010-09-16  7:35                                     ` Jan Djärv
2010-09-16  7:23                                 ` martin rudalics
2010-09-16 10:59                                   ` Jan Djärv
2010-09-16 12:10                                     ` martin rudalics
2010-09-16 13:34                                       ` Jan Djärv
2010-09-16 16:17                                         ` martin rudalics
2010-09-17  5:25                                           ` Jan Djärv
2010-09-17  6:34                                             ` martin rudalics
2010-09-17  7:09                                               ` Jan Djärv
2010-09-17  8:29                                                 ` martin rudalics
2010-09-11 12:44       ` Stefan Monnier
2010-09-10 13:40 ` MON KEY
2010-09-10 16:06   ` Jan Djärv
2010-09-11  3:38     ` MON KEY
2010-12-08 13:55 ` Dani Moncayo
2011-03-16 20:13 ` bug#7004: " Dani Moncayo
2011-03-17 12:08 ` bug#7004: 23.2; " Tassilo Horn
2011-03-17 18:43   ` Dani Moncayo [this message]
2011-03-17 20:31     ` Tassilo Horn
2011-03-17 22:01       ` Dani Moncayo
2011-03-17 22:33         ` Tassilo Horn
2011-03-18  6:21     ` Jan Djärv
2011-03-18  7:30       ` Dani Moncayo
2011-03-18  7:36         ` Dani Moncayo
2011-09-05 10:32 ` bug#7004: " Dani Moncayo
2011-09-05 17:51   ` 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

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

  git send-email \
    --in-reply-to=AANLkTim9oPPkiXoWpbRYa3cn1+Q36fuA7zf6HBfVhyHU@mail.gmail.com \
    --to=dmoncayo@gmail.com \
    --cc=7004@debbugs.gnu.org \
    --cc=tassilo@member.fsf.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.