Failure building packages (Vin Shelton)

[steven Mitchell]

On 01/08/2012 11:54 PM, Vin Shelton wrote:
> Symbol's function definition is void: behavior-enabled-p
>
> behavior-enabled-p is not defined in 21.4.  I probably could import
> the definition from 21.5, but usually the packages try to work around
> such incompatibilities.  Can you work around the lack of
> behavior-enabled-p in 21.4?
>
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?  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.  I should probably also look 
and see how
other packages use behaviors, if they 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.  When you
disable the functionality by toggling the menu item, it closes up shop 
in a decent way,
returning the menu state and toolbar to the way it was before the 
behavior was enabled,
except that the toggle for the behavior is still on the menu.

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?  Or maybe I am misunderstanding why they can be toggled but it 
is not a good
idea for packages.  I'm not resisting changing to not using behaviors, 
I'm just trying to
be sure I have the straight of it.

If the consensus of the group is to find another way than using 
behaviors, we will do so,
either using Vin's patch or another way.
> 2. Those messages should not appear on stderr.
Hmm. Why do they appear on stdin? is that the default maybe?  Since we 
didn't
explicitly tell them to appear on stdin, or anywhere else, I'm wondering 
what mechanism
you use to make them appear any certain place.

> 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?

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.  That it is the default face *is* documented 
several places,
but not where/when you need that knowledge to make a decision to modify 
it. That
can be remedied 2 ways I can think of, but neither way is implemented 
right now.
I can talk about that later, I don't want to get distracted.

The point I am making is that in a similar way to the example I gave:
new features have to be discovered.  You don't know they are there, or 
that they are
things that can be changed, until you find out some way.  And if the 
"some way" isn't
is handy as on the menu as a toggle, it may not be/isn't clear that a 
feature exists or
can be changed.

This stumbling block of not having a piece of knowledge is more a 
problem for new users
than old hands.  I am just explaining why I think having something 
toggled on the menu
might be a good idea, but not saying that using behaviors is the best or 
only way.

I'd like to hear more about how packages should interface with different 
versions of
XEmacs and what tests you do to tell which one you are running under.  
Were behaviors
started with 21.5.0? or at some later point?

Regards,
Steve Mitchell