Bug 523882

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