>>>>> Noam Postavsky writes: >>>>> Ivan Shmakov writes: >> I’m somewhat unsure if this change is NEWS-worthy; if so, I suggest >> the following entry. > The behaviour of debug tracing functions is somewhat in the gray area > between user visible and internal details, but I’d say there’s no > need to update NEWS for this. ACK. >> + (let ((old (set-marker (make-marker) (point)))) > You could use (point-marker) instead. ACK, thanks! >> + (set-marker-insertion-type old t) >> + (goto-char (point-max)) >> + (let ((inhibit-read-only t)) >> + (terpri (current-buffer) t) > This looks like you’re adding an extra newline, Only if there’s none already, as the second argument to terpri is non-nil. Which can happen, for example, should user edit the buffer manually (for whatever reason.) > or was there a lack of newlines before? Actually, yes, there seem to be an issue with a “missing” trailing newline when rcirc-debug is called from rcirc-filter. AIUI, when the remote produces a large amount of data (such as just after the handshake), rcirc-filter gets called for each bufferful of data, e. g.: (rcirc-filter # "line-1\nline-2\nli") (rcirc-filter # "ne-3\nline-4\nline") (rcirc-filter # "-5\nline-6\nline-7") ; and so on… There, rcirc-filter will accumulate data in rcirc-process-output and process only when the value ends with a newline. OTOH, rcirc-debug gets called once for each rcirc-debug call, currently resulting in the *rcirc debug* state being like: [2018-09-14T18:35:19 process] line-1 line-2 li[2018-09-14T18:35:19 process] ne-3 line-4 line[2018-09-14T18:35:19 process] -5… This patch ensures a newline before every [timestamp] marker. Please consider the revised patch MIMEd. FTR, a ‘side effect’ of this change is that rcirc-debug no longer returns the string appended to buffer. (Instead, it returns the marker coinciding with point.) AFAICT, the return value of this function is never used in the Rcirc code. -- FSF associate member #7257 http://softwarefreedomday.org/ 15 September 2018