December 2012 - XEmacs-Beta - XEmacs Mailing List Archives

buildbot failure in XEmacs on x86 gentoo cfg1 11 years, 11 months

Stephen J. Turnbull

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

2 participants
6 comments

Menu :active tag 11 years, 11 months

Byrel Mitchell

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

2 participants
2 comments

New INSTALL file 11 years, 11 months

Robert Royar

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

3 participants
3 comments

GSoC 2013 (reminder) 11 years, 11 months

Stephen J. Turnbull

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

1 participants
0 comments

Summary of XEmacs Issue Tracking System Issues 11 years, 11 months

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2012-12-18 - 2012-12-25) XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 552 open ( +0) / 294 closed ( +0) / 846 total ( +0) Open issues with patches: 13 Average duration of open issues: 1317 days. Median duration of open issues: 1397 days. Open Issues Breakdown new 233 ( +0) deferred 6 ( +0) napping 3 ( +0) verified 56 ( +0) assigned 153 ( +0) committed 19 ( +0) documented 3 ( +0) done/needs work 17 ( +0) Issues Now Closed (4) _____________________ MX service issues 1785 days http://tracker.xemacs.org/XEmacs/its/issue277 stephen Required fields need emphasis, missing field message confusing 1774 days http://tracker.xemacs.org/XEmacs/its/issue292 stephen [Bug: 21.5-b29] list-matching lines 553 days http://tracker.xemacs.org/XEmacs/its/issue777 stephen Re: Problem with forward-sexp. 505 days http://tracker.xemacs.org/XEmacs/its/issue795 stephen _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

Fwd: Menu :active tag 11 years, 11 months

Byrel Mitchell

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

2 participants
1 comments

Re: finding the function mark-c-function 11 years, 11 months

Stephen J. Turnbull

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

1 participants
0 comments

Small documentation error 11 years, 11 months

Byrel Mitchell

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

1 participants
1 comments

re: XEmacs crashes and patch 11 years, 11 months

steven Mitchell

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

1 participants
0 comments

Re: editres patch 11 years, 11 months

Charles Waldman

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

3 participants
2 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 December 2012