Bug 523882 - xemacs comint.elc does not load by default
Summary: xemacs comint.elc does not load by default
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: aplus-fsf
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jochen Schmitt
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 531238 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-17 02:24 UTC by Doug Scoular
Modified: 2012-08-16 21:57 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 21:57:49 UTC


Attachments (Terms of Use)

Description Doug Scoular 2009-09-17 02:24:29 UTC
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.

Comment 1 Jerry James 2009-09-17 02:36:38 UTC
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?

Comment 2 Doug Scoular 2009-09-17 05:31:05 UTC
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

Comment 3 Jerry James 2009-09-17 14:34:49 UTC
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?

Comment 4 Doug Scoular 2009-09-18 04:49:35 UTC
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

Comment 5 Jerry James 2009-09-18 15:07:04 UTC
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.

Comment 6 Doug Scoular 2009-09-18 21:30:25 UTC
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

Comment 7 Jerry James 2009-09-18 22:02:58 UTC
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.

Comment 8 Jerry James 2009-10-26 21:30:31 UTC
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.

Comment 9 Jerry James 2009-10-27 15:27:20 UTC
*** Bug 531238 has been marked as a duplicate of this bug. ***

Comment 10 Jerry James 2009-10-27 15:28:58 UTC
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.

Comment 11 Matt Fago 2009-10-27 21:18:11 UTC
(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

Comment 12 Bug Zapper 2010-04-28 10:25:14 UTC
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

Comment 13 Jerry James 2010-04-28 15:01:05 UTC
This is still a problem.  Please fix aplus-fsf-init.el so that it only installs autoloads.

Comment 14 Bug Zapper 2010-07-30 10:44:00 UTC
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

Comment 15 Jerry James 2010-10-10 03:38:37 UTC
Jochen, I just worked with yet another person with a broken XEmacs, reporting on xemacs-beta@xemacs.org, 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.

Comment 16 Jason Tibbitts 2010-10-16 17:34:32 UTC
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.

Comment 17 Fedora End Of Life 2012-08-16 21:57:52 UTC
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


Note You need to log in before you can comment on or make changes to this bug.