April 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [proposed PATCH] Re: Customize and `nil' variables 26 years

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> Yikes, this is because the docstring begins with > Hrvoje> "Non-nil", and confuses the Customize guessing code. Set > Hrvoje> (or change) `custom-guess-doc-alist' to work around the > Hrvoje> problem. > > Thanks. In this case, isn't changing `custom-guess-name-alist' > better? No, why? In this case I'll try to convince Kyle to change the docstring. The "non-nil" beginning is unnecessary, really. It could read, just as nicely, as this: Vm Reply Ignored Reply Tos: * [Toggle] off (nil) [State]: this option has not been changed with customize. list of regular expressions that matches * addresses that, if VM finds in a message's Reply-To header, VM should ignore the Reply-To header and not use it for replies. VM -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Ask not for whom the <CONTROL-G> tolls.

1 participants
0 comments

[PATCH maybe] process output uner cygwin 26 years

Andy Piper

Well this fixes the cygwin process output problem, but I have a sneaking suspicion that this might be a bad thing to do in some circumstances. Can someone confirm or deny this? All I've done is used the coding type to dynamically determine the output. andy 1998-04-29 Andy Piper <andyp(a)parallax.co.uk> * code-process.el: dynamically decide process coding type under cygwin. =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/lisp/code-process.el,v retrieving revision 1.3 diff -c -r1.3 code-process.el *** code-process.el 1998/04/11 05:36:53 1.3 --- code-process.el 1998/04/30 02:07:59 *************** *** 77,82 **** --- 77,84 ---- (setq ret (funcall ret 'call-process program)) ) (cond ((consp ret) (car ret)) + ((and (not ret) (eq system-type 'cygwin32)) + 'undecided) ((find-coding-system ret) ret) ) ))))

2 participants
2 comments

Re: [PATCH] font handling for w3 under mswindows 26 years

William M. Perry

Andy Piper <andyp(a)parallax.co.uk> writes: > [1 <text/plain; us-ascii (7bit)>] > Well, this allows w3 to begin displaying a page, but there are then further > unrelated errors. Really someone who understands w3 needs to revisit all of > this under mswindows. > > andy > > 1998-04-29 Andy Piper <andyp(a)parallax.co.uk> > > * font.el (mswindows-font-create-name) > (mswindows-font-create-object): new functions for mswindows type > fonts. The font.el stuff looks fine - it will be in the next beta version of Emacs/W3, but god knows when that will be. -Bill P.

1 participants
0 comments

Re: select-window focus problem [was: Re: minor compile.el bug] 26 years

Hrvoje Niksic

Glynn Clements <glynn(a)sensei.co.uk> writes: > This seems to be the usual `applications should confine themselves to > their own window' rule. From reading the docstring of > focus-follows-mouse, I would guess that it probably needs to be > non-nil for ICCCM-compliant behaviour. > > Switching focus between frames (top-level windows) is something that > is usually considered to be the WMs job, so the question probably > isn't `how should C-x 5 o behave?' but `should it exist at all?'. > > What is the motivation for `other-frame'? Is it an attempt to get > around twm's rigid focus-follows-mouse policy? Probably. Also, it is sometimes useful. I suggest the following: keep the behaviour of `C-x 5 o' independent of focus-follows-mouse (implement it by binding `focus-follows-mouse' to nil within the function), and document that `other-frame' is non-ICCCM compliant. The lucky thing with `C-x 5 o' is that you can't really press it "by mistake", nor can XEmacs activate it for you. If you press that mouthful, you probably know what you want to get, and XEmacs should give it to you. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Satellite Safety Tip #14: If you see a bright streak in the sky coming at you, duck.

1 participants
0 comments

[PATCH] Toolbar fixes 26 years

Kirill M. Katsnelson

I started fixing one bug, and found whole bughillock... All these are reproduced in 20.3 1. (redraw-frame) and C-l (recenter) do not redraw toolbars. 2. Do (set-specifier default-toolbar-height 70 (current-buffer)). Nothing happens. Now press C-M-l twice (assuming there isother buffer). Toolbar is tall, and modeline is beneath bottob edge of the frame. Same for default-toolbar-border-width. 3. Do (set-specifier default-toolbar-visible-p nil (current-buffer)). Not as dramatic as in the above case, but does not regard the new spec unless switched buffers. 4. In the above case, on X only *sometimes* (I can't describe it more precise) the toolbar is not drawn when switching to a buffer with toolbar from the one without. C-l does not help (see 1) 5. MS Windows ignores all 3 specifier changes, in any domain, so there is either a hole or modeline is moved down the window. Patch attached. Kirill 1998-04-29 Kirill M. Katsnelson <kkm(a)kis.ru> * frame.c (change_frame_size_1): Adjust frame row/columns taking real toolbar size into account, not the theoretical one. * toolbar.c (set_frame_toolbar): Removed unused parameter. Return void, not unused int. Logic which checks whether toolbar to be recomputed moved here from macro COMPUTE_TOOLBAR_DATA (r.i.p) (compute_frame_toolbars_data): Removed COMPUTE_TOOLBAR_DATA. It did not work due to a bug, and also did not check whether toolbar size has changed. Compute new character sizes passed to change_frame_size, do not use the old (pre-toolbar-change) ones. (update_frame_toolbars): Honor frame_changed and clear frame bits. (recompute_overlaying_specifier): New helper function, called from default toolbar specifier change handlers. (default_toolbar_specs_changed): Use it. (default_toolbar_size_changed_in_frame): Ditto. (default_toolbar_border_width_changed_in_frame): Ditto. (default_toolbar_visible_p_changed_in_frame): Ditto. (toolbar_geometry_changed_in_window): New handler. The old one, some_windows_value_changed, did not do the trick. (default_toolbar_size_changed_in_window): New handler for default toolbar. (default_toolbar_border_width_changed_in_window): Ditto. (default_toolbar_visible_p_changed_in_window): Ditto. (specifier_vars_of_toolbar): Use one of the above four handlers instead of some_windows_value_changed in toolbar specifiers. Index: src/frame.c =================================================================== RCS file: /var/cvsroot/ntxemacs/src/frame.c,v retrieving revision 1.5 diff --unified=2 -r1.5 frame.c --- src/frame.c 1998/04/27 21:50:10 1.5 +++ src/frame.c 1998/04/29 08:31:58 ＠＠ -2742,21 +2742,32 ＠＠ /* when frame_conversion_internal() calculated the number of rows/cols - in the frame, the toolbar sizes were subtracted out. However, - if the corresponding toolbar is not actually visible in the - selected window, then the extra space needs to be filled in - with rows/cols. */ - if (!FRAME_REAL_TOP_TOOLBAR_VISIBLE (f)) - new_pixheight += FRAME_THEORETICAL_TOP_TOOLBAR_HEIGHT (f) + - 2 * FRAME_THEORETICAL_TOP_TOOLBAR_BORDER_WIDTH (f); - if (!FRAME_REAL_BOTTOM_TOOLBAR_VISIBLE (f)) - new_pixheight += FRAME_THEORETICAL_BOTTOM_TOOLBAR_HEIGHT (f) + - 2 * FRAME_THEORETICAL_BOTTOM_TOOLBAR_BORDER_WIDTH (f); - if (!FRAME_REAL_LEFT_TOOLBAR_VISIBLE (f)) - new_pixwidth += FRAME_THEORETICAL_LEFT_TOOLBAR_WIDTH (f) + - 2 * FRAME_THEORETICAL_LEFT_TOOLBAR_BORDER_WIDTH (f); - if (!FRAME_REAL_RIGHT_TOOLBAR_VISIBLE (f)) - new_pixwidth += FRAME_THEORETICAL_RIGHT_TOOLBAR_WIDTH (f) + - 2 * FRAME_THEORETICAL_RIGHT_TOOLBAR_BORDER_WIDTH (f); + in the frame, the theoretical toolbar sizes were subtracted out. + The caluclations below adjust for real toolbar height/width in + frame, which may be different from frame spec, taking the above + fact into account */ + new_pixheight += + + FRAME_THEORETICAL_TOP_TOOLBAR_HEIGHT (f) + + 2 * FRAME_THEORETICAL_TOP_TOOLBAR_BORDER_WIDTH (f) + - FRAME_REAL_TOP_TOOLBAR_HEIGHT (f) + - 2 * FRAME_REAL_TOP_TOOLBAR_BORDER_WIDTH (f); + + new_pixheight += + + FRAME_THEORETICAL_BOTTOM_TOOLBAR_HEIGHT (f) + + 2 * FRAME_THEORETICAL_BOTTOM_TOOLBAR_BORDER_WIDTH (f) + - FRAME_REAL_BOTTOM_TOOLBAR_HEIGHT (f) + - 2 * FRAME_REAL_BOTTOM_TOOLBAR_BORDER_WIDTH (f); + new_pixwidth += + + FRAME_THEORETICAL_LEFT_TOOLBAR_WIDTH (f) + + 2 * FRAME_THEORETICAL_LEFT_TOOLBAR_BORDER_WIDTH (f) + - FRAME_REAL_LEFT_TOOLBAR_WIDTH (f) + - 2 * FRAME_REAL_LEFT_TOOLBAR_BORDER_WIDTH (f); + + new_pixwidth += + + FRAME_THEORETICAL_RIGHT_TOOLBAR_WIDTH (f) + + 2 * FRAME_THEORETICAL_RIGHT_TOOLBAR_BORDER_WIDTH (f) + - FRAME_REAL_RIGHT_TOOLBAR_WIDTH (f) + - 2 * FRAME_REAL_RIGHT_TOOLBAR_BORDER_WIDTH (f); + /* Adjust the width for the end glyph which may be a different width than the default character width. */ Index: src/toolbar.c =================================================================== RCS file: /var/cvsroot/ntxemacs/src/toolbar.c,v retrieving revision 1.1.1.5 diff --unified=2 -r1.1.1.5 toolbar.c --- src/toolbar.c 1998/04/19 02:07:45 1.1.1.5 +++ src/toolbar.c 1998/04/27 21:17:01 ＠＠ -722,12 +722,16 ＠＠ } -static int -set_frame_toolbar (struct frame *f, enum toolbar_pos pos, int first_time_p) +static void +set_frame_toolbar (struct frame *f, enum toolbar_pos pos) { Lisp_Object toolbar, buttons; struct window *w = XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW (f)); Lisp_Object buffer = w->buffer; - int visible = FRAME_THEORETICAL_TOOLBAR_SIZE (f, pos); + if (!f->toolbar_changed + && !NILP (f->toolbar_data[pos]) + && EQ (FRAME_TOOLBAR_DATA (f, pos)->last_toolbar_buffer, buffer)) + return; + toolbar = w->toolbar[pos]; ＠＠ -742,58 +746,27 ＠＠ } - buttons = visible ? compute_frame_toolbar_buttons (f, pos, toolbar) : Qnil; + buttons = (FRAME_REAL_TOOLBAR_VISIBLE (f, pos) + ? compute_frame_toolbar_buttons (f, pos, toolbar) : Qnil); FRAME_TOOLBAR_DATA (f, pos)->last_toolbar_buffer = buffer; FRAME_TOOLBAR_DATA (f, pos)->toolbar_buttons = buttons; - - return visible; } -#define COMPUTE_TOOLBAR_DATA(position) \ - do \ - { \ - local_toolbar_changed = \ - (f->toolbar_changed \ - || NILP (f->toolbar_data[position]) \ - || (!EQ (FRAME_TOOLBAR_DATA (f, position)->last_toolbar_buffer, \ - XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW (f))->buffer))); \ - \ - toolbar_was_visible = \ - (!NILP (f->toolbar_data[position]) \ - && !NILP (FRAME_TOOLBAR_DATA (f, position)->toolbar_buttons)); \ - toolbar_will_be_visible = toolbar_was_visible; \ - \ - if (local_toolbar_changed) \ - toolbar_will_be_visible = \ - set_frame_toolbar (f, position, first_time_p); \ - \ - toolbar_visibility_changed = \ - (toolbar_was_visible != toolbar_will_be_visible); \ - \ - if (toolbar_visibility_changed) \ - frame_changed_size = 1; \ - } while (0) - static void compute_frame_toolbars_data (struct frame *f, int first_time_p) { - int local_toolbar_changed; - int toolbar_was_visible, toolbar_will_be_visible; - int toolbar_visibility_changed; - int frame_changed_size = 0; - - COMPUTE_TOOLBAR_DATA (TOP_TOOLBAR); - COMPUTE_TOOLBAR_DATA (BOTTOM_TOOLBAR); - COMPUTE_TOOLBAR_DATA (LEFT_TOOLBAR); - COMPUTE_TOOLBAR_DATA (RIGHT_TOOLBAR); - - /* The frame itself doesn't actually change size, but the usable - text area does. All we have to do is call change_frame_size with - the current height and width parameters and it will readjust for - all changes in the toolbars. */ - if (frame_changed_size && !first_time_p) - change_frame_size (f, FRAME_HEIGHT (f), FRAME_WIDTH (f), 0); + set_frame_toolbar (f, TOP_TOOLBAR); + set_frame_toolbar (f, BOTTOM_TOOLBAR); + set_frame_toolbar (f, LEFT_TOOLBAR); + set_frame_toolbar (f, RIGHT_TOOLBAR); + + if (!first_time_p) + { + int height, width; + pixel_to_char_size (f, FRAME_PIXWIDTH(f), FRAME_PIXHEIGHT(f), + &width, &height); + change_frame_size (f, height, width, 0); + } } -#undef COMPUTE_TOOLBAR_DATA void ＠＠ -807,5 +780,5 ＠＠ toolbars need to be recomputed. */ if ((HAS_DEVMETH_P (d, output_frame_toolbars)) - && (f->toolbar_changed + && (f->toolbar_changed || f->frame_changed || f->clear || !EQ (FRAME_TOOLBAR_BUFFER (f, TOP_TOOLBAR), buffer) || !EQ (FRAME_TOOLBAR_BUFFER (f, BOTTOM_TOOLBAR), buffer) ＠＠ -1231,4 +1204,15 ＠＠ +/* + Helper for invalidating the real specifier when default + specifier caching changes +*/ +static void +recompute_overlaying_specifier (Lisp_Object real_one[4]) +{ + enum toolbar_pos pos = decode_toolbar_position (Vdefault_toolbar_position); + Fset_specifier_dirty_flag (real_one[pos]); +} + static void toolbar_specs_changed (Lisp_Object specifier, struct window *w, ＠＠ -1246,7 +1230,5 ＠＠ Lisp_Object oldval) { - enum toolbar_pos pos = decode_toolbar_position (Vdefault_toolbar_position); - - Fset_specifier_dirty_flag (Vtoolbar[pos]); + recompute_overlaying_specifier (Vtoolbar); } ＠＠ -1314,10 +1296,5 ＠＠ Lisp_Object oldval) { - enum toolbar_pos pos = decode_toolbar_position (Vdefault_toolbar_position); - - Fset_specifier_dirty_flag (Vtoolbar_size[pos]); - - /* Let redisplay know that something has possibly changed. */ - MARK_TOOLBAR_CHANGED; + recompute_overlaying_specifier (Vtoolbar_size); } ＠＠ -1327,10 +1304,5 ＠＠ Lisp_Object oldval) { - enum toolbar_pos pos = decode_toolbar_position (Vdefault_toolbar_position); - - Fset_specifier_dirty_flag (Vtoolbar_border_width[pos]); - - /* Let redisplay know that something has possibly changed. */ - MARK_TOOLBAR_CHANGED; + recompute_overlaying_specifier (Vtoolbar_border_width); } ＠＠ -1340,12 +1312,37 ＠＠ Lisp_Object oldval) { - enum toolbar_pos pos = decode_toolbar_position (Vdefault_toolbar_position); - - Fset_specifier_dirty_flag (Vtoolbar_visible_p[pos]); + recompute_overlaying_specifier (Vtoolbar_visible_p); +} - /* Let redisplay know that something has possibly changed. */ +static void +toolbar_geometry_changed_in_window (Lisp_Object specifier, struct window *w, + Lisp_Object oldval) +{ MARK_TOOLBAR_CHANGED; + MARK_WINDOWS_CHANGED (w); } +static void +default_toolbar_size_changed_in_window (Lisp_Object specifier, struct window *w, + Lisp_Object oldval) +{ + recompute_overlaying_specifier (Vtoolbar_size); +} + +static void +default_toolbar_border_width_changed_in_window (Lisp_Object specifier, + struct window *w, + Lisp_Object oldval) +{ + recompute_overlaying_specifier (Vtoolbar_border_width); +} + +static void +default_toolbar_visible_p_changed_in_window (Lisp_Object specifier, + struct window *w, + Lisp_Object oldval) +{ + recompute_overlaying_specifier (Vtoolbar_visible_p); +} static void ＠＠ -1643,5 +1640,5 ＠＠ slot_offset (struct window, default_toolbar_height), - some_window_value_changed, + default_toolbar_size_changed_in_window, slot_offset (struct frame, default_toolbar_height), ＠＠ -1658,5 +1655,5 ＠＠ slot_offset (struct window, default_toolbar_width), - some_window_value_changed, + default_toolbar_size_changed_in_window, slot_offset (struct frame, default_toolbar_width), ＠＠ -1674,5 +1671,5 ＠＠ slot_offset (struct window, toolbar_size[TOP_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_size[TOP_TOOLBAR]), ＠＠ -1690,5 +1687,5 ＠＠ slot_offset (struct window, toolbar_size[BOTTOM_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_size[BOTTOM_TOOLBAR]), ＠＠ -1706,5 +1703,5 ＠＠ slot_offset (struct window, toolbar_size[LEFT_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_size[LEFT_TOOLBAR]), ＠＠ -1722,5 +1719,5 ＠＠ slot_offset (struct window, toolbar_size[RIGHT_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_size[RIGHT_TOOLBAR]), ＠＠ -1787,5 +1784,5 ＠＠ slot_offset (struct window, default_toolbar_border_width), - some_window_value_changed, + default_toolbar_border_width_changed_in_window, slot_offset (struct frame, default_toolbar_border_width), ＠＠ -1803,5 +1800,5 ＠＠ slot_offset (struct window, toolbar_border_width[TOP_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_border_width[TOP_TOOLBAR]), ＠＠ -1819,5 +1816,5 ＠＠ slot_offset (struct window, toolbar_border_width[BOTTOM_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_border_width[BOTTOM_TOOLBAR]), ＠＠ -1835,5 +1832,5 ＠＠ slot_offset (struct window, toolbar_border_width[LEFT_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_border_width[LEFT_TOOLBAR]), ＠＠ -1851,5 +1848,5 ＠＠ slot_offset (struct window, toolbar_border_width[RIGHT_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_border_width[RIGHT_TOOLBAR]), ＠＠ -1899,5 +1896,5 ＠＠ slot_offset (struct window, default_toolbar_visible_p), - some_window_value_changed, + default_toolbar_visible_p_changed_in_window, slot_offset (struct frame, default_toolbar_visible_p), ＠＠ -1915,5 +1912,5 ＠＠ slot_offset (struct window, toolbar_visible_p[TOP_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_visible_p[TOP_TOOLBAR]), ＠＠ -1931,5 +1928,5 ＠＠ slot_offset (struct window, toolbar_visible_p[BOTTOM_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_visible_p[BOTTOM_TOOLBAR]), ＠＠ -1947,5 +1944,5 ＠＠ slot_offset (struct window, toolbar_visible_p[LEFT_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_visible_p[LEFT_TOOLBAR]), ＠＠ -1963,5 +1960,5 ＠＠ slot_offset (struct window, toolbar_visible_p[RIGHT_TOOLBAR]), - some_window_value_changed, + toolbar_geometry_changed_in_window, slot_offset (struct frame, toolbar_visible_p[RIGHT_TOOLBAR]),

2 participants
2 comments

Re: Lstreams, coding and md5 (was: Re: [PATCH] menubar selection in mswindows) 26 years

P. E. Jareth Hein

Hrvoje Niksic <hniksic(a)srce.hr> writes: > "Kirill M. Katsnelson" <kkm(a)kis.ru> writes: > > > | True, but that variable doesn't exists for strings. For instance: > > | > > | (md5 "some Japanese text") > > | > > | This is what the CODING-SYSTEM argument and the guessing code is there > > | for. > > > > This is what undecided streams are for, but the comment in md5 about > > hit and miss is unfortunately rather correct... > > OK, should I default the coding system to `undecided'? BTW, Jareth, > could you please enter this discussion? I still haven't heard back > from you regarding md5.c. I'd like to know that my changes to it are > correct before attempting to work more on that file. Your changes work just fine on my test cases. I don't have a problem with it at all. As for changing the coding system to undecided, what does that buy us? I think we've got enough decision logic in there at the moment to cover the bases. What we really need to do is rethink Mule and coding system functionality completly. > > coding-system-for-write is absolutely no friend of yours, 'cause it > > is constantly nil, and can be nothing else. > > Well, that variable doesn't look very useful then. At the moment, it is next to useless. None of the environments properly set it. Again, serious rethinking is needed. -- Jareth Hein | jareth(a)camelot-soft.com | ハインジェラス Toolsmith & Program lead | http://www.camelot-soft.com | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "Contrary to popular belief, penguins are not the salvation of modern technology. Neither do they throw parties for the urban proletariat."

2 participants
1 comments

Re: Lstreams, coding and md5 (was: Re: [PATCH] menubar selection in mswindows) 26 years

Hrvoje Niksic

"Kirill M. Katsnelson" <kkm(a)kis.ru> writes: > | True, but that variable doesn't exists for strings. For instance: > | > | (md5 "some Japanese text") > | > | This is what the CODING-SYSTEM argument and the guessing code is there > | for. > > This is what undecided streams are for, but the comment in md5 about > hit and miss is unfortunately rather correct... OK, should I default the coding system to `undecided'? BTW, Jareth, could you please enter this discussion? I still haven't heard back from you regarding md5.c. I'd like to know that my changes to it are correct before attempting to work more on that file. > coding-system-for-write is absolutely no friend of yours, 'cause it > is constantly nil, and can be nothing else. Well, that variable doesn't look very useful then. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- I luv the smell of nature in the morning. Smells like manure!

2 participants
1 comments

[PATCH] respect should-use-dialog-box-p in toolbar-compile 26 years

Gunnar Evermann

I hate dialog-boxes!! I guess I'm the only person who compiles with-toolbar and without-dialogbox :-) 1998-04-30 Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> * x-toolbar.el (toolbar-compile): respect should-use-dialog-box-p --- lisp/x-toolbar.el 1998/04/29 23:03:47 1.10 +++ lisp/x-toolbar.el 1998/05/01 01:02:37 ＠＠ -298,12 +298,14 ＠＠ (if toolbar-compile-already-run (compile compile-command) (setq toolbar-compile-already-run t) - (popup-dialog-box - `(,(concat "Compile:\n " compile-command) - ["Compile" (compile compile-command) t] - ["Edit command" compile t] - nil - ["Cancel" (message "Quit") t])))) + (if (should-use-dialog-box-p) + (popup-dialog-box + `(,(concat "Compile:\n " compile-command) + ["Compile" (compile compile-command) t] + ["Edit command" compile t] + nil + ["Cancel" (message "Quit") t])) + (compile compile-command)))) ;; ;; toolbar news variables and defuns

2 participants
1 comments

Re: [Failure] 21.0 "Repartida-pre1" XEmacs Lucid (beta38) on sparc-sun-solaris2.6 26 years

Gunnar Evermann

Georg Nikodym <georgn(a)canada.sun.com> writes: > This looks suspiciously similar to my problems. Have you tried > building without -gung-ho? Yep, just finished. indeed it works! But I still think we should try to track down the problem.

1 participants
0 comments

Re: select-window focus problem [was: Re: minor compile.el bug] 26 years

Greg Klanderman

Hrvoje> This is true, but, as I said before, I am very satisfied with Greg's Hrvoje> latest patch, except for the `C-x 5 o' part. Never fear, I haven't forgotten this. I'll get a patch out today or tomorrow, along with some documentation updates.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta April 1998