Re: Fontifying-errors make Emacs (mostly) unusable

Re: Fontifying-errors make Emacs (mostly) unusable

[Stefan Monnier]

> Thats probably because the error appears in a (fontifying) hook
> function thats called before any real action.
> How can I get out of this 'trap' without restarting Emacs?

Depends on the specific problem you're encountering, but it may very
well be that kill&restart is the only way to fix it.

Due to Emacs's extensive reliance of "modifiable Elisp code", it's
generally impossible to prevent such situations.

There is code in various parts of Emacs to try and handle some
particular cases (e.g. an error in a pre-command-hook will cause Emacs
to remove that function from the hook), so if you can give details about
your particular case and it seems to be a common enough problem, maybe
we can find a way to make Emacs behave more gracefully.


        Stefan

Re: Fontifying-errors make Emacs (mostly) unusable

[Thorsten Jolitz]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Thats probably because the error appears in a (fontifying) hook
>> function thats called before any real action.
>> How can I get out of this 'trap' without restarting Emacs?
>
> Depends on the specific problem you're encountering, but it may very
> well be that kill&restart is the only way to fix it.
>
> Due to Emacs's extensive reliance of "modifiable Elisp code", it's
> generally impossible to prevent such situations.
>
> There is code in various parts of Emacs to try and handle some
> particular cases (e.g. an error in a pre-command-hook will cause Emacs
> to remove that function from the hook), so if you can give details about
> your particular case and it seems to be a common enough problem, maybe
> we can find a way to make Emacs behave more gracefully.

Ok, here is a recipe to reproduce the error: 

0. with fully functional emacs, get markdown.el (via package manager)
   and make a copy of it (marktest.el)
1. (re)start "emacs -Q"
2. open file marktest.el
3. comment out this defun (at line 1954):

;; (defun markdown-fontify-buffer-wiki-links ()
;;   "Refontify all wiki links in the buffer."
;;   (interactive)
;;   (markdown-check-change-for-wiki-link (point-min) (point-max) 0))


4. save and eval-buffer (or load marktest.el)
5. find (new empty) file test.md
6. put it in markdown-mode (M-x markdown-mode)

#Bang#

'Symbol is void...' error message
try M-x, M-:, C-x d, nothing works, you are trapped. 

-- 
cheers,
Thorsten

Re: Fontifying-errors make Emacs (mostly) unusable

[Stefan Monnier]

> 3. comment out this defun (at line 1954):
> ;; (defun markdown-fontify-buffer-wiki-links ()
> 4. save and eval-buffer (or load marktest.el)
> 5. find (new empty) file test.md
> 6. put it in markdown-mode (M-x markdown-mode)
> #Bang#
> 'Symbol is void...' error message
> try M-x, M-:, C-x d, nothing works, you are trapped. 

I see it, yes.

Actually it's only the minibuffer-using functions which are affected and
only while the markdown-mode buffer is displayed in your frame, so if
you switch buffer (without minibuffer interaction, e.g. by clicking on
the buffer-name in the mode-line), then M-x works again (and you can C-x
k the offending markdown-mode buffer).

The fix is to run window-configuration-change-hook with the trick as
used for pre-command-hook (and various other hooks).  The only problem
is that window-configuration-change-hook is a highly non-standard hook
which cannot be run by the usual run_hook functions, so it'll require
more work to make Emacs behave gracefully.


        Stefan

Re: Fontifying-errors make Emacs (mostly) unusable

[Thorsten Jolitz]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 3. comment out this defun (at line 1954):
>> ;; (defun markdown-fontify-buffer-wiki-links ()
>> 4. save and eval-buffer (or load marktest.el)
>> 5. find (new empty) file test.md
>> 6. put it in markdown-mode (M-x markdown-mode)
>> #Bang#
>> 'Symbol is void...' error message
>> try M-x, M-:, C-x d, nothing works, you are trapped. 
>
> I see it, yes.
>
> Actually it's only the minibuffer-using functions which are affected and
> only while the markdown-mode buffer is displayed in your frame, so if
> you switch buffer (without minibuffer interaction, e.g. by clicking on
> the buffer-name in the mode-line), then M-x works again (and you can C-x
> k the offending markdown-mode buffer).

Using emacs-server and emacsclients, I used my window-manager to get to
another emacsclient window and write these mails with gnus. But to
continue working on my markdown-clone.el and the test.md file, I had to
restart emacs-server.

> The fix is to run window-configuration-change-hook with the trick as
> used for pre-command-hook (and various other hooks).  The only problem
> is that window-configuration-change-hook is a highly non-standard hook
> which cannot be run by the usual run_hook functions, so it'll require
> more work to make Emacs behave gracefully.

I now fixed all those errors for my usecase. If its worth to fix the
general behaviour would be your decision, thats a bit too specific for
me to be of any help there. Only wanted to report the problem. 

-- 
cheers,
Thorsten

Fontifying-errors make Emacs (mostly) unusable

[Thorsten Jolitz]

Hi List, 

while cloning an Emacs major mode for a special wiki syntax, I
experienced that errors related to fontifying really can become
show-stoppers.

Lets say, I'm modifying/adapting some face definitions for the new
mode, but do not recognize that one old definition is still used in e.g.
a parsing function. Then, evaluating the buffer, I get an error message
like:

,-----------------------------------------
| Symbol's function-definiton is void: ...
`-----------------------------------------

I can fix the error, but from that moment on Emacs core functionality is
blocked. M-x as well as M-: or e.g. C-x d do nothing anymore but giving
me the same error message like above (although the root-cause of the
error is already fixed).

Thats probably because the error appears in a (fontifying) hook
function thats called before any real action.

How can I get out of this 'trap' without restarting Emacs?

-- 
cheers,
Thorsten