Eli Zaretskii writes: >> > This still uses a less-than-elegant implementation that calls >> > with-current-buffer twice. >> >> Yes, true. But since `sieve-manage--set-internal-buffer-properties' is >> used in two different places, the more elegant solution you suggested >> above would require duplicating the body of the function in those >> places. I just didn't see a better way. > > I'm not sure why you need to force the encoding of the process buffer, > when you already set the coding-system to be used for decoding stuff > from the process. Is that really needed? Not sure if it is really needed. But I wanted to make sure that both, the process buffer and the log buffer use identical settings. Otherwise, the content of the log buffer might be misleading. > But if you really need this, then just make the insertion of the text > into the buffer you create optional: then for the process-buffer pass > nil as the text to insert, and you can do the with-current-buffer > dance only inside that function. Sorry, you lost me there. I don't understand what you want to tell me. Which (optional) text in which buffer? > Since you seem to be encoding and decoding to/from UTF-8 by hand in > sieve-manage-encode/decode, you should use 'binary' as the > process-codings-system for the network connection to the server, and > that's it. That works. Done. > What you should do is call sieve-manage-encode inside > sieve-manage-send, and count the bytes there after encoding the > payload. Unfortunately, that is too late since the sent data - in case that the sent text may contain CRLF sequences - contains its own length. So in order to insert the correct length, I need to encode before sending. See: (defun sieve-manage-putscript (name content &optional buffer) (with-current-buffer (or buffer (current-buffer)) (sieve-manage-send (format "PUTSCRIPT \"%s\" {%d+}%s%s" name (length (sieve-manage-encode content)) sieve-manage-client-eol content)) (sieve-manage-parse-oknobye))) >> 1. set `sieve-manage--coding-system' to 'utf-8-unix and >> 2. changed the call to `open-network-stream' in the patch above to >> >> @@ -244,8 +267,7 @@ sieve-manage-open-server >> >> (open-network-stream >> >> "SIEVE" buffer server port >> >> :type stream >> >> - ;; eol type unix is required to preserve "\r\n" >> >> - :coding 'raw-text-unix >> >> + :coding sieve-manage--coding-system >> instead of the previous, asymmetric mix of `binary and >> `sieve-manage--coding-system'. > > This could work, but AFAIU, you need to specify the content length in > bytes for the PUTSCRIPT command, so you must encode the content > yourself. Thus my suggestion to use 'binary' in the :coding attribute > of the process, and instead encode/decode using > sieve-manage-encode/decode to/from UTF-8 inside sieve-manage-send and > sieve-manage-parse-* functions. Yes, that's what I explained above (before reading this part of your reply). Unfortunately, just using `sieve-manage--coding-system' for the :coding property didn't work, but I'm now using 'binary' encoding for both directions. >> > Should the addition of BYE support be mentioned in NEWS? >> >> I can certainly do that if you think that this is useful. It just seems >> to be more of an internal detail which probably doesn't mean much to >> most users. > > Isn't BYE provides some capabilities that user/callers would like to > know about? From RFC5804: response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"] [SP string] CRLF ;; The string contains human-readable text ;; encoded as UTF-8. As far as I understand, the difference between NO and BYE is that BYE is just a different (and more drastic, because the server will also disconnect) way of signalling an error. Fortunately, the human readable is typically included in these responses and will be shown to the user. Here is some more info about where BYE SHOULD (not MUST) be used: The BYE response SHOULD be used if the server wishes to close the connection. A server may wish to do this because the client was idle for too long or there were too many failed authentication attempts. This response can be issued at any time and should be immediately followed by a server hang-up of the connection. ... If I remember correctly, the timeout case was the reason why I added the BYE handling (since during my experiments, I sometimes used the debugger to understand what's going on which introduced long delays between connection establishment/authentication and sending the first request and resulted in a BYE instead of a NO). There's also one additional (more interesting) case: REFERRAL This response code may be returned with a BYE result from any command, and includes a mandatory parameter that indicates what server to access to manage this user's Sieve scripts. The server will be specified by a Sieve URL (see Section 3). The scriptname portion of the URL MUST NOT be specified. The client should authenticate to the specified server and use it for all further commands in the current session. However, even my updated sieve-manage code doesn't handle REFERRALs. So I still think that to understand the difference between a BYE and a NO would require the user to take a (deeper) dive into the RFC. But to avoid a longer discussion, how about: * Changes in Specialized Modes and Packages in Emacs 30.1 ... ** sieve-manage -- *** Added (partial) handling of BYE responses The managesieve client in `sieve-manage' now handles BYE responses sent be the server (in addition to OK and NO). This makes the implementation more robust in case of e.g. timeouts and authentication failures. Note: The special case of a REFERRAL/BYE responses is still not handled by the client (s. RFC5804 for more details).