1:28 p.m.
Vin,
That sounds familiar, the custom-set-face-bold.
I had filed a bug in the issue tracker about custom-set-face-bold not
auto-loading. Issue 816.
In that bug report I wrote how I fixed it here, by editing it in the
auto-autoloads.el but didn't
have write permissions to push (correct word?) a patch, so started an issue.
A few days later Byrel and I uploaded our first packages, which included
all 5 of the files that
were changed. So we could be responsible...
We used custom-set-face-bold in setting bold on for the text-icons
theme. Maybe since the
icon-themes package is uploaded now, the issue of custom-set-face-bold
not auto-loading is showing
up for everyone? I'm just guessing, maybe it is something else.
Steve Mitchell
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:02 p.m.
Steven -
On Sun, Jan 8, 2012 at 8:28 AM, steven Mitchell wrote:
That sounds familiar, the custom-set-face-bold. I had filed a bug
in the issue tracker about custom-set-face-bold not auto-loading.
Issue 816. In that bug report I wrote how I fixed it here, by
editing it in the auto-autoloads.el but didn't have write
permissions to push (correct word?) a patch, so started an issue.
A few days later Byrel and I uploaded our first packages, which
included all 5 of the files that were changed. So we could be
responsible...
We used custom-set-face-bold in setting bold on for the text-icons
theme. Maybe since the icon-themes package is uploaded now, the
issue of custom-set-face-bold not auto-loading is showing up for
everyone? I'm just guessing, maybe it is something else.
Thanks. I think your analysis is correct. Here's the change that I
will apply to both 21.4 and 21.5 to resolve Issue 816:
diff -r 3fefbc2159f6 lisp/ChangeLog
--- a/lisp/ChangeLog Fri Dec 23 18:38:41 2011 -0500
+++ b/lisp/ChangeLog Sun Jan 08 16:29:04 2012 -0500
ï¼ ï¼ -1,3 +1,7 ï¼ ï¼
+2012-01-08 Vin Shelton <acs(a)xemacs.org>
+
+ * cus-face.el: autoload custom-set-face-bold.
+
2011-11-14 Vin Shelton <acs(a)xemacs.org>
* faces.el: When the default background was changed from light to
diff -r 3fefbc2159f6 lisp/cus-face.el
--- a/lisp/cus-face.el Fri Dec 23 18:38:41 2011 -0500
+++ b/lisp/cus-face.el Sun Jan 08 16:29:04 2012 -0500
ï¼ ï¼ -161,6 +161,7 ï¼ ï¼
(list (list t (face-custom-attributes-get
symbol (selected-frame))))))
+;;;###autoload
(defun custom-set-face-bold (face value &optional frame tags)
"Set the bold property of FACE to VALUE."
(if value
Thanks for your insight.
- Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:54 a.m.
Hi, Steven and Byrel -
With my modified 21.4, I can now build the packages. Good! However,
there are still a few issues with buffer-colors and icon-themes:
1. I cannot load XEmacs 21.4:
xemacs -vanilla
Loading icon-themes...
Loading cus-face...
Loading cus-face...done
Loading icon-themes...done
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?
2. Those messages should not appear on stderr. 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.
Here's the hack I threw together to address this:
diff -r 6cab68dcb147 buffer-colors.el
--- a/buffer-colors.el Sat Jan 07 06:17:23 2012 -0500
+++ b/buffer-colors.el Sun Jan 08 22:36:05 2012 -0500
ï¼ ï¼ -407,15 +407,17 ï¼ ï¼
;;;;--- start up code ----------------------------------------------
-;;;###autoload
-(unless (featurep 'buffer-colors)
+(defun initialize-buffer-colors ()
+ "Load buffer-colors and add an item to the Options menu."
+
+ (unless (featurep 'buffer-colors)
+ (add-menu-button '("Options" "Display")
+ "---")) ;add a separator only first time loaded
+
(add-menu-button '("Options" "Display")
- "---")) ;add a separator only first time loaded
-;;;###autoload
-(add-menu-button '("Options" "Display")
- [ "Buffer Colors" bc-toggle-behavior
- :style toggle
- :selected (behavior-enabled-p 'buffer-colors)])
+ [ "Buffer Colors" bc-toggle-behavior
+ :style toggle
+ :selected (behavior-enabled-p 'buffer-colors)]))
(provide 'buffer-colors)
diff -r 6cab68dcb147 icon-themes.el
--- a/icon-themes.el Sat Jan 07 06:17:23 2012 -0500
+++ b/icon-themes.el Sun Jan 08 22:36:05 2012 -0500
ï¼ ï¼ -349,8 +349,10 ï¼ ï¼
;;;;--- initialize icon-themes ------------------------------------------
-;;;###autoload
-(theme-load-menu '("Options") "Display")
+(defun initialize-icon-themes ()
+ "Load icon-theme support and add an item to the Options menu."
+ (theme-load-menu '("Options") "Display")
+)
;;;;---- customize group and variables for icon-themes
------------------------------
ï¼ ï¼ -445,4 +447,4 ï¼ ï¼
(provide 'icon-themes)
-;; icon-themes.el ends here
\ No newline at end of file
+;; icon-themes.el ends here
Please let me know if you want me to apply that patch or if you want
to do something less hackish.
Regards,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:04 a.m.
Vin Shelton writes:
behavior-enabled-p is not defined in 21.4. I probably could import
the definition from 21.5,
Ben-style behaviors don't exist at all in 21.4, so it would be quite a
bit more complicated than that. Maybe behaviors themselves should be
moved to a package (eg, xemacs-base)?
2. Those messages should not appear on stderr. In fact, IMO,
it's bad
form for packages to do things like insinuate themselves into the menu
system just on loading.
If a package is actually loaded, of course it should insinuate itself
into the menus. It's arguable that auto-autoloads should not
insinuate menus, but I tend to think that is actually a good idea, as
long as the only menu that is affected is a list of auto-insinuated
behaviors (in a general sense, not just Ben's implementation) that can
be enabled. (As this list grows there will be a menu management
problem, but how else to make such behaviors discoverable?)
I'm not sure how this should work in 21.4, since Ben-style behaviors
aren't implemented there.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:45 a.m.
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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
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
10:03 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
It's arguable that auto-autoloads should not insinuate menus, but
I
tend to think that is actually a good idea, as long as the only menu
that is affected is a list of auto-insinuated behaviors (in a
general sense, not just Ben's implementation) that can be enabled.
Could this as well be handled by customize? customize-behaviours?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:18 a.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> It's arguable that auto-autoloads should not insinuate menus, but I
> tend to think that is actually a good idea, as long as the only menu
> that is affected is a list of auto-insinuated behaviors (in a
> general sense, not just Ben's implementation) that can be enabled.
Could this as well be handled by customize?
Keeping state (whether a particular user has enabled the behavior or
not) can and should be done in customize. Whether menus shold be
insinuated or not, and if so, what form that should take, are style
guide/policy issues. I don't see any reason what the insinuation
would be implemented by customize, though. That's not what it's for.
customize-behaviours?
Just `(defgroup 'behavior ,list-of-behaviors)' and M-x customize-group
will do for what customize can handle now. Maybe a bit of additional
infrastructure to make it easy to add a new behavior to that custom
group.
I suppose it's theoretically possible that behaviors themselves could
be implemented in customize, but Ben didn't do that, and his scanty
notes suggest there were reasons he didn't.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:15 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Using behaviors is the right thing for the future [...]
I haven't heard about behaviors until this thread. (Good to learn
something new every day!)
It seems like it is a kind of framework for packages. Making it easier
to activate and deactivate a package with integration with customize
around the corner.
I also find some examples(?) for mail and mwheel but fail to
understand if those examples can be activated or if they already are
activated. What is the status of behaviors? Is the code working and
ready to be used?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:40 p.m.
So far as I could tell, behaviors were essentially a means of globally
enabling or disabling a certain feature. Whoever implemented the
feature would write functions for enabling and disabling it, and
register those through `define-behavior'. The behavior can then be
turned on and off through disable- and enable-behavior. That much, at
least, is implemented.
However,it looks like there was going to be a behavior menu (with
functions like behavior-menu-filter defined.) I don't believe there is
such a menu on the default menu-bar in the latest beta.
Sincerely,
Byrel
On Wed, Jan 11, 2012 at 12:15, Mats Lidell <matsl(a)xemacs.org> wrote:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
> Using behaviors is the right thing for the future [...]
I haven't heard about behaviors until this thread. (Good to learn
something new every day!)
It seems like it is a kind of framework for packages. Making it easier
to activate and deactivate a package with integration with customize
around the corner.
I also find some examples(?) for mail and mwheel but fail to
understand if those examples can be activated or if they already are
activated. What is the status of behaviors? Is the code working and
ready to be used?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:26 a.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
activated. What is the status of behaviors? Is the code working and
ready to be used?
Working, yes, ready for use, not by my standards (documentation is
lacking). They're also in a very primitive state, AFAIK users need to
build up almost all the scaffolding themselves (kinda like defining a
minor mode without using define-minor-mode).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:04 a.m.
Byrel Mitchell writes:
So far as I could tell, behaviors were essentially a means of
globally
enabling or disabling a certain feature. Whoever implemented the
feature would write functions for enabling and disabling it, and
register those through `define-behavior'. The behavior can then be
turned on and off through disable- and enable-behavior. That much, at
least, is implemented.
However,it looks like there was going to be a behavior menu (with
functions like behavior-menu-filter defined.) I don't believe there is
such a menu on the default menu-bar in the latest beta.
Yes, and yes. Excellent summary, thank you!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:08 a.m.
I think the behavior menu DOES exist in 21.5.
It is just that it has been morphed into a different form/name
If you look at behavior.el, the last function in the file, is the menu
that Ben Wing was intending:
(defun behavior-menu-filter (menu)
(append
`(("%_Package Utilities"
("%_Set Download Site"
("%_Official Releases"
:filter ,#'(lambda (&rest junk)
(menu-split-long-menu
(submenu-generate-accelerator-spec
(package-ui-download-menu)))))
("%_Pre-Releases"
:filter ,#'(lambda (&rest junk)
(menu-split-long-menu
(submenu-generate-accelerator-spec
(package-ui-pre-release-download-menu)))))
("%_Site Releases"
:filter ,#'(lambda (&rest junk)
(menu-split-long-menu
(submenu-generate-accelerator-spec
(package-ui-site-release-download-menu))))))
"--:shadowEtchedIn"
["%_Update Package Index" package-get-update-base]
["%_List and Install" pui-list-packages]
["U%_pdate Installed Packages" package-get-update-all]
["%_Help" (Info-goto-node "(xemacs)Packages")])
"----")
(behavior-menu-filter-1 menu nil)))
;; Initialize top-level group.
(puthash nil '(:children nil :short-doc "Root") behavior-group-hash-table)
And that menu structure is what I see on the menu as Tools-->Packages.
That was 10 years ago, and is not to say we have to do it that way now.
Nor am I saying it is the correct way. This is just a response to what is
actually implemented at this point.
it looks like the intention way back when, was to have a menu with
behaviors (though maybe not called that) that had all the stuff under
Tools-->Packages currently, appended to it.
Again, I'm not saying we have to go back to that design, I'm just saying
what it looks like was intended.
In the discussion now, about a policy for menu insinuation done by packages,
maybe a menu-path could be designated as the place for any insinuation
to occur
and nowhere else?
The other choices seem to be to allow it at will, or not allow menu
insinuation
at all.
I don't have an opinion which way it should be done, just trying to clarify
options.
Steve Mitchell
On 01/12/2012 02:04 AM, Stephen J. Turnbull wrote:
Byrel Mitchell writes:
> So far as I could tell, behaviors were essentially a means of globally
> enabling or disabling a certain feature. Whoever implemented the
> feature would write functions for enabling and disabling it, and
> register those through `define-behavior'. The behavior can then be
> turned on and off through disable- and enable-behavior. That much, at
> least, is implemented.
>
> However,it looks like there was going to be a behavior menu (with
> functions like behavior-menu-filter defined.) I don't believe there is
> such a menu on the default menu-bar in the latest beta.
Yes, and yes. Excellent summary, thank you!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:09 a.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Working, yes, ...
I was trying to find the behaviors-menu since it seemed like it could
be defined but failed to find it. (And my 21.5-latest-and-greatest
crashes repeatedly with to many menu accesses so I got bored in trying
this further.) I take it from Byrels post that I'm not the only one
missing that.
... ready for use, not by my standards (documentation is
lacking). They're also in a very primitive state, AFAIK users need
to build up almost all the scaffolding themselves (kinda like
defining a minor mode without using define-minor-mode).
Looks like an interesting project. There should not need to be that
much framework code to get it into something useful.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:23 a.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> ... ready for use, not by my standards (documentation is
> lacking). They're also in a very primitive state, AFAIK users need
> to build up almost all the scaffolding themselves (kinda like
> defining a minor mode without using define-minor-mode).
Looks like an interesting project. There should not need to be that
much framework code to get it into something useful.
Some of it will be superficial and easy to kaizen (Japanese for
"improve gradually" if you're not familiar with the word).
There's a deeper project I've had in mind for a while, which is a mode
domain for specifiers. Currently if you have a specifier (say
comment-face's font) and want to change it for a given mode, you need
to map over all buffers in that mode and add a buffer-specific spec
for each one to the specifier. However, it should be possible to add
logic to check if the buffer is in a particular mode, and if so
instantiate that spec.
The specification problems here are somewhat knotty, though. Do we
want to count minor modes as modes for this purpose? Do they override
major modes? Since modes and frames aren't nested, which comes first
when searching? etc.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:48 p.m.
>>>> steven Mitchell <smitchel(a)bnin.net> writes:
If you look at behavior.el, the last function in the file, is the
menu
that Ben Wing was intending:
[...]
(behavior-menu-filter-1 menu nil)))
I was thinking that mwheel would show up here, as part of
behavior-menu-filter-1, but no. Not here at least. I didn't try to
debug or analyse further. I asked the list instead.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4486
days inactive
4490
days old
15 comments
5 participants
participants (5)
-
Byrel Mitchell -
Stephen J. Turnbull -
steven Mitchell -
The XEmacs Package Smoketest -
Vin Shelton