GNU bug report logs - #11138
23.3; on Windows, message-box does not display line breaks in the message

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11138 in the body.
You can then email your comments to 11138 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Dino Chiesa" <dpchiesa <at> hotmail.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 07:53:40 -0700

[Message part 1 (text/plain, inline)]

When I run this code: 

  (message-box (concat "First line in a long-ish message.\n"
                     "This is line number 2 in the message."))

The message gets displayed in one very wide dialog box. 
I would expect it to break at the \n.  Line breaks work, apparently,
on Linux, so I am told. But I have confirmed with others that they
see this anomalous message-box behavior on Windows . 




In GNU Emacs 23.3.1 (i386-mingw-nt6.1.7601)
of 2011-03-10 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.5) --no-opt --cflags -Ic:/imagesupport/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Dired by ext

Minor modes in effect:
  show-paren-mode: t
  recentf-mode: t
  shell-dirtrack-mode: t
  yas/global-mode: t
  yas/minor-mode: t
  global-hl-line-mode: t
  hl-line-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
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<C-left> u i - l i g h t n e s s <escape> d <C-left> 
<C-left> <left> <escape> SPC <C-left> <left> C-w C-y 
C-y <escape> b s t a r t <escape> d C-b C-b C-b C-b 
C-b C-b <escape> SPC <escape> b C-b C-w C-y C-t C-x 
u <escape> SPC <escape> C-b C-w C-y C-y <escape> b 
h u m a n i t y <escape> d C-n C-n C-n C-n C-x C-s 
<up> <up> <up> <up> <C-right> <C-right> <down> <C-right> 
<C-right> <C-right> <C-right> <C-right> <C-right> <C-right> 
<C-right> <C-right> <C-right> <C-right> <C-right> <C-right> 
<C-right> <C-left> <left> <backspace> 1 <down> <down> 
<down> $ 0 C-x C-s <help-echo> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> C-e <down> <C-right> 
<C-right> <C-right> <right> u i . <escape> b <backspace> 
- C-x C-s C-x C-f <backspace> <return> g s C-p C-p 
C-p C-n C-n C-n u C-p C-p <help-echo> <down> f C-e 
<down> <down> <down> <down> <down> <down> <down> <up> 
C-e <down> C-e <up> C-e <left> <C-left> <C-left> <C-left> 
<left> <backspace> <backspace> <down> C-x C-s <left> 
<down> C-d <up> <up> <up> <up> <up> C-e <left> <left> 
<down> <down> <down> <down> <down> C-x C-s C-x C-f 
<backspace> <return> C-p C-p C-p C-p C-p C-p f C-n 
C-n C-n C-n C-e C-b C-b C-d C-n C-x C-s C-x k <return> 
C-n f C-n C-n C-e C-n C-n C-p C-p C-p C-n C-n C-n C-n 
C-n C-x k <return> C-n C-n C-n C-n C-n C-n C-n C-p 
C-p C-x b t h e <tab> C-g C-x C-f <escape> <backspace> 
<escape> <backspace> <escape> <backspace> t h e s <tab> 
e l <tab> <return> <escape> SPC <escape> > C-w C-y 
C-x k <return> y e s <return> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <escape> x r e 
p o r t - e m <tab> <return>

Recent messages:
Directory has changed on disk; type g to update Dired
Saving file c:/Users/Dino/elisp/snippets/html-mode/script-jquery-ui...
Wrote c:/Users/Dino/elisp/snippets/html-mode/script-jquery-ui
Saving file c:/Users/Dino/elisp/snippets/html-mode/script-jquery-ui...
Wrote c:/Users/Dino/elisp/snippets/html-mode/script-jquery-ui
Saving file c:/Users/Dino/elisp/snippets/html-mode/link...
Wrote c:/Users/Dino/elisp/snippets/html-mode/link
Quit
Mark set [2 times]
Auto-saving...

Load-path shadows:
/users/dino/elisp/refill hides c:/emacs/lisp/textmodes/refill

Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailabbrev nnheader
gnus-util netrc gmm-utils mailheader canlock sha1 hex-util hashcash
emacsbug sgml-mode holidays hol-loaddefs cal-menu calendar cal-loaddefs
ebnf2ps ps-print ps-def lpr epg-config ansi-color goto-addr nxml-uchnm
rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri
rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok
vbs-mode browse-url mail-utils info find-func dabbrev smart-op
flymake-for-jslint-for-wsh autopair js json etags imenu dired-aux tabify
compare-w rfringe paren csharp-mode cc-langs cc-mode cc-fonts cc-menus
cc-cmds align mule-util pp grep time-stamp multi-isearch conf-mode
newcomment cl-specs edebug url-cache format-spec url-http tls mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums time-date url-gw url-auth url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-util url-parse url-vars mm-util mail-prsvr mailcap autorevert server
thesaurus recentf tree-widget flyphpcs flymake-cursor byte-opt warnings
bytecomp byte-compile flymake compile synonyms-autoloads package
cperl-mode jsshell-bundle jsshell shell comint ring hideshow cc-styles
cc-align cc-engine cc-vars cc-defs dired regexp-opt defaultcontent
thingatpt yasnippet dropdown-list derived easy-mmode help-mode view
assoc cl cl-19 tfs skeleton edmacro kmacro httpget hl-line advice
help-fns advice-preload cus-edit easymenu cus-start cus-load wid-edit
tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table
ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
loaddefs button minibuffer faces cus-face files text-properties overlay
md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

[Message part 2 (text/html, inline)]

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Dino Chiesa'" <dpchiesa <at> hotmail.com>, <11138 <at> debbugs.gnu.org>
Subject: RE: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 08:26:50 -0700

> (message-box (concat "First line in a long-ish message.\n"
>                      "This is line number 2 in the message."))
>
> The message gets displayed in one very wide dialog box. 
> I would expect it to break at the \n.  Line breaks work, apparently,
> on Linux, so I am told. But I have confirmed with others that they
> see this anomalous message-box behavior on Windows . 

Yes, I can confirm that this is broken on MS Windows, and has been so back
through at least Emacs 20.  The newline char is displayed (in emacs -Q, at
least) as an empty box.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
Subject: Re: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 21:06:27 +0300

severity 11138 wishlist
stop

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Sat, 31 Mar 2012 08:26:50 -0700
> 
> > (message-box (concat "First line in a long-ish message.\n"
> >                      "This is line number 2 in the message."))
> >
> > The message gets displayed in one very wide dialog box. 
> > I would expect it to break at the \n.  Line breaks work, apparently,
> > on Linux, so I am told. But I have confirmed with others that they
> > see this anomalous message-box behavior on Windows . 
> 
> Yes, I can confirm that this is broken on MS Windows, and has been so back
> through at least Emacs 20.  The newline char is displayed (in emacs -Q, at
> least) as an empty box.

The Windows port doesn't really have an implementation of a message
box, it just pops up a menu.  And in a menu, each item is one line.

Patches to implement a true message box are welcome.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
Subject: RE: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 11:14:34 -0700

> The Windows port doesn't really have an implementation of a message
> box, it just pops up a menu.  And in a menu, each item is one line.
> Patches to implement a true message box are welcome.

I see.  I don't have a true message-box implementation, but wouldn't it be
possible to just use multiple menu lines for this?  The current menu line is not
selectable anyway, AFAICT.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
Subject: Re: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 21:30:19 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <dpchiesa <at> hotmail.com>, <11138 <at> debbugs.gnu.org>
> Date: Sat, 31 Mar 2012 11:14:34 -0700
> 
> > The Windows port doesn't really have an implementation of a message
> > box, it just pops up a menu.  And in a menu, each item is one line.
> > Patches to implement a true message box are welcome.
> 
> I see.  I don't have a true message-box implementation, but wouldn't it be
> possible to just use multiple menu lines for this?

Not if we reuse the normal menu-creation code, I would think.  But the
truth is that I simply don't know enough about this to say something
intelligent.  Again, if this is possible, patches are welcome.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
Subject: RE: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 11:37:35 -0700

> > I see.  I don't have a true message-box implementation, but 
> > wouldn't it be possible to just use multiple menu lines for this?
> 
> Not if we reuse the normal menu-creation code, I would think.  But the
> truth is that I simply don't know enough about this to say something
> intelligent.  Again, if this is possible, patches are welcome.

It certainly would be possible (trivial) in Lisp: just split the string at each
\n and create a separate (non-selectable) menu item for each.

But this code is in C for some reason, so I'm afraid someone else will need to
come up with the requisite patch.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
Subject: Re: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 21:58:59 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <dpchiesa <at> hotmail.com>, <11138 <at> debbugs.gnu.org>
> Date: Sat, 31 Mar 2012 11:37:35 -0700
> 
> > > I see.  I don't have a true message-box implementation, but 
> > > wouldn't it be possible to just use multiple menu lines for this?
> > 
> > Not if we reuse the normal menu-creation code, I would think.  But the
> > truth is that I simply don't know enough about this to say something
> > intelligent.  Again, if this is possible, patches are welcome.
> 
> It certainly would be possible (trivial) in Lisp: just split the string at each
> \n and create a separate (non-selectable) menu item for each.

But the same code is used for a real menu, where we don't want to
create two separate menu items for a line with embedded newline.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11138 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>,
	dpchiesa <at> hotmail.com
Subject: Re: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 15:10:00 -0400

Maybe the window-box could be re-implemented as a kind of tooltip-frame.


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
Subject: RE: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 12:19:03 -0700

> > > > wouldn't it be possible to just use multiple menu lines...
> > > 
> > > Not if we reuse the normal menu-creation code...
> > 
> > It certainly would be possible (trivial) in Lisp: just 
> > split the string at each \n and create a separate
> > (non-selectable) menu item for each.
> 
> But the same code is used for a real menu, where we don't want to
> create two separate menu items for a line with embedded newline.

Sorry, I don't follow you - don't know what you mean.

What I'm saying is that (in Lisp, at least) it would be possible to create a
menu here that had one non-selectable menu item (line) for each line of the
multiline input (as split by \n), plus a selectable final line for the `OK'
action.

Not sure what you intend by a "real" menu, but it is certainly possible (in Lisp
at least) to create a menu with N non-selectable menu items followed by one
selectable item.  Such a menu is as real as any other I've come across. 

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
	"'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
Subject: RE: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 12:19:36 -0700

> Maybe the window-box could be re-implemented as a kind of 
> tooltip-frame.

That sounds good too.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
Subject: Re: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 22:26:29 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <dpchiesa <at> hotmail.com>, <11138 <at> debbugs.gnu.org>
> Date: Sat, 31 Mar 2012 12:19:03 -0700
> 
> > > > > wouldn't it be possible to just use multiple menu lines...
> > > > 
> > > > Not if we reuse the normal menu-creation code...
> > > 
> > > It certainly would be possible (trivial) in Lisp: just 
> > > split the string at each \n and create a separate
> > > (non-selectable) menu item for each.
> > 
> > But the same code is used for a real menu, where we don't want to
> > create two separate menu items for a line with embedded newline.
> 
> Sorry, I don't follow you - don't know what you mean.

What I mean is that message-box on Windows eventually calls
x-popup-menu.  So whatever you do for multi-line messages inside
x-popup-menu will also affect x-popup-menu calls that want to display
menus as well.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
Subject: RE: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sat, 31 Mar 2012 14:29:31 -0700

> What I mean is that message-box on Windows eventually calls
> x-popup-menu.  So whatever you do for multi-line messages inside
> x-popup-menu will also affect x-popup-menu calls that want to display
> menus as well.

I would not suggest changing `x-popup-menu'.  My suggestion was to have
`message-box' call `x-popup-menu' (or other code to create the menu) passing
multiple menu lines, all of which, except the last one ("OK"), are
non-selectable.

The multiple lines come from splitting, at each \n, the result of applying
FORMAT-STRING to ARGS.

(BTW, I do not have the Emacs 24 C code, but in Emacs 23.3 it looks like
`message-box' calls `x-popup-dialog', not `x-popup-menu'.  Same idea, anyway.)

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11138 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>,
	dpchiesa <at> hotmail.com
Subject: Re: bug#11138: 23.3; on Windows, message-box does not display line
	breaks in the message
Date: Sat, 31 Mar 2012 23:36:01 +0200

On Sat, Mar 31, 2012 at 20:06, Eli Zaretskii <eliz <at> gnu.org> wrote:

> The Windows port doesn't really have an implementation of a message
> box, it just pops up a menu.  And in a menu, each item is one line.

And some checking for excessive length is missing, BTW:

emacs -Q
M-: (message-box (make-string (/ most-positive-fixnum 2) ?a) "") <RETURN>

Program received signal SIGSEGV, Segmentation fault.
0x754f8dd2 in strcat () from C:\Windows\syswow64\msvcrt.dll
(gdb) bt
#0  0x754f8dd2 in strcat () from C:\Windows\syswow64\msvcrt.dll
#1  0x64c9000c in ?? ()
#2  0x012b68f4 in fill_in_menu (menu=0x37640627, wv=0x9f1740) at w32menu.c:1564
#3  0x012b5673 in w32_menu_show (f=0x3a22e00, x=340, y=304,
for_click=0, keymaps=0, title=55546785, error=0x88f290) at
w32menu.c:867
#4  0x0129e565 in Fx_popup_menu (position=59320198, menu=59320214) at
menu.c:1323
#5  0x012b3782 in Fx_popup_dialog (position=54708274,
contents=59320166, header=54708274) at w32menu.c:206
#6  0x011061d6 in Fmessage_box (nargs=2, args=0x88f3a0) at editfns.c:3420
#7  0x01034c46 in eval_sub (form=59319710) at eval.c:2322
#8  0x01034572 in Feval (form=59319710, lexical=54708250) at eval.c:2204
#9  0x01036ce9 in Ffuncall (nargs=3, args=0x88f570) at eval.c:3005
#10 0x010dec96 in exec_byte_code (bytestr=20473265, vector=20473381,
maxdepth=20, args_template=54708250, nargs=0, args=0x0) at
bytecode.c:785
#11 0x01037b9c in funcall_lambda (fun=20473213, nargs=2,
arg_vector=0x342c81a) at eval.c:3233
#12 0x01037082 in Ffuncall (nargs=3, args=0x88f870) at eval.c:3051
#13 0x01035c57 in Fapply (nargs=2, args=0x88f904) at eval.c:2507
#14 0x010361a4 in apply1 (fn=55149410, arg=59320094) at eval.c:2745
#15 0x010e1a41 in Fcall_interactively (function=55149410,
record_flag=54708250, keys=54729477) at callint.c:377
#16 0x01036d57 in Ffuncall (nargs=4, args=0x88fb40) at eval.c:3009
#17 0x01036273 in call3 (fn=54828442, arg1=55149410, arg2=54708250,
arg3=54708250) at eval.c:2802
#18 0x0101f9f4 in Fcommand_execute (cmd=55149410,
record_flag=54708250, keys=54708250, special=54708250) at
keyboard.c:10330
#19 0x0100658f in command_loop_1 () at keyboard.c:1572
#20 0x01032c4f in internal_condition_case (bfun=0x100569b
<command_loop_1>, handlers=54766026, hfun=0x1004eba <cmd_error>) at
eval.c:1515
#21 0x010052f7 in command_loop_2 (ignore=54708250) at keyboard.c:1160
#22 0x01032672 in internal_catch (tag=54764026, func=0x10052d3
<command_loop_2>, arg=54708250) at eval.c:1272
#23 0x010052b3 in command_loop () at keyboard.c:1139
#24 0x0100488f in recursive_edit_1 () at keyboard.c:759
#25 0x01004baa in Frecursive_edit () at keyboard.c:823
#26 0x010028b5 in main (argc=2, argv=0xbe15f8) at emacs.c:1715

Lisp Backtrace:
"message-box" (0x88f3a0)
"eval" (0x88f574)
"eval-expression" (0x88f874)
"call-interactively" (0x88fb44)
(gdb)

    Juanma

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
Subject: Re: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sun, 01 Apr 2012 06:00:36 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <dpchiesa <at> hotmail.com>, <11138 <at> debbugs.gnu.org>
> Date: Sat, 31 Mar 2012 14:29:31 -0700
> 
> (BTW, I do not have the Emacs 24 C code, but in Emacs 23.3 it looks like
> `message-box' calls `x-popup-dialog', not `x-popup-menu'.  Same idea, anyway.)

If you look at the sources, you will see that x-popup-dialog calls
x-popup-menu internally.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 11138 <at> debbugs.gnu.org, drew.adams <at> oracle.com, dpchiesa <at> hotmail.com
Subject: Re: bug#11138: 23.3;
	on Windows, message-box does not display line breaks in the message
Date: Sun, 01 Apr 2012 19:58:43 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sat, 31 Mar 2012 23:36:01 +0200
> Cc: Drew Adams <drew.adams <at> oracle.com>, 11138 <at> debbugs.gnu.org, dpchiesa <at> hotmail.com
> 
> On Sat, Mar 31, 2012 at 20:06, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > The Windows port doesn't really have an implementation of a message
> > box, it just pops up a menu.  And in a menu, each item is one line.
> 
> And some checking for excessive length is missing, BTW:
> 
> emacs -Q
> M-: (message-box (make-string (/ most-positive-fixnum 2) ?a) "") <RETURN>
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x754f8dd2 in strcat () from C:\Windows\syswow64\msvcrt.dll
> (gdb) bt
> #0  0x754f8dd2 in strcat () from C:\Windows\syswow64\msvcrt.dll
> #1  0x64c9000c in ?? ()
> #2  0x012b68f4 in fill_in_menu (menu=0x37640627, wv=0x9f1740) at w32menu.c:1564

This crash should be fixed in trunk revision 107723.  Now even your
crazy test case doesn't crash, just says that it ran out of memory
after a while (kids, don't try that at home).

Btw, it looks like MS-Windows menus cannot have strings longer than
64K, although I cannot find this documented anywhere.

Previous Next

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