Bug 631707
| Summary: | Xemacs incorrectly detects perl programs as statistical scripts (ESS) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Simon Andrews <simon.andrews> | ||||
| Component: | emacs-common-ess | Assignee: | Alex Lancaster <alex> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 13 | CC: | alex, loganjerry, steve.traylen | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | emacs-common-ess-5.11-2.fc14 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-10-27 22:37:08 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Do you have xemacs-packages-extra installed? The Perl support is in there. For me, opening your attached file produces a buffer in CPerl-mode. Yes, my installed xemacs packages are: $ rpm -qa | grep xemacs xemacs-packages-base-20100727-1.fc13.noarch xemacs-21.5.29-13.fc13.x86_64 xemacs-ess-5.11-1.fc13.noarch xemacs-common-21.5.29-13.fc13.x86_64 xemacs-packages-extra-20100727-1.fc13.noarch Using the file I attached previously, if I do: xemacs perltest ..I get ESS mode but if I do cp perltest perltest.pl xemacs perltest.pl I get perl mode. Playing some more I find that if I remove xemacs-ess-5.11-1.fc13.noarch then xemacs perltest opens in perl mode again. So I guess it's a combination of xmeacs and the xemacs-ess package which trigger this. Yup. After starting XEmacs with the xemacs-ess package installed, interpreter-mode-alist contains this gem:
("r" . r-mode)
which comes from line 266 of /usr/share/xemacs/site-packages/lisp/ess/ess-site.el(c), which is loaded unconditionally by /usr/share/xemacs/site-packages/lisp/site-start.d/ess-init.el. That's right. Anything containing the letter 'r' on the interpreter line now gets r-mode, which precedes the rule for perl-mode in the list. So this line:
#!/usr/bin/perl
contains an 'r', therefore you must want r-mode, right?
That's broken in multiple ways. First, just installing the xemacs-ess package should not unconditionally activate it for every user of the machine where it is installed. Make the users who want this mode add (require 'ess-site) to ~/.xemacs/init.el and get rid of the file in site-start.d. Second, "r" is a totally unreasonable regular expression. Should that be "^r$" or "^R$", perhaps?
Reassigning to the emacs-common-ess package.
Hello? Anybody home? I'd like to see this fixed so I don't get more bug reports about it. (In reply to comment #4) > Hello? Anybody home? I'd like to see this fixed so I don't get more bug > reports about it. I'll have a look into it soon. That actually comes from the original upstream package, but I agree that's a bad choice for the regex and it needs to be fixed. I'll fix it locally and then report it upstream. Hmm, don't get this issue with GNU Emacs, so seems to be xemacs specific. Also just installed xemacs-ess to try to duplicate it by loading a .pl script with #!/usr/bin/perl -w in the header and it appears to do the right thing (i.e. load Perl mode) and loads R mode for files with .r as extension. Can you attach some .pl and .r files that can reproduce this error? Thanks. There is already a script attached to this job which exhibited the problem on my system and which was used to reproduce this by the xemacs maintainer. I also found that this was xemacs specific as the problem didn't occur in regular emacs. Oops, sorry just saw the attachment in comment #0. I can now reproduce the issue with xemacs but GNU Emacs does the right thing. OK, I have patched the package with a workaround to use "r$" as a regex. It seems to work locally, builds for updates-testing will be on their way soon, meanwhile I have reported the issue upstream as well (will post link to thread on upstream ML once it is moderated). emacs-common-ess-5.11-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/emacs-common-ess-5.11-2.fc14 emacs-common-ess-5.11-2.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/emacs-common-ess-5.11-2.fc13 emacs-common-ess-5.11-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update emacs-common-ess'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/emacs-common-ess-5.11-2.fc13 Also reported upstream: https://stat.ethz.ch/pipermail/ess-help/2010-October/006418.html emacs-common-ess-5.11-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. emacs-common-ess-5.11-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. |
Created attachment 445922 [details] Perl program which illustrates the problem Description of problem: Opening a perl program without a .pl extension, but with a correct #! line causes xemacs to open in ESS mode. Version-Release number of selected component (if applicable): xemacs-21.5.29-13.fc13.x86_64 How reproducible: xemacs-21.5.29-13.fc13.x86_64 Steps to Reproduce: 1. Create a small perl program without a .pl extension on the filename 2. xemacs perl_program Actual results: Xemacs opens in ESS mode rather than perl mode, with odd effects on the keyboard (underscores produce arrows etc). Expected results: Preferably, xemacs opens in perl mode, but if not then generic text mode. Additional info: This bug doesn't seem to affect emacs hence filing under xemacs. The bug persists even after deleting .xemacs and .xemacs.d and occurs in multiple user accounts.