Description of problem: xemacs' comint mode doesn't appear to load automagically any more. Hence the Meta-P and Meta-N binding in any comint based mode (like shell mode) no longer get bound to comint-next-input and comint-previous-input respectively. Version-Release number of selected component (if applicable): xemacs-packages-base-el-20090217-3.fc11.noarch How reproducible: 100% Steps to Reproduce: 1. Start up xemacs on the command line with "xemacs -nw". 2. Start up a shell with "M-x shell". 3. Enter some linux commands e.g. "date" followed by "ls" 4. Attempt to use "Meta-P" to get the previous command to appear on the command line. Nothing will happen, in the status line "M-p not defined will appear". It should display "ls" on the command line if the binding was in place. Actual results: No previous command shown on command-line. The status line will show "M-p not defined". Expected results: Previous command (in the above example "ls") should appear on command-line Additional info: On previous xemacs releases comint.el was loaded by default.
I tried your steps to reproduce, and got the expected behavior of M-p and M-n. Can you reproduce if you start xemacs with -vanilla?
Hi Jerry, Okay, I found that -vanilla fixed the issue for me. However, I wanted to ensure that nothing was being inherited from my user environment so I did the following as root: [root@prestwick ~]# useradd -m foobar [root@prestwick ~]# passwd foobar Changing password for user foobar. New password: Retype new password: passwd: all authentication tokens updated successfully. [root@prestwick ~]# ssh foobar@localhost foobar@localhost's password: [foobar@prestwick ~]$ ls -a . .bash_logout .bashrc .gnome2 .mozilla .xemacs .. .bash_profile .emacs .kshrc .Xauthority .zshrc I then ran "xemacs -nw" and "M-p" and "M-n fail after "M-x shell". If I run it with -vanilla it works. This is a completely standard new user with no customisation. I'm not sure why -vanilla is loading more packages than running it without. From the man page: -vanilla Load no extra files at startup. Equivalent to the combination of -q, -no-site-file, and -no-early-packages. When I load with -q (aka -no-init-file), comint.elc isn't loaded. When I run with -no-early-packages, comint.elc isn't loaded. When I run with -no-site-file it *is* loaded. Surely comint.el should load by default ? Cheers, Doug
I created a new user, and still get the expected behavior from M-n and M-p in shell mode. But your discovery that -no-site-file makes the difference is an important clue. That means you have something in /usr/share/xemacs/site-packages/lisp/site-start.d that is triggering this behavior, and I do not have whatever it is installed on my machine. Could you show me the contents of that directory, please?
Hi Jerry, Here you go: [dscoular@prestwick ~]$ ls -ltr /usr/share/xemacs/site-packages/lisp/site-start.d total 24 -rw-r--r-- 1 root root 216 2008-04-23 15:19 uim-init.el -rw-r--r-- 1 root root 202 2009-02-25 01:50 muse-init.el -rw-r--r-- 1 root root 168 2009-02-25 01:53 ess-init.el -rw-r--r-- 1 root root 63 2009-03-11 07:41 aplus-fsf-init.el -rw-r--r-- 1 root root 79 2009-07-27 05:47 ebib-init.el -rw-r--r-- 1 root root 164 2009-08-01 08:58 pg-init.el lrwxrwxrwx 1 root root 37 2009-09-12 01:21 rpmdev-init.el -> /usr/share/rpmdevtools/rpmdev-init.el And their respective md5sums: [dscoular@prestwick ~]$ [dscoular@prestwick ~]$ d5da373d146c1d3c1bb0962233ed8acc /usr/share/xemacs/site-packages/lisp/site-start.d/aplus-fsf-\ init.el 7a8693791db478bdd35b2519c8a766b0 /usr/share/xemacs/site-packages/lisp/site-start.d/ebib-init.el 4e7d9aab588def167fa9b07de0cc8952 /usr/share/xemacs/site-packages/lisp/site-start.d/ess-init.el ed17d7ec9e0ff16571b18fc36265ea8d /usr/share/xemacs/site-packages/lisp/site-start.d/muse-init.el ddc646cceb02ec9afc78f248533af675 /usr/share/xemacs/site-packages/lisp/site-start.d/pg-init.el 0cb4cb3dd03be94231a081d4ded7cd38 /usr/share/xemacs/site-packages/lisp/site-start.d/rpmdev-init.el 4820bf96b3a109f424a96262d339e0ae /usr/share/xemacs/site-packages/lisp/site-start.d/uim-init.el And the packages that spawned them: rpm -qf /usr/share/xemacs/site-packages/lisp/site-start.d/* xemacs-aplus-fsf-4.22.4-15.fc11.noarch xemacs-ebib-1.8.0-1.fc11.noarch xemacs-ess-5.3.10-2.fc11.noarch xemacs-muse-3.12-2.fc11.noarch xemacs-proofgeneral-3.7.1-4.fc11.noarch rpmdevtools-7.3-1.fc11.noarch xemacs-uim-1.5.6-1.fc11.i586 Hope that helps... Cheers, Doug
So xemacs-aplus-fsf is the culprit. It is "fixing" comint mode for you. Look at this code near the bottom of /usr/share/xemacs/site-packages/lisp/aplus-fsf/a.el: (defvar a-mode-fix-comint t "Fix comint because I want to use A+.") (if a-mode-fix-comint (progn (defun comint-patch () "Redefines COMINT mode keymap to remove conflicts with A+" (interactive) (define-key comint-mode-map "\M-n" nil) (define-key comint-mode-map "\M-p" nil) (define-key comint-mode-map "\M-r" nil) (define-key comint-mode-map "\M-s" nil) (define-key comint-mode-map "\M-?" nil) ... I've looked through the Elisp in the xemacs-aplus-fsf package some, and all I can say is that this is some of the shoddiest code I've ever seen. Use at your own risk. I'm closing this as NOTABUG, because the package deliberately inflicted this brain damage on you. If you still consider the behavior a bug, feel free to reopen this bug against the aplus-fsf component.
Hi Jerry, This package was installed by default during the overall install by anaconda. I did not specifically request this package. Surely this is a packaging issue. A+ must be of minority interest when compared to having a functioning shell mode. I took the defaults: repo --name="Fedora 11 - i386" --baseurl=http://mirrors.cat.pdx.edu/fedora/lin\ ux/releases/11/Everything/i386/os/ repo --name="Fedora 11 - i386 - Updates" --baseurl=http://mirrors.kernel.org/f\ edora/updates/11/i386/ %packages @admin-tools @base @core @development-libs @development-tools @editors @fedora-packager @fonts @gnome-desktop @gnome-software-development @games @graphical-internet @graphics @hardware-support @input-methods @java @kde-desktop @lxde-desktop @mysql @office @online-docs @perl @printing @sound-and-video @system-tools @text-internet @virtualization @web-server @smb-server @x-software-development @base-x @xfce-desktop kpackagekit xfsprogs mtools iscsi-initiator-utils gpgme gpm pax gnupg2 bridge-utils aspell rpmdevtools koji mercurial lua cpan-upload rpmlint plague-client mock perltidy bzr leafpad openoffice.org-opensymbol-fonts pcmanfm gvfs-obexftp gnome-vfs2-devel libsigc++20-devel libart_lgpl-devel fortune-mod gnuchess kdegames konversation kdepim kftpgrabber ImageMagick digikam dcraw kipi-plugins netpbm-progs kdegraphics gypsy gpsd hdparm m17n-db-tamil m17n-db-gujarati m17n-db-kannada m17n-db-hindi gok m17n-db-oriya m17n-db-bengali m17n-contrib-sinhala m17n-db-assamese m17n-db-punjabi iok m17n-db-telugu m17n-db-malayalam qt-mysql php-mysql kdepim amarok kaffeine kdemultimedia vbetool gssdp gnokii geoclue createrepo radeontool arj festival gupnp rdesktop fuse mesa-libGLU-devel xorg-x11-apps slim xscreensaver-gl-extras xscreensaver-extras gdm xscreensaver-base xterm xorg-x11-resutils lxpanel Terminal -PolicyKit-kde -lxsession-lite Cheers, Doug
Ah, okay. I thought you had installed it on purpose. In that case, let's reopen this and reassign to the aplus-fsf maintainer. Jochen, just having xemacs-aplus-fsf installed cripples comint-mode. (This may be true for emacs-plus-fsf, too.) Since comint-mode is used to interact with other programs, such as gdb and the shell, this can be a problem. Doug, aplus-fsf is marked as optional in the comps file, so I am at a loss to explain how it got installed on your machine.
Jochen, the XEmacs team also got a report that line and column numbers don't show up in the modeline when xemacs-aplus-fsf is installed. That appears to be due to the variable a-mode-fix-my-modeline, defined in a.el. Both problems have the same underlying cause: the aplus-fsf-init.el file in site-packages/site-start.d should be setting autoloads only. For this package, it is doing much more than that.
*** Bug 531238 has been marked as a duplicate of this bug. ***
Note that bug 531238 wasn't REALLY a duplicate of this bug, as it is complaining about history rather than keybindings, but the underlying problem is once again the same: aplus-fsf makes invasive changes to XEmacs that break stuff, just by being installed.
(In reply to comment #8) > Jochen, the XEmacs team also got a report that line and column numbers don't > show up in the modeline when xemacs-aplus-fsf is installed. That appears to be > due to the variable a-mode-fix-my-modeline, defined in a.el. I'm the reporter of this other issue. I'm used to installing *xemacs* and it would be great if this didn't break XEmacs. Thanks, Matt
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is still a problem. Please fix aplus-fsf-init.el so that it only installs autoloads.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Jochen, I just worked with yet another person with a broken XEmacs, reporting on xemacs-beta, that turned out to be caused by this package. It's been over a year with no response from you. I'm starting the unresponsive maintainer process. Please respond within 2 weeks or I will apply to take over this package. To be clear, I have no intention of even attempting to fix this package. My sole act as maintainer will be to get it out of Fedora. If someone wants to keep it, acting now would be a good idea.
How about attaching a patch which would work for you? Fixing collateral damage from this package is somewhat separate from the question of whether Jochen is unresponsive, and a provenpackager could spin a new package in a jiffy given a patch. Is it sufficient to simply change the defvar? It's been years since I worked in elisp.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping