Description of problem: I have installed xemacs from cauldron (fully updated Alpha 2) (along with xemacs-extra, xemacs-el, xemacs-mule + dependencies) - no customisation. When I launch xemacs, it immediately fails with a seg fault Version-Release number of selected component (if applicable): xemacs-21.4.22 How reproducible: always Steps to Reproduce: 1. install xemacs 2. launch xemacs 3. Reproducible: Steps to Reproduce:
Created attachment 4359 [details] output when xemacs is launched from a console
Attachment 4359 mime type: application/octet-stream => text/plain
Created attachment 4362 [details] backtrace
CC: (none) => davidwhodgins
Assignee: bugsquad => nanardon
Investing efforts on fixing a bug on such a 5-year-old release looks like a loss of time. To avoid duplication of efforts: I have now done a local build of xemacs-21.5.34. Quite a lot of changes (essentially evident) in the spec file: now builds correctly, nothing dramatic in rmplint. There is though a series of issues to be pursued: - the newly built xemacs runs nicely, the present bug is gone, but has a successor: xemacs segfaults when I do Edit -> Find when Xemacs tries to pop up a window (saw nothing on this looking at what Fedora and Opensuse have done -> might be Mageia-specific?) - so far, I have thrown out all patches that were in 21.4.22 - still need to review which of them should be re-diffed into 21.5.34 - I needed to do the build with "with-mule=yes" - otherwise the build fails due to missing Quail (xemacs-leim package) - need to verify the consequences and consistency with policy - so far, I run the out-of-the-box xemacs, still need to find out why xemacs does not find my customization packages. I should find some, but rather limited, time to pursue this (and my skills are - more than rather - limited). If / once it works, I guess there should no problem to get xemacs-21.5.34 into Mageia 4 in spite of version freeze since the current xemacs is broken - right? Is this the right place to discuss building the new version? - looks too specific to go into the dev mailing list.
I have now locally built an xemacs-21.5.34 that does all I need and allows me - finally - to use Mageia-4 pre-releases as my production system. However the transition from 21.4.22 to 21.5.34 implies changes (at least with respect to customisation (and the typical xemacs user uses xemacs because of customisation) that are non-transparent to the user / to the site. This requires decisions / discussions which go beyond my "xemacs culture" and where the maintainer needs to be involved - for the moment, I will therefore not continue towards a cauldron build. Using my local build is also a lazy work-around for the find-segfault problem: I have my own menubar, and do not use the vanilla Find button. My principal difficulty looking at this problem is that I did not manage to convince xemacs that I need a core dump - without that, the Find button problem is difficult to tackle.
Created attachment 4503 [details] fixed Mandriva-customized initialisation file The bug is due to obsolete statements in the customised initialisation file from Mandriva. Two lines need to be commented out (in this attachment marked as ;;fixed ) - they are the reason for the core dump and are not necessary
Will this bug be fixed before Mageia-4 is released? In comparison to other distros, a broken xemacs would be a black mark (my local workaround is not fit for general use).
CC: (none) => remco
*** Bug 13856 has been marked as a duplicate of this bug. ***
CC: (none) => steve
There was no action in this report since over a year ago, is it still valid? If so, in which Mageia version do you still see it in cauldron and Mageia 5 or only Mageia 5? re-assigning to BugSquad, because nobody maintains xemacs now. Not yet CC'ing xemacs-committers, that can still be done if it's still valid
CC: (none) => marja11Assignee: nanardon => bugsquadWhiteboard: (none) => NEEDINFO
Still valid in Mageia 5 x86_64. I get a lisp backtrace and a segfault. If I run it under gdb, it doesn't crash, but the editor does not respond to any mouse or keyboard events.
Created attachment 7118 [details] lisp backtrace
(In reply to Dave Hodgins from comment #9) > Still valid in Mageia 5 x86_64. I get a lisp backtrace and a segfault. If I > run it under gdb, it doesn't crash, but the editor does not respond to any > mouse or keyboard events. (In reply to Dave Hodgins from comment #10) > Created attachment 7118 [details] > lisp backtrace Assuming it still valid for cauldron, too, because nothing happened to xemacs there since long before Mga5 got branched. http://svnweb.mageia.org/packages/cauldron/xemacs/current/SPECS/xemacs.spec?view=log Otoh, I don't understand how we can have a mga6 xemacs package in cauldron, if there wasn't even a rebuild after Mga5 was branched. The packages differ in size, too, on my local mirror: 24592476 Oct 18 2014 xemacs-21.4.22-26.mga5.i586.rpm 24582604 Jul 2 12:51 xemacs-21.4.22-26.mga6.i586.rpm 24632044 Oct 18 2014 xemacs-21.4.22-26.mga5.x86_64.rpm 24631200 Jul 2 12:51 xemacs-21.4.22-26.mga6.x86_64.rpm What do I miss? CC'ing some xemacs committers
CC: (none) => fundawang, luigiwalser, mageia, olav, pterjan, thierry.vignaudHardware: i586 => AllSource RPM: xemacs-21.4.22-22.mga4.src.rpm => xemacs-21.4.22-26.mga6, xemacs-21.4.22-26.mga5Whiteboard: NEEDINFO => MGA5TOO
found it: Name : xemacs Relocations: (not relocatable) Version : 21.4.22 Vendor: Mageia.Org Release : 26.mga6 Build Date: Thu Jul 2 12:41:11 2015 Install Date: (not installed) Build Host: sucuk.mageia.org Group : Editors Source RPM: (none) Size : 41011508 License: GPLv2+ Signature : (none) Packager : joequant <joequant> but the only message was: umeabot <umeabot> 21.4.22-26.mga5: + Revision: 742216 - Second Mageia 5 Mass Rebuild :-( @ Joseph What did you push it for?
CC: (none) => joequant
IMHO we should drop xemacs (ake make emacs obsolete it) as it's no more maintained. This is a dead project. The latest stable version (which we package) is 6+ years old... Even the latest unstable version is near 3 years old Or else, do like FC & update to a snapshot: http://pkgs.fedoraproject.org/cgit/xemacs.git/commit/?id=eac4eb5a41b5d5bdb4c5f7e9f3b198844cd4004c
Joseph wanted to rebuild it, but abused the fact that the disttag changed and didn't bump the release tag. I agree with Thierry. The emacs package should have obsoleted xemacs years ago, when it finally added syntax highlighting by default (22.1?).
Well, if no one really wants to grab maintainership and fix it (it does indeed crash in cauldron, too), then I fully agree with obsoleting it. (Just for the record, when installing it in cauldron, it gives the following error: 3/4: xemacs ################################################################################################### install-info: No such file or directory for /usr/share/info/texinfo.info.xz install-info: warning: no info dir entry in `/usr/share/info/emodules.info.xz') btw, when obsoleting it, should _all_ the xemacs packages be obsoleted by emacs? So: Obsoletes: xemacs < 21.4.23 Obsoletes: xemacs-devel < 21.4.23 Obsoletes: xemacs-el < 21.4.23 Obsoletes: xemacs-ess < 12.04.5 Obsoletes: xemacs-extras < 21.4.23 Obsoletes: xemacs-mule < 21.4.23 Obsoletes: xemacs-mule-el < 21.4.23 or should some of them be obsoleted by task-obsolete?
They should be obsoleted by the appropriate emacs subpackages. The ones without a match can be obsoleted by the main package or emacs-common.
(In reply to David Walser from comment #16) > They should be obsoleted by the appropriate emacs subpackages. The ones > without a match can be obsoleted by the main package or emacs-common. Thanks, David @ Shlomi I'd like to do this next week, _if_ no one grabs maintainership of xemacs with the intention to fix it before Monday, October 19, 00:00h UTC. However, it looks complicated to my unexperienced packaging mind. * There's xemacs-mule, which is for Asian languages and multi-language support, and emacs-leim, for input methods for various international character scripts. I'm not sure leim fully "covers" mule * the gcl spec, should e.g. the "%if %($(pkg-config xemacs) ; echo $?)", "%package xemacs" etc. parts be removed, or commented out with #s before all lines in those parts? * I'm not sure either what, apart from letting emacs-ess obsolete xemacs-ess, should be done with all the xemacs-ess related lines in the emacs-ess specfile (it was used to build xemacs-ess, too, until xemacs-ess got its own source package). * I don't find an equivalent for xemacs-devel, but cannot imagine there are no emacs-devel files Would you like to help me do it right?
CC: (none) => shlomif
Hi Marja, (In reply to Marja van Waes from comment #17) > (In reply to David Walser from comment #16) > > They should be obsoleted by the appropriate emacs subpackages. The ones > > without a match can be obsoleted by the main package or emacs-common. > > Thanks, David > > @ Shlomi > > I'd like to do this next week, _if_ no one grabs maintainership of xemacs > with the intention to fix it before Monday, October 19, 00:00h UTC. > Sounds good - go for it. > However, it looks complicated to my unexperienced packaging mind. > * There's xemacs-mule, which is for Asian languages and multi-language > support, and emacs-leim, for input methods for various international > character scripts. I'm not sure leim fully "covers" mule Well, it is possible that it is covered by the core emacs package. > * the gcl spec, should e.g. the "%if %($(pkg-config xemacs) ; echo $?)", > "%package xemacs" etc. parts be removed, or commented out with #s before all > lines in those parts? They should be removed. Note that I tried upgrading gcl recently and ran into problems including the fact that I was unable to compile the vanilla source release of GCL on my x86-64 Mageia Cauldron system. > * I'm not sure either what, apart from letting emacs-ess obsolete > xemacs-ess, should be done with all the xemacs-ess related lines in the > emacs-ess specfile (it was used to build xemacs-ess, too, until xemacs-ess > got its own source package). I'll have to investigate that. > * I don't find an equivalent for xemacs-devel, but cannot imagine there are > no emacs-devel files > maybe there are not. > Would you like to help me do it right? sure!
The fix for the crash is very simple: add this line to the top of the file ~/.xemacs/init.el (create the file and .xemacs directory if necessary): (setq progress-feedback-use-echo-area t) I have used xemacs with a customised x-symbol package for editing LaTeX files for many years. Please don't remove it from Mageia! Thanks.
Status: NEW => RESOLVEDCC: (none) => martinResolution: (none) => FIXED
This is not fixed if it crashes when people start it. If this needs to be disabled it should be done in the package.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Thank you - that is good news. But I agree, suggesting users to modify their .xemacs/init.el is a workaround, not a fix. Why not patch the statement suggested in comment #19 into the file /etc/emacs/site-start.d/xemacs-init.el That is where it logically belongs to. It avoids xemacs breaking without requiring users to edit their home directory; and it also works if you launch xemacs as root. Easy to implement as a bug fix: this file comes from source #5 of the xemacs package (site-start-mdk-el), a file that can be directly patched. And I join your plea for keeping xemacs on board - like probably most old hands using xemacs, I have added lisp functions which I do not want to miss (a compare feature that is much easier to use than diff3). But I am training my fingers to become expert with kwrite, and have an item on my todo list to see whether my elisp goodies can be made work with plain emacs)
CC: olav => (none)
I was a bit premature in declaring the problem "fixed", but Juergen's suggestion to add the line to a system startup file in /etc/emacs/ is a good one!
I withdraw my recommendation to keep xemacs in the Mageia repositories: emacs is now the more mature and flexible tool (beyond the negative arguments re mainting xemacs). Migrating an elisp library from xemacs takes time (2 days for my overly complex library) but is not a major problem. I stopped using my patched xemacs.
(In reply to Juergen Harms from comment #23) > I withdraw my recommendation to keep xemacs in the Mageia repositories: > emacs is now the more mature and flexible tool (beyond the negative > arguments re mainting xemacs). Migrating an elisp library from xemacs takes > time (2 days for my overly complex library) but is not a major problem. I > stopped using my patched xemacs. Thanks for letting us know. I also think that xemacs should be removed.
+1 for keeping and fixing if possible. Here's a backtrace in case it helps: #0 XDrawLine (dpy=0x176a110, d=20971649, gc=0x2800000014, x1=1, y1=10, x2=248, y2=10) at DrLine.c:50 #1 0x0000000000580e89 in GaugeExpose (w=0x2085980, event=0x1400081, region=0x2800000014) at /usr/src/debug/xemacs-21.4.22/lwlib/xlwgauge.c:427 #2 0x00007ffff6bd5ca4 in SendExposureEvent (event=event@entry=0x7fffffffc020, widget=widget@entry=0x2085980, pd=0x1779178) at Event.c:1128 #3 0x00007ffff6bd7886 in CompressExposures (widget=0x2085980, event=0x7fffffffc020) at Event.c:967 #4 XtDispatchEventToWidget (widget=widget@entry=0x2085980, event=event@entry=0x7fffffffc020) at Event.c:821 #5 0x00007ffff6bd7ddb in _XtDefaultDispatcher (event=0x7fffffffc020) at Event.c:1344 #6 0x00007ffff6bd7f19 in XtDispatchEvent (event=0x7fffffffc020) at Event.c:1423 #7 0x00007ffff6be33e7 in XtAppProcessEvent (app=0x952030, mask=140737488338976) at NextEvent.c:1397 #8 0x0000000000558bc1 in drain_X_queue () at /usr/src/debug/xemacs-21.4.22/src/event-Xt.c:2992 #9 emacs_Xt_event_pending_p (user_p=0) at /usr/src/debug/xemacs-21.4.22/src/event-Xt.c:3117 #10 0x00000000004b2ee4 in event_stream_event_pending_p (user=0) at /usr/src/debug/xemacs-21.4.22/src/event-stream.c:438 #11 Fdispatch_non_command_events () at /usr/src/debug/xemacs-21.4.22/src/event-stream.c:2369 #12 0x000000000047a5ec in Feval (form=form@entry=140737283962872) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3335 #13 0x000000000047697d in condition_case_1 (handlers=<optimized out>, bfun=bfun@entry=0x479ca0 <Feval>, barg=140737283962872, hfun=hfun@entry=0x47b180 <run_condition_case_handlers>, harg=140737283660848) at /usr/src/debug/xemacs-21.4.22/src/eval.c:1652 #14 0x0000000000476a27 in condition_case_3 (bodyform=<optimized out>, var=<optimized out>, handlers=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/eval.c:1730 #15 0x00000000004528a4 in execute_rare_opcode (stack_ptr=0x7fffffffc458, stack_ptr@entry=0x7fffffffc468, program_ptr=program_ptr@entry=0x15c2e94 "\207", opcode=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:1273 #16 0x0000000000453dac in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3dba2f8) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:658 #17 0x00000000004541d1 in funcall_compiled_function (fun=140737285618296, nargs=0, args=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #18 0x00000000004785e5 in Ffuncall (nargs=1, args=0x7fffffffc618) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572 #19 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3da9438) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748 #20 0x00000000004541d1 in funcall_compiled_function (fun=140737285598376, nargs=4, args=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #21 0x00000000004785e5 in Ffuncall (nargs=5, args=0x7fffffffc7e8) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572 #22 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3da9688) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748 #23 0x00000000004541d1 in funcall_compiled_function (fun=140737285598472, nargs=3, args=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #24 0x00000000004785e5 in Ffuncall (nargs=4, args=0x7fffffffc9c8) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572 #25 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3d9c410) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748 #26 0x00000000004541d1 in funcall_compiled_function (fun=140737285587384, nargs=4, args=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #27 0x00000000004785e5 in Ffuncall (nargs=5, args=0x7fffffffcb98) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572 #28 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x178fcf0) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748 #29 0x00000000004541d1 in funcall_compiled_function (fun=26043128, nargs=3, args=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #30 0x00000000004785e5 in Ffuncall (nargs=4, args=0x7fffffffcd68) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572 #31 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x179fc10) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748 #32 0x00000000004541d1 in funcall_compiled_function (fun=26042936, nargs=3, args=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #33 0x00000000004785e5 in Ffuncall (nargs=4, args=0x7fffffffcf38) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572 #34 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x17caab0) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748 #35 0x00000000004541d1 in funcall_compiled_function (fun=26042984, nargs=0, args=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #36 0x00000000004785e5 in Ffuncall (nargs=1, args=0x7fffffffd118) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572 #37 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x179fe80) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748 #38 0x00000000004541d1 in funcall_compiled_function (fun=26042792, nargs=0, args=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #39 0x00000000004785e5 in Ffuncall (nargs=1, args=0x7fffffffd2c8) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572 #40 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x1791460) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748 #41 0x00000000004541d1 in funcall_compiled_function (fun=fun@entry=26042456, nargs=nargs@entry=0, args=args@entry=0x7fffffffd400) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #42 0x000000000047a3f7 in Feval (form=24439064) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3392 #43 0x000000000047a6c1 in Fprogn (args=args@entry=24438848) at /usr/src/debug/xemacs-21.4.22/src/eval.c:775 #44 0x000000000047829a in funcall_lambda (fun=24438800, nargs=0, args=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3863 #45 0x000000000047851e in Ffuncall (nargs=1, args=0x7fffffffd6a8) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3580 #46 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3dbf210) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748 #47 0x00000000004541d1 in funcall_compiled_function (fun=fun@entry=140737285624536, nargs=nargs@entry=0, args=args@entry=0x7fffffffd7d0) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #48 0x000000000047a3f7 in Feval (form=form@entry=140737283989536) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3392 #49 0x000000000047697d in condition_case_1 (handlers=<optimized out>, bfun=bfun@entry=0x479ca0 <Feval>, barg=140737283989536, hfun=hfun@entry=0x47b180 <run_condition_case_handlers>, harg=140737283623648) at /usr/src/debug/xemacs-21.4.22/src/eval.c:1652 #50 0x0000000000476a27 in condition_case_3 (bodyform=<optimized out>, var=<optimized out>, handlers=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/eval.c:1730 #51 0x00000000004528a4 in execute_rare_opcode (stack_ptr=0x7fffffffda98, stack_ptr@entry=0x7fffffffdaa8, program_ptr=program_ptr@entry=0x15000c1 "\210\314\r!\025\016.\253\016\332\323\341\016.\342 \343 $!\026\067\344\345!\210\016&\253\005\344\346!\21 0\334\026&\347 \210\016(\253\005\344\350!\210\334\026(\t\253\b\351\t@\tA\"\210)\016\070\255\003\352 \207", opcode=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:1273 #52 0x0000000000453dac in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3dbffa8) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:658 #53 0x00000000004541d1 in funcall_compiled_function (fun=fun@entry=140737285625976, nargs=nargs@entry=0, args=args@entry=0x7fffffffdbd0) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517 #54 0x000000000047a3f7 in Feval (form=form@entry=140737283836200) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3392 #55 0x000000000047697d in condition_case_1 (handlers=<optimized out>, bfun=0x479ca0 <Feval>, barg=140737283836200, hfun=hfun@entry=0x45c650 <cmd_error>, harg=140737283664160) at /usr/src/debug/xemacs-21.4.22/src/eval.c:1652 #56 0x000000000045c26d in top_level_1 (dummy=dummy@entry=140737283664160) at /usr/src/debug/xemacs-21.4.22/src/cmdloop.c:206 #57 0x00000000004753cc in internal_catch (tag=<optimized out>, func=func@entry=0x45c240 <top_level_1>, arg=140737283664160, threw=threw@entry=0x0) at /usr/src/debug/xemacs-21.4.22/src/eval.c:1318 #58 0x000000000045c7c0 in initial_command_loop (load_me=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/cmdloop.c:285 #59 0x0000000000473976 in xemacs_21_4_22_x86_64_mageia_linux (argc=1, argv=0x7fffffffe198, envp=<optimized out>, restart=restart@entry=0) at /usr/src/debug/xemacs-21.4.22/src/emacs.c:2460 #60 0x0000000000444a6d in main (argc=<optimized out>, argv=<optimized out>, envp=0x7fffffffe1a8) at /usr/src/debug/xemacs-21.4.22/src/emacs.c:2829 It seems to crash in an X call during updating the progress bar while fontifying the buffer. (There was a progress bar displayed at the bottom previously when it worked.)
CC: (none) => balaton
Hi Zoltan, (In reply to Zoltan Balaton from comment #25) > +1 for keeping and fixing if possible. Here's a backtrace in case it helps: > -1 for keeping xemacs, because the upstream project is unmaintained. Please either switch to GNU Emacs or alternatively build a working xemacs snapshot locally which you can maintain (and use it at your own risk). Regards, -- Shlomi Fish
After consulting the documentation group, I am starting to write a short summary of what I (re-)learned on customization of elisp warts. While it is being drafted, it can be found (and commented on) at https://wiki.mageia.org/en/User:Jharms/Migrating_from_Xemacs_to_Emacs Hopefully that will help to minimise the effort needed for porting customization code from xemacs to emacs.
(In reply to Juergen Harms from comment #27) > After consulting the documentation group, I am starting to write a short > summary of what I (re-)learned on customization of elisp warts. While it is > being drafted, it can be found (and commented on) at > > https://wiki.mageia.org/en/User:Jharms/Migrating_from_Xemacs_to_Emacs > > Hopefully that will help to minimise the effort needed for porting > customization code from xemacs to emacs. that's great! Many thanks for your effort!
The page is now ready - still in my user space at https://wiki.mageia.org/en/User:Jharms/Quick_guide_to_customizing_Emacs will be moved to the official pages in a couple of days. It has become a guide to customization rather then a migration guide, but that is what such a document needs to be.
(In reply to Juergen Harms from comment #29) > The page is now ready - still in my user space at > > https://wiki.mageia.org/en/User:Jharms/Quick_guide_to_customizing_Emacs > > will be moved to the official pages in a couple of days. It has become a > guide to customization rather then a migration guide, but that is what such > a document needs to be. Many thanks!
(In reply to Juergen Harms from comment #29) > The page is now ready - still in my user space at > > https://wiki.mageia.org/en/User:Jharms/Quick_guide_to_customizing_Emacs > > will be moved to the official pages in a couple of days. It has become a > guide to customization rather then a migration guide, but that is what such > a document needs to be. Juergen moved the page to where it belongs: https://wiki.mageia.org/en/Guide_to_customizing_Emacs :-D Sorry for not yet having worked on obsoleting Xemacs, as I said I would. Overestimating how much time I have is a trap I keep falling in :-(
Of interest here, irt the status of xemacs, might be the following message and its assorted follow-ups: http://list-archive.xemacs.org/pipermail/xemacs-beta/2015-November/025919.html
(In reply to Shlomi Fish from comment #24) > (In reply to Juergen Harms from comment #23) > > I withdraw my recommendation to keep xemacs in the Mageia repositories: > > Thanks for letting us know. I also think that xemacs should be removed. Currently Xemacs crashes on launch in Cauldron [Mga6-dev1], both x86 and i586. The x86 .iso is in excess of 4Gb As this package is no longer receiving support, please remove it.
CC: (none) => westel
(In reply to Remco Rijnders from comment #32) > Of interest here, irt the status of xemacs, might be the following message > and its assorted follow-ups: > http://list-archive.xemacs.org/pipermail/xemacs-beta/2015-November/025919. > html Thanks, Remmy, there were indeed many replies (which I won't read, though) I'll work on letting emacs obsolete xemacs today, but won't remove things from spec files that are or might be needed again if we decide xemacs is good enough to reimport. Question 1, wrt the obsoleting: Why is xemacs-ess still here http://svnweb.mageia.org/packages/cauldron/xemacs-ess/ when emacs-ess already obsoleted it http://svnweb.mageia.org/packages/cauldron/emacs-ess/current/SPECS/emacs-ess.spec?revision=892500&view=markup (If if umeabot bumps xemacs-ess release, the obsoletes will no longer work.... or can that not happpen?)
Obsoleting packages in the spec file removed them from the mirrors, but does not touch the SVN repo. You need to move it manually to the obsolete section: $ svn mv svn+ssh://svn.mageia.org/svn/packages/cauldron/xemacs-ess svn+ssh://svn.mageia.org/svn/packages/obsolete/xemacs-ess
xemacs and all related packages are obsolete in cauldron, now, so closing as WONTFIX. However, this decision isn't cut in stone: if a Mageia packager finds that upstream revives the project well, and if he wants to import a new working version and _maintain_ it, then it is unlikely that we'll stop him.
Status: REOPENED => RESOLVEDResolution: (none) => WONTFIX