[Erc-help] Re: [PATCH] (erc-process-sentinel): add customizable option to close server buffers automatically, code cleanup

[Michael O. <mw...@me...>]

On Thu, 15 Jul 2004 21:15:09 +0100, lawrence mitchell wrote:

> Michael Olson wrote:
>
>> On Thu, 15 Jul 2004 13:11:53 +0100, lawrence mitchell wrote:
>
>>> Why does let-binding (I assume that's what you're doing)
>>> inhibit-read-only to t not allow reconnection.  That sounds like
>>> a deeper problem, but, without looking, I'm not really sure.
>
>> I think this is a problem with Emacs from CVS.  I never experienced
>> that problem with Emacs 21.3 .  I'm thinking about reporting this
>> problem to the emacs-devel list.  XEmacs handled an attempt to kill
>> read-only text by refusing to do it, even though the buffer had the
>> inhibit-read-only flag set.

> If this is indeed the case, then I think we probably want to
> report it as an Emacs bug, rather than use work-arounds in ERC.
> However, I see that you no longer use this method (due to the
> problems it causes) --- is the new code "neater" than the old
> buggy stuff?

I'll go into some detail about the problem.  The message that appears
when the lock-up occurs is "error in process sentinel:
erc-encode-coding-string: Text is read-only".  I traced that error
and found the path of execution to be:
erc-process-sentinel -> erc-login -> erc-display-message

My guess is that when I used:

 (let ((inhibit-read-only t))
   (kill-line 0))

to kill the prompt, Emacs would allow the text to be killed, but the
next time ERC tried to write "special" text properties like read-only
to the buffer, Emacs choked.

The use of erc-remove-text-properties-region is indeed a much better
approach, IMO, as it works on both Emacs and XEmacs, and more
elegantly solves the problem at hand.

I'll try to come up with a sample routine that will break Emacs, so
that the Emacs maintainers can replicate the error.