April 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Richard Ketchersid

The latest couple of CVS versions of XEmacs 21.2 (beta32) seem to have a problem with the pop-ups. The problem is that a box will pop up with a question like "Do you want to save such an such ?" when you press "%_yes" (which is what the button currently shows ?) all that happens is: (1) The pop-up goes away. (2) XEmacs beeps. (3) A message appears in the minibuffer requesting that you respond to the now non existent pop-up. (4) XEmacs now just beeps at you, you can't type, quit, anything. I've tried using Motif and Athena dialogs/widgets with the same results so this is not a Motif/Athena problem.

3 participants
2 comments

Re: 21.2.32 crash in scrollbars 24 years, 7 months

Raymond Toy

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> I had a long replz to this but XEmacs crashed :-( Jan> Raymond Toy <toy(a)rtp.ericsson.se> writes: >> System: Solaris 2.7, gcc 2.7.2.2, full tarball of 21.2.32. >> >> In a VM window, I pressed C-g to get XEmacs to stop whatever it was >> doing. The window refreshed, and, immediately after, I clicked in the >> scrollbar area just below the scrollbar but above the bottom arrow. >> XEmacs crashed then. Jan> Great so now we know what can cause it... >> #3 real_window (mir=0x0, no_abort=1) at window.c:489 >> #4 0xce764 in x_update_vertical_scrollbar_callback (widget=0xd9b200, id=65568, >> client_data=0xffbed948) at scrollbar-x.c:409 Jan> D*mn.. I have had a patch for this for 3 weeks but forgot to apply it. Jan> I am at my parents now and don't have a decent internet conenction. Jan> Maybe Monday.. That's fine. Unless your patch applies to stock 21.2.32, I'll have to wait for the next beta to do anything about it. I'll just have to stop doing these things until then. :-) Ray

1 participants
0 comments

Cygwin/Mingw and configure 24 years, 7 months

Craig Lanning

I am trying to improve support for mingw (and, as a side effect, cygwin) in the configure script. Specifically, there are some #define's that are needed by the older version of cygwin, but are included in the newer snapshots and upcoming net release. Currently, these defines are in s/cygwin32.h and s/mingw32.h as #ifndef xxx #define xxx yyy #endif The problem with this is that the s/cygwin32.h or s/mingw32.h file gets included before the system headers. This causes a lot of "xxx being redefined ... previously defined here" messages. Below is a preliminary patch to configure.in and src/config.h.in to check for one of these defines and add it to config.h if it is not defined int the system headers. I am interested to know if anyone knows a better way to check for this or if there is a better position in the configuration process to do this checking. Craig ----- Index: configure.in =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/configure.in,v retrieving revision 1.111.2.97 diff -u -r1.111.2.97 configure.in --- configure.in 2000/04/03 06:28:54 1.111.2.97 +++ configure.in 2000/04/06 14:56:32 ＠＠ -2798,6 +2798,19 ＠＠ test "$opsys" = "hpux9-shr" && opsysfile="s/hpux9shxr4.h" esac +if test "$with_msw" = "yes"; then + AC_CHECKING(MS-Windows specific DEFINEs) + AC_CHECKING(for WM_MOUSEWHEEL) + AC_TRY_RUN([#include <windows.h> + int main() { +#ifdef WM_MOUSEWHEEL + return 1; +#else + return 0; +#endif +}],[AC_DEFINE(WM_MOUSEWHEEL,0x20A)]) +fi + dnl Enable or disable proper handling of WM_COMMAND AC_CHECKING(for WM_COMMAND option); dnl if test "$with_wmcommand" = "yes"; then cvs server: Diffing src Index: src/config.h.in =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/config.h.in,v retrieving revision 1.49.2.34 diff -u -r1.49.2.34 config.h.in --- config.h.in 2000/03/27 19:54:49 1.49.2.34 +++ config.h.in 2000/04/06 14:56:42 ＠＠ -162,6 +162,19 ＠＠ /* Compile in support for MS windows? */ #undef HAVE_MS_WINDOWS +/* defines that are needed by older versions of the cygwin/mingw system */ +#undef SPI_GETWHEELSCROLLLINES +#undef WHEEL_PAGESCROLL +#undef WHEEL_DELTA +#undef WM_MOUSEWHEEL +#undef TCS_BOTTOM +#undef TCS_VERTICAL +#undef PHYSICALWIDTH +#undef PHYSICALHEIGHT +#undef PHYSICALOFFSETX +#undef PHYSICALOFFSETY +#undef PBS_SMOOTH + /* special cygwin process handling? */ #undef HAVE_MSG_SELECT

4 participants
14 comments

Re: Custom migration to ~/.xemacs/options.el 24 years, 7 months

Hrvoje Niksic

Colin Rafferty <colin(a)xemacs.org> writes: > However, giving it a little thought, I think the idea was that we > were trying to stop having XEmacs modify ~/.emacs. ~/.emacs is for > the user to fool with, and ~/.custom.emacs is for XEmacs to fool > with. > > In general, I think this is still the right idea. It was the right idea, and that's what we're trying to achieve now. The part that was wrong was the use of `custom-file' for disabled commands as well as Custom. Either that file should have remained reserved for Custom's private use, or the concept of automatically generated startup Lisp should have been expanded to cover both Custom and disabled commands. This is not a big problem; it can be worked around. I just quoted the ChangeLog to show that the use of custom-file for disabled commands was added as an after-thought.

1 participants
0 comments

Re: Custom migration to ~/.xemacs/options.el 24 years, 7 months

Colin Rafferty

Hrvoje Niksic writes: > Ironically, it doesn't pick one thing, and that one is not really > Custom-related: > (put 'narrow-to-page 'disabled nil) > I have no idea how that leaked into my `.xemacs-custom', but I'm sure > I didn't put it there. Oh, now I see: > 1997-09-18 Colin Rafferty <craffert(a)ml.com> > * prim/novice.el (disable-command): Made it modify > `custom-file' instead of `user-init-file'. > Stop multiple disable/enable-command calls from adding extra > newlines. > Not that I blame Colin -- the patch must have made sense at the time. If I were still at ml.com, I would have the original patch email, and I could read the text that was above the ChangeLog and patch. However, giving it a little thought, I think the idea was that we were trying to stop having XEmacs modify ~/.emacs. ~/.emacs is for the user to fool with, and ~/.custom.emacs is for XEmacs to fool with. In general, I think this is still the right idea. -- Colin

1 participants
0 comments

Re: Custom migration to ~/.xemacs/options.el 24 years, 7 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > > > What's a politically correct (and preferably simple) to determine the > > set/region of forms in ~/.emacs under the control of customize? Can I > > search for (custom-load-themes ...) or (custom-set-variables ...) and > > take the region from there to the end of the file? Or can I take all > > forms starting with (custom-... ...). Or what? > > (defun migrate-custom (oldfile newfile) > (require 'cus-edit) > (let ((custom-file oldfile)) > (mapc 'custom-save-delete > '(custom-load-themes custom-reset-variables > custom-set-variables > custom-set-faces > custom-reset-faces))) > (setq custom-file newfile) > (custom-save-all)) I'm impressed. Ironically, it doesn't pick one thing, and that one is not really Custom-related: (put 'narrow-to-page 'disabled nil) I have no idea how that leaked into my `.xemacs-custom', but I'm sure I didn't put it there. Oh, now I see: (defun enable-command (command) "Allow COMMAND to be executed without special confirmation from now on. The user's `custom-file' is altered so that this will apply to future sessions." ... (defun disable-command (command) "Require special confirmation to execute COMMAND from now on. The user's `custom-file' is altered so that this will apply to future sessions." ... And, if you look real hard: 1997-09-18 Colin Rafferty <craffert(a)ml.com> * prim/novice.el (disable-command): Made it modify `custom-file' instead of `user-init-file'. Stop multiple disable/enable-command calls from adding extra newlines. Not that I blame Colin -- the patch must have made sense at the time.

1 participants
0 comments

Re: Custom migration to ~/.xemacs/options.el 24 years, 7 months

Jan Vroonhof

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > What's a politically correct (and preferably simple) to determine the > set/region of forms in ~/.emacs under the control of customize? Can I > search for (custom-load-themes ...) or (custom-set-variables ...) and > take the region from there to the end of the file? Or can I take all > forms starting with (custom-... ...). Or what? (defun migrate-custom (oldfile newfile) (require 'cus-edit) (let ((custom-file oldfile)) (mapc 'custom-save-delete '(custom-load-themes custom-reset-variables custom-set-variables custom-set-faces custom-reset-faces))) (setq custom-file newfile) (custom-save-all))

1 participants
0 comments

Re: Custom migration to ~/.xemacs/options.el 24 years, 7 months

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Hrvoje> The way Custom does it is to read the top-level forms until > Hrvoje> the form whose car is the required symbol is found. Look at > Hrvoje> `custom-save-delete' for an example of that. Unless I'm > Hrvoje> missing something, it's very easy to implement. > > The problem is: how do I determine the set of all "required > symbols"? It seems to be hardwired into cus-edit.el. Well, you could look into what's hard-wired into cus-edit and use that as your set. :-) Your code needn't support all the future versions of Custom, because those will use other init files anyway.

1 participants
0 comments

Re: Custom migration to ~/.xemacs/options.el 24 years, 7 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> So, customize puts its variables into ~/.emacs according to a >> heuristic I haven't groked yet fully. (Needless to say, this was a >> bad idea ...) Hrvoje> IIRC, this was not so under original Per's design. Stallman insisted Hrvoje> on using ~/.emacs. That's what I meant by "needless to say" :-) >> What's a politically correct (and preferably simple) to determine >> the set/region of forms in ~/.emacs under the control of customize? >> Can I search for (custom-load-themes ...) or (custom-set-variables >> ...) and take the region from there to the end of the file? Or can >> I take all forms starting with (custom-... ...). Or what? Hrvoje> I think you should do it the way Customize does it. This is virtually Hrvoje> guaranteed to be correct, because then if somebody uses a weird .emacs Hrvoje> format, Customize will not work with it either. Hrvoje> The way Custom does it is to read the top-level forms until the form Hrvoje> whose car is the required symbol is found. Look at Hrvoje> `custom-save-delete' for an example of that. Unless I'm missing Hrvoje> something, it's very easy to implement. The problem is: how do I determine the set of all "required symbols"? It seems to be hardwired into cus-edit.el. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

progress gauge oddity 24 years, 7 months

Yoshiki Hayashi

xemacs -vanilla and evaluate following form. New frame should have progress gaguge, but it doesn't. (progn (lprogress-display 'test "Test" 1) (make-frame) (delete-frame) (lprogress-display 'test "Test" 2)) -- Yoshiki Hayashi

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 2000