Flyspell loading first time buries buffer and inhibits mode hooks (Win32)

Flyspell loading first time buries buffer and inhibits mode hooks (Win32)

[petermonsson]

Hi All,

I'm having a problem with flyspell on my Emacs 22.1.1 on Win32. When I
find the first file flyspell will load and bury the file I'm opening
in the buffer list. modes will not start such as ruby-mode or cc-mode.
This only happens on the first file when flyspell thinks it should
load which is also when I start Emacs with a file to open from
Explorer.

It literally pisses me off to the point where I'm thinking of ditching
flyspell. Do you know any solution to my problem?

I have extracted the relevant parts of my .emacs file (and removed the
ranting)

;; Spelling
(setq ispell-program-name "aspell")

(add-hook 'text-mode-hook (lambda () (flyspell-mode 1)))
(global-set-key "\C-csd" (lambda() (interactive) (ispell-change-
dictionary "dansk" nil)))
(global-set-key "\C-cse" (lambda() (interactive) (ispell-change-
dictionary "english" nil)))

(if (fboundp 'longlines-mode)
    (add-hook 'text-mode-hook '(lambda () (longlines-mode))) ;;better
than auto-fill
  (add-hook 'text-mode-hook
            '(lambda nil
               (setq fill-column 79)
               (auto-fill-mode 1))))

;; Ruby
(autoload 'ruby-mode "ruby-mode" "Major mode for editing ruby
scripts." t)
(add-to-list 'auto-mode-alist '("\\.rb$" . ruby-mode))
(add-to-list 'interpreter-mode-alist '("ruby" . ruby-mode)) ;; For irb
;; irb in Emacs
(autoload 'run-ruby "inf-ruby" "Run an inferior Ruby process")
(autoload 'inf-ruby-keys "inf-ruby"
  "Set local key defs for inf-ruby in ruby-mode")

(add-hook 'ruby-mode-hook
          '(lambda ()
             (font-lock-mode t)
             (inf-ruby-keys)))

Thank you for your help in advance.
Peter Monsson

Re: Flyspell loading first time buries buffer and inhibits mode hooks (Win32)

[Tony Mc]

On Mon, 19 May 2008 12:25:53 -0700 (PDT), petermonsson@yahoo.dk wrote:

> It literally pisses me off

Is that literally true? The process isn't easy to imagine. And perhaps
I shouldn't even try.

Tony

Re: Flyspell loading first time buries buffer and inhibits mode hooks (Win32)

[petermonsson]

On 20 Maj, 12:53, Tony Mc <af...@btinternet.com> wrote:
> Is that literally true? The process isn't easy to imagine.

I mean, yeah, I have to take a shower each time I start Emacs. For
some people that would be a good time to do it anyway, but I start up
Emacs 5 or 6 times a day so it quickly starts getting annoying.

Anyway I've found out why I have the problem, but first I need to
admit that I have forgotten a relevant part of my .emacs file:

(setq default-major-mode 'text-mode) ;; rather than fundamental

Alright, so when I find most files, text-mode will load and flyspell
will load because text-mode is loaded. Apparently this happens all the
time when I start Emacs from explorer. I suppose that *scratch* is one
of the few exceptions that don't depend on text-mode.

In *Messages* I have the following output:
Loading longlines...done
Loading flyspell...done
Starting new Ispell process [default] ...
ispell-init-process: aspell did not output version line

That doesn't tell much. If I comment out (setq default-major-mode
'text-mode) I don't get have problems with ruby-mode, cc-mode, etc.,
but I like text-mode as the default mode much more than fundamental.

Looking at *Messages* after opening a text file I see it has changed
to:
Loading longlines...done
Loading flyspell...done
Starting new Ispell process [default] ...
File mode specification error: (error "aspell did not output version
line")

Hmm, new incompatible version of aspell perhaps? (I check whether the
same problem exists on an Emacs 21.3 on a linux box. There is no
problem and aspell loading is extremely fast compared to my win box)
Aspell version on linux box is 0.50 so there might be a version
incompatibility here. (Note: Aspell 0.50 was released before last
ispell.el release and 0.6 after the last ispell.el release.)

I dive into Ispell.el to see what's wrong. I can't find anything that
has to do with line parsing around that error message, but there are
methods which invoke aspell and wait for it until some timeout limit.
That might be it? My computer is dog slow, but extending the timeout
limit has no effect except for giving the same error much later :(.

What does error do? Stopping whatever the current and parent methods
do. If programming is robust, then the developer frees resources and
returns everything back to the state before the method was run. I
don't think that is what is happening here, although I haven't looked
at the source thoroughly. What happens if I replace the (error ...)
call with nil? Bingo! the annoying behavior dissappears.

Now flyspell won't exactly work like a charm because of that, but I
can live with having to do M-x flyspell-buffer the first time I want
to spell check a buffer and flyspell is now a pleasure and not a pain
to work with.

I don't think other people will have the same error as me, but for the
public service

Best Regards
Peter

RE: Flyspell loading first time buries buffer and inhibits modehooks (Win32)

[Drew Adams]

> I mean, yeah, I have to take a shower each time I start Emacs.
> For some people that would be a good time to do it anyway,
  --- ---- ------ ---- ----- -- - ---- ---- -- -- -- ------

> but I start up Emacs 5 or 6 times a day so it quickly starts
> getting annoying.

Definitely a candidate for the Emacs humor list.

Perhaps we should add that as a reminder to the Emacs splash screen: "WARNING:
If you have not had a shower since you last started Emacs, then begin
decontamination process NOW."

Re: Flyspell loading first time buries buffer and inhibits mode hooks (Win32)

[Eli Zaretskii]

> From: petermonsson@yahoo.dk
> Date: Tue, 20 May 2008 10:00:39 -0700 (PDT)
> 
> In *Messages* I have the following output:
> Loading longlines...done
> Loading flyspell...done
> Starting new Ispell process [default] ...
> ispell-init-process: aspell did not output version line
> 
> That doesn't tell much.

Use the code, Luc!  When ispell.el starts the speller program, it
first invokes it with the -v or -vv switch, and looks at the output
produced by the speller, to make sure the version it announces is
compatible with what ispell.el supports.  The message above tells that
either aspell didn't understand -v, or ispell.el didn't understand its
output (or both).


> Hmm, new incompatible version of aspell perhaps?

Maybe.  What does "aspell -v" produce when invoked from the command
line on Windows?