April 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: How about a new XEmacs logo? 24 years, 1 month

Jens Lautenbacher

Giacomo Boffi <giacomo.boffi(a)polimi.it> writes: > i feel appropriate a full capitalization _in the logo only_ for > reasons of visual balance among the regoionss of the image Actually I don't know how the visual balance would be affercted by writing the name XEMACS instead of XEmacs. In fact I suspect that using XEMACS leads to something completely visually symmetric w.r.t the middle axis. This isn't visual balance, but just the simplest form how one could achive visual balance. Look at some pieces of modern art, e.g. Kandinsky. Although they are very asymmetric, they nevertheless have a strong visual balance, and in the same time have more "tension" than a simple ornamental thing. jtl

2 participants
1 comments

Re: How about a new XEmacs logo? 24 years, 1 month

Jens Lautenbacher

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > Sergej Malinovski <sergej(a)nospam.dk> writes: > > > How old is the existing logo? > > Two or three years, IIRC. Prior to that, we used to have a color > version of `xemacs.xbm' as the logo. > > > So, what do you think of the whole idea? > > I agree that the current logo is not very nice, and I'd love to see a > better one. me too... and if even I say this.... jtl

7 participants
7 comments

pcl-cvs 2.9.8 24 years, 1 month

Neal D. Becker

http://apps.freshmeat.net/download/937892372/

1 participants
0 comments

gutter-only dialogs and search dialogs 24 years, 1 month

Ben Wing

thanks very much for working on dialog boxes! however, i have some comments ... the function make-gutter-only-dialog-frame is bogus. the use of the gutter here to hold widgets is an implementation detail and should not be exposed in the interface. similarly, make-search-dialog should not have to do all the futzing that it does. creating the frame unmapped, creating an extent and messing with the gutter: all this stuff should be hidden. you should have a simple function make-dialog-frame that takes a dialog specification, and that's all you need to do. also, these dialog boxes, and this function make-dialog-frame, should (a) be in dialog.el, not gutter-items.el. (b) when possible, be placed in the interactive spec of standard lisp functions rather than accessed directly from menubar-items.el (c) wrapped in calls to should-use-dialog-box-p, so the user has control over when dialog boxes appear. finally, once again i implore you to please fix your layout code so it's not necessary to specify widths and heights all over the place! -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.

2 participants
2 comments

Re: Startup changes 24 years, 1 month

Hrvoje Niksic

Ben Wing <ben(a)666.com> writes: > OK, we need to create a design document for all of this, including: > > PRINCIPLE #1: Whenever you have auto-generated stuff, *CLEARLY* > indicate this in comments around the stuff. These comments get > searched for, and used to locate the existing generated stuff to > replace. Custom currently doesn't do this. Agreed. > PRINCIPLE #2: Currently, lots of functions want to add code to the > .emacs. (e.g. I get prompted for my mail address from > add-change-log-entry, and then prompted if I want to make this > permanent). There needs to be a Lisp API... Actually, the ChangeLog question comes from the `user-mail-address' function, which uses Custom as a mechanism for saving the settings. So it doesn't violate the principle #2, because it doesn't attempt to open the init file itself. ... > PRINCIPLE #5: Packages are encouraged, as much as possible, to work > within the customize model and store all their customizations there. > However, if they really need to have their own init files, these > files should be placed in .xemacs/, given normal names > (e.g. saved-abbrevs.el not .abbrevs), and there should be some magic > comment at the top of the file that causes it to get automatically > loaded while loading a user's init file. (Alternatively, the > above-named API could specify a function that lets a package specify > that they want such-and-such file loaded from the init file, and > have the specifics of this get handled correctly.) I agree with this. > OVERARCHING GOAL: The overarching goal is to provide a unified > mechanism for packages to store state and setting information about > the user and what they were doing when XEmacs exited, so that the > same or a similar environment can be automatically set up the next > time. In general, we are working more and more towards being a > truly GUI app where users' settings are easy to change and get > remembered correctly and consistently from one session to the next, > rather than requiring nasty hacking in elisp. That would be cool. Yes, I have interest in this -- notice the minibuffer-history-saving hack that I wrote and that is now part of XEmacs -- but I'm afraid I don't have much time to hack on it. I agree with the directions you gave, and I'll likely help deal with the startup issues when I have some more time. (Real Work, just like Real Life, can sometimes suck.)

1 participants
0 comments

Re: Startup changes 24 years, 1 month

Ben Wing

OK, we need to create a design document for all of this, including: PRINCIPLE #1: Whenever you have auto-generated stuff, *CLEARLY* indicate this in comments around the stuff. These comments get searched for, and used to locate the existing generated stuff to replace. Custom currently doesn't do this. PRINCIPLE #2: Currently, lots of functions want to add code to the .emacs. (e.g. I get prompted for my mail address from add-change-log-entry, and then prompted if I want to make this permanent). There needs to be a Lisp API for working with arbitrary code to be added to a user's startup. This API hides all the details of which file to put the fragment in, where in it, how to mark it with magical comments of the right kind so that previous fragments can be replaced, etc. PRINCIPLE #3: *ALL* generated stuff should be loaded before any user-written init stuff. This way the user can override the generated settings. Although in the case of customize, it may work when the custom stuff is at the end of the init file, it surely won't work for arbitrary code fragments (which typically do `setq' or the like). PRINCIPLE #4: As much as possible, generated stuff should be place in separate files from non-generated stuff. Otherwise it's inevitable that some corruption is going to result. PRINCIPLE #5: Packages are encouraged, as much as possible, to work within the customize model and store all their customizations there. However, if they really need to have their own init files, these files should be placed in .xemacs/, given normal names (e.g. saved-abbrevs.el not .abbrevs), and there should be some magic comment at the top of the file that causes it to get automatically loaded while loading a user's init file. (Alternatively, the above-named API could specify a function that lets a package specify that they want such-and-such file loaded from the init file, and have the specifics of this get handled correctly.) OVERARCHING GOAL: The overarching goal is to provide a unified mechanism for packages to store state and setting information about the user and what they were doing when XEmacs exited, so that the same or a similar environment can be automatically set up the next time. In general, we are working more and more towards being a truly GUI app where users' settings are easy to change and get remembered correctly and consistently from one session to the next, rather than requiring nasty hacking in elisp. Hrvoje, do you have any interest in this? How about you, Martin? This seems like it might be up your alley. This stuff has been ad-hocked since kingdom come, and it's high time that we make this work properly so that it could be relied upon, and a lot of things could "just work". Jan Vroonhof wrote: > Ben Wing <ben(a)666.com> writes: > > > while we're at it, can we > > > > (1) put custom-created options in a separate file (it's bad juju to put > > auto-generated stuff in a non-auto-generated file), and > > Amen.. > > I have been using ~/.xemacs/options.el for ages now. > > The only problem is how to cleanly migrate users away from the > .emacs setup, which is slightly nontrivial. (It basically involves > detecting whether the where custom-set-* statements in .emacs or > .xemacs/init.el and then adjusting custom-file accordingly) > > > (2) make these options get set up *before* the init file is loaded (or at the > > beginning of it), so users can override it in the init file. > > This is not needed. You can already override it. Custom settings > behave essentially as 'defvars'. If the users setq comes before it > will take the setq version and NOT override it. > > That has other weird consequences (such as the variable not being > bound untill the the defcustom is loaded), but this works OK. > > Jan -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.

1 participants
0 comments

Redisplay lossage 24 years, 1 month

Kirill 'Big K' Katsnelson

xemacs -q Click or hit a key to go to scratch. Then start inserting characters into the first line so that it wraps. For me, only the last period in the first line is wrapped to the second line, and the right side of the string rightwards to nowhere. Swithching windows redisplays the broken second line immediately. Anybody else seenig this? Big K

1 participants
0 comments

Progress bars + events [Re: crash when using W3] 24 years, 1 month

Jan Vroonhof

Ben Wing <ben(a)666.com> writes: > we wouldn't need to inhibit event processing. bill perry would get a lisp > error upon buffer deletion, and would then have to change his code not to > trigger event processing in after-change. We have a catch-22 here. The code is that is triggering the event processing is to display progress bars and Andy's says event processing is NEEDED there :-( It doesn't even help to inhibit process events because for instance the GPM code (text based mouse support) uses them. May we should simply start by signalling an error and see what breaks.. Jan

3 participants
3 comments

Re: Rectangular selection appears to be broken 24 years, 1 month

Dmitry Yaitskov

Mike Alexander <mta(a)arbortext.com> wrote: > I can't make rectangular selections work in the native NT version of > XEmacs 21.2 built from the CVS archive as of just after midnight on > 4/4. When I do a meta-button1 drag the rectangular selection > highlights ok, but as soon as I release the mouse it disappears (both > the highlight and the selection). I tried this with -vanilla and it > still doesn't work <snip> Ditto here - cygwin XEmacs 21.2 beta32 (not CVS). -- Cheers, -Dima.

1 participants
0 comments

Re: XEmacs 21.2.32 on SGI IRIX 24 years, 1 month

Colin Rafferty

Martin Buchholz writes: >>>>>> "Colin" == Colin Rafferty <colin(a)xemacs.org> writes: Colin> Martin Buchholz writes: Colin> Björn Torkelsson writes: >>>>> The latest version of XEmacs updated from CVS yesterday (2000-04-03) is >>>>> uncompilable under SGI IRIX with the naitive SGI cc compiler. Colin> I submitted the patch to xemacs-patches to undo Martin's changes Colin> already. Here it is for your personal enjoyment. Colin> * alloc.c (size_vector): Colin> (make_vector_internal): Colin> (make_bit_vector_internal): Colin> (sweep_bit_vectors_1): Colin> Replace calls to offsetof with STRETCHY_STRUCT_SIZEOF macro. >>> I don't like reversing this change. Is the code in XEmacs >>> ANSI-compliant? I think so. Colin> I don't. While I don't have a copy of the standard, SGI compilers are Colin> very good at following the standards. > Your intuition is correct. As usual, I was wrong. Arguments of this > type are best won by citing chapter and verse. Thanks. If I had a copy of the standard, I would certainly have cited. > We can put back the original code, but I would like to revisit the > naming scheme. "stretchy struct" is a phrase adopted from some > proprietary debugging tool (Insure, if I recall). This practice has > not been legal ANSI C, but all known compilers support it. Including IRIX :-). Given how a C compiler works, I can't imagine how one couldn't support flexible arrays. > So let's audit all the occurrences of offsetof in the sources, and > change the ones required back to use STRETCHY_STRUCT_SIZEOF, except > let's use a naming convention like this: > #define FLEXIBLE_ARRAY_STRUCT_SIZEOF(flexible_array_structtype, flexible_array_member, flexible_array_length) \ The auditing part is easy. The SGI compiler does it for me. In about five minutes, I'll submit a new patch that uses FLEXIBLE_ARRAY_STRUCT_SIZEOF instead of STRETCHY_STRUCT_SIZEOF. -- Colin

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