June 1998 - XEmacs-Beta - XEmacs Mailing List Archives

SL Baur

The XEmacs Gnus package has been updated to Gnus-5.6.20. package-get-base fodder is: (gnus (standards-version 1.0 version "1.20" author-version "5.6.20" date "1998-06-27" build-date "1998-06-27" maintainer "XEmacs Development Team <xemacs-beta(a)xemacs.org>" distribution stable priority medium category "comm" dump nil description "The Gnus Newsreader and Mailreader." filename "gnus-1.20-pkg.tar.gz" md5sum "8f9bb83d15bae3d98f3ff718eb02321a" size 1691816 provides (gnus message) requires (gnus w3 mh-e mailcrypt rmail mail-lib xemacs-base) type regular ))

1 participants
0 comments

skip-syntax-backward dies while in ediff 27 years

Jim Radford

If I do a find-function or C-h f in a highlighted ediff difference region I consistently get the following crash: Lisp backtrace follows: skip-syntax-backward("_w") # (unwind-protect ...) # (unwind-protect ...) # bind (stab) byte-code("..." [syntax-table stab ((set-syntax-table stab)) set-syntax-table copy-syntax-table emacs-lisp-mode-syntax-table zerop skip-syntax-backward "_w" ?w ?\_ forward-sexp -1 "`'" nil read obj fboundp] 4) # (condition-case ... . ((error))) function-at-point() # bind (variable-p) find-function-read() call-interactively(find-function) # (condition-case ... . error) # (catch top-level ...) GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (sparc-sun-solaris2.5), Copyright 1996 Free Software Foundation, Inc... Core was generated by `./src/xemacs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/dt/lib/libXm.so.3...done. Reading symbols from /local/misc/lib/libtiff.so...done. Reading symbols from /local/gnu/lib/libpng.so.2...done. Reading symbols from /local/kde/lib/libjpeg.so.6...done. Reading symbols from /local/gnu/lib/libz.so.1.0.4...done. Reading symbols from /local/xcontrib/lib/libXpm.so.4.9...done. Reading symbols from /usr/openwin/lib/libtt.so.2...done. Reading symbols from /usr/openwin/lib/libXmu.so.4...done. Reading symbols from /usr/openwin/lib/libXt.so.4...done. Reading symbols from /usr/openwin/lib/libXext.so.0...done. Reading symbols from /usr/openwin/lib/libX11.so.4...done. Reading symbols from /usr/lib/libdl.so.1...done. Reading symbols from /local/kde/lib/libgdbm.so.1...done. Reading symbols from /usr/lib/libintl.so.1...done. Reading symbols from /usr/lib/libkvm.so.1...done. Reading symbols from /usr/lib/libkstat.so.1...done. Reading symbols from /usr/lib/libm.so.1...done. Reading symbols from /usr/lib/libsocket.so.1...done. Reading symbols from /usr/lib/libnsl.so.1...done. Reading symbols from /usr/lib/libelf.so.1...done. Reading symbols from /usr/lib/libc.so.1...done. ---Type <return> to continue, or q <return> to quit--- Reading symbols from /usr/lib/libw.so.1...done. Reading symbols from /usr/lib/libmp.so.1...done. #0 0xef134424 in kill () (gdb) where #0 0xef134424 in kill () #1 0x6f600 in fatal_error_signal (sig=11) at emacs.c:262 #2 <signal handler called> #3 bufpos_to_bytind_func (buf=0xb, x=0) at insdel.c:581 #4 0x118c9c in skip_chars (buf=0x6e0400, forwardp=0, syntaxp=1, string=119, lim=1) at buffer.h:985 #5 0x1192c0 in Fskip_syntax_backward (syntax=1612745732, lim=-1607827452, buffer=-1607827452) at search.c:941 #6 0x76490 in funcall_recording_as (recorded_as=539374972, nargs=1, args=0xefffe3fc) at eval.c:3193 #7 0x767c8 in Ffuncall (nargs=2, args=0xefffe3fc) at eval.c:3238 #8 0x51ad8 in Fbyte_code (bytestr=1612745516, vector=-2145350752, maxdepth=16) at bytecode.c:416 #9 0x75f98 in Feval (form=1075874588) at eval.c:3063 #10 0x73e8c in condition_case_1 (handlers=1075874860, bfun=0x75850 <Feval>, barg=1075874588, hfun=0x73ed8 <run_condition_case_handlers>, harg=-1607827452) at eval.c:1653 #11 0x74014 in condition_case_3 (bodyform=1075874588, var=-1607827452, handlers=1075874860) at eval.c:1715 #12 0x51f98 in Fbyte_code (bytestr=1612745440, vector=-2145350908, maxdepth=4) at bytecode.c:576 #13 0x7734c in funcall_lambda (fun=539004112, nargs=0, arg_vector=0xefffecac) at eval.c:3597 #14 0x76774 in funcall_recording_as (recorded_as=539004112, nargs=0, args=0xefffeca8) at eval.c:3214 ---Type <return> to continue, or q <return> to quit--- #15 0x767c8 in Ffuncall (nargs=1, args=0xefffeca8) at eval.c:3238 #16 0x51ad8 in Fbyte_code (bytestr=1618751100, vector=-2139357184, maxdepth=8) at bytecode.c:416 #17 0x7734c in funcall_lambda (fun=545421228, nargs=0, arg_vector=0xefffee48) at eval.c:3597 #18 0x76fd0 in apply_lambda (fun=545421228, numargs=0, unevalled_args=-1607827452) at eval.c:3501 #19 0x76114 in Feval (form=1082971972) at eval.c:3085 #20 0x5334c in Fcall_interactively (function=-1606357932, record_flag=-1607827452, keys=-1607827452) at callint.c:339 #21 0x75160 in Fcommand_execute (cmd=-1606357932, record=-1607827452, keys=-1607827452) at eval.c:2584 #22 0xa9368 in execute_command_event (command_builder=0x407640, event=543770204) at event-stream.c:4346 #23 0xa9918 in Fdispatch_event (event=543770204) at event-stream.c:4637 #24 0x5ab54 in Fcommand_loop_1 () at cmdloop.c:579 #25 0x5a964 in command_loop_1 (dummy=-1607827452) at cmdloop.c:494 #26 0x73e8c in condition_case_1 (handlers=-1607827356, bfun=0x5a940 <command_loop_1>, barg=-1607827452, hfun=0x5a28c <cmd_error>, harg=-1607827452) at eval.c:1653 #27 0x5a3a0 in command_loop_3 () at cmdloop.c:256 #28 0x5a3c8 in command_loop_2 (dummy=-1607827452) at cmdloop.c:267 #29 0x73b24 in internal_catch (tag=-1607749532, func=0x5a3bc <command_loop_2>, arg=-1607827452, threw=0x0) at eval.c:1328 #30 0x5a5d0 in initial_command_loop (load_me=369596) at cmdloop.c:305 ---Type <return> to continue, or q <return> to quit--- #31 0x709dc in xemacs_21_0_sparc_sun_solaris2_5 (argc=1, argv=0xeffff92c, envp=0xeffff934, restart=2568036) at emacs.c:1702 #32 0x71120 in main (argc=0, argv=0xeffff92c, envp=0xeffff934) at emacs.c:2119

1 participants
0 comments

To ChangeLog or not to ChangeLog, that is the question 27 years

SL Baur

It has been suggested that as mild an improvement in code documentation as adopting full FSF Emacs-style ChangeLogs is hurting XEmacs development. I don't think any patch should patch should be applied to the code base without a ChangeLog entry. I don't know how Richard manages to keep with the minute details of every single patch, but I can't. I can manage in the case of (relatively) simple patches. Large patches are problematic. This is a vote, majority wins. Voting ends July 5th at Midnight (US/Pacific daylight time -- -0700). This announcement will not be reposted by me. Send yes votes to <cl-yes(a)vmailer.xemacs.org>, send no votes to <cl-no(a)vmailer.xemacs.org>. Questions to <xemacs-beta(a)xemacs.org>.

6 participants
5 comments

Re: XEmacs 21.0b46, Packages 27 years

Adrian Aichner

>>>>> "John" == John W Jones <jj(a)hobbes.la.asu.edu> writes: John> I sent a patch many moons ago to fix this problem. In some sense When and where did you send it? I couldn't find it. Please re-send it if possible. Thanks, Adrian John> packge-get-update-all does not currently do the right thing. It uses John> package-get-all which fetches dependent packages. This is bad since John> someone may intentionally not have a certain package even though it is John> declared as required by a package they do have (e.g., vm is not really John> needed to use efs). Fetching of dependent packages should be done at John> the time a user initially gets a package. John> So, packge-get-update-all should use package-get in place of John> package-get-all (works like package-get-all, but it does not also get John> dependent packages). If a dependent package requires updating, that John> will still be picked up. Moreover, by making this change, we would John> fix the problem of getting some packages many times when using John> package-get-update-all. John> John Jones John> --------------------------------------------------------------- John> Department of Mathematics Office: PSA 729 John> Arizona State University Phone: 965-3725 John> Tempe, AZ 85287-1804 FAX: 965-8119 John> URL: http://math.la.asu.edu/~jj e-mail: JJ(a)asu.edu John> --------------------------------------------------------------- -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail aichner(a)ecf.teradyne.com

1 participants
0 comments

Re: To ChangeLog or not to ChangeLog, that is the question 27 years

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > Scenario: J. Random Luser has been lurking on xemacs-beta and comes > up with his first patch to XEmacs. Here it is: [...] Martin, I can relate to your point, but I see some problems in it. > Maintainer to JRL: Could you add a ChangeLog for that change? > JRL to Maintainer: You're kidding, right? > Maintainer to JRL: Nope. > JRL to Maintainer: F!(* you. > > Did we just lose an XEmacs contributor? No. I wouldn't want to work with a person who says `Fine You' so easily anyway. > I currently have submitted patches that have not been applied due to > lack of ChangeLog. I believe this is wrong. I also believe it's wrong when Kyle harasses people about their changelogs not being precise enough. Yes, changelogs serve a very useful purpose, but they are not religion. When a changelog addition is not needed, it's not needed. For example, none of my NEWS patches contain a changelog entry. Why? Because it's not needed. > These are the kind of changes that don't deserve a ChangeLog, > i.e. adding ChangeLog entriess would make XEmacs LESS maintainable. > If the yes votes win, the likelihood that I will be contributing in > the future will drop significantly. Oh come on Martin! If you have reasons to drop out, do so. But don't pretend it to be because of ChangeLogs. :-( -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Manic depression is cool... your body can make its own drugs.

1 participants
0 comments

Re: package-get-base to RPM spec converter 27 years

Oliver Graf

Oliver Graf <ograf(a)fga.de> writes: > It's sort of a loop: gnus requires rmail requires tm requires gnus,vm,rmail > etc. > > In my eyes the following is a standart install scenario: > The user wants a mail-reader, so he selects one of gnus, vm, or rmail. > No he also wants support for MIME encoded messages. He finds tm and tries to > install it. But RPM (or package-get) will tell him that he also needs rmail > and vm, simply because tm also supports them... These are the packages which 'hurt' my dependency 'feeling'. All these packages are primary utility packages to some other packages (mailreaders). And cause we have more than one mail/news reader they require all mail/news readers they support. And this is the thing I think is wrong (or perhaps not elegant ;-) I've also attached a file which shows how it should be (as I think about requirements). Regards, Oliver.

1 participants
0 comments

Re: package-get-base to RPM spec converter 27 years

Oliver Graf

SL Baur <steve(a)vmailer.xemacs.org> writes: > Oliver Graf <ograf(a)fga.de> writes: > > ... > > XEmacs will be dumped with: > > xemacs-base > > mail-lib > > fsf-compat > > vm > > vc > > None of the above except VM are required for dumping. In general, the vc and vc-cc also set dump to t. Is this a typo? > XEmacs binary should not be required to be redumped after installing > packages -- they should Just Work. That's the whole point of loading > autoloads at run time instead of dump time. fsf-compat is required by mule-base. So I thought I but it into the basic package. We should remember that an RPM package should be an easy to use package for users who don't want to compile, dump, or tinker with XEmacs. They just want something that works and is easy to install. > Before we release we want to get rid of all the package `dumped-lisp.el' > files for flexibility. VM is probably an easy fix. > > > XEmacs-mule will be dumped with the same, plus: > > mule-base > > leim > > egg-its (only if WNN is compiled in) > > egg-its can also be used with SJ3. SJ3 support is entirely Lisp-based. > > > edict (whats this?) > > A Japanese dictionary. _Very cool_ ... > > > skk (whats this?) > > A Lisp-based Japanese input package. But they need to be dumped. Correct? So they must go into the XEmacs-mule RPM. Perhaps I will make better a XEmacs and a XEmacs-nomule package. Cause mule should be the standart to use. Wrong? Regards, Oliver. P.S.: What about those cyclic requires? gnus -> rmail -> tm -> rmail & gnus

1 participants
0 comments

How can I color the vertical dividers? 27 years

Karl M. Hegbloom

3 participants
2 comments

Re: To ChangeLog or not to ChangeLog, that is the question 27 years

Lars Magne Ingebrigtsen

Martin Buchholz <martin(a)xemacs.org> writes: > My feeling is that ChangeLogs are a good thing, for MOST BUT NOT ALL > changes, and that contributions should not be categorically turned > down due to lack of ChangeLogs. I think this is just Common Sense. I think ChangeLog entries are nice to have, and all changes that are user-visible should have ChangeLog entries. (That is -- all code changes should have entries; changes to indentation, comments (etc.) shouldn't necessarily have.) What I've started doing lately with Gnus patches that I get is including a standard response at the end of the aqc of patches that are ChangeLog-less saying something like "In the future, could you include ChangeLog entries?", and then I write the ChangeLog entries myself. However, XEmacs is a project of several magnitudes larger than Gnus, so I understand the temptation to reject ChangeLog-less patches. -- (domestic pets only, the antidote for overdose, milk.) larsi(a)ifi.uio.no * Lars Magne Ingebrigtsen

2 participants
1 comments

Re: package-get-base to RPM spec converter 27 years

SL Baur

Oliver Graf <ograf(a)fga.de> writes: ... > XEmacs will be dumped with: > xemacs-base > mail-lib > fsf-compat > vm > vc None of the above except VM are required for dumping. In general, the XEmacs binary should not be required to be redumped after installing packages -- they should Just Work. That's the whole point of loading autoloads at run time instead of dump time. Before we release we want to get rid of all the package `dumped-lisp.el' files for flexibility. VM is probably an easy fix. > XEmacs-mule will be dumped with the same, plus: > mule-base > leim > egg-its (only if WNN is compiled in) egg-its can also be used with SJ3. SJ3 support is entirely Lisp-based. > edict (whats this?) A Japanese dictionary. _Very cool_ ... > skk (whats this?) A Lisp-based Japanese input package.

1 participants
0 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 June 1998