buildbot(a)lidell.nu writes:
> The Buildbot has detected a new failure on builder x86 gentoo cfg1
> while building XEmacs. Full details are available at:
> http://www.lidell.nu/xemacs-buildbot/builders/x86%20gentoo%20cfg1/builds/3
> BUILD FAILED: failed test
I don't understand these failures at all. There are a bunch of void
function failures, a failure to find cat(1), and some weird Unicode
errors. All this from a patch to ./INSTALL and ./ChangeLog??
So I'm going to assume it wasn't me. But I would really like to hear
from anybody who sees similar failures when doing "make check".
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Ben and I were playing around with the menu structure, and noticed a
discrepancy in the documentation. According to the lispref, the :active
keyword is only valid for leaf entries. According to current-menubar's
docstring, it's valid for submenus as well.
We tested it, and it turns out the syntax check function precludes using
the:active keyword. However, the functionality is implemented, and works
if you bypass the syntax check. Here's a patch to the syntax checker and
lispref that would enable it.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Stephen's recent upload of changes to the INSTALL file prompted me to
read the file for the first time in years.
I have made some corrections (to minor word forms and version numbers)
in the new INSTALL file. The patch is included for INSTALL and
CHANGELOG. I read one section where more detail would help, but I do
not know the detail to add. In "Specifying Location of Headers and
Libraries" the --with-site-runtime-libraries explanation states that
multiple directories can be added to the search path; however, it does
not specify the format of that list. The paragraph above it for
--with-site-includes specifies the format for its directory list. The
formats for directory search paths accepted by the configure procedure
either require colon-delimited, comma-delimited, or space-delimited
lists (the latter enclosed within quotation marks) as stated in other
sections of the INSTALL file. It is not clear how to format the
--with-site-runtime-libraries list of directories based on the
paragraph in this section.
In the section "Advanced Make" the default for datadir is listed as
/usr/local/data. This does not seem to be correct on all systems.
Earlier in INSTALL, the directories listed here as being part of the
installation defaulted to PREFIX/share/xemacs-VERSION rather than to
PREFIX/data/xemacs-VERSION. On my system where PREFIX=~/usr/local, I
have ~/usr/local/share/xemacs-21.5.b32/ with etc, lisp, and info as
child directories. Should `data' in `/usr/local/data' be changed to
`share'? Note, that in later references to datadir, /usr/local/share
is referenced as the default directory. I included this in the patch.
I cahnged one "can not" to "cannot" to match other uses in the document.
I changed references to version numbers at various places in the file
in attempt to show only the latest stable and the latest beta. I did
this because other examples of directories created with the version
name had already been updated.
Consider whether the section "Selecting configure Options" should
include a forward reference to "Appendix: Correspondence to Old
configure Options." The list of removed options and enable/with
modifiers could be useful. I suggest moving the last paragraph of
"Random Notes" into the "Selecting configure Options" section.
I am not certain of the style for some nomenclature. I cannot tell
whether the document should always to refer to the file `configure' in
all lower case or to let that float. In some titles the style is to
use all caps for CONFIGURE when it appears to be a reference to the
file, but in others it is configure (lc), and in one it is Configure
(using title case).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Hi all,
Is there interest having XEmacs participate in GSoC next year?
The last time this question came up, there was no real interest in
mentoring from the reviewers. This time I'm willing to serve as a
mentor or co-mentor having some experience as a co-mentor for
Mailman. I'd love to have other mentor volunteers from reviewers (or
folks who feel they are candidates for reviewer).
Of course we need students. If anybody *is* a student, or has an
affiliation with an academic organization where likely candidates
could be recruited, please feel free to let me know.
There is some preparation we need to do at some point, in particular
we need to set up to receive funds from Google. In theory we could
incorporate as an NPO, but it's probably a better idea to affiliate
with an existing umbrella organization, such as Software in the Public
Interest, the Software Freedom Conservancy, or the Apache Software
Foundation. Comments welcome.
Apparently this kind of thing can be done in a couple of months, since
there was an announcement on the GSoC Mentors list in July 2012 for
GSoC 2012 payments. But I figured I might as well mention it since
it's on my mind, and applications for next year's mentoring
organizations will catch us by surprise if we ignore it for the next
few months.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

On Sun, Dec 23, 2012 at 7:24 PM, Stephen J. Turnbull <stephen(a)xemacs.org>wrote:
>
> Is there a use case for the :active keyword in submenus?
>
> Well, we're making a different menu interface to the register
functionality. This makes submenus for each function (like "Copy to
Register" or " Insert from Register) with entries for a bunch of different
registers. Those use suffixes, etc. to preview the values for easy
insertion/copying. From a tree perspective:
|+Copy to Register
|| a (a contents)
|| b (b contents)
|+Insert from Register
|| a (a contents)
|| b (b contents)
etc.
We were looking at using :active to disable the submenus for functions that
need an active region, whenever the region isn't active. We can always use
:included, but it seems more natural to have an entry there even if it's
impossible to use.
Thanks for the patches! I've got a few more old patches I want to
> clear out of my workspace, and then I'll try to take a bite out of the
> backlog of user patches.
>
You're welcome. We just happen to be poking in this section of the code
right now. There was one thing I was wondering about when reading through
the menubar.el. There's a lot of special-casing to handle the fact that the
top-level menu doesn't have a leading string. Is there a good reason for
this, other than just history? Ben and I were thinking about rehashing it
to work with a leading string (probably just "") if that's something you
guys would be interested in looking at. On the other hand, I don't know if
there might be a lot of packages and whatnot that directly access the menu
that such a change might break.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

I'm going to take the liberty ofalso eposting to xemacs-beta. There are
a couple of amusing ideas here that bear wider
steven Mitchell writes:
> I should have looked further [in the packages].
Yeah, locating stuff is one downside of packaging. Hm. We could
etags the whole package tree, maybe?
> big-menubar.el is what adds that section of the menu.
Thanks for checking.
> Is the proper thing to ask the maintainer of that package to change it?
> Or submit a patch so he sees what is proposed?
The maintainer is XEmacs Development Team <xemacs-beta(a)xemacs.org>.
(You can get the information from M-x package-get-info, but for some
files in a package it may be inaccurate. The definitive reference is
the MAINTAINERS file in the top directory of the package source.)
Regarding the patch, for people using old-c-mode the menu is probably
correct. So the patch should be somewhat complicated, supplying an
option depending on which C mode is in use.
The XEmacs user manual should not refer to features supplied by
external (and semi-obsolete!) packages, of course, so a manual patch
is very welcome.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

There's a mistake in an example the the section of the lispref on Menu
Accelerators: the text refers to a different accelerator than is actually
in the code. Here's a patch!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

One symptom I forgot in describing the XEmacs crashes.
They happen when you click on any menu item.
If you don't click on any menu items (so as to keep working on solving the
problem, your new menu item would appear on the menu bar, and maybe
a minute or two later your new menu item would disappear, and then
wait 30 seconds or so and reappear, for a little while, then disappear
again.
Kind of a Flying Dutchman Menu Item.
Per Byrel, to replicate this one, just make any top-level *empty* menu item.
It shows up, then doesn't, then does...
The patch doesn't fix this, this is separate,
it still exists in Linux, but sorry, not XEmacs in Window 7.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

If it's just a coding style patch, then I think it may be ill-advised. If you look at how editres is implemented, most of the res_labels have formatting characters in them. See for instance
http://stuff.mit.edu/afs/sipb/project/hp/x11r5/lib/app-defaults/Editres
The lines containing "label" are initializing the res_labels array.
On Fri, Dec 21, 2012 at 2:28 AM, Mats Lidell <matsl(a)xemacs.org> wrote:
> I think it is just a coding style patch. It is bad practice to have a
> format string from a variable in case you'll get a % in there
> somehow. So better guard against that an use a simple "%s" as
> format. Maybe compilers even warn if you don't supply at least three
> args to sprintf!?
I've never seen such a warning.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta