viper bug (void-variable activate-input-method)

Hi, calling emacs -Q and then M-x viper, I get the following (debug-on-error enabled): ### Debugger entered--Lisp error: (void-variable activate-input-method) eval(activate-input-method) eval-after-load(mule-cmds

Re: viper bug (void-variable activate-input-method)

Thorsten Bonow [EMAIL PROTECTED] writes: Debugger entered--Lisp error: (void-variable activate-input-method) Thanks! The recent changes to load-history exposed this bug in Viper. (These eval-after-load calls never worked before because load-history had international/mule-cmds and not

Re: Problem with ispell-local-dictionary

Hallöchen! Richard M. Stallman [EMAIL PROTECTED] writes: Does this patch fix the bug? It seems to when I try it. I reproduced those problems, applied the fix, and now they are gone. So yes, this fixes it. Thanks! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ

Comment body colourless in eight-colour terminal.

Using Debian GNU/Linux, in a stock xterm or on the console, run TERM=linux emacs -nw -Q -fg black -bg white -f global-font-lock-mode ~/.emacs TERM=linux emacs -nw -Q -fg white -bg black -f global-font-lock-mode ~/.emacs The comment characters (;) are coloured red, but comment

Comment body colourless in eight-colour terminal.

Trent Buck writes: Using Debian GNU/Linux, in a stock xterm or on the console, run TERM=linux emacs -nw -Q -fg black -bg white -f global-font-lock-mode ~/.emacs TERM=linux emacs -nw -Q -fg white -bg black -f global-font-lock-mode ~/.emacs The comment characters (;)

Weird behavior of fill-paragraph.

Hi the list. Again, I don't really know if it's expected, but I seems weirdo to me. My fill-column is 70, I'm in emacs -Q. I've buffer that contains : Qqqq qq qq qq qqq. Qqq If I M-q on this line, I obtain : Qqqq

Re: Weird behavior of fill-paragraph.

From: Michael Cadilhac [EMAIL PROTECTED] Date: Mon, 24 Oct 2005 00:23:02 +0200 My fill-column is 70, I'm in emacs -Q. I've buffer that contains : Qqqq qq qq qq qqq. Qqq If I M-q on this line, I obtain : Qqqq

Re: Weird behavior of fill-paragraph.

Eli Zaretskii [EMAIL PROTECTED] writes: This happens because you have only one space after the period that ends the sentence. So Emacs thinks the two words surrounding the period should not be separated, as in J. R. R. Tolkien. In other words, by default Emacs doesn't think a period ends a

Re: GC bug?

On Sat, 22 Oct 2005 11:51:30 -0400 Richard M. Stallman [EMAIL PROTECTED] wrote: [Stephen Berman wrote:] I made a diary entry and then called calendar and Emacs immediately hung or went into an infinite loop, presumably in diary-list-entries, since the last message was Preparing

Re: problems with face-spec-reset-face and set-face-attribute

I think that the vectors in face-new-frame-defaults need to have an additional state, different from `unspecified' and a specific value. This additional state would be `nothing here'. If the value in `face-new-frame-defaults' is `unspecified', it would override the defface with `unspecified'. If

Re: Setting multiple face attributes on all frames

Does this fix the bug? *** faces.el23 Oct 2005 15:13:19 -0400 1.338 --- faces.el23 Oct 2005 20:09:30 -0400 *** *** 33,39 (autoload 'xw-defined-colors x-win)) (defvar help-xref-stack-item) - 

Re: perl mode color highlighting working badly

I finally had time to study the last couple of weeks' messages about this. font-lock-syntactic-keywords is not really applied eagerly to the whole buffer, but only to the region between point-min and the currently visible area. That is good enough, provided this is done in all the

Re: Setting multiple face attributes on all frames

On Sun, 23 Oct 2005 21:01:04 -0400, Richard M. Stallman [EMAIL PROTECTED] said: Does this fix the bug? Yes, it works fine. Thanks. Now we can encourage those who dislike XLFDs to use set-face-attribute instead of adding an XLFD entry to default-frame-alist.