From: Erwin Achermann To: Geoff Voelker Subject: upgrading: 19.34.6 to 20.3 Date: Sat, 03 Oct 1998 10:30:10 +0200 So i assembled all the information, that i got to my "upgrading" post. I also add a section remarks/problems. It is a collection of messages i found are closely related to upgrading. [...] Cheers Erwin Upgrading from 19.34.6 to 20.3.1 I addapted Karel Sprengers upgrade procedure: 1. Downloaded the precompiled version and the lisp source from: ftp://ftp.cs.washington.edu/pub/ntemacs/latest/i386/emacs-20.3.1-bin-i386.tar.gz ftp://ftp.cs.washington.edu/pub/ntemacs/latest/i386/emacs-20.3.1-lisp.tar.gz or one of the many mirrors; 2. Used Winzip 6.3 SR-1 to unzip/untar these into C:\emacs-20.3.1 and subdirectories; 4. Copied my site-lisp tree from C:\emacs-19.34 to C:\emacs-20.3.1, and then removed all *.elc files from this tree; 5. Changed my PATH to use C:\prog\emacs-20.3.1\bin instead of C:\prog\emacs-19.34\bin; 6. Ran "C:\prog\emacs-20.3.1\bin\addpm C:\prog\emacs-20.3.1" as per instructions; 7. deleted following environment vars. EMACSDATA=c:\prog\emacs\etc EMACSDOC=c:\prog\emacs\etc EMACSLOADPATH=c:\prog\emacs\lisp EMACSPATH=c:\prog\emacs\bin 8. Started "runemacs --no-site-file --no-init-file", and recompiled all the *.el files in my site-lisp tree (adjusting Makefiles and such where needed); 9. Started "runemacs --no-site-file --no-init-file", and stepped through my site-start.el and default.el files (in the site-lisp directory) by selecting a region and then doing Emacs-Lisp -> Evaluate Region or simply C-x C-e after each sexp. I did the same for my .emacs file; Several things became obsolet, rename win32- to w32- 10. Renamed C:\emacs-20.3.1 to C:\emacs and ran addpm again; 11. Changed all shortcuts to "runemacs" to "runemacs -unibyte" 12. Byte-compiled all *.el files in site-lisp. Problems/Remarks: * the following (to me) essetial packages run without further tweaking: - visemacs ok - gnuserv ok - auctex ok - ispell ok * I miss the tex <-> iso conversion that iso-cvt.el used to provide on save and find-file. How is this accomplished nowadays? * printing is supposed to be done by emacs itself. I didn't manage it to configure it. The FAQ doesn't really help me. Some standard examples would be nice... "Karel Sprenger" reports * According to GNU Emacs NEWS: > The default value of load-path now includes most subdirectories of > the site-specific directories /usr/local/share/emacs/site-lisp and > /usr/local/share/emacs/VERSION/site-lisp, in addition to those > directories themselves. Both immediate subdirectories and > subdirectories multiple levels down are added to load-path. This is unfortunately not the case for NTEmacs. * ediff-revision used to show revisions of files with anoying trailing C-m's, but the 20.3.1 version makes it even worse by displaying TWO C-m's. I found out that this originates somewhere in the bowels of vc.el, where a shell command like "co -p > file" is used. This somehow introduces the C-m's. * the standard speedbar.el has a bug (as already pointed out here and noted in Geoff's excellent FAQ), but luckily JDE contains a good one; * I still use (standard-display-european t) although it is marked as semi-obsolete in the function help. I didn't understand how to use > `set-language-environment' and `set-terminal-coding-system', coupled with > the `--unibyte' option if you prefer to use unibyte characters. to have files (in which I had used iso-accents-mode) to display the accented characters. "Dr. Francis J. Wright" reports: * Firstly, it now calls Tex using `tex \nonstopmode\input file', but it doubles the backslashes to escape them for a UNIX shell. This causes havoc using command.com (via cmdproxy). A possible solution is just to edit the source code, but I currently prefer to advise tex-send-command to replace all \\s by \s. That seems to work. * Secondly, the *tex-shell* buffer is now put into compilation-minor-mode, which is fine except that if you want to interact with TeX (in the event of some TeX source error) then you need to turn off compilation-minor-mode first. I don't feel that this is as clearly documented in the Emacs manual as it might be. * The two together lead to an amusing (?) catch-22 situation. The \\s provoke TeX errors, but you can't interact with TeX to stop it. I tended to end up with several hung processes that prevented me shutting down the machine until I figured out what was going on! More from Francis Wright: * If you want to, you are welcome to add a pointer to http://www.maths.qmw.ac.uk/~fjw/public_emacs/ in which the file msdos-tex-shell.el implements the above fix, together with a few others. This file and msdos-shell-fix.el together give me an environment that runs TeX nicely (and fairly reliably) using the standard Windows 95 shell (command.com). However, as I have said before, I don't know how these files work with AUCTeX, because I don't use it. "Davcd Nichols" reports: * I'd like to have white letters on a black background and 11-point Courier New. The following (lifted from the FAQ with slight changes) in .emacs does the trick. (setq default-frame-alist '((cursor-color . "white") (cursor-type . box) (foreground-color . "white") (background-color . "black") (font . "-*-Courier New-normal-r-*-*-18-108-*-*-c-*-*-ansi-") )) The problem is that the modeline also shows up with white letters and a black background, not inverted as desired. The odd thing is that if I select the same font (using Shift-Mouse1 to get the font selection dialog and selecting 11-point Courier New) the mode line now displays correctly (black letters on a white background). What do I need to add to my .emacs file so that emacs launches with the correct appearence? -- Erwin Achermann Tel: ++41 1 632 74 40 Institut fuer Wissenschaftliches Rechnen Fax: ++41 1 632 13 74 ETH Zentrum, IFW C29.2 mailto:acherman@inf.ethz.ch ICQ:4625051 CH-8092 Zuerich http://www.inf.ethz.ch/personal/acherman/ > Perfection is reached, not when there is no longer anything to add, < > but when there is no longer anything to take away. < > -- Antoine de Saint-Exupery < Hi, Geoff Voelker writes: > > Erwin raises a good point here: it'd be worth preparing a migration guide > > for those considering the move from 19.34 - I'm still running into the > > odd incompatibility from time to time, and it'd be useful to know whether > > I'm missing something from the version change, or whether the problem is > > more "fundamental". > > I think this would be useful, too. does anyone have the interest to > write something up for the FAQ? > Don't know if I want to volunteer, but I think the migration from 19.34.6 to 20.3.1 went rather smoothly in my case. The steps I took were the following: 1. Downloaded the precompiled version and the lisp source from: ftp://ftp.cs.washington.edu/pub/ntemacs/latest/i386/emacs-20.3.1-bin-i386.tar.gz ftp://ftp.cs.washington.edu/pub/ntemacs/latest/i386/emacs-20.3.1-lisp.tar.gz or one of the many mirrors; 2. Used Winzip 6.3 SR-1 to unzip/untar these into C:\emacs-20.3.1 and subdirectories; 3. Copied my site-lisp tree from C:\emacs-19.34 to C:\emacs-20.3.1, and then removed all *.elc files from this tree; 4. Changed my PATH to use C:\emacs-20.3.1\bin instead of C:\emacs-19.34\bin; 5. Ran "C:\emacs-20.3.1\addpm C:\emacs-20.3.1" as per instructions; 6. Started "runemacs --no-site-file --no-init-file", and recompiled all the *.el files in my site-lisp tree (adjusting Makefiles and such where needed); 7. Started "runemacs --no-site-file --no-init-file", and stepped through my site-start.el and default.el files (in the site-lisp directory) by selecting a region and then doing Emacs-Lisp -> Evaluate Region or simply C-x C-e after each sexp. I did the same for my .emacs file; 8. Renamed C:\emacs-20.3.1 to C:\emacs and ran addpm again; 9. And that's it. Or rather, that should have been it. A few glitches on the way: 1. According to GNU Emacs NEWS: > ** The default value of load-path now includes most subdirectories of > the site-specific directories /usr/local/share/emacs/site-lisp and > /usr/local/share/emacs/VERSION/site-lisp, in addition to those > directories themselves. Both immediate subdirectories and > subdirectories multiple levels down are added to load-path. This is unfortunately not the case for NTEmacs; 2. ediff-revision used to show revisions of files with anoying trailing C-m's, but the 20.3.1 version makes it even worse by displaying TWO C-m's. I found out that this originates somewhere in the bowels of vc.el, where a shell command like "co -p > file" is used. This somehow introduces the C-m's. 3. the standard speedbar.el has a bug (as already pointed out here and noted in Geoff's excellent FAQ), but luckily JDE contains a good one; 4. I still use (standard-display-european t) although it is marked as semi-obsolete in the function help. I didn't understand how to use > `set-language-environment' and `set-terminal-coding-system', coupled with > the `--unibyte' option if you prefer to use unibyte characters. to have files (in which I had used iso-accents-mode) to display the accented characters. In all, the migration went well, and I'm now happily working with the new version (although I am VERY annoyed with glitch #2). Looking forward to all the improvements that are bound to show up! Cheers, Karel -- Karel Sprenger | phone: +31-20-525 2302 Informatiseringscentrum | +31-20-525 2741 Universiteit van Amsterdam | fax : +31-20-525 2084 Turfdraagsterpad 9, NL-1012 XT AMSTERDAM | home : +31-20-670 0942 *** PGP Public Key available on servers *** | email: