February 2001 - XEmacs-Beta - XEmacs Mailing List Archives

Ben Wing

I've compiled a short list of bugs that I consider to be showstoppers for the 21.0 release. It's located at: http://devel.xemacs.org/xemacs/showstoppers.html Ben (typed by Martin)

6 participants
6 comments

Re: Commenting out code in lisp 7 years, 3 months

Adrian Aichner

>>>>> "Paul" == Paul Krause <paulkrause1(a)mediaone.net> writes: Paul> Adrian Aichner <adrian(a)xemacs.org> writes: >> >> Do we want to make C-u M-x comment-region smarter? >> Paul> No! Make indentation smarter. If a comment begins in column Paul> 1, don't Paul> indent it when reindenting a region. This solves the Paul> problem without Paul> style-changes or hacks to comment-region. >> Paul> Have I overlooked anything? >> >> This, maybe? >> >> (Info-goto-node "(xemacs)Comments") >> >> Adrian Paul> Could you be a little more specific? I don't what you're Paul> referring to. Maybe this? Paul> You can also use `Meta-;' to align an existing comment. If a line Paul> already contains the string that starts comments, `M-;' just moves Paul> point after it and re-indents it to the conventional place. Paul> Exception: Paul> comments starting in column 0 are not moved. Yes, that, and also the following paragraph. Some major modes have special rules for indenting certain kinds of comments in certain contexts. For example, in Lisp code, comments which start with two semicolons are indented as if they were lines of code, instead of at the comment column. Comments which start with three semicolons are supposed to start at the left margin. Emacs understands these conventions by indenting a double-semicolon comment using TAB and by not changing the indentation of a triple-semicolon comment at all. You have a valid point, though. single-; comments srarting in column 0 should not be moved and comment-region would work as advertised! You opened my eyes! To All: Isn't this what we should do? Martin? Stephen? Best regards, Adrian Paul> The trouble is, it doesn't work as documented. Here's a sample. Paul> ;;; header comment Paul> ;; This function is just an example. Paul> ;;; Here either two or three semicolons are appropriate. Paul> (defun foo (x) Paul> ;;; And now, the first part of the function: Paul> (lambda (foo bar) Paul> (if (foo bar) Paul> 'bif Paul> 'baz)) Paul> ;; The following line adds one. Paul> (1+ x)) ; This line adds one. Paul> ;; This function is just an example. Paul> ;;; Here either two or three semicolons are appropriate. Paul> (defun foo (x) Paul> ;;; And now, the first part of the function: Paul> ;; The following sexp is commented out using comment-region. Paul> ; (lambda (foo bar) Paul> ; (if (foo bar) Paul> ; 'bif Paul> ; 'baz)) Paul> ;; The following line adds one. Paul> (1+ x)) ; This line adds one. Paul> I get the same indentation using either M-; or C-M-q. Paul> Testing using xemacs -vanilla on Paul> XEmacs 21.2 (beta37) "Pan" (win32) of Sun Dec 03 2000 on PAULKRAUSE Paul> as well as Paul> XEmacs 21.0 "20 minutes to Nikko" (win32) of Fri Mar 26 1999 on Paul> BLACKBIRD Paul> (which I just happen to have lying around) -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

4 participants
3 comments

pcl-cvs buglet 23 years

Neal D. Becker

I marked a bunch of files in pcl-cvs mode. Then I chose "undo changes" from the menu. It prompts "Delete 8 files?". Rather misleading.

4 participants
13 comments

GTK+ and 21.2 23 years, 6 months

Doug Alcorn

After seeing the "Call for Testers" for 21.2/22.0, I thought I would jump on the bandwagon. I'm primarily interested in the GTK+ port. So, I went out and grabbed the latest xemacs from cvs with: $ cvs -d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot checkout -d xemacs-21.2 -r release-21-2 xemacs When I run ./configure, I don't see anything about enabling gtk+. Has the gtk+ port been merged in with 21.2 yet? Is it the default toolkit? How do I compile xemacs with GTK+ support? -- (__) Doug Alcorn (mailto:doug＠lathi.net http://www.lathi.net) oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543 |_/ If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait.

4 participants
3 comments

Re: gud.el broken or is it just me? 23 years, 7 months

SL Baur

Aki Vehtari <Aki.Vehtari(a)hut.fi> writes in xemacs-beta(a)xemacs.org: ... > Btw. gud.el in XEmacs is dated 1993 and gud.el in emacs-20.3 is > dated 1998. Unfortunately gud.el in emacs-20.3 does not work in > XEmacs and I don't know much work it would need to make it work and I've done the initial port of gud.el to XEmacs. It mostly works[1], but it sorely lacks the functionality in gdbsrc.el. Making a gudsrc.el mode is on my list of things to do. It was in ftp://altair.xemacs.org/pub/xemacs-futures/ when I was on the 'net. It was delayed integration into the XEmacs packages pending 21.0 release. I also have a ported cua-mode.el to integrate. NOTE: The gud.el and cua-mode.el XEmacs portings are courtesy of Altrasoft, Inc. Thank you Altrasoft. Footnotes: [1] I have a report that my port does not work on Solaris with dbx.

2 participants
1 comments

what happened to beopen.com / InfoDock? 23 years, 9 months

William M. Perry

http://www.beopen.com/ gives you a rousing little web page informing you: This domain is for sale! Please email domains(a)beopen.com for more information. Ditto for http://www.gnulinux.org/ Anybody know what led up to this, and what will happen to the infodock code? -bp

5 participants
4 comments

Re: Utility to submit patches against CVS 23 years, 9 months

Adrian Aichner

>>>>> "APA" == Adrian Aichner <Adrian.Aichner(a)t-online.de> writes: >>>>> "drv" == Didier Verna <didier(a)xemacs.org> writes: drv> Red Alert ! Major fuckage in XEmacs session drv> ... Probable overheat in drv> the byte compiler drv> ... All systems alted. Mister La Forge, report to the drv> drv> bridge. drv> Let's try again: APA> Much better, patcher.el beamed up in one piece now and is soon to get APA> out of quarantine. APA> I haven't looked at it yet. Hello Didier, the model of project definition you use in patcher.el suits me well. I have tested it a bit and had to start a new XEmacs to be able to send you this mail :-) The defun trickery inside (eval-when-compile is to blame. Another issue: Is patcher-mail suppose to create a fresh mail/message buffer and fill it in correctly? It doesn't for me when setting patcher-mail-method ot sendmail or message. For sendmail the diff command output is inserted just after the "To:" header. Setting the method to gnus does not work at all with gnus-version "Gnus v5.8.7" Why not use (compose-mail ...) instead? See build-report or pxp. I would definitely like to see patcher.el added to xemacs-devel once these child sicknesses are overcome. Best regards, Adrian APA> Best regards, APA> Adrian APA> -- APA> Adrian Aichner APA> mailto:adrian＠xemacs.org APA> http://www.xemacs.org/ -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

2 participants
3 comments

[crash] delete a buffer shown in both X and tty frames 23 years, 9 months

Yoshiaki Kasahara

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta38) "Peisino,Ak(B" [Lucid] (i386-unknown-freebsd4.2, Mule) of Wed Dec 13 2000 on elvenbow.nc.kyushu-u.ac.jp configured using `configure --with-mule --without-xim --error-checking=all --debug --with-xfs --with-widgets=athena --without-canna --site-prefixes=/usr/local '--cflags=-g -O3 -pipe -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow'' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: xemacs -vanilla M-x make-frame-on-tty C-x b test (in the X frame) C-x b test (in the tty frame) C-x k (in the X frame) ** crash ** It is repeatable. It won't crash when doing C-x k in the tty frame. Lisp backtrace follows: # (condition-case ... . error) # (catch top-level ...) C backtrace follows: (gdb) where #0 0x286323e0 in kill () from /usr/lib/libc.so.4 #1 0x80bb823 in fatal_error_signal (sig=6) at emacs.c:535 #2 0xbfbfffac in ?? () #3 0x80be869 in assert_failed (file=0x824d9a7 "eval.c", line=1885, expr=0x824d508 "abort()") at emacs.c:3214 #4 0x80c12f1 in signal_1 (sig=137300068, data=142340244) at eval.c:1885 #5 0x80c2791 in error (fmt=0x8285dc0 "Marker does not point anywhere") at eval.c:2052 #6 0x8194e66 in marker_position (marker=141246172) at marker.c:354 #7 0x81afc17 in redisplay_window (window=141753344, skip_selected=0) at redisplay.c:5896 #8 0x81b098c in redisplay_frame (f=0x8738400, preemption_check=0) at redisplay.c:6393 #9 0x81b0b6f in redisplay_device (d=0x870a600, automatic=1) at redisplay.c:6467 #10 0x81b0edd in redisplay_without_hooks () at redisplay.c:6556 #11 0x81b8ee6 in redisplay () at redisplay.c:6613 #12 0x8114eca in Fnext_event (event=141418308, prompt=137299972) at event-stream.c:2176 #13 0x80a2ce9 in Fcommand_loop_1 () at cmdloop.c:574 #14 0x80a2f96 in command_loop_1 (dummy=137299972) at cmdloop.c:494 #15 0x80cac25 in condition_case_1 (handlers=137300068, bfun=0x80a2f58 <command_loop_1>, barg=137299972, hfun=0x80a3008 <cmd_error>, harg=137299972) at eval.c:1651 #16 0x80a30f7 in command_loop_2 (dummy=137299972) at cmdloop.c:256 #17 0x80cab24 in internal_catch (tag=137384396, func=0x80a30bc <command_loop_2>, arg=137299972, threw=0x0) at eval.c:1317 #18 0x80a256e in initial_command_loop (load_me=137299972) at cmdloop.c:305 #19 0x80bcb9f in xemacs_21_2_b38_i386_unknown_freebsd4_2 (argc=2, argv=0xbfbff5b4, envp=0xbfbff5c0, restart=0) at emacs.c:2253 #20 0x80bead1 in main (argc=2, argv=0xbfbff5b4, envp=0xbfbff5c0) at emacs.c:2682 #21 0x80808e9 in _start () -- Yoshiaki Kasahara Computing and Communications Center, Kyushu University kasahara(a)nc.kyushu-u.ac.jp

3 participants
12 comments

RFC: The Great Trunk Move in CVS 23 years, 9 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

Possible GPL violation in package distribution 23 years, 9 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

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