unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 7004@debbugs.gnu.org
Subject: bug#7004: 23.2; In fullscreen mode, the echo area takes too much vertical space
Date: Wed, 15 Sep 2010 09:00:25 +0200	[thread overview]
Message-ID: <4C906F09.2030809@gmx.at> (raw)
In-Reply-To: <83vd682puw.fsf@gnu.org>

 >> (1) Pixel-to-character conversion routines.
 >>
 >> (2) Pixel-wise mouse tracking and coordinates_in_window stuff.
 >>
 >> (3) Pixel-wise window-configurations storing and comparing.
 >
 > Maybe I don't understand something, but all these are already in place
 > (perhaps with the exception of no. 3).  Note that I'm not talking
 > about being able to set a window height to any number of pixels, just
 > waste less space in the mini-window, ...

You have to be able to set a window height to any number of pixels if
you want to fix the bug.  The case at hand is when Emacs gets a request
from the window manager to set the frame height to a value that is _not_
an integer multiple of Emacs' canonical line height (aka default font
height) of that frame.

IIUC Emacs usually refuses to do that but rounds the height to the
nearest integer multiple of the canonical line height instead.  For the
maximize-frame case, however, Emacs does try to satisfy the request but
adds the remainder of the rounding operation to the minibuffer window
which gives a strange effect because we are accustomed to see the latter
as a one line window without mode-/header-line.

So let's assume that we want to move this remainder to the frame root
window instead.  Now coordinates_in_window from window.c has to

   "Test if the character at column *X, row *Y is within window W.
    If it is not, return ON_NOTHING;
    if it is in the window's text area,
       set *x and *y to its location relative to the upper left corner
          of the window, and
       return ON_TEXT;
    if it is on the window's modeline, return ON_MODE_LINE;
    ..."

but the tests it performs is currently based on things like

WINDOW_BOTTOM_EDGE_Y

which is defined as

#define WINDOW_BOTTOM_EDGE_Y(W) \
   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
     ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
    + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))

that is, an integer multiple of the canonical line height of the frame
of W.  So this does not account for the remainder we want to add and the
result could be that a mouse click in the window text area is recognized
as a click on the window's modeline or even another window.  Obviously,
sampling windows for mouse-autoselection might give strange results as
well.

 > which was the reason for this bug
 > report.

ISTR that Jan and Yamamoto here discussed a similar problem for the
horizontal case, that is, what to do with the remainder on the left or
right of the scrollbar.

martin





  reply	other threads:[~2010-09-15  7:00 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 [this message]
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
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

  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=4C906F09.2030809@gmx.at \
    --to=rudalics@gmx.at \
    --cc=7004@debbugs.gnu.org \
    --cc=eliz@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).