GNU bug report logs - #18528
24.3.93; Crash during restoration of frameset from desktop

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Mon, 22 Sep 2014 15:24:02 UTC

Severity: normal

Found in version 24.3.93

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #38 received at 18528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 18528 <at> debbugs.gnu.org
Subject: Re: bug#18528: 24.3.93;
 Crash during restoration of frameset from desktop
Date: Wed, 24 Sep 2014 10:15:48 +0300
> Date: Wed, 24 Sep 2014 08:16:47 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 18528 <at> debbugs.gnu.org
> 
>  > So now I don't understand why you asked about rounding up, since we
>  > evidently already do.
> 
> Not everywhere.  For example, we don't in FRAME_MESSAGE_BUF_SIZE and
> FRAME_CURSOR_X_LIMIT.  And the following check in compute_motion of
> indent.c seems dubious as well.
> 
> 	  if (!NILP (Vtruncate_partial_width_windows)
> 	      && (total_width < FRAME_COLS (XFRAME (WINDOW_FRAME (win)))))

That has nothing to do with rounding, does it?

Anyway, FRAME_MESSAGE_BUF_SIZE has nothing to do with frame/window
width, AFAIR, it is just computed based on the width.

FRAME_CURSOR_X_LIMIT is used only for the echo area, so the
probability of having a non-default font there is very low.  We should
probably do that calculation in pixels, though.

As for the second example, I have a difficulty concocting a use case
when it should matter, due to a combination of conditions that enter
that block.  But feel free to fix that if it sometimes gives bad
results.




This bug report was last modified 10 years and 244 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.