GNU bug report logs -
#16051
24.3.50; Emacs hang - resize frame manually
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Wed, 4 Dec 2013 14:41:01 UTC
Severity: normal
Found in version 24.3.50
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16051 in the body.
You can then email your comments to 16051 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Wed, 04 Dec 2013 14:41:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 04 Dec 2013 14:41:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
emacs -Q
Grab the right edge of the frame with your mouse and move it left.
Move it far enough and the frame turns white and Emacs hangs. You will
need to kill it using the task manager.
(If you change a frame parameter (I tried tool-bar-lines) then you need
not move the frame border as much before getting a hang.)
In GNU Emacs 24.3.50.2 (i686-pc-mingw32)
of 2013-11-28 on LEG570
Bzr revision: 115271 rgm <at> gnu.org-20131128203155-qjc1xsp19z2k64b2
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Wed, 04 Dec 2013 17:57:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 4 Dec 2013 06:40:15 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
>
> emacs -Q
>
> Grab the right edge of the frame with your mouse and move it left.
>
> Move it far enough and the frame turns white and Emacs hangs. You will
> need to kill it using the task manager.
Don't you get an abort dialog? I do, and the backtrace is below:
dispnew.c:1369: Emacs fatal error: assertion failed: row >= 0 && row < matrix->nrows
Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647)
at emacs.c:350
350 signal (sig, SIG_DFL);
(gdb) bt
#0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647)
at emacs.c:350
#1 0x01168801 in die (
msg=0x148f378 <DEFAULT_REHASH_SIZE+704> "row >= 0 && row < matrix->nrows", file=0x148f124 <DEFAULT_REHASH_SIZE+108> "dispnew.c", line=1369)
at alloc.c:6726
#2 0x01004ad5 in matrix_row (matrix=0x36ce000, row=7) at dispnew.c:1369
#3 0x010415de in hscroll_window_tree (window=59745149) at xdisp.c:12607
#4 0x01041c34 in hscroll_windows (window=59726325) at xdisp.c:12733
#5 0x0104409b in redisplay_internal () at xdisp.c:13627
#6 0x01044918 in redisplay_preserve_echo_area (from_where=8) at xdisp.c:13852
#7 0x011073fb in detect_input_pending_run_timers (do_display=true)
at keyboard.c:9882
#8 0x011d5c9e in wait_reading_process_output (time_limit=0, nsecs=0,
read_kbd=-1, do_display=true, wait_for_cell=56436762, wait_proc=0x0,
just_wait_proc=0) at process.c:4680
#9 0x010fb5eb in kbd_buffer_get_event (kbp=0x82f94c,
used_mouse_menu=0x82fc9b, end_time=0x0) at keyboard.c:3897
#10 0x010f7985 in read_event_from_main_queue (end_time=0x0,
local_getcjmp=0x82fb40, used_mouse_menu=0x82fc9b) at keyboard.c:2242
#11 0x010f7bbc in read_decoded_event_from_main_queue (end_time=0x0,
local_getcjmp=0x82fb40, prev_event=56436762, used_mouse_menu=0x82fc9b)
at keyboard.c:2306
#12 0x010f8f62 in read_char (commandflag=1, map=60377926,
prev_event=56436762, used_mouse_menu=0x82fc9b, end_time=0x0)
at keyboard.c:2891
#13 0x01105902 in read_key_sequence (keybuf=0x82fd80, bufsize=30,
prompt=56436762, dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9074
#14 0x010f5ee3 in command_loop_1 () at keyboard.c:1445
#15 0x01184d4b in internal_condition_case (bfun=0x10f5b7c <command_loop_1>,
handlers=56487250, hfun=0x10f53e5 <cmd_error>) at eval.c:1344
#16 0x010f584b in command_loop_2 (ignore=56436762) at keyboard.c:1170
#17 0x01184336 in internal_catch (tag=56477154,
func=0x10f5828 <command_loop_2>, arg=56436762) at eval.c:1108
#18 0x010f5803 in command_loop () at keyboard.c:1149
#19 0x010f4f9f in recursive_edit_1 () at keyboard.c:777
#20 0x010f514f in Frecursive_edit () at keyboard.c:841
#21 0x010f32f3 in main (argc=2, argv=0xa42878) at emacs.c:1598
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Wed, 04 Dec 2013 18:46:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Don't you get an abort dialog? I do, and the backtrace is below:
No. I got nothing at all - just a blank Emacs.
But note the build I am using. (See bug #16028.)
Perhaps you are using a more recent build. When #16028 is fixed
I will use a more recent build, so I will have access to your
added bactrace info.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 05 Dec 2013 14:04:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 16051 <at> debbugs.gnu.org (full text, mbox):
>> emacs -Q
>>
>> Grab the right edge of the frame with your mouse and move it left.
>>
>> Move it far enough and the frame turns white and Emacs hangs. You will
>> need to kill it using the task manager.
>
> Don't you get an abort dialog? I do, and the backtrace is below:
FWIW I never ever managed to get anything weird here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 05 Dec 2013 17:53:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 05 Dec 2013 15:03:01 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Drew Adams <drew.adams <at> oracle.com>, 16051 <at> debbugs.gnu.org
>
> >> emacs -Q
> >>
> >> Grab the right edge of the frame with your mouse and move it left.
> >>
> >> Move it far enough and the frame turns white and Emacs hangs. You will
> >> need to kill it using the task manager.
> >
> > Don't you get an abort dialog? I do, and the backtrace is below:
>
> FWIW I never ever managed to get anything weird here.
Did you drag the mouse far enough to the left?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 05 Dec 2013 18:00:05 GMT)
Full text and
rfc822 format available.
Message #20 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Did you drag the mouse far enough to the left?
How could I? It stops as expected when a minimum width
is encountered.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 05 Dec 2013 18:22:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 05 Dec 2013 18:59:33 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: drew.adams <at> oracle.com, 16051 <at> debbugs.gnu.org
>
> > Did you drag the mouse far enough to the left?
>
> How could I? It stops as expected when a minimum width
> is encountered.
Yes, and that's when it aborts on my machine. Do it several times and
quickly, if it doesn't happen otherwise.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 05 Dec 2013 18:29:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Yes, and that's when it aborts on my machine. Do it several times and
> quickly, if it doesn't happen otherwise.
Doesn't happen here. Probably you have some transitional effects
(or whatever they are called in English) activated on your Windows.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 05 Dec 2013 18:31:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 05 Dec 2013 20:21:42 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 16051 <at> debbugs.gnu.org
>
> > Date: Thu, 05 Dec 2013 18:59:33 +0100
> > From: martin rudalics <rudalics <at> gmx.at>
> > CC: drew.adams <at> oracle.com, 16051 <at> debbugs.gnu.org
> >
> > > Did you drag the mouse far enough to the left?
> >
> > How could I? It stops as expected when a minimum width
> > is encountered.
>
> Yes, and that's when it aborts on my machine. Do it several times and
> quickly, if it doesn't happen otherwise.
FWIW, it aborts because 'row' is 7, whereas matrix->nrows is 5. From
these numbers, I'm guessing that the problem happens when Emacs tries
to redisplay the tool-bar window (which gets taller when you shrink
the frame width like this).
Some missing block_input somewhere, perhaps?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Fri, 06 Dec 2013 14:33:04 GMT)
Full text and
rfc822 format available.
Message #32 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> FWIW, it aborts because 'row' is 7, whereas matrix->nrows is 5. From
> these numbers, I'm guessing that the problem happens when Emacs tries
> to redisplay the tool-bar window (which gets taller when you shrink
> the frame width like this).
>
> Some missing block_input somewhere, perhaps?
Maybe I don't get it then because I build without image support. But I
can't reproduce it on Debian where I have image support. What is your
oldest build where this abort occurs?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Fri, 06 Dec 2013 15:32:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 06 Dec 2013 15:32:24 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 16051 <at> debbugs.gnu.org
>
> > FWIW, it aborts because 'row' is 7, whereas matrix->nrows is 5. From
> > these numbers, I'm guessing that the problem happens when Emacs tries
> > to redisplay the tool-bar window (which gets taller when you shrink
> > the frame width like this).
> >
> > Some missing block_input somewhere, perhaps?
>
> Maybe I don't get it then because I build without image support.
What, not even XPM? That's all that is needed in "emacs -Q".
> But I can't reproduce it on Debian where I have image support.
Depending on the toolkit, Emacs does not necessarily draw the tool bar
on Unix.
> What is your oldest build where this abort occurs?
It occurs as far back as Oct 19. I think this is an old bug, so you
don't need to worry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Fri, 06 Dec 2013 16:22:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 16051 <at> debbugs.gnu.org (full text, mbox):
>> Maybe I don't get it then because I build without image support.
>
> What, not even XPM? That's all that is needed in "emacs -Q".
I always compiled --without-xpm. But with MSYS I apparently don't pass
this option any more. What happens in configure if it's not here? In
any case I can't find the libraries anywhere on my system. Funny.
>> But I can't reproduce it on Debian where I have image support.
>
> Depending on the toolkit, Emacs does not necessarily draw the tool bar
> on Unix.
This is with-x-toolkit=no.
>> What is your oldest build where this abort occurs?
>
> It occurs as far back as Oct 19. I think this is an old bug, so you
> don't need to worry.
Does it occur with Emacs 24.3 ?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Fri, 06 Dec 2013 18:17:04 GMT)
Full text and
rfc822 format available.
Message #41 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 06 Dec 2013 17:21:00 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 16051 <at> debbugs.gnu.org
>
> >> Maybe I don't get it then because I build without image support.
> >
> > What, not even XPM? That's all that is needed in "emacs -Q".
>
> I always compiled --without-xpm. But with MSYS I apparently don't pass
> this option any more. What happens in configure if it's not here? In
> any case I can't find the libraries anywhere on my system. Funny.
>
> >> But I can't reproduce it on Debian where I have image support.
> >
> > Depending on the toolkit, Emacs does not necessarily draw the tool bar
> > on Unix.
>
> This is with-x-toolkit=no.
So what kind of tool bar you get with that? (I didn't see such a
build in a long time.)
> >> What is your oldest build where this abort occurs?
> >
> > It occurs as far back as Oct 19. I think this is an old bug, so you
> > don't need to worry.
>
> Does it occur with Emacs 24.3 ?
No.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Fri, 06 Dec 2013 18:58:03 GMT)
Full text and
rfc822 format available.
Message #44 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> So what kind of tool bar you get with that? (I didn't see such a
> build in a long time.)
How can I tell you? I could send you a screenshot.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Fri, 06 Dec 2013 19:09:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 06 Dec 2013 19:57:03 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 16051 <at> debbugs.gnu.org
>
> > So what kind of tool bar you get with that? (I didn't see such a
> > build in a long time.)
>
> How can I tell you? I could send you a screenshot.
Yes, please.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 07 Dec 2013 12:26:03 GMT)
Full text and
rfc822 format available.
Message #50 received at 16051 <at> debbugs.gnu.org (full text, mbox):
>> How can I tell you? I could send you a screenshot.
>
> Yes, please.
Attached find two screenshots. The Windows one is from a build
configured as
"CFLAGS='-O0 -g3' ./nt/msysconfig.sh --prefix=/c/emacs/... --enable-checking=yes --enable-gcc-warnings=yes --enable-check-lisp-object-type=yes"
The XFCE is from a build configured as
"CFLAGS='-O0 -g3' ./configure --without-tiff --with-x-toolkit=no --enable-checking=yes --enable-check-lisp-object-type=yes"
Can you say what the build scripts did?
I never cared about these because I don't use the toolbar.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 07 Dec 2013 12:32:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 16051 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Attached find two screenshots.
And now I really attach them.
martin
[Windows.png (image/png, inline)]
[XFCE.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 07 Dec 2013 13:13:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 07 Dec 2013 13:25:06 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 16051 <at> debbugs.gnu.org
>
> >> How can I tell you? I could send you a screenshot.
> >
> > Yes, please.
>
> Attached find two screenshots. The Windows one is from a build
> configured as
>
> "CFLAGS='-O0 -g3' ./nt/msysconfig.sh --prefix=/c/emacs/... --enable-checking=yes --enable-gcc-warnings=yes --enable-check-lisp-object-type=yes"
>
> The XFCE is from a build configured as
>
> "CFLAGS='-O0 -g3' ./configure --without-tiff --with-x-toolkit=no --enable-checking=yes --enable-check-lisp-object-type=yes"
Now I understand why your build doesn't crash: you didn't specify
GLYPH_DEBUG. I build with --enable-checking='yes,glyphs'. The
function where Emacs hits the assertion is not compiled in without
GLYPH_DEBUG being defined.
> Can you say what the build scripts did?
Not sure what are you asking. The Windows build seems indeed to be
devoid of XPM, but the Unix build does display color icons on the
toolbar. Try using image-type-available-p to see which image types
are supported.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 07 Dec 2013 14:25:04 GMT)
Full text and
rfc822 format available.
Message #59 received at 16051 <at> debbugs.gnu.org (full text, mbox):
>> Attached find two screenshots. The Windows one is from a build
>> configured as
>>
>> "CFLAGS='-O0 -g3' ./nt/msysconfig.sh --prefix=/c/emacs/... --enable-checking=yes --enable-gcc-warnings=yes --enable-check-lisp-object-type=yes"
>>
>> The XFCE is from a build configured as
>>
>> "CFLAGS='-O0 -g3' ./configure --without-tiff --with-x-toolkit=no --enable-checking=yes --enable-check-lisp-object-type=yes"
>
> Now I understand why your build doesn't crash: you didn't specify
> GLYPH_DEBUG. I build with --enable-checking='yes,glyphs'. The
> function where Emacs hits the assertion is not compiled in without
> GLYPH_DEBUG being defined.
OK. But Drew's didn't crash either and he talked about a hang IIRC.
>> Can you say what the build scripts did?
>
> Not sure what are you asking. The Windows build seems indeed to be
> devoid of XPM,
Yes. Currently building as
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? no
Does Emacs use -ljpeg? no
Does Emacs use -ltiff? no
Does Emacs use a gif library? no
Does Emacs use -lpng? no
Does Emacs use -lrsvg-2? no
Does Emacs use imagemagick? no
Why did the build script not complain (not that I mind - I rather prefer
it this way)? Earlier I had to explicitly specify
--without-xpm --without-png --without-jpeg --without-tiff --without-gif
And BTW what happend to ./nt/msysconfig.sh? I just noticed
bash: ./nt/msysconfig.sh: No such file or directory
> but the Unix build does display color icons on the
> toolbar. Try using image-type-available-p to see which image types
> are supported.
All but for tiff, as specified.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 07 Dec 2013 15:19:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 07 Dec 2013 15:23:53 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 16051 <at> debbugs.gnu.org
>
> > Now I understand why your build doesn't crash: you didn't specify
> > GLYPH_DEBUG. I build with --enable-checking='yes,glyphs'. The
> > function where Emacs hits the assertion is not compiled in without
> > GLYPH_DEBUG being defined.
>
> OK. But Drew's didn't crash either and he talked about a hang IIRC.
His build is with GLYPH_DEBUG:
In GNU Emacs 24.3.50.2 (i686-pc-mingw32)
of 2013-11-28 on LEG570
Bzr revision: 115271 rgm <at> gnu.org-20131128203155-qjc1xsp19z2k64b2
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'
I don't know why it didn't crash.
> > Not sure what are you asking. The Windows build seems indeed to be
> > devoid of XPM,
>
> Yes. Currently building as
>
> Does Emacs use -lXaw3d? no
> Does Emacs use -lXpm? no
> Does Emacs use -ljpeg? no
> Does Emacs use -ltiff? no
> Does Emacs use a gif library? no
> Does Emacs use -lpng? no
> Does Emacs use -lrsvg-2? no
> Does Emacs use imagemagick? no
>
> Why did the build script not complain (not that I mind - I rather prefer
> it this way)?
Complain about what? It is perfectly OK to build without XPM, it's
just not common.
> Earlier I had to explicitly specify
>
> --without-xpm --without-png --without-jpeg --without-tiff --without-gif
Maybe on Unix.
> And BTW what happend to ./nt/msysconfig.sh?
Its functionality was incorporated into configure.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 07 Dec 2013 15:48:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> In GNU Emacs 24.3.50.2 (i686-pc-mingw32)
> of 2013-11-28 on LEG570
> Bzr revision: 115271 rgm <at> gnu.org-20131128203155-qjc1xsp19z2k64b2
> Windowing system distributor `Microsoft Corp.', version 6.1.7601
> Configured using:
> `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'
How do you get this information?
>> Earlier I had to explicitly specify
>>
>> --without-xpm --without-png --without-jpeg --without-tiff --without-gif
>
> Maybe on Unix.
On Windows of course!
>> And BTW what happend to ./nt/msysconfig.sh?
>
> Its functionality was incorporated into configure.
OK. I see there must have been other changes as well. I currently do
c:/Programme/MinGW/msys/1.0/bin/bash.exe --login -i -c "cd /c/emacs/trunk/ ; CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3' --prefix=/c/emacs/trunk --enable-checking=yes --enable-gcc-warnings=yes --enable-check-lisp-object-type=yes"
and am immediately told
bash: --prefix=/c/emacs/trunk: No such file or directory
but what's more annoying that apparently my gcc directives don't get
through any more. I see, for example
gcc -std=gnu99 -c -mtune=pentium4 -DUSE_CRT_DLL=1 -I /c/emacs/trunk/nt/inc -Demacs -I. -I. -I../lib -I./../lib -mtune=pentium4 -MMD -MF deps/firstfile.d -MP -g3 -O2 -gdwarf-2 firstfile.c
that is -O0 has become -O2 IIUC. Any ideas?
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 07 Dec 2013 16:29:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 07 Dec 2013 16:47:03 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 16051 <at> debbugs.gnu.org
>
> > In GNU Emacs 24.3.50.2 (i686-pc-mingw32)
> > of 2013-11-28 on LEG570
> > Bzr revision: 115271 rgm <at> gnu.org-20131128203155-qjc1xsp19z2k64b2
> > Windowing system distributor `Microsoft Corp.', version 6.1.7601
> > Configured using:
> > `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'
>
> How do you get this information?
Drew reported it with his original bug report.
> >> Earlier I had to explicitly specify
> >>
> >> --without-xpm --without-png --without-jpeg --without-tiff --without-gif
> >
> > Maybe on Unix.
>
> On Windows of course!
>
> >> And BTW what happend to ./nt/msysconfig.sh?
> >
> > Its functionality was incorporated into configure.
>
> OK. I see there must have been other changes as well. I currently do
>
> c:/Programme/MinGW/msys/1.0/bin/bash.exe --login -i -c "cd /c/emacs/trunk/ ; CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3' --prefix=/c/emacs/trunk --enable-checking=yes --enable-gcc-warnings=yes --enable-check-lisp-object-type=yes"
>
> and am immediately told
>
> bash: --prefix=/c/emacs/trunk: No such file or directory
>
> but what's more annoying that apparently my gcc directives don't get
> through any more. I see, for example
>
> gcc -std=gnu99 -c -mtune=pentium4 -DUSE_CRT_DLL=1 -I /c/emacs/trunk/nt/inc -Demacs -I. -I. -I../lib -I./../lib -mtune=pentium4 -MMD -MF deps/firstfile.d -MP -g3 -O2 -gdwarf-2 firstfile.c
>
> that is -O0 has become -O2 IIUC. Any ideas?
None, except that I invoke the command from the Bash prompt.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 07 Dec 2013 17:01:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 16051 <at> debbugs.gnu.org (full text, mbox):
>>> And BTW what happend to ./nt/msysconfig.sh?
>>
>> Its functionality was incorporated into configure.
>
> OK. I see there must have been other changes as well. I currently do
>
> c:/Programme/MinGW/msys/1.0/bin/bash.exe --login -i -c "cd /c/emacs/trunk/
> ; CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3' --prefix=/c/emacs/trunk
> --enable-checking=yes --enable-gcc-warnings=yes
> --enable-check-lisp-object-type=yes"
>
> and am immediately told
>
> bash: --prefix=/c/emacs/trunk: No such file or directory
Your command should invoke the configure script. What you probably
want to to is:
c:/Programme/MinGW/msys/1.0/bin/bash.exe --login -i -c "cd
/c/emacs/trunk/ ; CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3'
./configure --prefix=/c/emacs/trunk --enable-checking=yes
--enable-gcc-warnings=yes --enable-check-lisp-object-type=yes"
HTH
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 07 Dec 2013 17:37:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Your command should invoke the configure script. What you probably
> want to to is:
>
> c:/Programme/MinGW/msys/1.0/bin/bash.exe --login -i -c "cd
> /c/emacs/trunk/ ; CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3'
> ./configure --prefix=/c/emacs/trunk --enable-checking=yes
> --enable-gcc-warnings=yes --enable-check-lisp-object-type=yes"
Thanks Dani. Seems to work now.
Apparently people on Windows never use the last two options ;-)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 07 Dec 2013 20:38:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> > > In GNU Emacs 24.3.50.2 (i686-pc-mingw32)
> > > of 2013-11-28 on LEG570
> > > Bzr revision: 115271 rgm <at> gnu.org-20131128203155-qjc1xsp19z2k64b2
> > > Windowing system distributor `Microsoft Corp.', version 6.1.7601
> > > Configured using:
> > > `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-
> DGLYPH_DEBUG=1'
> >
> > How do you get this information?
>
> Drew reported it with his original bug report.
It is inserted by `report-emacs-bug'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 21 Dec 2013 13:45:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 16051 <at> debbugs.gnu.org (full text, mbox):
The bug report seems to have been hijacked. Let's now get back to the
subject:
I reproduce the issue in r115660, with default building configuration
(no checks).
1. emacs -Q
2. drag the bottom right corner of the window up and left
3. before you reach the up left corner of the window Emacs stops
displaying its contents, only scroll-bars are visible - it hangs
Not reproducable in 100%. The most easily when dragging slowly (only
right edge of the window may suffice) to the left. Then it's noticeable,
that it happens after reaching toolbar size, so it should wrap.
Sometimes it's possible to avoid the freeze by doing quick movements.
In my case this is the part (from xdisp.c:~13620) that replays
infinitely (redisplay_internal does not end):
if (f->fonts_changed)
{
adjust_frame_glyphs (f);
f->fonts_changed = 0;
printf("A"); fflush(stdout); //BS
goto retry_frame;
}
Jarek
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 21 Dec 2013 15:13:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 21 Dec 2013 14:44:36 +0100
> From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
>
> The bug report seems to have been hijacked. Let's now get back to the
> subject:
>
> I reproduce the issue in r115660, with default building configuration
> (no checks).
>
> 1. emacs -Q
> 2. drag the bottom right corner of the window up and left
> 3. before you reach the up left corner of the window Emacs stops
> displaying its contents, only scroll-bars are visible - it hangs
Why would you want to drag the bottom right corner so far left as to
leave no space for displaying the windows?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 21 Dec 2013 15:18:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 21 Dec 2013 17:12:24 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 16051 <at> debbugs.gnu.org
>
> > Date: Sat, 21 Dec 2013 14:44:36 +0100
> > From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
> >
> > The bug report seems to have been hijacked. Let's now get back to the
> > subject:
> >
> > I reproduce the issue in r115660, with default building configuration
> > (no checks).
> >
> > 1. emacs -Q
> > 2. drag the bottom right corner of the window up and left
> > 3. before you reach the up left corner of the window Emacs stops
> > displaying its contents, only scroll-bars are visible - it hangs
>
> Why would you want to drag the bottom right corner so far left as to
> leave no space for displaying the windows?
Btw, it doesn't hang here: C-g gets control back.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 21 Dec 2013 15:47:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 16051 <at> debbugs.gnu.org (full text, mbox):
W dniu 2013-12-21 16:12, Eli Zaretskii pisze:
> Why would you want to drag the bottom right corner so far left as to
> leave no space for displaying the windows?
To reproduce the issue and help Emacs development. I don't understand
this question, by the way. If this is not extremely important let's
don't investigate it further. I promise to stop unreasonable resizing of
the windows, Emacs windows.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 21 Dec 2013 16:21:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 21 Dec 2013 16:46:50 +0100
> From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
>
> W dniu 2013-12-21 16:12, Eli Zaretskii pisze:
> > Why would you want to drag the bottom right corner so far left as to
> > leave no space for displaying the windows?
>
> To reproduce the issue and help Emacs development. I don't understand
> this question, by the way. If this is not extremely important let's
> don't investigate it further. I promise to stop unreasonable resizing of
> the windows, Emacs windows.
I don't think it's important, certainly not extremely important. You
can hang Emacs with as little as '(while t)'. Users who do
unreasonable things should expect trouble, because Emacs gives them a
lot of rope to hang themselves.
Of course, if someone comes up with a patch to prevent infinite
redisplay cycles in this case, such a patch will be welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 21 Dec 2013 17:14:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> I don't think it's important, certainly not extremely important. You
> can hang Emacs with as little as '(while t)'. Users who do
> unreasonable things should expect trouble, because Emacs gives them a
> lot of rope to hang themselves.
If I do drag _very_ fast as described by the OP, Emacs reliably crashes
here as:
#0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
#1 0x0116400a in die (msg=0x14763e0 "row >= 0 && row < matrix->nrows", file=0x147618c "dispnew.c", line=1369) at alloc.c:6742
#2 0x01004ed3 in matrix_row (matrix=0x36e2800, row=7) at dispnew.c:1369
#3 0x01040eaa in hscroll_window_tree (window=...) at xdisp.c:12610
#4 0x01041398 in hscroll_windows (window=...) at xdisp.c:12737
#5 0x010437bd in redisplay_internal () at xdisp.c:13631
#6 0x01044126 in redisplay_preserve_echo_area (from_where=11) at xdisp.c:13856
#7 0x011cd0f5 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at process.c:4528
#8 0x0100eef8 in sit_for (timeout=..., reading=true, display_option=1) at dispnew.c:5801
#9 0x010f7e19 in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x82f7ef, end_time=0x0) at keyboard.c:2802
#10 0x01104dcd in read_key_sequence (keybuf=0x82f8e4, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9071
#11 0x010f5109 in command_loop_1 () at keyboard.c:1445
#12 0x0117ef24 in internal_condition_case (bfun=0x10f4d84 <command_loop_1>, handlers=..., hfun=0x10f45ef <cmd_error>) at eval.c:1344
#13 0x010f4a37 in command_loop_2 (ignore=...) at keyboard.c:1170
#14 0x0117e4d8 in internal_catch (tag=..., func=0x10f4a13 <command_loop_2>, arg=...) at eval.c:1108
#15 0x010f49f1 in command_loop () at keyboard.c:1149
#16 0x010f418b in recursive_edit_1 () at keyboard.c:777
#17 0x010f4348 in Frecursive_edit () at keyboard.c:841
#18 0x010f2522 in main (argc=2, argv=0xa32840) at emacs.c:1634
Lisp Backtrace:
"redisplay_internal (C function)" (0x152db1c)
I can't reproduce the crash with the toolbar turned off.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 21 Dec 2013 18:49:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 21 Dec 2013 18:13:25 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Jarek Czekalski <jarekczek <at> poczta.onet.pl>, 16051 <at> debbugs.gnu.org
>
> > I don't think it's important, certainly not extremely important. You
> > can hang Emacs with as little as '(while t)'. Users who do
> > unreasonable things should expect trouble, because Emacs gives them a
> > lot of rope to hang themselves.
>
> If I do drag _very_ fast as described by the OP, Emacs reliably crashes
> here as:
>
>
> #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
> #1 0x0116400a in die (msg=0x14763e0 "row >= 0 && row < matrix->nrows", file=0x147618c "dispnew.c", line=1369) at alloc.c:6742
> #2 0x01004ed3 in matrix_row (matrix=0x36e2800, row=7) at dispnew.c:1369
Isn't that what I said in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16051#8
?
> I can't reproduce the crash with the toolbar turned off.
Because the crash happens while we redraw the toolbar.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Sat, 21 Dec 2013 19:41:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Isn't that what I said in
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16051#8
>
> ?
>
>> I can't reproduce the crash with the toolbar turned off.
>
> Because the crash happens while we redraw the toolbar.
Correct. My repentance finished up in the wrong thread.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Mon, 23 Dec 2013 16:58:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 21 Dec 2013 18:13:25 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Jarek Czekalski <jarekczek <at> poczta.onet.pl>, 16051 <at> debbugs.gnu.org
>
> > I don't think it's important, certainly not extremely important. You
> > can hang Emacs with as little as '(while t)'. Users who do
> > unreasonable things should expect trouble, because Emacs gives them a
> > lot of rope to hang themselves.
>
> If I do drag _very_ fast as described by the OP, Emacs reliably crashes
> here as:
>
>
> #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
> #1 0x0116400a in die (msg=0x14763e0 "row >= 0 && row < matrix->nrows", file=0x147618c "dispnew.c", line=1369) at alloc.c:6742
> #2 0x01004ed3 in matrix_row (matrix=0x36e2800, row=7) at dispnew.c:1369
> #3 0x01040eaa in hscroll_window_tree (window=...) at xdisp.c:12610
> #4 0x01041398 in hscroll_windows (window=...) at xdisp.c:12737
> #5 0x010437bd in redisplay_internal () at xdisp.c:13631
> #6 0x01044126 in redisplay_preserve_echo_area (from_where=11) at xdisp.c:13856
It turns out this bug has 3 separate parts. 2 of them are very clear
and uncontroversial, so I simply fixed them; see revision 115718 on
the trunk. After that, there are no more assertion violations like
above, and no hangs, and it is much harder to cause a redisplay loop.
Also, the only redisplay loops I can trigger are immediately
interrupted by C-g. But since such loops can still be triggered,
there's another part to this riddle.
Here, the problem and the solution seem clear to me, but since the
code is quite deliberately doing what it does, I'd like to ask Martin
about the underlying logic. I'm talking about this part of
redisplay_tool_bar:
if (change_height_p)
{
int new_lines = ((new_height + FRAME_LINE_HEIGHT (f) - 1)
/ FRAME_LINE_HEIGHT (f));
XSETFRAME (frame, f);
Fmodify_frame_parameters (frame,
list1 (Fcons (Qtool_bar_lines,
make_number (new_lines))));
/* Always do that now. */
clear_glyph_matrix (w->desired_matrix);
f->n_tool_bar_rows = nrows;
f->fonts_changed = 1;
return 1;
}
Why does it make sense to "always do that"? Suppose new_lines is
exactly equal to the current number of canonical lines used by the
tool-bar window (it can happen even if pixel sizes are different, due
to integer truncation). Or suppose you are asking for N lines, but
don't get it because the frame is too small. Why set the
fonts_changed flag in those cases? That flag causes redisplay to give
up, abandon the current glyph matrices, and retry anew. What happens
with those endless cycles is precisely that: redisplay_tool_bar sets
the fonts_changed flag, which causes redisplay_internal to retry,
which again calls redisplay_tool_bar, which again sets the flag,
etc., ad nauseam.
If there is some reasoning behind this "always do that" logic, please
describe it. Otherwise, I propose the patch below, which cures the
problem altogether for me; if you agree, I will install it.
As an aside, I stared for a long time at this part of
w32fns.c:x_set_tool_bar_lines (which is part of the issue, because it
is called by modify-frame-parameters, when the tool-bar-lines
parameter is changed), and I still don't get why it does what it does:
root_height = WINDOW_PIXEL_HEIGHT (XWINDOW (FRAME_ROOT_WINDOW (f)));
if (root_height - delta < unit)
{
delta = root_height - unit;
nlines = (root_height / unit) + min (1, (root_height % unit));
}
First, delta is recomputed, but the result is never used. More
importantly, you assign to nlines a value that is the size of the root
window _plus_ one line? Did you mean minus instead?
Finally, the corresponding xfns.c implementation still works in lines,
not in pixels, as w32fns.c did before your pixelwise changes. Is this
disparity on purpose or an oversight?
Here's the patch I propose to solve the last part of this bug. It
abandons the "do it always" method, and only changes the
tool-bar-lines parameter and sets the fonts_changed flag if the
required height of the tool bar differs from the current height by at
least 1 canonical line, and if it is smaller than the maximum number
of lines any window can get on this frame.
--- src/xdisp.c~1 2013-12-23 18:20:09.678832900 +0200
+++ src/xdisp.c 2013-12-23 18:50:56.993834000 +0200
@@ -12289,18 +12289,24 @@ redisplay_tool_bar (struct frame *f)
if (change_height_p)
{
+ int old_lines = WINDOW_TOTAL_LINES (w);
int new_lines = ((new_height + FRAME_LINE_HEIGHT (f) - 1)
/ FRAME_LINE_HEIGHT (f));
+ int max_lines =
+ WINDOW_TOTAL_LINES (XWINDOW (FRAME_ROOT_WINDOW (f))) - 1;
- XSETFRAME (frame, f);
- Fmodify_frame_parameters (frame,
- list1 (Fcons (Qtool_bar_lines,
- make_number (new_lines))));
- /* Always do that now. */
- clear_glyph_matrix (w->desired_matrix);
- f->n_tool_bar_rows = nrows;
- f->fonts_changed = 1;
- return 1;
+ if (new_lines <= max_lines
+ && eabs (new_lines - old_lines) >= 1)
+ {
+ XSETFRAME (frame, f);
+ Fmodify_frame_parameters (frame,
+ list1 (Fcons (Qtool_bar_lines,
+ make_number (new_lines))));
+ clear_glyph_matrix (w->desired_matrix);
+ f->n_tool_bar_rows = nrows;
+ f->fonts_changed = 1;
+ return 1;
+ }
}
}
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Mon, 23 Dec 2013 18:45:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> It turns out this bug has 3 separate parts. 2 of them are very clear
> and uncontroversial, so I simply fixed them; see revision 115718 on
> the trunk. After that, there are no more assertion violations like
> above, and no hangs, and it is much harder to cause a redisplay loop.
Thanks.
- it.last_visible_x = FRAME_TOTAL_COLS (f) * FRAME_COLUMN_WIDTH (f);
+ it.last_visible_x = WINDOW_PIXEL_WIDTH (w);
Wonderful. The effect of this was visible in the Lucid/Motif builds but
since I hadn't seen it in the Windows build I didn't expect to find the
cause in the toolkit independent part of the code. But is this related
to the current bug?
The second issue belongs in the category of things I expected to happen
hoping that sooner or later you would detect and fix them. I would
certainly be able to spend some time studying your fix and still not
grasp it.
> if (change_height_p)
> {
> int new_lines = ((new_height + FRAME_LINE_HEIGHT (f) - 1)
> / FRAME_LINE_HEIGHT (f));
>
> XSETFRAME (frame, f);
> Fmodify_frame_parameters (frame,
> list1 (Fcons (Qtool_bar_lines,
> make_number (new_lines))));
> /* Always do that now. */
> clear_glyph_matrix (w->desired_matrix);
> f->n_tool_bar_rows = nrows;
> f->fonts_changed = 1;
> return 1;
> }
>
> Why does it make sense to "always do that"? Suppose new_lines is
> exactly equal to the current number of canonical lines used by the
> tool-bar window (it can happen even if pixel sizes are different, due
> to integer truncation). Or suppose you are asking for N lines, but
> don't get it because the frame is too small. Why set the
> fonts_changed flag in those cases? That flag causes redisplay to give
> up, abandon the current glyph matrices, and retry anew. What happens
> with those endless cycles is precisely that: redisplay_tool_bar sets
> the fonts_changed flag, which causes redisplay_internal to retry,
> which again calls redisplay_tool_bar, which again sets the flag,
> etc., ad nauseam.
"Always" referred to the glyph matrix clearing part. I was completely
ignorant of the fact that setting the fonts_changed flag would cause
this to loop. Admittedly, I normally don't use the toolbar and so have
not given it enough testing with more extreme behavior.
As an aside, I have never been able to understand the purpose of the
tool-bar-lines parameter. IIUC we are only supposed to read its value
from Lisp but never to set it to anything but zero or one. Am I right?
> If there is some reasoning behind this "always do that" logic, please
> describe it. Otherwise, I propose the patch below, which cures the
> problem altogether for me; if you agree, I will install it.
I certainly agree :-)
> As an aside, I stared for a long time at this part of
> w32fns.c:x_set_tool_bar_lines (which is part of the issue, because it
> is called by modify-frame-parameters, when the tool-bar-lines
> parameter is changed), and I still don't get why it does what it does:
> root_height = WINDOW_PIXEL_HEIGHT (XWINDOW (FRAME_ROOT_WINDOW (f)));
> if (root_height - delta < unit)
How would you know - it probably doesn't do anything reasonable. When
we enter this part we see only the upper part of the first row of the
toolbar, the rest of the toolbar, root and minibuffer window being
clipped by the window manager.
> {
> delta = root_height - unit;
> nlines = (root_height / unit) + min (1, (root_height % unit));
> }
>
> First, delta is recomputed, but the result is never used. More
> importantly, you assign to nlines a value that is the size of the root
> window _plus_ one line? Did you mean minus instead?
Probably. If you have any good idea what to do here, please do it.
IIUC we want to pretend that the frame has the full toolbar (probably as
many rows as it has items), a one line root window and, if it's present,
a one line minibuffer window. This should be robust enough to avoid a
crash.
But the underlying problem, namely that shrinking the width of the frame
may mean that we'd have to enlarge its height, remains. Currently, our
internal toolbar gets nominally larger than the containing frame.
> Finally, the corresponding xfns.c implementation still works in lines,
> not in pixels, as w32fns.c did before your pixelwise changes. Is this
> disparity on purpose or an oversight?
When I installed my changes I tested this only with the Windows and the
Gtk builds. It's only now that I encountered problems with the Lucid
and Motif builds. I'm working on this currently.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Mon, 23 Dec 2013 19:32:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 23 Dec 2013 19:44:33 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: jarekczek <at> poczta.onet.pl, 16051 <at> debbugs.gnu.org
>
> - it.last_visible_x = FRAME_TOTAL_COLS (f) * FRAME_COLUMN_WIDTH (f);
> + it.last_visible_x = WINDOW_PIXEL_WIDTH (w);
>
> Wonderful. The effect of this was visible in the Lucid/Motif builds but
> since I hadn't seen it in the Windows build I didn't expect to find the
> cause in the toolkit independent part of the code. But is this related
> to the current bug?
Yes, definitely. redisplay_tool_bar was using WINDOW_PIXEL_WIDTH,
while tool_bar_height was using FRAME_TOTAL_COLS (f) * FRAME_COLUMN_WIDTH (f)
so these two were inconsistent with each other, and when the former
claimed (correctly) that there's not enough space to draw the tool bar
in one row, tool_bar_height was (incorrectly) returning 1 as the
required number of rows. And then you set the fonts_changed flag,
which starts the infloop...
> As an aside, I have never been able to understand the purpose of the
> tool-bar-lines parameter. IIUC we are only supposed to read its value
> from Lisp but never to set it to anything but zero or one. Am I right?
If you are right, then I'm confused: the call to
Fmodify_frame_parameters that changes the tool-bar-lines parameter
leads to a call to x_set_tool_bar_lines, which in turn resizes the
tool-bar window. And the value is certainly not always 1, I've seen
it as large as 7.
Maybe you meant the n_tool_bar_rows member of 'struct frame' instead?
But that, too, is not always 1, it can be greater. Confused...
> > If there is some reasoning behind this "always do that" logic, please
> > describe it. Otherwise, I propose the patch below, which cures the
> > problem altogether for me; if you agree, I will install it.
>
> I certainly agree :-)
OK, installed as trunk revision 115720.
> > As an aside, I stared for a long time at this part of
> > w32fns.c:x_set_tool_bar_lines (which is part of the issue, because it
> > is called by modify-frame-parameters, when the tool-bar-lines
> > parameter is changed), and I still don't get why it does what it does:
> > root_height = WINDOW_PIXEL_HEIGHT (XWINDOW (FRAME_ROOT_WINDOW (f)));
> > if (root_height - delta < unit)
>
> How would you know - it probably doesn't do anything reasonable. When
> we enter this part we see only the upper part of the first row of the
> toolbar, the rest of the toolbar, root and minibuffer window being
> clipped by the window manager.
Actually, we enter there any time a change is requested for the
frame's tool-bar-lines parameter, and the change is so large it will
leave no space for the rest of the root window.
> > {
> > delta = root_height - unit;
> > nlines = (root_height / unit) + min (1, (root_height % unit));
> > }
> >
> > First, delta is recomputed, but the result is never used. More
> > importantly, you assign to nlines a value that is the size of the root
> > window _plus_ one line? Did you mean minus instead?
>
> Probably. If you have any good idea what to do here, please do it.
Well, the old code simply left at least one screen line to the window,
and if the tool bar asked for more than that, its request was not
honored:
delta = nlines - FRAME_TOOL_BAR_LINES (f);
/* Don't resize the tool-bar to more than we have room for. */
root_window = FRAME_ROOT_WINDOW (f);
root_height = WINDOW_TOTAL_LINES (XWINDOW (root_window));
if (root_height - delta < 1)
{
delta = root_height - 1;
nlines = FRAME_TOOL_BAR_LINES (f) + delta;
}
FRAME_TOOL_BAR_LINES (f) = nlines;
Translation of this to pixels is straightforward, but it looks like
you wanted to do something different here?
> IIUC we want to pretend that the frame has the full toolbar (probably as
> many rows as it has items), a one line root window and, if it's present,
> a one line minibuffer window. This should be robust enough to avoid a
> crash.
There's no crash anymore, at least not on Windows. But doing what you
suggest above means we will need to resize the entire frame, something
we never did.
> But the underlying problem, namely that shrinking the width of the frame
> may mean that we'd have to enlarge its height, remains. Currently, our
> internal toolbar gets nominally larger than the containing frame.
It gets larger and is displayed only partially. I think this is
reasonable under these circumstances: if the user does dumb things,
which shouldn't we let her suffer?
> > Finally, the corresponding xfns.c implementation still works in lines,
> > not in pixels, as w32fns.c did before your pixelwise changes. Is this
> > disparity on purpose or an oversight?
>
> When I installed my changes I tested this only with the Windows and the
> Gtk builds. It's only now that I encountered problems with the Lucid
> and Motif builds. I'm working on this currently.
OK, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Mon, 23 Dec 2013 20:03:03 GMT)
Full text and
rfc822 format available.
Message #113 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> If you are right, then I'm confused: the call to
> Fmodify_frame_parameters that changes the tool-bar-lines parameter
> leads to a call to x_set_tool_bar_lines, which in turn resizes the
> tool-bar window. And the value is certainly not always 1, I've seen
> it as large as 7.
This must be the display code which takes the deviation via the frame
parameter to communicate the new size to resize_frame_windows. Not very
clean IMHO.
> Well, the old code simply left at least one screen line to the window,
> and if the tool bar asked for more than that, its request was not
> honored:
This is not what I see with 24.3: With emacs -Q make the frame very
narrow and shrink its height. Here I see 3 tool-bar lines but no root
or minibuffer window.
> delta = nlines - FRAME_TOOL_BAR_LINES (f);
>
> /* Don't resize the tool-bar to more than we have room for. */
> root_window = FRAME_ROOT_WINDOW (f);
> root_height = WINDOW_TOTAL_LINES (XWINDOW (root_window));
> if (root_height - delta < 1)
> {
> delta = root_height - 1;
> nlines = FRAME_TOOL_BAR_LINES (f) + delta;
> }
>
> FRAME_TOOL_BAR_LINES (f) = nlines;
I understand its meaning and also that the subsequent call to
resize_frame_windows is OK. But, as stated above, the toolbar is not
shrunk to one line. The change does not get propagated back to the
display engine to display less lines. Or am I missing something?
> Translation of this to pixels is straightforward, but it looks like
> you wanted to do something different here?
I can do that translation but would rather like to understand first what
really goes on here.
>> IIUC we want to pretend that the frame has the full toolbar (probably as
>> many rows as it has items), a one line root window and, if it's present,
>> a one line minibuffer window. This should be robust enough to avoid a
>> crash.
>
> There's no crash anymore, at least not on Windows. But doing what you
> suggest above means we will need to resize the entire frame, something
> we never did.
No. I meant to keep the frame size fixed at some minimum value and let
the window manager do the clipping - just as it does now.
>> But the underlying problem, namely that shrinking the width of the frame
>> may mean that we'd have to enlarge its height, remains. Currently, our
>> internal toolbar gets nominally larger than the containing frame.
>
> It gets larger and is displayed only partially. I think this is
> reasonable under these circumstances: if the user does dumb things,
> which shouldn't we let her suffer?
The problem is not that it gets larger. The problem is that it gets
larger than the containing frame. OTOH if Emacs thinks that it has only
one line that might be good enough for us.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Mon, 23 Dec 2013 20:19:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 23 Dec 2013 21:02:24 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: jarekczek <at> poczta.onet.pl, 16051 <at> debbugs.gnu.org
>
> > If you are right, then I'm confused: the call to
> > Fmodify_frame_parameters that changes the tool-bar-lines parameter
> > leads to a call to x_set_tool_bar_lines, which in turn resizes the
> > tool-bar window. And the value is certainly not always 1, I've seen
> > it as large as 7.
>
> This must be the display code which takes the deviation via the frame
> parameter to communicate the new size to resize_frame_windows. Not very
> clean IMHO.
No, that's not what happens. What happens is this call sequence:
Fmodify_frame_parameters
|
+------> x_set_frame_parameters
|
+-------> x_set_tool_bar_lines
(The last call is via the FRAME_RIF (f)->frame_parm_handlers[] array.)
> > Well, the old code simply left at least one screen line to the window,
> > and if the tool bar asked for more than that, its request was not
> > honored:
>
> This is not what I see with 24.3: With emacs -Q make the frame very
> narrow and shrink its height. Here I see 3 tool-bar lines but no root
> or minibuffer window.
I'm talking about what the code did, not about the effect. FWIW,
Emacs 24.3 just hits an assertion when I try that:
xdisp.c:1053: Emacs fatal error: assertion failed: height >= 0
I guess your Emacs 24.3 is built without --enable-checking.
> > delta = nlines - FRAME_TOOL_BAR_LINES (f);
> >
> > /* Don't resize the tool-bar to more than we have room for. */
> > root_window = FRAME_ROOT_WINDOW (f);
> > root_height = WINDOW_TOTAL_LINES (XWINDOW (root_window));
> > if (root_height - delta < 1)
> > {
> > delta = root_height - 1;
> > nlines = FRAME_TOOL_BAR_LINES (f) + delta;
> > }
> >
> > FRAME_TOOL_BAR_LINES (f) = nlines;
>
> I understand its meaning and also that the subsequent call to
> resize_frame_windows is OK. But, as stated above, the toolbar is not
> shrunk to one line.
The code above does not attempt to shrink the toolbar to one line, it
limits the DELTA, i.e. the additional lines the toolbar will get, to
the height of the frame's root window minus one line. IOW, it shrinks
the rest of the root window to one line.
> >> IIUC we want to pretend that the frame has the full toolbar (probably as
> >> many rows as it has items), a one line root window and, if it's present,
> >> a one line minibuffer window. This should be robust enough to avoid a
> >> crash.
> >
> > There's no crash anymore, at least not on Windows. But doing what you
> > suggest above means we will need to resize the entire frame, something
> > we never did.
>
> No. I meant to keep the frame size fixed at some minimum value and let
> the window manager do the clipping - just as it does now.
The frame size should remain as it was -- as the user determined by
dragging. We should not change it. The question is what value should
we limit the tool bar to, given those constraints, and how much space
should we leave to the rest of the root window of the frame.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Tue, 24 Dec 2013 10:15:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 16051 <at> debbugs.gnu.org (full text, mbox):
>> > If you are right, then I'm confused: the call to
>> > Fmodify_frame_parameters that changes the tool-bar-lines parameter
>> > leads to a call to x_set_tool_bar_lines, which in turn resizes the
>> > tool-bar window. And the value is certainly not always 1, I've seen
>> > it as large as 7.
>>
>> This must be the display code which takes the deviation via the frame
>> parameter to communicate the new size to resize_frame_windows. Not very
>> clean IMHO.
>
> No, that's not what happens. What happens is this call sequence:
>
> Fmodify_frame_parameters
Who calls Fmodify_frame_parameters here? It's redisplay_tool_bar in
if (new_height != WINDOW_PIXEL_HEIGHT (w))
...
Fmodify_frame_parameters (frame,
list1 (Fcons (Qtool_bar_lines,
make_number (new_lines))));
discovering that the present line doesn't suffice.
> |
> +------> x_set_frame_parameters
> |
> +-------> x_set_tool_bar_lines
>
> (The last call is via the FRAME_RIF (f)->frame_parm_handlers[] array.)
>
>> > Well, the old code simply left at least one screen line to the window,
>> > and if the tool bar asked for more than that, its request was not
>> > honored:
>>
>> This is not what I see with 24.3: With emacs -Q make the frame very
>> narrow and shrink its height. Here I see 3 tool-bar lines but no root
>> or minibuffer window.
>
> I'm talking about what the code did, not about the effect. FWIW,
> Emacs 24.3 just hits an assertion when I try that:
>
> xdisp.c:1053: Emacs fatal error: assertion failed: height >= 0
>
> I guess your Emacs 24.3 is built without --enable-checking.
Probably. Not entirely relieving to see that the problem is not new.
> The code above does not attempt to shrink the toolbar to one line, it
> limits the DELTA, i.e. the additional lines the toolbar will get, to
> the height of the frame's root window minus one line. IOW, it shrinks
> the rest of the root window to one line.
And this is completely wrong at this place. I already marked the
problem when I applied my changes but forgot about it. It's here:
/* Max tool-bar height. Basically, this is what makes all other windows
disappear when the frame gets too small. Rethink this! */
#define MAX_FRAME_TOOL_BAR_HEIGHT(f) \
((FRAME_LINE_HEIGHT (f) * FRAME_LINES (f)))
This means that the toolbar is allowed to grasp the whole frame, killing
everything else.
>> No. I meant to keep the frame size fixed at some minimum value and let
>> the window manager do the clipping - just as it does now.
>
> The frame size should remain as it was -- as the user determined by
> dragging.
But this means that we currently do change the frame size.
> We should not change it. The question is what value should
> we limit the tool bar to, given those constraints, and how much space
> should we leave to the rest of the root window of the frame.
What we do when there's no toolbar, I presume. That is, if there's not
enough space, then kill the toolbar.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Tue, 24 Dec 2013 17:35:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 24 Dec 2013 11:14:25 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: jarekczek <at> poczta.onet.pl, 16051 <at> debbugs.gnu.org
>
> >> > If you are right, then I'm confused: the call to
> >> > Fmodify_frame_parameters that changes the tool-bar-lines parameter
> >> > leads to a call to x_set_tool_bar_lines, which in turn resizes the
> >> > tool-bar window. And the value is certainly not always 1, I've seen
> >> > it as large as 7.
> >>
> >> This must be the display code which takes the deviation via the frame
> >> parameter to communicate the new size to resize_frame_windows. Not very
> >> clean IMHO.
> >
> > No, that's not what happens. What happens is this call sequence:
> >
> > Fmodify_frame_parameters
>
> Who calls Fmodify_frame_parameters here? It's redisplay_tool_bar in
>
> if (new_height != WINDOW_PIXEL_HEIGHT (w))
> ...
> Fmodify_frame_parameters (frame,
> list1 (Fcons (Qtool_bar_lines,
> make_number (new_lines))));
>
> discovering that the present line doesn't suffice.
Right.
> /* Max tool-bar height. Basically, this is what makes all other windows
> disappear when the frame gets too small. Rethink this! */
>
> #define MAX_FRAME_TOOL_BAR_HEIGHT(f) \
> ((FRAME_LINE_HEIGHT (f) * FRAME_LINES (f)))
>
> This means that the toolbar is allowed to grasp the whole frame, killing
> everything else.
Yes, it is. Not very nice, but if the user wants that, she will get
what she asks for.
> >> No. I meant to keep the frame size fixed at some minimum value and let
> >> the window manager do the clipping - just as it does now.
> >
> > The frame size should remain as it was -- as the user determined by
> > dragging.
>
> But this means that we currently do change the frame size.
I think we are miscommunicating, because we certainly don't change the
frame size; the user does.
> > We should not change it. The question is what value should
> > we limit the tool bar to, given those constraints, and how much space
> > should we leave to the rest of the root window of the frame.
>
> What we do when there's no toolbar, I presume. That is, if there's not
> enough space, then kill the toolbar.
That's too drastic I think. We are perfectly capable of displaying
the tool bar truncated to the part that can be rendered. If the user
doesn't like that, she can always turn off the tool bar manually.
After all, it's the user who caused this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Tue, 24 Dec 2013 18:46:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 16051 <at> debbugs.gnu.org (full text, mbox):
>> > The frame size should remain as it was -- as the user determined by
>> > dragging.
>>
>> But this means that we currently do change the frame size.
>
> I think we are miscommunicating, because we certainly don't change the
> frame size; the user does.
Tha user only asks us to change it. And the point I wanted to make here
is that instead of changing it we could refuse to change it, either by
(1) setting the according wm hints, or by
(2) issuing a re-resize request to the wm, or by
(3) simply not processing the new frame size and let the wm do the
clipping.
Now (1) seems difficult because people can change height and width at
the same time and with a wrapping toolbar we hardly can specify the
proper hints here (essentially we would have to be able to pass the
minimum size of the Emacs window to the wm). (2) is not nice although
we do something similar already IIRC.
So my preference for this is (3). Which would just imply that the size
of an Emacs frame does not correspond to what the user sees.
>> > We should not change it. The question is what value should
>> > we limit the tool bar to, given those constraints, and how much space
>> > should we leave to the rest of the root window of the frame.
>>
>> What we do when there's no toolbar, I presume. That is, if there's not
>> enough space, then kill the toolbar.
>
> That's too drastic I think. We are perfectly capable of displaying
> the tool bar truncated to the part that can be rendered. If the user
> doesn't like that, she can always turn off the tool bar manually.
> After all, it's the user who caused this.
It's not a question of what we can display. The problem is that our
internal understanding of the geometry of a frame is broken when the
toolbar gets a greater height than the containing frame.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Tue, 24 Dec 2013 18:56:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 24 Dec 2013 19:45:26 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: jarekczek <at> poczta.onet.pl, 16051 <at> debbugs.gnu.org
>
> >> > The frame size should remain as it was -- as the user determined by
> >> > dragging.
> >>
> >> But this means that we currently do change the frame size.
> >
> > I think we are miscommunicating, because we certainly don't change the
> > frame size; the user does.
>
> Tha user only asks us to change it. And the point I wanted to make here
> is that instead of changing it we could refuse to change it
That'd be fine, if you know how to do that on all supported platforms.
> (1) setting the according wm hints, or by
>
> (2) issuing a re-resize request to the wm, or by
>
> (3) simply not processing the new frame size and let the wm do the
> clipping.
>
> Now (1) seems difficult because people can change height and width at
> the same time and with a wrapping toolbar we hardly can specify the
> proper hints here (essentially we would have to be able to pass the
> minimum size of the Emacs window to the wm). (2) is not nice although
> we do something similar already IIRC.
>
> So my preference for this is (3). Which would just imply that the size
> of an Emacs frame does not correspond to what the user sees.
I agree. I just hope it won't be too hard to do this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 26 Dec 2013 11:53:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 16051 <at> debbugs.gnu.org (full text, mbox):
I now do two things: I do not shrink the root window to less than one
line/column (though apparently setting a window's pixel size to zero or
a negative value didn't harm even earlier) and never delete a subwindow
when shrinking a frame. Frame size and toolbar/root window sizes still
do not correspond. We've been living long enough with this issue. So
let's see whether I've broken anything.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 26 Dec 2013 17:32:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 26 Dec 2013 12:51:59 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: jarekczek <at> poczta.onet.pl, 16051 <at> debbugs.gnu.org
>
> I now do two things: I do not shrink the root window to less than one
> line/column (though apparently setting a window's pixel size to zero or
> a negative value didn't harm even earlier) and never delete a subwindow
> when shrinking a frame. Frame size and toolbar/root window sizes still
> do not correspond. We've been living long enough with this issue. So
> let's see whether I've broken anything.
Thanks. I don't see any problems with the new version, but I still
can make the frame as small as just the tool bar, or even smaller. It
looks like the leave one line/column strategy is being defeated by
something. Not that I think it's terribly important to fix this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 26 Dec 2013 18:05:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Thanks. I don't see any problems with the new version, but I still
> can make the frame as small as just the tool bar, or even smaller. It
> looks like the leave one line/column strategy is being defeated by
> something. Not that I think it's terribly important to fix this.
You can make the frame as small as the window manager allows it. But
the root window should now be always at least one line/column large
(earlier you could easily give it a negative size). So there's a loose
synchronization between frame and root window size: If the frame is
large enough, the root window will be fit into it and you can see it
together with the toolbar and the minibuffer window. If the frame is
not large enough, toolbar, root and minibuffer window together are
larger than the frame and the window manager clips parts or all of them.
This means that in certain states you cannot, for example, derive the
size of the root window from the size of the frame. But this wasn't
possible before my change either.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 26 Dec 2013 18:48:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 26 Dec 2013 19:04:11 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: jarekczek <at> poczta.onet.pl, 16051 <at> debbugs.gnu.org
>
> > Thanks. I don't see any problems with the new version, but I still
> > can make the frame as small as just the tool bar, or even smaller. It
> > looks like the leave one line/column strategy is being defeated by
> > something. Not that I think it's terribly important to fix this.
>
> You can make the frame as small as the window manager allows it. But
> the root window should now be always at least one line/column large
I'm actually able to make the frame so small that it consists only of
the caption bar. No tool bar, no text area, nothing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16051; Package
emacs.
(Thu, 26 Dec 2013 19:57:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 16051 <at> debbugs.gnu.org (full text, mbox):
> I'm actually able to make the frame so small that it consists only of
> the caption bar. No tool bar, no text area, nothing.
As I mentioned earlier they are clipped by the window manager. You
should see their real size by evaluating something like
(defvar foo nil)
(defun foo ()
(setq foo
(cons
(list (frame-height)
(window-height (frame-root-window))
(window-height (minibuffer-window)))
foo)))
(add-hook 'window-configuration-change-hook 'foo)
with emacs -Q and making the frame as small as you can. From the value
of foo you will see that the frame height can drop to zero while the
window heights remain positive (better seen with split windows now).
Unfortunately, I still get crashes here and elsewhere - mostly related
to minibuffer resizing with a tiny frame.
martin
Reply sent
to
martin rudalics <rudalics <at> gmx.at>:
You have taken responsibility.
(Thu, 25 Dec 2014 10:56:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Drew Adams <drew.adams <at> oracle.com>:
bug acknowledged by developer.
(Thu, 25 Dec 2014 10:56:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 16051-done <at> debbugs.gnu.org (full text, mbox):
>> emacs -Q
>>
>> Grab the right edge of the frame with your mouse and move it left.
>>
>> Move it far enough and the frame turns white and Emacs hangs. You will
>> need to kill it using the task manager.
This should work now. Closing.
Thanks, martin
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 22 Jan 2015 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 103 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.