Re: Strange Emacs crash

[Martin Lüthi]

Kim

Thanks, this fixes the problem for me.

Best, Martin

Kim F. Storm writes:
 > > Emacs crashes consistently when I use iso-accents-mode in the *mail*
 > > buffer. I could reduce my .emacs to the following two lines
 > >
 > > ======= .emacs =======
 > > (custom-set-variables
 > >  '(global-font-lock-mode t nil (font-lock))
 > >  '(mail-archive-file-name "~/mail/sent")
 > >  )
 > > ======================
 > >
 > > To reproduce the error do the following steps:
 > >
 > > - M-x mail                          [enter mail mode]
 > > - M-x iso-accents-mode              [enter iso-accents-mode]
 > > - put point on the Subject line
 > > - enter "u                          [write a 'ü' (u Umlaut)]
 > > - go to the mail body
 > > - enter S-h                         [write a upcase 'H']
 > > - Emacs crashes
 > >
 > 
 > 
 > It turns out that when you hit " iso-accents-mode has setup
 > a function to be called via key-translation-map with the purpose
 > of reading the next character and combine them into a single
 > character.  The problem is that this function modifies the
 > buffer in a state where emacs expects the window and buffer
 > contents to be in a consitent state.
 > 
 > The following patch fixes the problem for iso-accents-mode.
 > 
 > This should probably be fixed in emacs' core to handle this situation
 > in general, but I'm not too familiar with that specific part of the
 > code.  Richard? Stefan?
 > 
 > 
 > 
 > *** iso-acc.el       01 Sep 2003 17:45:28 +0200      1.58
 > --- iso-acc.el       23 Feb 2005 17:00:45 +0100      
 > ***************
 > *** 290,295 ****
 > --- 290,305 ----
 >         (iso-accents-compose prompt)
 >       (vector last-input-char)))
 >   
 > + 
 > + ;; The iso-accents-compose function is called deep inside Emacs' read
 > + ;; key sequence machinery, so the call to read-event below actually
 > + ;; recurses into that machinery.  Doing that does not cause any
 > + ;; problem on its own, but read-event will have marked the window's
 > + ;; display matrix to be accurate -- which is broken by the subsequent
 > + ;; call to delete-region.  Therefore, we must call force-window-update
 > + ;; after delete-region to explicitly clear the accurate state of the
 > + ;; window's display matrix.
 > + 
 >   (defun iso-accents-compose (prompt)
 >     (let* ((first-char last-input-char)
 >       (list (assq first-char iso-accents-list))
 > ***************
 > *** 308,314 ****
 >                          (read-event))
 >                      (insert first-char)
 >                      (prog1 (read-event)
 > !                      (delete-region (1- (point)) (point)))))
 >       (entry (cdr (assq second-char list))))
 >       (if entry
 >      ;; Found it: return the mapped char
 > --- 318,326 ----
 >                          (read-event))
 >                      (insert first-char)
 >                      (prog1 (read-event)
 > !                      (delete-region (1- (point)) (point))
 > !                      ;; Display is no longer up-to-date.
 > !                      (force-window-update (selected-window)))))
 >       (entry (cdr (assq second-char list))))
 >       (if entry
 >      ;; Found it: return the mapped char