March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: the role of Custom in XEmacs (setting != saving) 25 years, 8 months

Jan Vroonhof

Didier Verna <verna(a)inf.enst.fr> writes: > information with what we have now ? For instance, it might be > interesting to have more details on the origin of the saved value: My themes stuff has to do that anyway. There isn't a real reason you could consider, f.e., your Xresources as a special king of "theme". We can discuss this in Tsukuba. > user init file (I consider it to be a saving), user option file, X > resource ... or even 'variable-type. It implicitely states that it > is for custom, and hides the fact that any other package or variable > modification method could use it. Ok. You have a point there. I think this can be solved with a little marketing :-). > Personaly, I'm not very much for set-variable acting like custom. > It's important to have a method for setting a variable that you KNOW > you won't want to save. However, custom is missing a set-variable > equivalent, that wouldn't need to display a heavy graphical > interface. Indeed. However that's simply because nobody has written it yet. A first implementation could be a trivial cut&paste job from set-variable. > Footnotes: > [1] It's completely off-topic, but in France, there's a debate on > feminization of several words describing professions for instance. > Historically, some professions were reserved for men which explains why > nowadays we lack many feminin equivalents. This is solved in Holland (in job advertisements etc) by appending a (v/m) to the name, for female/male. So have. "We are looking for a painter(f/m)". It works good enough for the discussion to have more or less died down. However you can not use that solution since it comes from Holland :-). The problem is really worse with "secretary" as there the male and female forms mean two different professions nowadays! secretaresse (female form) = typing, answering telephone etc.. As in "I'll ask my secretary to make an appointment. sectretaris (male form) = Managing assistant As in "Secretary of State". So now you can have a male secretaresse for a female secretaris! Jan

1 participants
0 comments

Re: the role of Custom in XEmacs (setting != saving) 25 years, 8 months

Didier Verna

Jan Vroonhof writes: >> * How can we figure out when and how a variable has been modified >> (different from the default value in its declaration). Maybe properties >> saying "value from an init file", "value from X resources", "value from >> user input during an xemacs session" etc. Jan> That's exactly what the customize properties are: Jan> 'saved-value = "value from an init file" 'customized-value = "value from Jan> user input during an xemacs session" >> * Provide a SINGLE XEmacs generic way of saving stuff if modified. Jan> The custom save variables stuff is fine. Indeed, Custom does already most of the job and has become THE prefered way to define a variable as a user option. I'm not claiming that we should undo this obviously. But do we have enough information with what we have now ? For instance, it might be interesting to have more details on the origin of the saved value: user init file (I consider it to be a saving), user option file, X resource ... >> Custom or any other setting method shouldn't have anything to do with this. Jan> Custom is not a setting method. It is _also_ a setting method. Fair enough. It's a lack of precision from my part. I agree that Custom is first a method for saving options, and additionally has a nice graphical interface for setting those options. Here I was talking about Custom as the interface part. >> * If we have a powerfull setting method like Custom which needs type >> information, very well. But this information shouldn't be regarded as a >> 'custom-type. It's really the 'type of the variable. We can imagine that >> `set-variable' could also use this information for completion purpose or >> whatever. I repeat, _it has nothing to do with the method for setting_. >> It's a global information, potentially usefull for different things. Jan> Indeed. So who cares that the property is called. custom-type is Jan> perfectly allright. Yes, who cares how it's called. However, the fact that it's called 'custom-type is just a symptom of the fact that when custom was more or less implicitely designated as the new standard way to declare user options, some important issues, like how it would interact with existing stuff were not raised enough. Calling it 'custom-type says more than calling it 'option-type or even 'variable-type. It implicitely states that it is for custom, and hides the fact that any other package or variable modification method could use it. Don't think I'm of bad faith. I usually attach a great importance to words and I'm convinced they carry more meaning than what seems at a first glance.[1] Jan> There is no reason set-variable shouldn't use it (and even update Jan> 'customized-value too??). All right, we're beginning to get at it! That's exactly the kind of question I had hoped to raise with my message. But this question is far from being anecdotic IMHO. How is it that it comes up only now ? I did the port of most of the options menu to custom a long time ago. However, this question didn't came to my mind at that time, and I think it should have. You ask why set-variable couldn't even update 'customized-value and I think that is a very important question. Do we want set-variable to act as custom or do we want it to do something else ? If we want it to act like custom, we're saying something important: it can not only set the variable, but tell XEmacs to save it. That's why I was saying that it's important to make the distinction between setting and saving. Only after realizing that I began to understand that set-variable is actually part of the problem we're discussing. Personaly, I'm not very much for set-variable acting like custom. It's important to have a method for setting a variable that you KNOW you won't want to save. However, custom is missing a set-variable equivalent, that wouldn't need to display a heavy graphical interface. Jan> I think you just missed what custom is all about. Customize is a saving Jan> and typing method. I didn't miss it. I hope I'm clearer now. Footnotes: [1] It's completely off-topic, but in France, there's a debate on feminization of several words describing professions for instance. Historically, some professions were reserved for men which explains why nowadays we lack many feminin equivalents. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
1 comments

Re: the role of Custom in XEmacs (setting != saving) 25 years, 8 months

Didier Verna

Per Abrahamsen writes: Per> Basically everything you discuss is already implemented, and all the Per> proper distinctions are already in place. No they aren't. Indeed Custom already implements most of the stuff and in a pretty good manner. But as soon as Custom becomes the de-facto standard for saving options, it also _forces_ you to use its own setting method (the customization buffers) if you want your stuff to be saved. That's why I consider that the proper distinctions are not in place. Those distinctions won't be in place until we have figured out all the ways a user option could possibly be set, modified, whatever, and whether these modifications should have an impact on the value Custom will save. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
1 comments

Re: BUG REPORT: mule-packages sometimes incorrectly used by latin-1 xemacs 25 years, 8 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> If I have a directory structure like this: Martin> /foo/pkgs/xemacs-packages Martin> /foo/pkgs/mule-packages Martin> and I Martin> configure --package-path=~/.xemacs:/foo/pkgs/ --without-mule ... Martin> Then the resulting xemacs, when run in place, has a load-path that Martin> includes subdirectories of /foo/pkgs/mule-packages. And this warning Martin> appears: Martin> (1) (warning/warning) Autoload error in: /usr/users/martin/x/pkgs/mule-packages/lisp/skk/auto-autoloads: Martin> Cannot open load file: mule Martin> I think I'm using the package system the way it was designed, But you're not. >From the Info docs: > It is possible to specify at configure-time the location of the > various package hierarchies with the `--package-path' option to > configure. So the components of --package-path are all package hierarchies. The docs then go on to explain that package hierarchies are things with lisp, etc, info, and lib-src subdirectories. So, the correct setting would be (note also the separation between early and late): configure --package-path=~/.xemacs::/foo/pkgs/mule-packages:/foo/pkgs/xemacs-packages ... -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: BUG REPORT: redisplay assertion failure 25 years, 8 months

Gunnar Evermann

Martin Buchholz <martin(a)xemacs.org> writes: > Fatal error: assertion failed, file /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c, line 6799, cur_elt >= 0 > > This has been reproduced in debug and optimized, mule and latin-1 > xemacs. I cannot (yet) reproduce it in a -vanilla xemacs. This is probably (somehow) related to the redisplay fix for the widening crash (1998-09-11 in the ChangeLog). There were some other reports of this happening but nobody could ever reproduce it. I still hope that the fix is OK and we are just exposing different redisplay bugs this way... Are you using scroll-in-place? That seems to be pretty good at triggering problems in redisplay (which is a Good Thing). > I might work on fixing this, but I'm afraid I won't return from an > excursion into redisplay.c for a year or so. Yeah, I know what you mean, but it would certainly be great for XEmacs if *you* spend a year improving/fixing redisplay :-) I really think we should do something about redisplay: either rewrite it or at least generate some helpful documentation. > #8 0x1ebb10 in redisplay_window (window={...}, skip_selected=0) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c:5166 could you print the values of: w->start_at_line_beg beginning_of_line_p(b,startp) in this frame? Currently I don't have any time at all to look into this (I got a deadline for some papers on Friday and still need to prepare the talk for next week :-) Maybe we can talk about it in Japan. Gunnar -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

2 participants
1 comments

Re: Better Installataion file and `describe-installation' under Windows 25 years, 8 months

Adrian Aichner

>>>>> "Jonathan" == Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes: Jonathan> Adrian Aichner wrote: Jonathan> [snip] >> >> +Installation.el: Installation >> >> + ＠type > Installation.el << >> >> +(setq Installation-string >> >> + (replace-in-string >> >> + " >> >> +<<NOKEEP >> >> + type Installation >> Installation.el >> >> + type >> Installation.el << >> >> +" >> >> + "" "")) >> >> Should be "" "")) >> >> What did I do wrong? After patching xemacs.mak on Windows 95, do you >> still have the C-m above? Jonathan> No. The ^M got thrown away by the time your patch got to Jonathan> me. Do you see the ^M in your patch as it appeared in Jonathan> xemacs-patches? Maybe my mail client or server discarded Hello Janathan, this was my mistake! It's not your mail server or client. I have tested a new patch based on Kyle's suggestion (thanks Kyle!) to use \r, which seems obvious *now* :-). Jonathan, Windows Native Builders (especially 95/98), could you please test this patch against 21.2-b13 and let me know? I'll submit the new patch to xemacs-patches then. Thanks, Adrian cd d:\export\home\tmp\21.2\xemacs\ cvs diff Compilation started at Wed Mar 17 20:19:23 1999 cvs server: Diffing lisp Index: lisp/dumped-lisp.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/dumped-lisp.el,v retrieving revision 1.30.2.2 diff -u -r1.30.2.2 dumped-lisp.el --- dumped-lisp.el 1999/02/17 16:43:08 1.30.2.2 +++ dumped-lisp.el 1999/03/18 03:07:10 ＠＠ -2,12 +2,12 ＠＠ (assemble-list "backquote" ; needed for defsubst etc. "bytecomp-runtime" ; define defsubst - "Installation.el" "find-paths" "packages" ; Bootstrap run-time lisp environment "setup-paths" "dump-paths" "subr" ; load the most basic Lisp functions + "Installation.el" ; needs replace-in-string from subr "replace" ; match-string used in version.el. ; Ignore compiled-by-mistake version.elc "version.el" Index: nt/xemacs.mak =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v retrieving revision 1.41.2.17 diff -u -r1.41.2.17 xemacs.mak --- xemacs.mak 1999/03/10 11:35:32 1.41.2.17 +++ xemacs.mak 1999/03/18 03:07:17 ＠＠ -24,9 +24,6 ＠＠ # Synched up with: Not in FSF. # -# Shell escape character. Used for escaping ', ` and " in commands. -ESC=^ - XEMACS=.. LISP=$(XEMACS)\lisp MODULES=$(XEMACS)\modules ＠＠ -138,8 +135,6 ＠＠ # !if !defined(OS) OS=Windows_95/98 -# command.com doesn't like or need '^' as an escape character -ESC= EMACS_CONFIGURATION=i586-pc-win32 !else if "$(PROCESSOR_ARCHITECTURE)" == "x86" EMACS_CONFIGURATION=i586-pc-win32 ＠＠ -238,79 +233,6 ＠＠ !endif # -# Small configuration report -# -!if !defined(CONF_REPORT_ALREADY_PRINTED) -!if [set CONF_REPORT_ALREADY_PRINTED=1] -!endif -!message ------------------------------------------------ -!message XEmacs $(XEMACS_VERSION_STRING) $(xemacs_codename) configured for "$(EMACS_CONFIGURATION)". -!message -!message Installation directory is "$(INSTALL_DIR)". -!message Package path is "$(PACKAGE_PATH)". -!message -!if $(INFODOCK) -!message Building InfoDock. -!endif -!if $(HAVE_MSW) -!message Compiling in support for native GUI. -!endif -!if $(HAVE_X) -!message Compiling in support for X-Windows. -!endif -!if $(HAVE_MULE) -!message Compiling in MULE. -!endif -!if $(HAVE_XPM) -!message Compiling in support for XPM images. -!endif -!if $(HAVE_GIF) -!message Compiling in support for GIF images. -!endif -!if $(HAVE_PNG) -!message Compiling in support for PNG images. -!endif -!if $(HAVE_TIFF) -!message Compiling in support for TIFF images. -!endif -!if $(HAVE_JPEG) -!message Compiling in support for JPEG images. -!endif -!if $(HAVE_XFACE) -!message Compiling in support for X-Face message headers. -!endif -!if $(HAVE_TOOLBARS) -!message Compiling in support for toolbars. -!endif -!if $(HAVE_DIALOGS) -!message Compiling in support for dialogs. -!endif -!if $(HAVE_NATIVE_SOUND) -!message Compiling in support for native sounds. -!endif -!if $(HAVE_MSW_C_DIRED) -# Define HAVE_MSW_C_DIRED to be non-zero if you want XEmacs to use C -# primitives to significantly speed up dired, at the expense of an -# additional ~4KB of code. -!message Compiling in fast dired implementation. -!endif -!if $(USE_MINIMAL_TAGBITS) -!message Using minimal tagbits. -!endif -!if $(USE_INDEXED_LRECORD_IMPLEMENTATION) -!message Using indexed lrecord implementation. -!endif -!if $(USE_UNION_TYPE) -!message Using union type for Lisp object storage. -!endif -!if $(DEBUG_XEMACS) -!message Compiling in extra debug checks. XEmacs will be slow! -!endif -!message ------------------------------------------------ -!message -!endif # !defined(CONF_REPORT_ALREADY_PRINTED) - -# # Compiler command echo control. Define VERBOSECC=1 to get vebose compilation. # !if !defined(VERBOSECC) ＠＠ -429,43 +351,6 ＠＠ -DWIN32 -D_WIN32 -DWIN32_LEAN_AND_MEAN -DWINDOWSNT -Demacs \ -DHAVE_CONFIG_H $(PROGRAM_DEFINES) $(PATH_DEFINES) -# -# Creating simplified versions of Installation and Installation.el -# -# Some values cannot be written on the same line with -# their key, since they cannot be put inside an echo command. -# Macro substitution (:"=\", :\=\\) can be performed on values in order -# to create a legal string in LISP for Installation.el. -# -!if [echo OS: $(OS)>Installation] ||\ -[echo XEmacs $(XEMACS_VERSION_STRING) $(xemacs_codename:"=\") configured for $(ESC)`$(EMACS_CONFIGURATION)$(ESC)'.>>Installation] ||\ -[echo Where should the build process find the source code?>>Installation] ||\ -[echo $(MAKEDIR:\=\\)>>Installation] -!endif -# Compiler Information -!if defined(CCV) &&\ -[echo What compiler should XEmacs be built with?>>Installation] &&\ -[echo $(CC) $(CFLAGS)>>Installation] -!endif -# Window System Information -!if [echo What window system should XEmacs use?>>Installation] -!endif -!if (defined (HAVE_X) && $(HAVE_X) == 1) -!if [echo X11>>Installation] -!endif -!endif -!if (defined (HAVE_MSW) && $(HAVE_MSW) == 1) -!if [echo MS Windows>>Installation] -!endif -!endif -# Creation of Installation.el -!if [type Installation] ||\ -[echo (setq Installation-string $(ESC)">Installation.el] ||\ -[type Installation >>Installation.el] ||\ -[echo $(ESC)")>>Installation.el] -!endif - - #------------------------------------------------------------------------------ default: $(OUTDIR)\nul all ＠＠ -505,17 +390,18 ＠＠ !if [echo Creating $(CONFIG_VALUES) && echo ;;; Do not edit this file!>$(CONFIG_VALUES)] !endif # MAKEDIR has to be made into a string. -!if [echo blddir>>$(CONFIG_VALUES) && echo $(ESC)"$(MAKEDIR:\=\\)\\..$(ESC)">>$(CONFIG_VALUES)] +#!if [echo blddir>>$(CONFIG_VALUES) && echo $(ESC)"$(MAKEDIR:\=\\)\\..$(ESC)">>$(CONFIG_VALUES)] +!if [echo blddir>>$(CONFIG_VALUES) && echo "$(MAKEDIR:\=\\)\\..">>$(CONFIG_VALUES)] !endif -!if [echo CC>>$(CONFIG_VALUES) && echo $(ESC)"$(CC:\=\\)$(ESC)">>$(CONFIG_VALUES)] +!if [echo CC>>$(CONFIG_VALUES) && echo "$(CC:\=\\)">>$(CONFIG_VALUES)] !endif -!if [echo CFLAGS>>$(CONFIG_VALUES) && echo $(ESC)"$(CFLAGS:\=\\)$(ESC)">>$(CONFIG_VALUES)] +!if [echo CFLAGS>>$(CONFIG_VALUES) && echo "$(CFLAGS:\=\\)">>$(CONFIG_VALUES)] !endif -!if [echo CPP>>$(CONFIG_VALUES) && echo $(ESC)"$(CPP:\=\\)$(ESC)">>$(CONFIG_VALUES)] +!if [echo CPP>>$(CONFIG_VALUES) && echo "$(CPP:\=\\)">>$(CONFIG_VALUES)] !endif -!if [echo CPPFLAGS>>$(CONFIG_VALUES) && echo $(ESC)"$(CPPFLAGS:\=\\)$(ESC)">>$(CONFIG_VALUES)] +!if [echo CPPFLAGS>>$(CONFIG_VALUES) && echo "$(CPPFLAGS:\=\\)">>$(CONFIG_VALUES)] !endif -!if [echo LISPDIR>>$(CONFIG_VALUES) && echo $(ESC)"$(MAKEDIR:\=\\)\\$(LISP:\=\\)$(ESC)">>$(CONFIG_VALUES)] +!if [echo LISPDIR>>$(CONFIG_VALUES) && echo "$(MAKEDIR:\=\\)\\$(LISP:\=\\)">>$(CONFIG_VALUES)] !endif # PATH_PACKAGEPATH is already a quoted string. !if [echo PACKAGE_PATH>>$(CONFIG_VALUES) && echo $(PATH_PACKAGEPATH)>>$(CONFIG_VALUES)] ＠＠ -1022,6 +908,18 ＠＠ $(LIB_SRC)\make-docfile.exe -a $(DOC) -d $(TEMACS_SRC) $(DOC_SRC8) $(LIB_SRC)\make-docfile.exe -a $(DOC) -d $(TEMACS_SRC) $(DOC_SRC9) +Installation.el: Installation + ＠type > Installation.el << +(setq Installation-string + (replace-in-string + " +<<NOKEEP + type Installation >> Installation.el + type >> Installation.el << +" + "\r" "")) +<<NOKEEP + $(LISP)\Installation.el: Installation.el copy Installation.el $(LISP) ＠＠ -1043,7 +941,7 ＠＠ #------------------------------------------------------------------------------ # use this rule to build the complete system -all: $(OUTDIR)\nul $(LASTFILE) $(LWLIB) $(LIB_SRC_TOOLS) $(RUNEMACS) \ +all: Installation $(OUTDIR)\nul $(LASTFILE) $(LWLIB) $(LIB_SRC_TOOLS) $(RUNEMACS) \ $(TEMACS) update-elc $(DOC) dump-xemacs temacs: $(TEMACS) ＠＠ -1112,6 +1010,99 ＠＠ depend: mkdepend -f xemacs.mak -p$(OUTDIR)\ -o.obj -w9999 -- $(TEMACS_CPP_FLAGS) -- $(DOC_SRC1) $(DOC_SRC2) $(DOC_SRC3) $(DOC_SRC4) $(DOC_SRC5) $(DOC_SRC6) $(DOC_SRC7) $(DOC_SRC8) $(DOC_SRC9) $(LASTFILE_SRC)\lastfile.c $(LIB_SRC)\make-docfile.c $(LIB_SRC)\run.c + +Installation: + ＠type > Installation << +!if defined(OS) +OS: $(OS) +!endif + +XEmacs $(XEMACS_VERSION_STRING) $(xemacs_codename:"=\") configured for `$(EMACS_CONFIGURATION)'. + + Building XEmacs in \"$(MAKEDIR:\=\\)\". +!if defined(CCV) + Using compiler \"$(CC) $(CFLAGS)\". +!endif + Installing XEmacs in \"$(INSTALL_DIR:\=\\)\". + Package path is $(PATH_PACKAGEPATH:"=\"). +!if $(INFODOCK) + Building InfoDock. +!endif +!if $(HAVE_MSW) + Compiling in support for Microsoft Windows native GUI. +!endif +!if $(HAVE_X) + Compiling in support for X-Windows. +!endif +!if $(HAVE_MULE) + Compiling in MULE. +!endif +!if $(HAVE_XPM) + Compiling in support for XPM images. +!else + -------------------------------------------------------------------- + WARNING: Compiling without XPM support. + WARNING: You should strongly consider installing XPM. + WARNING: Otherwise toolbars and other graphics will look suboptimal. + WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux) + -------------------------------------------------------------------- +!endif +!if $(HAVE_GIF) + Compiling in support for GIF images. +!endif +!if $(HAVE_PNG) + Compiling in support for PNG images. +!else + -------------------------------------------------------------------- + WARNING: Compiling without PNG image support. + WARNING: You should strongly consider installing the PNG libraries. + WARNING: Otherwise certain images and glyphs may not display. + WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux + -------------------------------------------------------------------- +!endif +!if $(HAVE_TIFF) + Compiling in support for TIFF images. +!endif +!if $(HAVE_JPEG) + Compiling in support for JPEG images. +!endif +!if $(HAVE_XFACE) + Compiling in support for X-Face message headers. +!endif +!if $(HAVE_TOOLBARS) + Compiling in support for toolbars. +!endif +!if $(HAVE_DIALOGS) + Compiling in support for dialogs. +!endif +!if $(HAVE_NATIVE_SOUND) + Compiling in support for native sounds. +!endif +!if $(HAVE_MSW_C_DIRED) + Compiling in fast dired implementation. +!else + -------------------------------------------------------------------- + WARNING: Define HAVE_MSW_C_DIRED to be non-zero if you want XEmacs + WARNING: to use C primitives to significantly speed up dired, at the + WARNING: expense of an additional ~4KB of code. + -------------------------------------------------------------------- +!endif +!if $(USE_MINIMAL_TAGBITS) + Using minimal tagbits. +!endif +!if $(USE_INDEXED_LRECORD_IMPLEMENTATION) + Using indexed lrecord implementation. +!endif +!if $(USE_UNION_TYPE) + Using union type for Lisp object storage. +!endif +!if $(DEBUG_XEMACS) + Compiling in extra debug checks. XEmacs will be slow! +!endif +<<NOKEEP + ＠echo -------------------------------------------------------------------- + ＠type Installation + ＠echo -------------------------------------------------------------------- # DO NOT DELETE THIS LINE -- make depend depends on it. cvs server: Diffing nt/inc Compilation exited abnormally with code 1 at Wed Mar 17 20:20:48 Jonathan> the ^M but if not perhaps you should resubmit with the Jonathan> patch as a binary attachment instead of as inline Jonathan> text. And lets hope that the cvs server doesn't decide Jonathan> to do something funky with it too. Jonathan> Putting the ^M back makes your patch work for me on non-MULE. Jonathan> Jonathan. Jonathan> -- Jonathan> Jonathan Harris | jhar(a)tardis.ed.ac.uk Jonathan> London, England | Jonathan.Harris(a)symbian.com -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

2 participants
1 comments

the role of Custom in XEmacs (setting != saving) 25 years, 8 months

Didier Verna

The recent thread on custom settings vs. X resource vs. etc gave me the feeling that it might be time for a real discussion on what we actually want to do, and how we envision doing it. My current impression is that things are more or less mixed up in our minds because what's immediately visible is not conceptual problems, but bugs or technical stuff that doesn't work the way we expect it to work. The whole idea that I'd like to develop here could be summarized in 5 words: _setting is not like saving_. Let's look back a bit at History: 1/ We have a .emacs file. This file is read at startup and contains stuff that you would otherwise type and eval in the scratch buffer for instance. Things that you want to keep for all emacs sessions, you put them in. Fine. Putting stuff in .emacs is a form of "saving", since you don't retype everything every time. 2/ Now, obviously, this raises the idea of an "xemacs environment", the general behavior you'd like to have in all emacs sessions. Hence the options menu. However, what the original options menu was doing is not as obvious as it seems. It actually had a double role: a way to set _AND_ save variables, and I think this is very important to keep this in mind. Not only it was _saving_ for you code that you would otherwise have had in .emacs, but it was also giving you an easy way to _set_ the variables without having to write a single line of Elisp. 3/ After this, several problems arise: - some variables can't be set with a just a toggle button in a menu. - what do we consider part of the "xemacs environment" ? we can't possibly add an options menu item each time Joe Hacker writes an interesting package and wish to give the user an easy way to set some variable. And Custom was born. What's incredibly nice with custom (and the underlying widget lib) is that you have information on the /type/ of the variable you set, which means that you could potentially set *any* variable only with the mouse and leave with a (sort of) empty .emacs. At least, this is the ultimate situation you could reach. But .... Custom comes with its own and hermetic way of _saving_ the variables too. :-( 4/ Aside from this, there are the X resources. XEmacs is deeply integrated in the toolkits so why not use them for everything ? They have an impact on the value of Lisp variables. Yet another set AND save method. Incomplete this time, since if you're running in tty only, they're useless. However, you'd be tempted to set a face foreground using X because it's easy: you've already written some kind of `*foreground' somewhere in a .Xresources file, you (think) know how it works. Then, you've got this brand new color xterm and fuck, the face is white. OKay I'll just add a line in .emacs, or even better, I'll customize the face. And the mess begins. Users can't be blamed for this kind of thing. We've provided them with so many ways to set, edit, view save stuff at the same time, each way not fully functioning, ignoring the others, wanting to act as a stand-alone. IMHO, the major problem we're facing is that we didn't succeed in properly making the conceptual difference between _setting_ and _saving_ (or `remembering' if you prefer). For instance, the one thing I hate is custom saying "This option has been changed outside the customize buffer". Hell I don't care! Sometimes I'll find quicker to `set-variable' the option, or `eval-region' a piece of code or whatever. And now the value couldn't be saved anymore, unless I open a custom buffer? Those are *different* issues. To be a bit more concrete, here's a first brainstorm at the things we should think about. This assume that we make the distinction between setting and saving. * What can/should be something `savable' in XEmacs and the packages. This is already pretty well figured out. * How can we specify that such or such variable is `savable'. Currently, regardless of any redundancy like the one introduced by defcustom and friends, the star at the beginning of the doc strings does it more or less. * How can we figure out when and how a variable has been modified (different from the default value in its declaration). Maybe properties saying "value from an init file", "value from X resources", "value from user input during an xemacs session" etc. * Provide a SINGLE XEmacs generic way of saving stuff if modified. Custom or any other setting method shouldn't have anything to do with this. * If we have a powerfull setting method like Custom which needs type information, very well. But this information shouldn't be regarded as a 'custom-type. It's really the 'type of the variable. We can imagine that `set-variable' could also use this information for completion purpose or whatever. I repeat, _it has nothing to do with the method for setting_. It's a global information, potentially usefull for different things. * If one setting method is not able to position correctly one variable, let's try fixing this or just prevent setting with this method. With a single saving process, this shouldn't have dramatic consequences. * How can we detect, and warn about settings that are conflicting with each other (like an X resources on something that is also twiddled in inint.el) * etc etc etc. I hope I'm not so far in the blue sky there, and I'd like very much to see the discussion oriented this way. Thanks for reading so far :-) If you've just scrolled the buffer, you're a cheater. :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
1 comments

Re: the role of Custom in XEmacs (setting != saving) 25 years, 8 months

Jan Vroonhof

Didier Verna <verna(a)inf.enst.fr> writes: > 2/ Now, obviously, this raises the idea of an "xemacs environment", the > general behavior you'd like to have in all emacs sessions. Hence the options > menu. However, what the original options menu was doing is not as obvious as > it seems. It actually had a double role: a way to set _AND_ save variables, > and I think this is very important to keep this in mind. Not only it was > _saving_ for you code that you would otherwise have had in .emacs, but it was > also giving you an easy way to _set_ the variables without having to write a > single line of Elisp. The same thing holds for custom. It is actually 4 things 1. An enhanced "weak" typing system. 2. A saving system. 3. A setting system. 4. A UI to this setting system. Parts 1 and 2 work quite well, apart from the face stuff because you need to decide what to save with more complex settings like faces. > `remembering' if you prefer). For instance, the one thing I hate is custom > saying "This option has been changed outside the customize buffer". Hell I > don't care! Sometimes I'll find quicker to `set-variable' the option, or > `eval-region' a piece of code or whatever. And now the value couldn't be saved > anymore, unless I open a custom buffer? Those are *different* > issues. The big problem is: What do you mean by "setting". 1. The _user_ setting this variable? consciously? 2. _any_ change to the variable. Custom tries to do 1. "This option ... outside the customize buffer" means: "It is changed but I am not sure the user did this". > * How can we figure out when and how a variable has been modified > (different from the default value in its declaration). Maybe properties > saying "value from an init file", "value from X resources", "value from user > input during an xemacs session" etc. That's exactly what the customize properties are: 'saved-value = "value from an init file" 'customized-value = "value from user input during an xemacs session" > * Provide a SINGLE XEmacs generic way of saving stuff if modified. The custom save variables stuff is fine. > Custom > or any other setting method shouldn't have anything to do with > this. Custom is not a setting method. It is _also_ a setting method. > * If we have a powerfull setting method like Custom which needs type > information, very well. But this information shouldn't be regarded as a > 'custom-type. It's really the 'type of the variable. We can imagine that > `set-variable' could also use this information for completion purpose or > whatever. I repeat, _it has nothing to do with the method for setting_. It's > a global information, potentially usefull for different things. Indeed. So who cares that the property is called. custom-type is perfectly allright. There is no reason set-variable shouldn't use it (and even update 'customized-value too??). One could also think of implementing a very fancy completing method for the value part of setq in elisp-modes etc...). > I hope I'm not so far in the blue sky there, and I'd like very much to > see the discussion oriented this way. Thanks for reading so far :-) If you've > just scrolled the buffer, you're a cheater. :-) I think you just missed what custom is all about. Customize is a saving and typing method. As a "reference implementation" has made a newbie friendly setting method on top of it (cus-edit.el). However it is by no means the only one, see the XEmacs options menu. All (or almost all ) the discussions about the face stuff has been about Customize as a saving method. Jan

1 participants
0 comments

Solaris 2.6 + SPARCbook == death @ dump time... 25 years, 8 months

William M. Perry

For no apparent reason. Rebuilding using just plain unexsol2.o instead of unexsol2-6.o fixes the problem though. Perhaps there is a problem with dldump() under 2.6? I tried every combination of gung-ho, indexed-lrecord, optimizations, compiler switches, etc. Nothing helped. First try with just using the dynodump distributed with XEmacs and everything works though. I cannot find an appropriate preprocessor define for figuring out whether I am on a tadpole or not though. Anybody have any suggestions? In all respects this is a sparc5, just in a laptop. -Bill P.

1 participants
0 comments

[patch, yes patch!] Custom Unwanted Face/Color interaction 25 years, 8 months

Jan Vroonhof

> Jan> I think I know how to solve this (and the MULE font problem) as > Jan> follows > Jan> 1. custom adds it stuff to the specifier with a 'custom tag. > Jan> 2. reset-face is replaced by > Jan> '(remove-all-face-specifier-entries-with-tag face '(custom)) > > Jan> This changes the way custom specs work. Custom will override only > Jan> those settings it actually sets. Thus it > Jan> 1. Will not mess with colors when setting the fonts. > Jan> 2. Will leave defaults/resources alone by not deleting their > Jan> specifier entries. Thus it the call to 'x-init-global-faces is no > Jan> longer necessary, nor are the calls to init-face-from-resources > Jan> 3. It no longer destroys the Mule info. > Jan> 4. Will probably make it incompatible with FSF 20.3 > > Jan> However I think it is too late to do it for 21.0. This is what per > Jan> meant with discussing this in Tsukuba. Well at least with this we have something to discuss. All ye Xresources folk try this out (I don't use resources but I think I got all angles covered) There are two known "problems" 1. The one mentioned by Per (by design, because this solves the problem Martin has with his shell buffers). 2. If there is color set using custom AND using lisp then using the font-menu will use the custom colors even if the lisp ones were current. I do not feel like solving this now. I have got other things to do now. Any issues remaining are for you guys to solve. Jan

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 March 1999