You are not logged in.
Pages: 1
I have three problems since the upgrade to emacs 23 earlier this month.
1. When not connected to the Internet, emacs takes infinity and a week to start.
Comment:
In the PROBLEMS file included in the emacs package, it was suggested that emacs was trying to resolve its email address, that, for SUNs at least, the statically linked version of some library (probably libresolv) lacked some code contained in the dynamically linked version. Emacs uses the statically linked version. Certainly, setting the nameserver to localhost in /etc/resolv.conf greatly reduces the starting time.
2. When starting emacs using the fvwm2 windows manager, the emacs frame is infinitely large, and quite unusable.
Comment
Emacs behaves normally if twm is used instead of fvwm2.
Fix (well, hardly a fix): I re-compiled emacs from scratch myself, and with my version, the problem does not occur.
Might be an xserver issue, as I note that Ctrl/Alt-BACKSPACE no longer works.
3. Emacs takes about 5 seconds to start up even with Internet if it is started from an xterm.
Comment:
At work I use Windows, and a 5 second start is normal for most windows applications. But this is one major reason for me not to use Windows, whence my frustration with emacs.
Final Comment:
I was using the CVS version (also version 23) before I left for a holiday at the end of July without any problems. After my holiday, I upgraded Auch Linux. and then the problems started. I suspect the xserver and possibly shared libraries rather than emacs itself.
Any help would be much appreciated.
Cheers,
Mike Dowling
Offline
1. Almost certainly a local DNS issue. Ensure your hostname is set correctly in /etc/hosts
2. Are subsequent frames created also too large? Are the frame fonts used identical to that of the version you compiled?
(cdr (assoc 'font (frame-parameters)))(The removal of Ctrl-Alt-Backspace in xorg was intentional, supposedly to avoid accidentally killing X.)
3. Is the timing equally as long with 'emacs -Q'? Does it only occur when invoking emacs with no window system ('emacs -nw') or at any time emacs is started via an xterm?
HTH
Last edited by chpln (2009-09-24 14:28:20)
Offline
Thanks very much for the reply.
1. You are right! This is a little embarrassing as I had thought of /etc/hosts but ruled it out because I knew it to be correct. But it had somehow been overwritten.
2. Still unsolved. The frame fonts are identical. Subsequent frames are similarly large. (They start off the correct size, and then bloat after a splity second, just as the primary frame does.)
The version I compiled myself was straight foward, without any configure options except --disable-nls. I note that ldd indicates that my version is linked to very much fewer shared libraries.
I cannot see the result of executing that elisp segment of code as the frame is too large; I never get anywhere nere the echo area. All I ever get to see is the top, left hand corner of the frame. I've tried to reduce the size with the mouse, but eventually had to give up. The frame appears to me to be infinite.
3. Again, thanks for the tip. There is no delay with emacs -Q or emacs -q, whence the problem must lie with my .emacs file. That should be sufficient for me to track down the problem! (Again, embarrassing; I should have tested that without being prompted.)
Last edited by Mike Dowling (2009-09-26 09:57:07)
Offline
Good to hear the majority of the problems are pretty much solved.
The frame size behaviour is quite unusual. A few more questions:
* Does setting the frame geometry explicitly have an effect?
* Does this still occur when fvwm is using the default configuration?
* Are any relevant X resources specified for emacs?
$ xrdb -query* Could you provide the result of
(frame-parameters)You should be able to insert the result into the current buffer by providing a prefix argument to `eval-last-sexp'. If the resulting list is truncated, move point within the inserted list and issue `last-sexp-toggle-display'.
Last edited by chpln (2009-09-26 12:48:23)
Offline
Thanks again for the support.
Firstly, the problem of the slow start when using X11: The offending line in the .emacs is:
(set-frame-font "-misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-15")
Why that should cause a slow start, I don't know. Perhaps I really should change to utf8 character encodings.
Now to the extremely large frames problem when using fvwm.
Setting the geometry explicitly using --geometry causes emacs to flicker for a split second with the correct size, and then to bloat.
I removed the .fvwm2rc configuration file but to no avail.
I also removed all X11 customisations so the xrdb -query produced no output at all, but to no avail.
(frame-parameters) produces:
(frame-parameters)((parent-id . 6291571) (explicit-name) (display . ":0.0") (visibility . t) (icon-name) (outer-window-id . "14680079") (window-id . "14680106") (top . 210) (left . 10) (buried-buffer-list) (buffer-list #<buffer *scratch*>) (unsplittable) ...)
What I shall attempt is to re-compile fvwm myself and see if that helps, but it will have to wait until next weekend. Today I fell rather ill, and I have to go to Berlin tomorrow, returning Friday.
Offline
Solutions!
2. Slow start under X11: The set-frame-font was the culprit. I deleted it from my .emacs file and added a "--font" flag to my bash aliases toi start emacs, and the problem was solved.
3. The "Big Problem" was the way the emacs frames bloated to appear infinite in size when started from the fvwm2 windows manager. But there is now a fvwm-devel package for Arch Linux that appeared during the week, and the problem disappeared after installing it. So the problem was presumably an fvwm problem, not an emacs problem!
Many thanks again for the help!
Cheers,
Mike Dowling
Offline
Solutions!
2. Slow start under X11: The set-frame-font was the culprit. I deleted it from my .emacs file and added a "--font" flag to my bash aliases toi start emacs, and the problem was solved.
Mike, I've had this problem for years. I set font using X resources instead:
Emacs*font: -b&h-lucidatypewriter-medium-r-normal-sans-10-*-*-*-m-*-iso8859-1Offline
Solutions!
3. So the problem was presumably an fvwm problem, not an emacs problem!
The problem will come from not reading the FVWM FAQ.
-- Thomas Adam
Offline
Pages: 1