* [simon.marshall@misys.com: Detached minibuffer cropped text]
@ 2006-06-17 17:58 Richard Stallman
2006-06-18 21:12 ` Kim F. Storm
0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2006-06-17 17:58 UTC (permalink / raw)
Would someone please DTRT and ack?
------- Start of forwarded message -------
From: "Marshall, Simon" <simon.marshall@misys.com>
To: "'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)'"
<emacs-pretest-bug@gnu.org>
Date: Fri, 16 Jun 2006 09:34:47 +0100
MIME-Version: 1.0
Content-Type: text/plain
Subject: Detached minibuffer cropped text
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed
version=3.0.4
Start emacs like this:
xrdb -load
^D
emacs -Q --eval '(setq minibuffer-frame-alist (quote ((width . 80) (height .
1))) initial-frame-alist (quote ((minibuffer))))'
The detached minibuffer has insufficient space to display text. There isn't
room to display the lower few pixels of minibuffer text.
In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, Motif Version 2.1.0) of
2006-06-15 on perth X server distributor `Hummingbird Ltd.', version
11.0.100015 configured using `configure
'--prefix=/rvcarma/marshals/software/slash/usr/local'
'--with-x-toolkit=motif' 'CFLAGS=-g''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: en_GB.ISO8859-1
value of $LC_CTYPE: en_GB.ISO8859-1
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_GB.ISO8859-1
value of $LC_NUMERIC: en_GB.ISO8859-1
value of $LC_TIME: en_GB.ISO8859-1
value of $LANG: en_GB.ISO8859-1
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
delete-selection-mode: t
mouse-sel-mode: t
msb-mode: t
partial-completion-mode: t
show-paren-mode: t
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<down-mouse-3> <mouse-3> <drag-mouse-1> <down-mouse-1> <mouse-1>
<double-down-mouse-1> <down-mouse-3> <mouse-3> <mouse-1> <select-window>
<help-echo> <select-window> <down-mouse-1> <mouse-1> <double-down-mouse-1>
<double-mouse-1> <triple-down-mouse-1> <triple-mouse-1> <down-mouse-1>
<mouse-1> <down-mouse-1> <mouse-1> ; ; SPC <backspace> ; SPC s p a c e
<down> <down> <return> <return> <down-mouse-1> <mouse-1> <backspace>
<down-mouse-1> <mouse-1> <backspace> <down-mouse-1> <mouse-1> <backspace>
<backspace> <down-mouse-1> <mouse-1> <double-down-mouse-1> <mouse-movement>
<mouse-movement> <double-drag-mouse-1> <down-mouse-1> <mouse-1>
<double-down-mouse-1> <double-mouse-1> 8 0 <down-mouse-1> <mouse-1>
<double-down-mouse-1> <double-mouse-1> 1 <down-mouse-1> <mouse-1>
<double-down-mouse-1> <double-mouse-1> <triple-down-mouse-1>
<triple-mouse-1> <down-mouse-1> <mouse-1> <escape> SPC <select-window>
<help-echo> C-x 5 2 <switch-frame> <drag-n-drop> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <menu-bar> <help-menu> <report-emacs-bug>
Recent messages:
Loading advice...done
Loading paren...done
Loading complete...done
Loading msb...done
Loading mouse-sel...done
Loading delsel...done
Loading lazy-lock...done
Quit
Mark set [3 times]
Loading emacsbug...done
_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [simon.marshall@misys.com: Detached minibuffer cropped text]
2006-06-17 17:58 Richard Stallman
@ 2006-06-18 21:12 ` Kim F. Storm
0 siblings, 0 replies; 9+ messages in thread
From: Kim F. Storm @ 2006-06-18 21:12 UTC (permalink / raw)
Cc: Marshall, Simon, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> Would someone please DTRT and ack?
It doesn't happen for me. The minibuffer frame has approx. two lines with this setup.
GNU Emacs 22.0.50.25 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-06-17 on kfs-l.imdomain.dk
>
> From: "Marshall, Simon" <simon.marshall@misys.com>
> Subject: Detached minibuffer cropped text
> To: "'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)'" <emacs-pretest-bug@gnu.org>
> Date: Fri, 16 Jun 2006 09:34:47 +0100
>
> Start emacs like this:
>
> xrdb -load
> ^D
> emacs -Q --eval '(setq minibuffer-frame-alist (quote ((width . 80) (height .
> 1))) initial-frame-alist (quote ((minibuffer))))'
>
> The detached minibuffer has insufficient space to display text. There isn't
> room to display the lower few pixels of minibuffer text.
>
> In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, Motif Version 2.1.0) of
> 2006-06-15 on perth X server distributor `Hummingbird Ltd.', version
> 11.0.100015 configured using `configure
> '--prefix=/rvcarma/marshals/software/slash/usr/local'
> '--with-x-toolkit=motif' 'CFLAGS=-g''
>
> Important settings:
> value of $LC_ALL: nil
> value of $LC_COLLATE: en_GB.ISO8859-1
> value of $LC_CTYPE: en_GB.ISO8859-1
> value of $LC_MESSAGES: C
> value of $LC_MONETARY: en_GB.ISO8859-1
> value of $LC_NUMERIC: en_GB.ISO8859-1
> value of $LC_TIME: en_GB.ISO8859-1
> value of $LANG: en_GB.ISO8859-1
> locale-coding-system: iso-8859-1
> default-enable-multibyte-characters: t
>
> Major mode: Emacs-Lisp
>
> Minor modes in effect:
> delete-selection-mode: t
> mouse-sel-mode: t
> msb-mode: t
> partial-completion-mode: t
> show-paren-mode: t
> tooltip-mode: t
> mouse-wheel-mode: t
> menu-bar-mode: t
> file-name-shadow-mode: t
> global-font-lock-mode: t
> font-lock-mode: t
> blink-cursor-mode: t
> unify-8859-on-encoding-mode: t
> utf-translate-cjk-mode: t
> auto-compression-mode: t
> line-number-mode: t
> transient-mark-mode: t
>
> Recent input:
> <down-mouse-3> <mouse-3> <drag-mouse-1> <down-mouse-1> <mouse-1>
> <double-down-mouse-1> <down-mouse-3> <mouse-3> <mouse-1> <select-window>
> <help-echo> <select-window> <down-mouse-1> <mouse-1> <double-down-mouse-1>
> <double-mouse-1> <triple-down-mouse-1> <triple-mouse-1> <down-mouse-1>
> <mouse-1> <down-mouse-1> <mouse-1> ; ; SPC <backspace> ; SPC s p a c e
> <down> <down> <return> <return> <down-mouse-1> <mouse-1> <backspace>
> <down-mouse-1> <mouse-1> <backspace> <down-mouse-1> <mouse-1> <backspace>
> <backspace> <down-mouse-1> <mouse-1> <double-down-mouse-1> <mouse-movement>
> <mouse-movement> <double-drag-mouse-1> <down-mouse-1> <mouse-1>
> <double-down-mouse-1> <double-mouse-1> 8 0 <down-mouse-1> <mouse-1>
> <double-down-mouse-1> <double-mouse-1> 1 <down-mouse-1> <mouse-1>
> <double-down-mouse-1> <double-mouse-1> <triple-down-mouse-1>
> <triple-mouse-1> <down-mouse-1> <mouse-1> <escape> SPC <select-window>
> <help-echo> C-x 5 2 <switch-frame> <drag-n-drop> <help-echo> <help-echo>
> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
> <help-echo> <help-echo> <menu-bar> <help-menu> <report-emacs-bug>
>
> Recent messages:
> Loading advice...done
> Loading paren...done
> Loading complete...done
> Loading msb...done
> Loading mouse-sel...done
> Loading delsel...done
> Loading lazy-lock...done
> Quit
> Mark set [3 times]
> Loading emacsbug...done
>
>
> _______________________________________________
> emacs-pretest-bug mailing list
> emacs-pretest-bug@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
> ----------
>
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [simon.marshall@misys.com: Detached minibuffer cropped text]
@ 2006-06-19 10:13 Marshall, Simon
2006-06-19 22:01 ` Kim F. Storm
0 siblings, 1 reply; 9+ messages in thread
From: Marshall, Simon @ 2006-06-19 10:13 UTC (permalink / raw)
Cc: 'emacs-devel@gnu.org'
[-- Attachment #1: Type: text/plain, Size: 4795 bytes --]
Hi Kim, that does sound quite right either - the minibuffer frame is
specified to have a height of 1, but you see 2 lines. Or are you including
the WM title bar?
I've also replicated it with:
In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit)
of 2006-06-19 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure '--with-x-toolkit=lucid' 'CFLAGS=-g''
I've tried to attach a screen dump of what I see with the LUCID toolkit. As
you can see, the tail of the "g" in "Auto-saving...done" cannot be seen (and
nor can the very bottom of the scrollbar).
Also notice that the minibuffer frame is slightly wider than the *scratch*
frame. There are extra pixels to the right of the fringe.
Simon.
-----Original Message-----
From: storm@cua.dk [mailto:storm@cua.dk]
Sent: 18 June 2006 22:12
To: rms@gnu.org
Cc: emacs-devel@gnu.org; Marshall, Simon
Subject: Re: [simon.marshall@misys.com: Detached minibuffer cropped text]
Richard Stallman <rms@gnu.org> writes:
> Would someone please DTRT and ack?
It doesn't happen for me. The minibuffer frame has approx. two lines with
this setup.
GNU Emacs 22.0.50.25 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2006-06-17 on kfs-l.imdomain.dk
>
> From: "Marshall, Simon" <simon.marshall@misys.com>
> Subject: Detached minibuffer cropped text
> To: "'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)'"
> <emacs-pretest-bug@gnu.org>
> Date: Fri, 16 Jun 2006 09:34:47 +0100
>
> Start emacs like this:
>
> xrdb -load
> ^D
> emacs -Q --eval '(setq minibuffer-frame-alist (quote ((width . 80) (height
.
> 1))) initial-frame-alist (quote ((minibuffer))))'
>
> The detached minibuffer has insufficient space to display text. There
> isn't room to display the lower few pixels of minibuffer text.
>
> In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, Motif Version 2.1.0) of
> 2006-06-15 on perth X server distributor `Hummingbird Ltd.', version
> 11.0.100015 configured using `configure
> '--prefix=/rvcarma/marshals/software/slash/usr/local'
> '--with-x-toolkit=motif' 'CFLAGS=-g''
>
> Important settings:
> value of $LC_ALL: nil
> value of $LC_COLLATE: en_GB.ISO8859-1
> value of $LC_CTYPE: en_GB.ISO8859-1
> value of $LC_MESSAGES: C
> value of $LC_MONETARY: en_GB.ISO8859-1
> value of $LC_NUMERIC: en_GB.ISO8859-1
> value of $LC_TIME: en_GB.ISO8859-1
> value of $LANG: en_GB.ISO8859-1
> locale-coding-system: iso-8859-1
> default-enable-multibyte-characters: t
>
> Major mode: Emacs-Lisp
>
> Minor modes in effect:
> delete-selection-mode: t
> mouse-sel-mode: t
> msb-mode: t
> partial-completion-mode: t
> show-paren-mode: t
> tooltip-mode: t
> mouse-wheel-mode: t
> menu-bar-mode: t
> file-name-shadow-mode: t
> global-font-lock-mode: t
> font-lock-mode: t
> blink-cursor-mode: t
> unify-8859-on-encoding-mode: t
> utf-translate-cjk-mode: t
> auto-compression-mode: t
> line-number-mode: t
> transient-mark-mode: t
>
> Recent input:
> <down-mouse-3> <mouse-3> <drag-mouse-1> <down-mouse-1> <mouse-1>
> <double-down-mouse-1> <down-mouse-3> <mouse-3> <mouse-1>
> <select-window> <help-echo> <select-window> <down-mouse-1> <mouse-1>
> <double-down-mouse-1> <double-mouse-1> <triple-down-mouse-1>
> <triple-mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> ; ;
> SPC <backspace> ; SPC s p a c e <down> <down> <return> <return>
> <down-mouse-1> <mouse-1> <backspace> <down-mouse-1> <mouse-1>
> <backspace> <down-mouse-1> <mouse-1> <backspace> <backspace>
> <down-mouse-1> <mouse-1> <double-down-mouse-1> <mouse-movement>
> <mouse-movement> <double-drag-mouse-1> <down-mouse-1> <mouse-1>
> <double-down-mouse-1> <double-mouse-1> 8 0 <down-mouse-1> <mouse-1>
> <double-down-mouse-1> <double-mouse-1> 1 <down-mouse-1> <mouse-1>
> <double-down-mouse-1> <double-mouse-1> <triple-down-mouse-1>
> <triple-mouse-1> <down-mouse-1> <mouse-1> <escape> SPC <select-window>
> <help-echo> C-x 5 2 <switch-frame> <drag-n-drop> <help-echo>
> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <menu-bar>
> <help-menu> <report-emacs-bug>
>
> Recent messages:
> Loading advice...done
> Loading paren...done
> Loading complete...done
> Loading msb...done
> Loading mouse-sel...done
> Loading delsel...done
> Loading lazy-lock...done
> Quit
> Mark set [3 times]
> Loading emacsbug...done
>
>
> _______________________________________________
> emacs-pretest-bug mailing list
> emacs-pretest-bug@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
> ----------
>
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
This message has been scanned for viruses by MailControl -
www.mailcontrol.com
[-- Attachment #2: New-1.gif --]
[-- Type: image/gif, Size: 45054 bytes --]
[-- Attachment #3: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [simon.marshall@misys.com: Detached minibuffer cropped text]
2006-06-19 10:13 [simon.marshall@misys.com: Detached minibuffer cropped text] Marshall, Simon
@ 2006-06-19 22:01 ` Kim F. Storm
2006-06-20 6:43 ` David Kastrup
0 siblings, 1 reply; 9+ messages in thread
From: Kim F. Storm @ 2006-06-19 22:01 UTC (permalink / raw)
Cc: 'emacs-devel@gnu.org'
"Marshall, Simon" <simon.marshall@misys.com> writes:
> Hi Kim, that does sound quite right either - the minibuffer frame is
> specified to have a height of 1, but you see 2 lines. Or are you including
> the WM title bar?
The display engine requires that window height is an whole multiple of
the default frame line height. So if 1 line is not enough, the next
choice is 2 lines.
I don't know why Emacs selects one line in your case, and 2 lines in my
case. It could be some property of the font -- I don't know.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [simon.marshall@misys.com: Detached minibuffer cropped text]
2006-06-19 22:01 ` Kim F. Storm
@ 2006-06-20 6:43 ` David Kastrup
2006-06-20 8:53 ` Kim F. Storm
0 siblings, 1 reply; 9+ messages in thread
From: David Kastrup @ 2006-06-20 6:43 UTC (permalink / raw)
Cc: Marshall, Simon, 'emacs-devel@gnu.org'
storm@cua.dk (Kim F. Storm) writes:
> "Marshall, Simon" <simon.marshall@misys.com> writes:
>
>> Hi Kim, that does sound quite right either - the minibuffer frame is
>> specified to have a height of 1, but you see 2 lines. Or are you including
>> the WM title bar?
>
> The display engine requires that window height is an whole multiple of
> the default frame line height. So if 1 line is not enough, the next
> choice is 2 lines.
>
> I don't know why Emacs selects one line in your case, and 2 lines in my
> case. It could be some property of the font -- I don't know.
Could be that the mode line font (or the minibuffer font after
font-lock) in one case is larger than one line of the default font,
and in one case isn't.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [simon.marshall@misys.com: Detached minibuffer cropped text]
@ 2006-06-20 8:50 Marshall, Simon
0 siblings, 0 replies; 9+ messages in thread
From: Marshall, Simon @ 2006-06-20 8:50 UTC (permalink / raw)
Cc: 'emacs-devel@gnu.org'
[-- Attachment #1: Type: text/plain, Size: 2877 bytes --]
> storm@cua.dk (Kim F. Storm) writes:
>
> > "Marshall, Simon" <simon.marshall@misys.com> writes:
> >
> >> Hi Kim, that does sound quite right either - the
> minibuffer frame is
> >> specified to have a height of 1, but you see 2 lines. Or are you
> >> including the WM title bar?
> >
> > The display engine requires that window height is an whole
> multiple of
> > the default frame line height. So if 1 line is not enough,
> the next
> > choice is 2 lines.
> >
> > I don't know why Emacs selects one line in your case, and 2
> lines in
> > my case. It could be some property of the font -- I don't know.
>
> Could be that the mode line font (or the minibuffer font after
> font-lock) in one case is larger than one line of the default
> font, and in one case isn't.
I don't think it can be the mode line font as the minibuffer frame does not
have one. But I tried with different minibuffer fonts, and it looks as
though you both are on to something. I've attached a screenshot with:
[1] + 9267 Running src/emacs -Q --font=5x8 --eval ...
[2] - 9272 Running src/emacs -Q --font=6x13 --eval ...
[3] 9275 Running src/emacs -Q --font=9x15 --eval ...
[4] 9282 Running src/emacs -Q --font=10x20 --eval ...
You can see that with the 10x20 font, the hanging parts of the letters are
displayed. The other fonts are not displayed with sufficient space for the
letters. I'm not sure it is quite correct even with the 10x20 font though -
there is (exactly) enough space for the letters but not enough for the
bottom of the scrollbar nor cursor box.
Note also that all fonts result in extra pixel space to the right of the
fringe. Where does this come from???
I began to wonder if this is due to my X server, if that is the correct
terminology, which is Hummingbird's Exceed (I have the latest version). I
use Exceed on my PC to provide the Solaris CDE environment on my PC. Exceed
is using the Solaris' font server. I am using a CVS Emacs built on Solaris.
I tried displaying the same Emacs on a GNU/Linux machine (some flavour of
RedHat) which is presumably running some Xfree86 server or something. On
that display, I do not see a problem with either character space or fringe
space. So presumably it is related to the information that Emacs is getting
from the Solaris font server via Exceed? I do not know how to determine
where the problem lies: it may be that Emacs is not dealing with the
information properly. I do not see any problems with any other applications
I use.
There is an additional problem that may help here. If I start Emacs with:
src/emacs -Q --geometry=80x20 --font=9x15
Then under Exceed I get an Emacs frame containing a *scratch* buffer whose
window is 78x17 in size as reported by window-width and window-height. On
the GNU/Linux box, the window is 80x19.
How can I help find what the problem is?
Simon.
[-- Attachment #2: New-2.gif --]
[-- Type: image/gif, Size: 110869 bytes --]
[-- Attachment #3: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [simon.marshall@misys.com: Detached minibuffer cropped text]
2006-06-20 6:43 ` David Kastrup
@ 2006-06-20 8:53 ` Kim F. Storm
0 siblings, 0 replies; 9+ messages in thread
From: Kim F. Storm @ 2006-06-20 8:53 UTC (permalink / raw)
Cc: Marshall, Simon, 'emacs-devel@gnu.org'
David Kastrup <dak@gnu.org> writes:
> storm@cua.dk (Kim F. Storm) writes:
>
>> "Marshall, Simon" <simon.marshall@misys.com> writes:
>>
>>> Hi Kim, that does sound quite right either - the minibuffer frame is
>>> specified to have a height of 1, but you see 2 lines. Or are you including
>>> the WM title bar?
>>
>> The display engine requires that window height is an whole multiple of
>> the default frame line height. So if 1 line is not enough, the next
>> choice is 2 lines.
>>
>> I don't know why Emacs selects one line in your case, and 2 lines in my
>> case. It could be some property of the font -- I don't know.
>
> Could be that the mode line font (or the minibuffer font after
> font-lock) in one case is larger than one line of the default font,
> and in one case isn't.
It must be a dicision made during frame creation, i.e. before any text
is displayed in the minibuffer window (which is the only window in the
detached minibuffer frame.
So in my case, the frame is created with two lines, in Simon's case it
is created with one line. Depending on the point of view, both
behaviours may be correct, but the question is what controls this.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [simon.marshall@misys.com: Detached minibuffer cropped text]
@ 2006-06-22 11:19 Marshall, Simon
0 siblings, 0 replies; 9+ messages in thread
From: Marshall, Simon @ 2006-06-22 11:19 UTC (permalink / raw)
Cc: 'emacs-devel@gnu.org'
Here's yet another quirk that may help track down the problem. From the
original bug report, if I do:
xrdb -load
^D
src/emacs -Q --font=9x15 --eval '(setq minibuffer-frame-alist (quote ((width
. 80) (height . 1))) initial-frame-alist (quote ((minibuffer))))'
Then the detached minibuffer has insufficient space for the trailing parts
of 9x15 characters such as "y". Also, there are a few pixels to the right
of the right fringe.
If I put WM focus in the detached minibuffer and do:
M-x set-frame-font RET 9x15bold RET
Then Emacs resizes the minibuffer frame to have sufficient height for 9x15
characters and removes the extra pixels to the right of the right fringe.
The same thing happens if the default font is 9x15bold and then I change it
to 9x15.
This suggests to me that it is somehow a problem within Emacs - it does not
get it right on startup but it does get it right if the font is changed
while running.
How can I help you track the cause of this? Simon.
> -----Original Message-----
> From: Marshall, Simon
> Sent: 20 June 2006 09:51
> To: 'David Kastrup'; 'storm@cua.dk'
> Cc: 'emacs-devel@gnu.org'
> Subject: RE: [simon.marshall@misys.com: Detached minibuffer
> cropped text]
>
> > storm@cua.dk (Kim F. Storm) writes:
> >
> > > "Marshall, Simon" <simon.marshall@misys.com> writes:
> > >
> > >> Hi Kim, that does sound quite right either - the
> > minibuffer frame is
> > >> specified to have a height of 1, but you see 2 lines.
> Or are you
> > >> including the WM title bar?
> > >
> > > The display engine requires that window height is an whole
> > multiple of
> > > the default frame line height. So if 1 line is not enough,
> > the next
> > > choice is 2 lines.
> > >
> > > I don't know why Emacs selects one line in your case, and 2
> > lines in
> > > my case. It could be some property of the font -- I don't know.
> >
> > Could be that the mode line font (or the minibuffer font after
> > font-lock) in one case is larger than one line of the default font,
> > and in one case isn't.
>
> I don't think it can be the mode line font as the minibuffer
> frame does not have one. But I tried with different
> minibuffer fonts, and it looks as though you both are on to
> something. I've attached a screenshot with:
>
> [1] + 9267 Running src/emacs -Q --font=5x8 --eval ...
> [2] - 9272 Running src/emacs -Q --font=6x13 --eval ...
> [3] 9275 Running src/emacs -Q --font=9x15 --eval ...
> [4] 9282 Running src/emacs -Q --font=10x20 --eval ...
>
> You can see that with the 10x20 font, the hanging parts of
> the letters are displayed. The other fonts are not displayed
> with sufficient space for the letters. I'm not sure it is
> quite correct even with the 10x20 font though - there is
> (exactly) enough space for the letters but not enough for the
> bottom of the scrollbar nor cursor box.
>
> Note also that all fonts result in extra pixel space to the
> right of the fringe. Where does this come from???
>
> I began to wonder if this is due to my X server, if that is
> the correct terminology, which is Hummingbird's Exceed (I
> have the latest version). I use Exceed on my PC to provide
> the Solaris CDE environment on my PC. Exceed is using the
> Solaris' font server. I am using a CVS Emacs built on
> Solaris. I tried displaying the same Emacs on a GNU/Linux
> machine (some flavour of RedHat) which is presumably running
> some Xfree86 server or something. On that display, I do not
> see a problem with either character space or fringe space.
> So presumably it is related to the information that Emacs is
> getting from the Solaris font server via Exceed? I do not
> know how to determine where the problem lies: it may be that
> Emacs is not dealing with the information properly. I do not
> see any problems with any other applications I use.
>
> There is an additional problem that may help here. If I
> start Emacs with:
>
> src/emacs -Q --geometry=80x20 --font=9x15
>
> Then under Exceed I get an Emacs frame containing a *scratch*
> buffer whose window is 78x17 in size as reported by
> window-width and window-height. On the GNU/Linux box, the
> window is 80x19.
>
> How can I help find what the problem is?
>
> Simon.
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [simon.marshall@misys.com: Detached minibuffer cropped text]
@ 2006-08-10 12:18 Marshall, Simon
0 siblings, 0 replies; 9+ messages in thread
From: Marshall, Simon @ 2006-08-10 12:18 UTC (permalink / raw)
Cc: 'emacs-devel@gnu.org'
> Here's yet another quirk that may help track down the
> problem. From the original bug report, if I do:
>
> xrdb -load
> ^D
> src/emacs -Q --font=9x15 --eval '(setq minibuffer-frame-alist
> (quote ((width . 80) (height . 1))) initial-frame-alist
> (quote ((minibuffer))))'
>
> Then the detached minibuffer has insufficient space for the
> trailing parts of 9x15 characters such as "y". Also, there
> are a few pixels to the right of the right fringe.
>
> If I put WM focus in the detached minibuffer and do:
>
> M-x set-frame-font RET 9x15bold RET
>
> Then Emacs resizes the minibuffer frame to have sufficient
> height for 9x15 characters and removes the extra pixels to
> the right of the right fringe. The same thing happens if the
> default font is 9x15bold and then I change it to 9x15.
>
> This suggests to me that it is somehow a problem within Emacs
> - it does not get it right on startup but it does get it
> right if the font is changed while running.
>
> How can I help you track the cause of this? Simon.
Ok, everyone's had enough of a chance to respond! ;-)
Now I've got a gcc build, I tried to debug this myself, concentrating on the
frame height issue. I started emacs with these breakpoints:
Breakpoint 5, Fx_create_frame (parms=5003429) at xfns.c:3161
Breakpoint 3, x_set_font (f=0x5bb200, arg=5495731, oldval=4687873) at
frame.c:3067
And then continued until the 3rd time we stop in Fx_create_frame(), when
we're creating the minibuffer frame:
Breakpoint 5, Fx_create_frame (parms=10327149) at xfns.c:3161
(gdb) where
#0 Fx_create_frame (parms=10327149) at xfns.c:3161
#1 0x0024aa9c in Ffuncall (nargs=2, args=0xffbecc00) at eval.c:2982
#2 0x002a2cb0 in Fbyte_code (bytestr=3433907, vector=3433924, maxdepth=40)
at bytecode.c:679
#3 0x0024b5b0 in funcall_lambda (fun=3433860, nargs=1,
arg_vector=0xffbececc) at eval.c:3169
#4 0x0024ad28 in Ffuncall (nargs=2, args=0xffbecec8) at eval.c:3028
#5 0x002a2cb0 in Fbyte_code (bytestr=3675779, vector=3675796, maxdepth=24)
at bytecode.c:679
#6 0x0024b5b0 in funcall_lambda (fun=3675732, nargs=1,
arg_vector=0xffbed194) at eval.c:3169
#7 0x0024ad28 in Ffuncall (nargs=2, args=0xffbed190) at eval.c:3028
#8 0x002a2cb0 in Fbyte_code (bytestr=3674875, vector=3674892, maxdepth=24)
at bytecode.c:679
#9 0x0024b5b0 in funcall_lambda (fun=3674844, nargs=1,
arg_vector=0xffbed45c) at eval.c:3169
#10 0x0024ad28 in Ffuncall (nargs=2, args=0xffbed458) at eval.c:3028
#11 0x002a2cb0 in Fbyte_code (bytestr=3674411, vector=3674428, maxdepth=64)
at bytecode.c:679
#12 0x0024b5b0 in funcall_lambda (fun=3674380, nargs=0,
arg_vector=0xffbed734) at eval.c:3169
#13 0x0024ad28 in Ffuncall (nargs=1, args=0xffbed730) at eval.c:3028
#14 0x002a2cb0 in Fbyte_code (bytestr=3785067, vector=3785092, maxdepth=56)
at bytecode.c:679
#15 0x0024929c in Feval (form=3785053) at eval.c:2319
#16 0x00244428 in Fprogn (args=3785045) at eval.c:435
#17 0x0024bf68 in unbind_to (count=2, value=4687873) at eval.c:3337
#18 0x002a2d9c in Fbyte_code (bytestr=3784739, vector=3784756, maxdepth=48)
at bytecode.c:701
#19 0x0024b5b0 in funcall_lambda (fun=3784716, nargs=0,
arg_vector=0xffbedd28) at eval.c:3169
#20 0x0024b094 in apply_lambda (fun=3784716, args=4687873, eval_flag=1) at
eval.c:3093
#21 0x00249438 in Feval (form=6856773) at eval.c:2355
#22 0x00178e20 in top_level_2 () at keyboard.c:1335
#23 0x00246eac in internal_condition_case (bfun=0x178e08 <top_level_2>,
handlers=4752009, hfun=0x17872c <cmd_error>) at eval.c:1469
#24 0x00178e80 in top_level_1 () at keyboard.c:1343
#25 0x0024663c in internal_catch (tag=4746241, func=0x178e34 <top_level_1>,
arg=4687873) at eval.c:1210
#26 0x00178d18 in command_loop () at keyboard.c:1300
#27 0x00178278 in recursive_edit_1 () at keyboard.c:1003
#28 0x001784d8 in Frecursive_edit () at keyboard.c:1064
#29 0x0017609c in main (argc=3, argv=0xffbee44c) at emacs.c:1794
Lisp Backtrace:
"x-create-frame" (0x9d953d)
"x-create-frame-with-faces" (0x9d962d)
"make-frame" (0x9d962d)
"make-initial-minibuffer-frame" (0x478801)
"frame-notice-user-settings" (0x72d6a1)
"byte-code" (0x39c16b)
"normal-top-level" (0x0)
(gdb) list
3156 /* Extract the window parameters from the supplied values
3157 that are needed to determine window geometry. */
3158 {
3159 Lisp_Object font;
3160
3161 -> font = x_get_arg (dpyinfo, parms, Qfont, "font", "Font",
RES_TYPE_STRING);
3162
3163 BLOCK_INPUT;
3164 /* First, try whatever font the caller has specified. */
3165 if (STRINGP (font))
(gdb)
stepping over the call of x_get_arg(), font gets set to:
(gdb) p font
$27 = 8136051
(gdb) pr
"9x15bold"
(gdb)
so far, so good. stepping further, we get to:
3166 {
3167 tem = Fquery_fontset (font, Qnil);
3168 if (STRINGP (tem))
3169 font = x_new_fontset (f, SDATA (tem));
3170 else
3171 -> font = x_new_font (f, SDATA (font));
3172 }
3173
3174 /* Try out a font which we hope has bold and italic variations.
*/
3175 if (!STRINGP (font))
if i step in, i get to:
x_new_font (f=0xb89200, fontname=0x88f828 "9x15bold") at xterm.c:7857
(gdb) list
7852 x_new_font (f, fontname)
7853 struct frame *f;
7854 register char *fontname;
7855 {
7856 struct font_info *fontp
7857 -> = FS_LOAD_FONT (f, 0, fontname, -1);
7858
7859 if (!fontp)
7860 return Qnil;
7861
(gdb)
stepping in further, we get to:
#0 x_load_font (f=0xb89200, fontname=0x88f828 "9x15bold", size=0) at
xterm.c:9814
#1 0x0015f4f4 in fs_load_font (f=0xb89200, c=0, fontname=0x88f828
"9x15bold", id=-1, face=0x0) at fontset.c:700
#2 0x0013cd40 in x_new_font (f=0xb89200, fontname=0x9d930d "G\210\001") at
xterm.c:7857
#3 0x0014c3c8 in Fx_create_frame (parms=10327149) at xfns.c:3171
...
and then stepping in again:
#0 x_list_fonts (f=0xb86200, pattern=10804675, size=0, maxnames=1) at
xterm.c:9427
#1 0x0014113c in x_load_font (f=0xb86200, fontname=0x88f828 "9x15bold",
size=0) at xterm.c:9814
#2 0x0015f4f4 in fs_load_font (f=0xb86200, c=0, fontname=0x88f828
"9x15bold", id=-1, face=0x0) at fontset.c:700
#3 0x0013cd40 in x_new_font (f=0xb86200, fontname=0xa4ddc3
"\b\377\377\377\377") at xterm.c:7857
#4 0x0014c3c8 in Fx_create_frame (parms=10327141) at xfns.c:3171
...
(gdb) p pattern
$33 = 10804675
(gdb) pr
"9x15bold"
(gdb)
where we are trying to get a list of fonts matching pattern. we eventually
start the loop:
pattern = XCAR (patterns);
/* See if we cached the result for this particular query.
The cache is an alist of the form:
((((PATTERN . MAXNAMES) . SCALABLE) (FONTNAME . WIDTH) ...) ...)
*/
tem = XCDR (dpyinfo->name_list_element);
-> key = Fcons (Fcons (pattern, make_number (maxnames)),
allow_auto_scaled_font ? Qt : Qnil);
list = Fassoc (key, tem);
if (!NILP (list))
{
list = Fcdr_safe (list);
/* We have a cashed list. Don't have to get the list again. */
goto label_cached;
}
(gdb) p pattern
$39 = 10804675
(gdb) pr
"9x15bold"
(gdb) p tem
$36 = 8022645
(gdb) pr
(((("-misc-fixed-medium-r-normal--13-100-100-100-c-80-iso8859-1" . 1))
("-Misc-Fixed-Medium-R-Normal--13-120-75-75-C-80-ISO8859-1"))
((("-misc-fixed-bold-r-normal--13-100-100-100-c-80-iso8859-1" . 1))
("-Misc-Fixed-Bold-R-Normal--13-120-75-75-C-80-ISO8859-1"))
((("-misc-fixed-*-ISO8859-1" . 100) . t)
("-misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1")
("-misc-fixed-medium-r-normal--0-0-75-75-c-0-iso8859-1")
("-misc-fixed-medium-o-semicondensed--0-0-75-75-c-0-iso8859-1")
("-misc-fixed-medium-o-normal--0-0-75-75-c-0-iso8859-1")
("-misc-fixed-bold-r-semicondensed--0-0-75-75-c-0-iso8859-1")
("-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-1")
("-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1")
("-misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1")
("-misc-fixed-medium-r-semicondensed--12-90-100-100-c-60-iso8859-1")
("-misc-fixed-medium-r-semicondensed--12-110-75-75-c-60-iso8859-1")
("-misc-fixed-medium-r-normal--9-90-75-75-c-60-iso8859-1")
("-misc-fixed-medium-r-normal--9-80-100-100-c-60-iso8859-1")
("-misc-fixed-medium-r-normal--8-80-75-75-c-50-iso8859-1")
("-misc-fixed-medium-r-normal--8-60-100-100-c-50-iso8859-1")
("-misc-fixed-medium-r-normal--7-70-75-75-c-50-iso8859-1")
("-misc-fixed-medium-r-normal--7-50-100-100-c-50-iso8859-1")
("-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1")
("-misc-fixed-medium-r-normal--20-140-100-100-c-100-iso8859-1")
("-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso8859-1")
("-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso8859-1")
("-misc-fixed-medium-r-normal--15-120-100-100-c-90-iso8859-1")
("-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1")
("-misc-fixed-medium-r-normal--14-110-100-100-c-70-iso8859-1")
("-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1")
("-misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1")
("-misc-fixed-medium-r-normal--13-100-100-100-c-80-iso8859-1")
("-misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1")
("-misc-fixed-medium-r-normal--10-70-100-100-c-60-iso8859-1")
("-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1")
("-misc-fixed-medium-o-semicondensed--13-120-75-75-c-60-iso8859-1")
("-misc-fixed-medium-o-normal--13-120-75-75-c-80-iso8859-1")
("-misc-fixed-medium-o-normal--13-120-75-75-c-70-iso8859-1")
("-misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso8859-1")
("-misc-fixed-bold-r-semicondensed--13-100-100-100-c-60-iso8859-1")
("-misc-fixed-bold-r-normal--18-120-100-100-c-90-iso8859-1")
("-misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1")
("-misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1")
("-misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-1")
("-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-1")
("-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-1")
("-misc-fixed-bold-r-normal--13-100-100-100-c-80-iso8859-1")
("-misc-fixed-bold-r-normal--13-100-100-100-c-70-iso8859-1"))
((("-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-1" . 1))
("-Misc-Fixed-Bold-R-Normal--13-120-75-75-C-80-ISO8859-1")) ((("8x13bold" .
1)) ("-Misc-Fixed-Bold-R-Normal--13-120-75-75-C-80-ISO8859-1"))
((("-*-fixed-medium-r-normal-*-16-*-*-*-*-*-iso8859-1" . 1))
("-Sony-Fixed-Medium-R-Normal--16-120-100-100-C-80-ISO8859-1")))
notice that tem has 8x13bold, but not 9x15bold.
(gdb) p key
$40 = 10326829
(gdb) pr
(("9x15bold" . 1))
(gdb)
obviously we don't find key in tem, so we go down further into A here
because maxnames=1 (and size=0) so we set try_XLoadQueryFont=1:
if (try_XLoadQueryFont)
{
A--> XFontStruct *font;
unsigned long value;
font = XLoadQueryFont (dpy, SDATA (pattern));
if (x_had_errors_p (dpy))
{
/* This error is perhaps due to insufficient memory on X
server. Let's just ignore it. */
font = NULL;
x_clear_errors (dpy);
}
if (font
&& XGetFontProperty (font, XA_FONT, &value))
{
B--> char *name = (char *) XGetAtomName (dpy, (Atom) value);
int len = strlen (name);
char *tmp;
/* If DXPC (a Differential X Protocol Compressor)
Ver.3.7 is running, XGetAtomName will return null
string. We must avoid such a name. */
if (len == 0)
try_XLoadQueryFont = 0;
else
{
num_fonts = 1;
names = (char **) alloca (sizeof (char *));
/* Some systems only allow alloca assigned to a
simple var. */
tmp = (char *) alloca (len + 1); names[0] = tmp;
bcopy (name, names[0], len + 1);
XFree (name);
}
}
else
try_XLoadQueryFont = 0;
if (font)
XFreeFont (dpy, font);
}
if i continue after the call of XLoadQueryFont(), I get:
(gdb) p pattern
$43 = 10804675
(gdb) pr
"9x15bold"
(gdb) p *font
$44 = {
ext_data = 0x0,
fid = 79693146,
direction = 0,
min_char_or_byte2 = 0,
max_char_or_byte2 = 255,
min_byte1 = 0,
max_byte1 = 0,
all_chars_exist = 0,
default_char = 0,
n_properties = 21,
properties = 0xb04500,
min_bounds = {
lbearing = 0,
rbearing = 0,
width = 9,
ascent = 0,
descent = -9,
attributes = 0
},
max_bounds = {
lbearing = 5,
rbearing = 9,
width = 9,
ascent = 12,
descent = 3,
attributes = 0
},
per_char = 0xb9a000,
ascent = 12,
descent = 3
}
(gdb)
there are no errors, so we get to B:
(gdb) p value
$49 = 435
(gdb) p name
$50 = 0x814180 "-Misc-Fixed-Bold-R-Normal--15-140-75-75-C-90-ISO8859-1"
(gdb)
before we leave x_list_fonts() we store what we've found in the cache:
/* Now store the result in the cache. */
XSETCDR (dpyinfo->name_list_element,
Fcons (Fcons (key, list), XCDR
(dpyinfo->name_list_element)));
Breakpoint 7, x_list_fonts (f=0xb86200, pattern=10804675, size=0,
maxnames=1) at xterm.c:9616
(gdb) p key
$53 = 10326829
(gdb) pr
(("9x15bold" . 1))
(gdb) p list
$54 = 10326813
(gdb) pr
(("-Misc-Fixed-Bold-R-Normal--15-140-75-75-C-90-ISO8859-1"))
(gdb)
and we return it:
Run till exit from #0 x_list_fonts (f=0xb86200, pattern=10804675, size=0,
maxnames=1) at xterm.c:9704
0x0014113c in x_load_font (f=0xb86200, fontname=0x88f828 "9x15bold", size=0)
at xterm.c:9814
Value returned is $59 = 10326789
(gdb) pr
("-Misc-Fixed-Bold-R-Normal--15-140-75-75-C-90-ISO8859-1")
(gdb)
in the callers, we fail to find the font in the list we have and get to:
/* If we have found fonts by x_list_font, load one of them. If
not, we still try to load a font by the name given as FONTNAME
because XListFonts (called in x_list_font) of some X server has
a bug of not finding a font even if the font surely exists and
is loadable by XLoadQueryFont. */
if (size > 0 && !NILP (font_names))
fontname = (char *) SDATA (XCAR (font_names));
BLOCK_INPUT;
x_catch_errors (FRAME_X_DISPLAY (f));
font = (XFontStruct *) XLoadQueryFont (FRAME_X_DISPLAY (f), fontname);
--> if (x_had_errors_p (FRAME_X_DISPLAY (f)))
(gdb) p size
$63 = 0
(gdb) p fontname
$64 = 0x88f828 "9x15bold"
(gdb) p *font
$65 = {
ext_data = 0x0,
fid = 79693147,
direction = 0,
min_char_or_byte2 = 0,
max_char_or_byte2 = 255,
min_byte1 = 0,
max_byte1 = 0,
all_chars_exist = 0,
default_char = 0,
n_properties = 21,
properties = 0xb04600,
min_bounds = {
lbearing = 0,
rbearing = 0,
width = 9,
ascent = 0,
descent = -9,
attributes = 0
},
max_bounds = {
lbearing = 5,
rbearing = 9,
width = 9,
ascent = 12,
descent = 3,
attributes = 0
},
per_char = 0xb9c000,
ascent = 12,
descent = 3
}
(gdb)
exiting from x_load_font() we have:
Run till exit from #0 x_load_font (f=0xb86200, fontname=0x88f828
"9x15bold", size=0) at xterm.c:10039
0x0015f4f4 in fs_load_font (f=0xb86200, c=0, fontname=0x88f828 "9x15bold",
id=-1, face=0x0) at fontset.c:700
Value returned is $68 = (struct font_info *) 0x783270
(gdb) p *fontp
$71 = {
font = 0xb9b280,
font_idx = 2,
name = 0xb7e3e0 "9x15bold",
full_name = 0x965700
"-Misc-Fixed-Bold-R-Normal--15-140-75-75-C-90-ISO8859-1",
charset = 0,
size = 9,
height = 15,
space_width = 9,
average_width = 9,
vertical_centering = 0,
encoding = "\0\377", '\0' <repeats 252 times>,
baseline_offset = 0,
relative_compose = 0,
default_ascent = 0,
font_encoder = 0x0
}
(gdb)
before we exit x_new_font(), I print the frame:
Breakpoint 15, x_new_font (f=0xb86200, fontname=0x0) at xterm.c:7902
(gdb) print *f
$75 = {
size = 1073742934,
next = 0xb91e00,
name = 8136131,
icon_name = 4687873,
title = 4687873,
focus_frame = 4687873,
root_window = 12084228,
selected_window = 12084228,
minibuffer_window = 12084228,
param_alist = 4687873,
scroll_bars = 4687873,
condemned_scroll_bars = 4687873,
menu_bar_items = 4687873,
face_alist = 4687873,
menu_bar_vector = 4687873,
menu_bar_items_used = 0,
buffer_predicate = 4687873,
buffer_list = 10326877,
menu_bar_window = 4687873,
tool_bar_window = 4687873,
tool_bar_items = 4687873,
desired_tool_bar_string = 4687873,
current_tool_bar_string = 4687873,
face_cache = 0x0,
namebuf = 0x0,
current_pool = 0x0,
desired_pool = 0x0,
desired_matrix = 0x0,
current_matrix = 0x0,
glyphs_initialized_p = 0,
tool_bar_lines = 0,
n_tool_bar_rows = 0,
n_tool_bar_items = 0,
decode_mode_spec_buffer = 0x0,
insert_line_cost = 0x0,
delete_line_cost = 0x0,
insert_n_lines_cost = 0x0,
delete_n_lines_cost = 0x0,
text_lines = 10,
text_cols = 10,
total_lines = 0,
total_cols = 10,
new_text_lines = 0,
new_text_cols = 0,
left_pos = 0,
top_pos = 0,
pixel_height = 0,
pixel_width = 0,
x_pixels_diff = 0,
y_pixels_diff = 0,
win_gravity = 0,
size_hint_flags = 0,
border_width = 0,
internal_border_width = 0,
column_width = 9,
space_width = 9,
line_height = 15,
output_method = output_x_window,
output_data = {
x = 0xb94000,
w32 = 0xb94000,
mac = 0xb94000,
nothing = 12140544
},
fringe_cols = 2,
left_fringe_width = 9,
right_fringe_width = 9,
kboard = 0x741680,
want_fullscreen = 0,
menu_bar_lines = 0,
external_menu_bar = 0,
display_preempted = 0 '\0',
visible = 0 '\0',
iconified = 0 '\0',
async_visible = 0 '\0',
async_iconified = 0 '\0',
garbaged = 1 '\001',
has_minibuffer = 1 '\001',
wants_modeline = 0 '\0',
can_have_scroll_bars = 1 '\001',
vertical_scroll_bar_type = vertical_scroll_bar_none,
desired_cursor = FILLED_BOX_CURSOR,
cursor_width = 0,
blink_off_cursor = FILLED_BOX_CURSOR,
blink_off_cursor_width = 0,
auto_raise = 0 '\0',
auto_lower = 0 '\0',
no_split = 1 '\001',
explicit_name = 1 '\001',
window_sizes_changed = 0 '\0',
message_buf = 0x0,
scroll_bottom_vpos = 0,
config_scroll_bar_width = 0,
config_scroll_bar_cols = 2,
scroll_bar_actual_width = 0,
cost_calculation_baud_rate = 0,
mouse_moved = 0 '\0',
gamma = 0,
extra_line_spacing = 0,
resized_p = 0,
force_flush_display_p = 0,
default_face_done_p = 0,
already_hscrolled_p = 0,
updated_p = 0
}
(gdb)
if we exit x_new_font() and contiune in Fx_create_frame(), we get:
x_set_frame_parameters (f, Fcons (Fcons (Qfont, font), Qnil));
where:
(gdb) p font
$81 = 10804611
(gdb) pr
"-Misc-Fixed-Bold-R-Normal--15-140-75-75-C-90-ISO8859-1"
(gdb)
i then let it continue to create the minibuffer frame. the minibuffer frame
is the wrong size. in *scratch*, if I eval (frame-parameters (car
(minibuffer-frame-list))) i get:
((parent-id . 46143352) (display . "dtp020071.misys-risk.com:0.0")
(visibility . t) (icon-name) (outer-window-id . "79693155") (window-id .
"79693157") (top . 0) (left . 250) (buffer-list #<buffer *Minibuf-0*>
#<buffer *Minibuf-1*> #<buffer *scratch*>) (unsplittable . t) (minibuffer .
only) (modeline) (width . 99) (height . 1) (name . "Minibuffer")
(background-mode . dark) (display-type . color) (reverse . t)
(scroll-bar-width . 0) (cursor-type . bar) (auto-lower) (auto-raise . t)
(icon-type . t) (wait-for-wm . t) (title) (buffer-predicate) (tool-bar-lines
. 0) (menu-bar-lines . 1) (scroll-bar-background . "grey75")
(scroll-bar-foreground) (right-fringe . 9) (left-fringe . 9) (line-spacing)
(screen-gamma) (border-color . "#fffff0") (cursor-color . "red")
(mouse-color . "red") (background-color . "black") (foreground-color .
"#fffff0") (vertical-scroll-bars) (internal-border-width . 1) (border-width
. 2) (font . "-Misc-Fixed-Bold-R-Normal--15-140-75-75-C-90-ISO8859-1"))
my session died and i had to start again. i got to this point again, where
emacs is running and has created the *scratch* and minibuffer frames.
so i move the mouse to the minibuffer frame and do M-x set-frame-font RET
(with the intention of changing it to 9x15bold) and i hit here:
Breakpoint 5, x_list_fonts (f=0xb88200, pattern=3678459, size=0,
maxnames=-1) at xterm.c:9427
(gdb) where
#0 x_list_fonts (f=0xb88200, pattern=3678459, size=0, maxnames=-1) at
xterm.c:9427
#1 0x0011d780 in Fx_list_fonts (pattern=3678459, face=4687873,
frame=12091908, maximum=4687873, width=4687873) at xfaces.c:3043
#2 0x00249308 in Feval (form=3678445) at eval.c:2327
#3 0x00249190 in Feval (form=3678405) at eval.c:2298
#4 0x00249190 in Feval (form=3678365) at eval.c:2298
#5 0x00245c10 in FletX (args=3678309) at eval.c:990
#6 0x00248fe0 in Feval (form=3678301) at eval.c:2260
#7 0x0024104c in Fcall_interactively (function=7537481,
record_flag=4687921, keys=4747268) at callint.c:380
#8 0x00190a74 in Fcommand_execute (cmd=7537481, record_flag=4687921,
keys=4687873, special=4687873) at keyboard.c:9797
#9 0x00190fa8 in Fexecute_extended_command (prefixarg=4687873) at
keyboard.c:9913
#10 0x0024aa9c in Ffuncall (nargs=2, args=0xffbedb10) at eval.c:2982
#11 0x00243520 in Fcall_interactively (function=4746361,
record_flag=4687873, keys=4747268) at callint.c:880
#12 0x00190a74 in Fcommand_execute (cmd=4746361, record_flag=4687873,
keys=4687873, special=4687873) at keyboard.c:9797
#13 0x0017b288 in command_loop_1 () at keyboard.c:1790
#14 0x00246eac in internal_condition_case (bfun=0x179104 <command_loop_1>,
handlers=4752009, hfun=0x17872c <cmd_error>) at eval.c:1469
#15 0x00178dd0 in command_loop_2 () at keyboard.c:1326
#16 0x0024663c in internal_catch (tag=4746241, func=0x178da4
<command_loop_2>, arg=4687873) at eval.c:1210
#17 0x00178d48 in command_loop () at keyboard.c:1305
#18 0x00178278 in recursive_edit_1 () at keyboard.c:1003
#19 0x001784d8 in Frecursive_edit () at keyboard.c:1064
#20 0x0017609c in main (argc=3, argv=0xffbee43c) at emacs.c:1794
Lisp Backtrace:
"x-list-fonts" (0x3820fb)
"mapcar" (0x3820cd)
"completing-read" (0x3820a5)
"let*" (0x382065)
"call-interactively" (0x730349)
"execute-extended-command" (0x478801)
"call-interactively" (0x486c79)
(gdb) p pattern
$8 = 3678459
(gdb) pr
"*"
(gdb)
when we search through the cached list, naturally we fail to find it. so we
then end up calling XListFonts() because maxnames=-1 (and size=0) so we set
try_XLoadQueryFont=0, and since this time the pattern is "*" we get a huge
list of fonts back, including 9x15bold.
i'm not sure what to make of this. the first time (when we're creating the
minibuffer frame), x_list_fonts() asks XLoadQueryFont() for "9x15bold" but
gets back "-Misc-Fixed-Bold-R-Normal--15-140-75-75-C-90-ISO8859-1". the
second time (when calling set-frame-font), x_list_fonts() asks XListFonts()
for "*" and gets back a huge list including 9x15bold.
So is it the fault with XLoadQueryFont()?
Or should emacs use XListFonts() in either case?
And surely, if Emacs gets to understand that 9x15bold is equivalent to
-Misc-Fixed-Bold-R-Normal--15-140-75-75-C-90-ISO8859-1, shouldn't Emacs
always assume that? (In other words, if Emacs fails to get the right font
when creating the minibuffer frame, should it not also fail when doing
set-frame-font?)
Simon.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-08-10 12:18 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-19 10:13 [simon.marshall@misys.com: Detached minibuffer cropped text] Marshall, Simon
2006-06-19 22:01 ` Kim F. Storm
2006-06-20 6:43 ` David Kastrup
2006-06-20 8:53 ` Kim F. Storm
-- strict thread matches above, loose matches on Subject: below --
2006-08-10 12:18 Marshall, Simon
2006-06-22 11:19 Marshall, Simon
2006-06-20 8:50 Marshall, Simon
2006-06-17 17:58 Richard Stallman
2006-06-18 21:12 ` Kim F. Storm
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.