4:11 p.m.
steven Mitchell writes:
That is something that I had not considered--that any of the things
we implemented would be new in 21.5, and be incompatible to 21.4.
Are there other incompatibilities that I should check for?
I'm sure there are some possibilities, but they're probably not worth
doing a search for them beyond installing 21.4 and testing briefly.
If you don't do that, the price is that your work won't get installed
until we do that check, and you may be asked to implement 21.4 support
at a time inconvenient for you, causing further delay.
As an aside, I should check the manuals too, to see if things new
in 21.5 are noted as being not in 21.4.
Mostly they are not. GNU's customize has a :version key, but I don't
think ours supports that yet. So it's generally hard to figure out.
The traditional method is to look in the NEWS file but that is
traditionally not well-maintained until just before a release.
CHANGES-beta (only in 21.5) is updated every micro release, and is
intermediate in detail between NEWS and ChangeLogs. Ie, it is pretty
voluminous by now.
I should probably also look and see how other packages use
behaviors, if they do.
I doubt there are very many that do.
I'm not sure how behaviors are normally used. The intent was to
be
a good citizen among packages; to have an elegant way to enable or
disable the package functionality, without having to edit the
init.el and restart XEmacs to be rid of a using the package.
What you said. ;-)
I thought about some things under the Options menu that seem to be
on the menu without me explicitly loading them, such as internet (I
don't use mail but it is there to be enabled), also
Display-->Scrollbars, which has a toggle on the menu whether it is
enabled or not. Is the difference that they are not a package, so
are allowed to have a toggle on the menu?
The big problem with "package insinuation" is that in the past many
packages would insinuate themselves into things like auto-mode-alist,
text-mode-hook, and so on when you load them. This can change the
behavior of XEmacs pretty dramatically in some cases. This is
especially nasty when you *don't* want the main behavior of some
library, but some other package loads it for some utility functions.
The problem with menu insinuation is relatively minor: menu clutter.
We don't yet have a policy for where to put disabled behaviors, but as
long as they're out of the way (maybe a "Behaviors" hierarchy under
the Options menu, like the "Customize" hierarchy), I don't see why
there would be an objection to a behavior toggle. On the other hand,
adding a whole menu to control various aspects of the buffer-colors
package (eg, "Buffer Foreground" and "Buffer Background" directly in
the "Options" menu would be obnoxious!) is a no-no.
The presence of the various mailers in the Tools | Internet menu is
bad form IMHO, ditto the *five* options for VC-related tasks in the
Tools menu itself, but we don't really have a best practice to avoid
that yet. Since you're interested in UI design, suggestions (and
code! if and when you have time) would be welcomed.
I'm not resisting changing to not using behaviors, I'm just
trying
to be sure I have the straight of it.
Using behaviors is the right thing for the future (although they are
still work-in-progress, especially documentation). Backwards
compatibility to 21.4 is policy for the foreseeable future (at least a
year). Elegance may need to be sacrificed on the altar of compromise
here.:-) (Ie, extra code that implements the same functionality as
behaviors for 21.4 may be needed.)
> 2. Those messages should not appear on stderr.
Hmm. Why do they appear on stdin? is that the default maybe?
They appear because something is loaded before the echo area is
initialized. This is a good thing, because only a few things
(auto-autoloads, custom-loads, site init files, and user init files)
should be loaded that early in startup, and those messages warn us
that something is out of order. Everything else should be loaded via
explicit calls in the site and user init files, by which time the
messages will appear in the echo area.
The "Loading..." messages are specially suppressed for the files
listed above.
> In fact, IMO, it's bad form for packages to do things like
> insinuate themselves into the menu system just on loading. The
> usual way is to create an initialization function that the user
> must explicitly call in order to invoke the functionality.
>
to continue your thought, that initialization function would be
intended to be called upon loading the function? or when the
init.el is loaded with a call to that function?
Normally a package's initialization function is auto-autoloaded (this
is done by placing a line containing only the string ";;;###autoload"
before the defun).
For example, the jka-compr package (which provides transparent
(de)compression of files) provides autoloads for `jka-compr-install'
(the initialization function that adds entries to various lists and
file handler hooks for automatic decompression), `jka-compr-load'
(which allows you to do "M-x jka-compr-load RET foo.elc.gz RET"),
`auto-compression-mode' (a mode that installs a compressor hook for
saving files), and `toggle-auto-compression' (the function that
actually implements turning the mode on and off). These functions
become automatically available merely by installing the package on
your disk, but otherwise the package does nothing (it's not even
loaded, so you won't see other "jka-compr" functions in a fresh
invocation of XEmacs, eg with C-h a ^jka-compr RET) until that
function is invoked, or jka-compr is explicitly loaded.
I really like the Customize system, creating a buffer to customize
a group of related variables is great. The only tiny flaw in it is
you have to know that a customize group exists--and know it's
name--before you can effectively use it. If want to change the
foreground and background colors, for a simple example, you have to
*know* that the face you want to edit is called the default face.
Or else you select Options-->Advanced (Customize)-->Faces... and
choose "default all" and peruse all faces (50+ faces) many of which
have a Fg and Bg color, on the way to finding the face you are
trying to modify. My point is there is required knowledge to use
the customize system (in the example, the name of the face that you
want to modify) that isn't given by the system at that point. You
have to *discover* the name of the face you want to modify.
I don't understand where you're going with this. Assuming that the
customization you want is (a) in an appropriate group and (b) the
customization and all its parents (groups) are well-documented, all
you need to know is the existence of Options|Advanced (Customize),
which itself is pretty discoverable (unless your only use of XEmacs is
at a securities trading company! :-)
Were behaviors started with 21.5.0? or at some later point?
Later.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta