Re: Eshell - `Text is read-only`

[Guido Van Hoecke]

Hi Drew,

Drew Adams <drew.adams@oracle.com> writes:

>> > Hi all, I've run into the dreaded `Text is read-only` bug which stops
>> > eshell from closing and Emacs from exiting. I got this in a previous
>> > version of Emacs and fixed it with the following snippet:
>> 
>> I just hit the problem today. I'd say it occurs once a month at the
>> most.
>>
>> Although it does not happen frequently, I sure would like to get it
>> solved. There's only one solution afaik, and that's just killing emacs,
>> as in `kill -9 emacs_pid`. This is drastic, but the only way I know to
>> get rid of the buffer :(
>> 
>> Any suggestion and/or help would be really appreciated!
>
> The standard error that shows that error message is `text-read-only'.
> (See (elisp) `Standard Errors'.)
>
> You could try wrapping whatever code you use that ends up calling
> calling code that raises the error with this:
>
> (condition-case handle-text-read-only
>   ... ; Your code that leads to the error goes here
>   (text-read-only (debug)))

Unfortunately I have no idea what code is causing the bug, and right now
there's not enough time to hunt down an annoying but infrequent
bug. I'll keep your suggestions in my archive. That way I'll be able to
use them when any of the above condition change.

> That should put you in the debugger whenever that error is raised.
> From there you can evaluate expressions (using `e') to possibly
> get more info about what the problem (cause) is.
>
> Note that this is a subcategory of standard error `buffer-read-only'.
> It arises when something tries to modify a character that has text
> property `read-only' (see (elisp) `Text Properties').
>
> You can also just try setting `debug-on-error' to t, in which case
> the debugger should be entered for any error.

I'll try that one.

> However you get to the debugger, it provides a backtrace of the
> functions that led to the error.  With that knowledge, you can
> use `debug-on-entry FUNCTION', to instead enter the debugger for
> a FUNCTION you see on the backtrace stack, and then step through
> its evaluation using `d'.  That will give you a better idea of
> what's going on.


Thanks for your help,

Guido