Re: Saving Erc buffers (Or: Broken C-x C-w)

[J.P.]

Alcor <alcor@tilde.club> writes:

> "J.P." <jp@neverwas.me> writes:
>
>> Alcor <alcor@tilde.club> writes:
>>
>>> Hi all,
>>>
>>> I'm not sure if this is a bug, but I'll ask just to make sure: I'd like
>>> to save an Erc (channel) buffer to a file. Intuitively, the Emacsism for
>>> this would be C-x C-w or `write-file'.
>>>
>>> However, this does not work on Erc. Or rather, it _does_ save the buffer
>>> to a file, at the rather steep price of breaking the Erc server
>>> state. It looks like Erc's part hook isn't executed, and there seems to
>>> be no simple way to repair the Erc session afterwards (except via
>>> quitting and /reconnect'ing).
>>
>> One consequence of the PART hook not running is that items in the
>> `erc-server-users' table retain stale references to the saved buffer,
>> which is no longer an ERC buffer. Aside from that, it seems the saved
>> buffer's `local-minor-modes' value retains ERC-specific minor modes and
>> its `kill-buffer-hook' is still set to `erc-kill-buffer-function'.
>
> There are also a myriad of other visual issues, e.g. fill/wrapping
> breaking, timestamps disappearing, and some of the faces/formatting
> changing.
>
>>> So the question is - what's the Erc-approved way for doing a one-off
>>> write out of a channel buffer to a file? (as opposed to logging).
>>>
>>> And, if possible, is there a way to fix the behavior of C-x C-w in Erc?
>>
>> Perhaps we ought to ask ourselves what we want to happen when running
>> this command and how that compares to what happens when doing so in
>> other non-file-based modes, like `gud-mode' or various REPLs.
>
> I tried testing on a few other REPLs/shells:
>
> * Eshell: Writes the file out & sets its visited file to the given
>   filename. Otherwise, the shell remains functional.
> * ansi-term: Likewise.

Interesting. It seems the buffer name also changes to the nondirectory
portion of whatever you enter at the prompt. However, if you enter a
directory, the existing name is retained, e.g., "*eshell*". The doc
string of `write-file' mentions something to this effect.

>
> No adverse effects are observed otherwise and both shells remain
> usable. Hitting C-x C-s writes out the current buffer content as expected.
>
>> If the answer turns out to be that C-x C-w (or C-x C-s) should act like
>> C-x h M-x write-region RET, then we should maybe consider declaring
>> `erc-mode' as `special', something that's been brought up casually on
>> occasion but never proposed in earnest (AFAIK).
>>
>> As far as implementations go, we likely couldn't have `erc-mode' inherit
>> from `special-mode' because `readonly' is a module and thus optional.
>> So, we'd most likely have to do a
>>
>>   (put 'erc-mode 'mode-class 'special)
>>
>> in ERC's major-mode definition.
>
> I tried out (put 'erc-mode 'mode-class 'special) and was surprised to
> see that it (mostly) seems to work. With that active, the Erc buffer
> remains functional on C-x C-w. However, the buffer is renamed to the
> filename, which is even reflected in the bufbar. I'm not sure whether
> the latter behavior can be suppressed, but if possible, then this would
> seem like a fair solution (although some other way of indicating that
> the Erc buffer is bound to a file will still be needed).

We could just add a note to the manual recommending the usage pattern
mentioned above re preserving the existing name by specifying a
directory at the prompt. Or, we could maybe mess around with
`after-set-visited-file-name-hook', but (AFAIK) its members must be
global to be effective, which may complicate things somewhat. Basically,
we'd want to rename the buffer to its former name via something like:

  (rename-buffer (buffer-last-name))

This shouldn't affect `buffer-file-name', so C-x C-s should still write
to the previously chosen file.

One approach to implementing this might be to remap `write-file' to our
own command that either shadows `after-set-visited-file-name-hook'
around a call to `write-file' or simply reverts the buffer name
afterwards without involving the hook at all. (I guess it'd come down to
whether the code in `write-file' following the execution of that hook
needs to know the final buffer name.)

> (Note: I tested this on a server buffer for like ~2 minutes, so there
> might be adverse effects I'm unaware of, but it *looks* definitely less
> broken)

Beyond the modification flag business, I'm not sure the connection isn't
more than tenuous for `special-mode' buffers.

> In the end, I remain unsure of the best way to handle this. Inheriting
> from 'special seems like a step in the right direction and warrants some
> further investigation. In the meantime, C-x h M-x write-region RET is
> also acceptable.

If you do pursue this further and arrive at something satisfactory,
please consider sending a patch to the tracker. :)