all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Jan Djärv" <jan.h.d@swipnet.se>
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: Mon, 13 Sep 2010 20:59:27 +0200	[thread overview]
Message-ID: <4C8E748F.5040107@swipnet.se> (raw)
In-Reply-To: <83r5gx4y6e.fsf@gnu.org>



Eli Zaretskii skrev 2010-09-13 14.37:
>> Date: Sat, 11 Sep 2010 09:50:30 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> Cc: "7004@debbugs.gnu.org"<7004@debbugs.gnu.org>
>>
>> David De La Harpe Golden skrev 2010-09-11 02.10:
>>
>>> has support for displaying only part of a character line, at least at the
>>> bottom edge of a pane [emacs: window] (not sure about the top). It also
>>> supports partial character display at the right/left edge of the pane.
>
> That's right: Emacs does know how to display a partial line at the
> bottom of a window (not at the top, though, IIRC).  The question is
> why doesn't it happen in the OP's case.
>
> Perhaps that is some unintended side effect of how a frame is
> maximized on X (I cannot reproduce the problem on MS-Windows).  What
> happens if the frame is enlarged (e.g., by the mouse) instead?

The resizing is constrained to increments of the font size, so it is not 
possible to resize it manually to a fraction of the font size.
If we remove that constraint by editing the source it will show the same 
behavour, extra pixels are unused at the bottom of the frame.

>
>> Windows use code like this all over the place:
>>
>> /* Return the frame y-position before which window W ends.
>>      This includes a mode line, if any.  */
>>
>> #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))
>>
>>
>> i.e. pixels = lines * font height.
>
> No, your conclusion is incorrect.  See the comment above this macro:
> this is the Y pixel coordinate _before_ which the window ends.  If the
> last line is only partially visible, the this macro will return a
> value that is beyond the actual window display area.
>
> IOW, the fact that Emacs counts pixels in increments of the frame's
> default font size does not contradict the ability of displaying
> partially visible lines at the window bottom.  When I maximize a frame
> on Windows, that is what I get: the last line is only partially
> visible.  Why doesn't this happen for the OP on X?

I know it can dispay partial lines, info does that on its first page, for 
example, since the title is in a larger font.

But I don't know of any function that sizes a window by pixels.  All the 
resizing code does is to calculate rows and columns from the pixel sizes and 
the call change_frame_size.  That in turn resizes windows, but just based on 
lines and columns, not pixels AFAIK.

I see that W32 does that also, so how can it be different?

	Jan D.






  reply	other threads:[~2010-09-13 18:59 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 [this message]
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
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=4C8E748F.5040107@swipnet.se \
    --to=jan.h.d@swipnet.se \
    --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 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.