March 2001 - XEmacs-Beta - XEmacs Mailing List Archives

syms_of_<module> vs. general-slots.h 24 years, 8 months

Stephen J. Turnbull

>>>>> "-BP" == William M Perry <wmperry(a)aventail.com> writes: -BP> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: >> (Stylistically, many of the symbols in your syms_of_* functions >> probably belong in general-slots.h.) -BP> Do you have a list? I wasn't sure when to use -BP> general-slots.h. Anytime you need to `extern Lisp_Object -BP> Qfoo;'? Ask Ben if he has any ideas about guidelines, but I would say this should follow the usual "no prefix means `general' namespace." Eg, unless commented otherwise, all of the following look pretty generic to me, so candidates for general-slots.h. But it really is a matter of style. If you think it's unlikely to be independently defsymbol'ed in another module, keep it in the module it's relevant to. Your guess is better than mine. ;-) void syms_of_event_gtk (void) { defsymbol (&Qkey_mapping, "key-mapping"); /* OK, Emacs lispers will keymap, not key-mapping */ defsymbol (&Qsans_modifiers, "sans-modifiers"); /* fonts might use this */ } void syms_of_gui_gtk (void) { #ifdef HAVE_POPUPS /* probably non-generic? */ defsymbol (&Qmenu_no_selection_hook, "menu-no-selection-hook"); #endif } void syms_of_frame_gtk (void) { /* your plan is that this kind of stuff will be shared, right? if it's abstracted into a separate .c file, put it there. but if the interface is all in .h, these go to general-slots.h */ defsymbol (&Qwindow_id, "window-id"); defsymbol (&Qtext_widget, "text-widget"); defsymbol (&Qcontainer_widget, "container-widget"); defsymbol (&Qshell_widget, "shell-widget"); defsymbol (&Qdetachable_menubar, "detachable-menubar"); /* Non-defsymbols omitted */ } void syms_of_ui_gtk (void) { /* Non-defsymbols omitted */ defsymbol (&Qemacs_ffip, "emacs-ffi-p"); /* OK, these are gtk-specific */ defsymbol (&Qemacs_gtk_objectp, "emacs-gtk-object-p"); defsymbol (&Qemacs_gtk_boxedp, "emacs-gtk-boxed-p"); defsymbol (&Qvoid, "void"); /* ... no way! */ } -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

2 participants
1 comments

RFC: The Great Trunk Move in CVS 24 years, 8 months

Stephen J. Turnbull

I've thought moderately carefully about the move-devel-to-trunk issue. I've come to the following conclusions. I would appreciate comments from anybody who's done this kind of thing before. I've done a little experimentation but I can't say I'm terribly confident of any of the analysis yet. Target date is mostly up to Martin, I guess, once Vin is set up. But because of the discontinuity imposed by my current practice of maintaining a temporary devel branch, we should do it fairly soon after the 21.4 release. 1. Vin can safely make the move of stable/21.1 OFF the trunk at any time. This is very important. The method is something like (1) doing a release. This involves making a release tag, say r21-1-16. (2) make a branch point tag (purely for documentation) as cvs rtag -r r21-1-16 21_1_moved_to_branch_at_21_1_16 xemacs cvs rtag -b -r 21_1_moved_to_branch_at_21_1_16 release-21-1 xemacs (3) moving his workspace on to the branch with cvs update -r release-21-1 (4) announcing that the stable trunk is dead, and all people using the stable code base must move to the branch and except in the event that he deletes his work space (when he must use a branch tag to check out), henceforth everything goes as usual for Vin. Note that people who use release tags rather than the stable branch to update their trees will notice no difference at all. Depending on how cautious we are, we could cvs remove all the files at that point, or after, to forcibly notify people that the stable branch has moved. Note: this removal is purely documentation for testers; a little experimentation with a toy repository has convinced me that unless you look carefully at cvs log, you can't see any difference between a file that has been removed and readded and one that was there all along. Until a file is changed, CVS annotate output is weird, though; the latest version mentioned in the annotations will be less than working version. Weird feeling. And all annotations will get the re-added version, unless you're careful to track back on the old devel branch. Whether that's a good feature is a debatable point. So committers and reviewers may notice anomolies, and there will be some diffculty in tracking things via CVS. But our ChangeLogs are generally pretty good, and the systematic tagging with each release (beta and stable) should make recovering old patches fairly easy. Step (1), (2), and (3) can actually be done retroactively to any tag, say r21-1-14, and then use cvs update -j r21-1-14 -j r21-1-16 (the second -j is simply paranoia). I think it does make sense to do things at "release epoch." 2. At release of 21.4 a node is created at the tip of the release-21-2 branch, with a branch point tag and the release-21-4 branch. This will have an ugly branch number, but after that devel will be on the trunk so that should be the worst. 3. The current unstable branch will just die on release of 21.4. Once the release-21-4 branch is created, we can safely cvs remove all the files from release-21-2. Note that CVS history of all of these branches will maintain continuity. 4. After a decent interval, delete all the files from a working directory containing the trunk tree, cvs remove them all, then copy all the files from a temporary-21-5 tree. Then cvs add in each directory by hand (or script). There doesn't seem to be an easy way to do this, or to arrange that CVS directly commit a temporary-21-5 tree to the trunk, but I'll keep looking and experimenting. The trunk will show a severe discontinuity in various history functions. This isn't really that bad, though; maybe a few scripts would help. The main thing is that we have to remember about stuff on the temporary devel branch, but even that can be worked around by merging the release branch to the trunk, then moving all the missing ChangeLogs to the top (so that they will appear at the top of the trunk ChangeLog after the temp devel branch is merged to the new trunk). Add a remark that "these changelogs refer to patches checked in to the temporary devel branch, you can get at them with cvs diff -r branch-point -r trunk-move-point", and I think we're covered. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

3 participants
2 comments

manual-entry bogosity 24 years, 8 months

Glynn Clements

The current version of manual-entry, when used interactively, performs an re-search-backward through the whole $#＠%ing buffer in an attempt to find a default. The attached patch, whilst being a quick hack, does at least make manual-entry usable again (unlike before: try the existing version from a shell-mode buffer which contains the output from a few dozen builds of substantial packages). -- Glynn Clements <glynn(a)sensei.co.uk> --- xemacs-packages/oa/edit-utils/man.el Tue Nov 14 02:41:09 2000 +++ xemacs-packages/oa/edit-utils/man.el.new Tue Mar 6 21:37:53 2001 ＠＠ -190,7 +190,8 ＠＠ (if (re-search-backward "\\sw\\|\\s_" nil t) (forward-char)) (re-search-backward - "\$\\sw\\|\\s_\$([0-9]+[A-Za-z]*\\=" nil t) + "\$\\sw\\|\\s_\$([0-9]+[A-Za-z]*\\=" + (- (point) 1000) t) (skip-syntax-backward "w_") (point)) (progn

1 participants
0 comments

Re: Cannot build from CVS under Cygwin 24 years, 8 months

Andy Piper

I have this also. I don't have time to debug it right now. andy At 01:51 PM 3/6/01 -0500, Bush, David wrote: >While trying to add my $0.02 to the discussion on GTK, pdump >and Cygwin/NT, I discovered that I have a more basic problem >in building in a tree freshly checked out from CVS. The build >hangs at the dump-elcs step as soon as temacs starts to byte >compile the first lisp file. The temacs is running: >./temacs -nd -batch -l >/cygdrive/c/Xemacsdevel/r21-2-44/src/../lisp/update-elc.el > >and gets as far as: >Bootstrapping from temacs... >Static heap usage: 4551252 of 8650752 -- 4003k wasted >Compiling /cygdrive/c/Xemacsdevel/r21-2-44/lisp/auto-autoloads.el > >And then it hangs. I've tried to bring up temacs using the run-temacs >command line, but that fails because it cannot find ../lib-src/DOC. >It is not possible to attach to the looping temacs and learn >anything. > >david

1 participants
0 comments

Cannot build from CVS under Cygwin 24 years, 8 months

Bush, David

While trying to add my $0.02 to the discussion on GTK, pdump and Cygwin/NT, I discovered that I have a more basic problem in building in a tree freshly checked out from CVS. The build hangs at the dump-elcs step as soon as temacs starts to byte compile the first lisp file. The temacs is running: ./temacs -nd -batch -l /cygdrive/c/Xemacsdevel/r21-2-44/src/../lisp/update-elc.el and gets as far as: Bootstrapping from temacs... Static heap usage: 4551252 of 8650752 -- 4003k wasted Compiling /cygdrive/c/Xemacsdevel/r21-2-44/lisp/auto-autoloads.el And then it hangs. I've tried to bring up temacs using the run-temacs command line, but that fails because it cannot find ../lib-src/DOC. It is not possible to attach to the looping temacs and learn anything. david

1 participants
0 comments

Font-lock bug in 21.2.45 24 years, 8 months

Raymond Toy

The current version of font-locking font-locks the following file incorrectly. The first #+:cmu is fontified as if it were a comment, but it's not. This doesn't happen with 21.2.44. To see this, I started xemacs -vanilla. Load the file. (The buffer is not fontified.) Kill the buffer. Load the file again. Now the buffer is fontified but fontified incorrectly. If you do the same with 21.2.44, #+:cmu and following is fontified correctly as lisp code, not a comment. Perhaps it's getting confused by the |# in column 0? Ray

1 participants
0 comments

XEmacs/GTK 21.2.45 checked in... 24 years, 8 months

William M. Perry

The 6 pdump cygwin builds I did late last night / this morning all seem to work. The code is checking in as I write this, and I will be rebooting to windows to finish the build run and submit my build reports. It takes a long time to build with the source on an SMB share. :) Is anybody else having problems getting the netinstall directory to build in a separate build directory? I've turned it off temporarily so my makefile and auto-build-report-submission scripts will run to completion. -Bill P.

4 participants
5 comments

Possible GPL violation in package distribution 24 years, 8 months

James LewisMoss

OK. I hate to bring this up, but looking at it the person who reported this bug to me looks to have a point. Neither the *sumo* files nor the *pkg.tar.gz files have the scripts/makefiles/whatever to rebuild the .elc files from the .el files. I think reasonable people can disagree on this issue and I hate bringing it up, but there seems to be a valid point in this email. Possible solutions I see: 1) Include *pkg-src.tar.gz files with the complete source. 2) Include the makefiles needed to rebuild in the *pkg.tar.gz (and *sumo*). Anyway. Sorry to bring up this issue, but it seemed necessary to do so. Jim -- ＠James LewisMoss <dres(a)debian.org> | Blessed Be! ＠ http://jimdres.home.mindspring.com | Linux is kewl! ＠"Argue for your limitations and sure enough, they're yours." Bach

7 participants
14 comments

Re: xemacs v21.2 beta 24 years, 8 months

Vin Shelton

Bruce, Please send issues about beta releases to xemacs-beta(a)xemacs.org. Your issues: 1. I hope someone will look into this. 2. Works for me - I end up with a title of "zion.rcn.com:/home/acs *scratch*" 3. GTK has not yet been merged into the 21.2 sources. The release manager has not yet decided whether the GTK support is now ready for prime time. You can fetch the GTK branch from CVS using the tag '-r gtk-xemacs-21-2', I believe. Thanks, vin shelton bingalls(a)panix.com (Bruce Ingalls) writes: > I'm quite happy with the latest xemacs beta. > Here are some issues: > xemacs -debug-init > Still doesn't work. I would think that this one would be easy to get > working- just do a > xemacs -q > (setq debug-on-error 't) > (load-file ".xemacs/init.el") ;or equivalent > > Unfortunately, if I have errors in my .emacs, > xemacs -debug-init > loads without a peep, whereas plain > xemacs > complains. > > I set the following in my .emacs: > (defconst system-name (system-name)) > (setq frame-title-format > '(" " system-name ":" default-directory " %12b")) > which used to work fine. Now it is almost blank. > > Finally, I thought that the gtk code was merged in. Is there not an > option in configure, to build with gtk support? Is this simply missing > in configure.usage? > -- > EMacro remakes Emacs http://www.sourceforge.net/projects/emacro/

1 participants
0 comments

XSLT-process package updated to new version 24 years, 8 months

Ovidiu Predescu

Steve, I've updated the XSLT-process package in the xemacs-packages to a new version based on release 1.2.1, its latest stable release. A list of changes since the 1.1 release (1.0 for XEmacs) is included in the README file. I now see an error message comming out when I compile the .el file: While compiling toplevel forms in file /home/ovidiu/src/xemacs-packages/prog/xslt-process/lisp/xslt-process.el: !! Symbol's function definition is void ((defmethod-engine)) There is no reference of defmethod-engine in this package, so I assume there must be a problem in JDE or one of the packages it depends on. Regards, -- Ovidiu Predescu <ovidiu(a)cup.hp.com> http://orion.nsr.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

3 participants
2 comments

2025

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 March 2001