From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#57376: 28.1; rcirc-fill-flag ignored after 27->28 upgrade Date: Sat, 27 Aug 2022 08:14:29 +0000 Message-ID: <875yiedrx6.fsf@posteo.net> References: <87y1vekpyl.fsf@gmail.com> <875yihoofa.fsf@gnus.org> <871qt4qquo.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39622"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 57376@debbugs.gnu.org To: "Trent W. Buck" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 27 10:15:33 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oRqya-000A7L-Su for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Aug 2022 10:15:33 +0200 Original-Received: from localhost ([::1]:46804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oRqyZ-0007zM-9n for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Aug 2022 04:15:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35922) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oRqy6-0007z8-2c for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 04:15:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37100) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oRqy5-0007bx-Pi for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 04:15:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oRqy5-0003hF-IZ for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 04:15:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Aug 2022 08:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57376 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 57376-submit@debbugs.gnu.org id=B57376.166158808614174 (code B ref 57376); Sat, 27 Aug 2022 08:15:01 +0000 Original-Received: (at 57376) by debbugs.gnu.org; 27 Aug 2022 08:14:46 +0000 Original-Received: from localhost ([127.0.0.1]:55082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRqxp-0003gX-TO for submit@debbugs.gnu.org; Sat, 27 Aug 2022 04:14:46 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:39427) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRqxo-0003gK-40 for 57376@debbugs.gnu.org; Sat, 27 Aug 2022 04:14:45 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4F36D240026 for <57376@debbugs.gnu.org>; Sat, 27 Aug 2022 10:14:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1661588078; bh=AGjBhYaNWxbZsXOLDrW6I6HAyjsY8WBQQf7XHpJcYQo=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=PH7o/8cBCvfv36LnMSMGILwh3BalpvWbXDBhTqRE/wRn155lJ1qnJztrpwJKuI+nA gX8Z121iIzlPg0jvQcSg1impqaWWqFX2v97sYGcIDkIFvUUAY7pPnd3s3uknji0Idq O9CowLX8gxFmgK5RkG6macSy4QFAyKIkSgV2KPwdD/dxHLpvT07nuwxJ/htcIdzY3L gc7HbSse8Lz/kB43xl0txL8vag2SItCvdFk5UH6efIfFIU+4Sb5ZKbRwHWtBAt+YDM T9xy/VQMk9w2S2hkygn3SELrc3EFfDASr8AZELPf3k565JdQDumW27kosKjrGZ7fpL ZTK1VbXWeBsKQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MF8cp5t54z6tmp; Sat, 27 Aug 2022 10:14:34 +0200 (CEST) In-Reply-To: (Trent W. Buck's message of "Sat, 27 Aug 2022 14:10:01 +1000") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:240884 Archived-At: "Trent W. Buck" writes: > > Philip Kaludercic wrote: >> Lars Ingebrigtsen writes: >> >> > >> > "Trent W. Buck" writes: >> > >> >> I just upgraded from 1:27.1+1-3.1 to 1:28.1+1-2~bpo11+1.2. >> >> Now, even though (setq rcirc-fill-flag nil) in my .emacs, >> >> I am getting hard wrapping. >> >> >> >> None of these (evaluated in-buffer with M-:) stopped new messages >> >> being >> >> hard-wrapped at 70 columns: >> >> >> >> (setq rcirc-fill-flag nil) >> >> (auto-fill-mode -1) >> >> (defun rcirc-markup-fill (x y)) ; nop out this unwanted >> >> function >> >> (defun rcirc-fill-paragraph (&optional x)) ; nop out this >> >> unwanted function >> > >> > I haven't tested myself, but it seems like the code in this area >> > was >> > changed by: >> > >> > commit 849e71fd83fa8796198035464897bf2f28f6226c >> > Author: Philip Kaludercic >> > AuthorDate: Wed Jun 9 17:55:55 2021 +0200 >> > >> > Implement server-time extension >> > >> > * rcirc.el (rcirc-implemented-capabilities): Add new capability >> > (rcirc-print): Insert messages in the right position >> > (rcirc-log): Use right time value >> > (rcirc-markup-timestamp): Use right time value >> > >> > In particular, this: >> > >> > - ;; squeeze spaces out of text before rcirc-text >> > - (fill-region fill-start >> > - (1- (or (next-single-property-change fill-start >> > - 'rcirc-text) >> > - rcirc-prompt-end-marker))) >> > >> > was changed to this: >> > >> > + ;; squeeze spaces out of text before rcirc-text >> > + (fill-region (point-min) (point-max)) >> > >> > But I don't really know the code well. Adding Philip to the CCs. >> >> The code was reduced to (fill-region (point-min) (point-max)) because >> the updated insertion algorithm narrows the buffer to the message, >> that >> doesn't have to be right before the prompt, as the entire point of >> the >> patch is that messages can be inserted anywhere, depending on >> server-time tag. >> >> As the comment indicates, the intention is to "squeeze >> [white]spaces", >> so a possible fix might be to use `canonically-space-region' instead >> of >> `fill-region'? > > FWIW, I don't want rcirc to change my whitespace either! Come to think about it, I don't understand the idea bind it either. I looked through the git history, and it appears the change was added in this commit: commit 2fbed782a0705d8b6e776926bb4eaa6b8801cfcb Author: Eli Zaretskii Date: Fri Feb 17 11:19:00 2006 +0000 (rcirc-connect): Make all arguments optional, and default to global variable values for unsupplied args. (rcirc-get-buffer-create): Fix bug with setting the target. (rcirc-any-buffer): Rename from rcirc-get-any-buffer, and include test for rcirc-always-use-server-buffer-flag here. (rcirc-response-formats): Add %N, which is a facified nick. %n uses the default face. Change the ACTION format string. If the "nick" is the server, don't print anything for that field. Comment fixes. (rcirc-target-buffer): Don't test rcirc-always-use-server-buffer-flag here. ~~~> (rcirc-print): Squeeze extra spaces out of the text before message. (rcirc-put-nick-channel): Strip potential "@" char from nick before adding them to nick table. (rcirc-url-regexp): Improve to match address like "foo.com". It appears to me that since `rcirc-fill-flag' will usually invoke `fill-region' just a few lines later, it should be possible to just get rid of the space-squeezing all together? But it might also be that I made a mistake in the commit that Lars mentioned previously. It appears that in the removed code --8<---------------cut here---------------start------------->8--- - ;; squeeze spaces out of text before rcirc-text - (fill-region fill-start - (1- (or (next-single-property-change fill-start - 'rcirc-text) - rcirc-prompt-end-marker))) --8<---------------cut here---------------end--------------->8--- the variable `fill-start' was initially bound to --8<---------------cut here---------------start------------->8--- (let ((moving (= (point) rcirc-prompt-end-marker)) - (old-point (point-marker)) - (fill-start (marker-position rcirc-prompt-start-marker))) + (old-point (point-marker))) --8<---------------cut here---------------end--------------->8--- But I am not sure I understand what is going on here, since this "fills the region" between the beginning of the prompt and either the end of the prompt or the next (nonexistant?) message? So shouldn't this have -- prior to my change -- have done nothing, all the time?