Package: emacs;
Reported by: "Trent W. Buck" <trentbuck <at> gmail.com>
Date: Wed, 24 Aug 2022 08:27:01 UTC
Severity: normal
Tags: moreinfo
Found in version 28.1
Done: Philip Kaludercic <philipk <at> posteo.net>
Bug is archived. No further changes may be made.
Message #16 received at 57376 <at> debbugs.gnu.org (full text, mbox):
From: "Trent W. Buck" <trentbuck <at> gmail.com> To: Philip Kaludercic <philipk <at> posteo.net> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 57376 <at> debbugs.gnu.org Subject: Re: bug#57376: 28.1; rcirc-fill-flag ignored after 27->28 upgrade Date: Sat, 27 Aug 2022 14:10:01 +1000
Philip Kaludercic wrote: > Lars Ingebrigtsen <larsi <at> gnus.org> writes: > > > > > "Trent W. Buck" <trentbuck <at> gmail.com> 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 <philipk <at> posteo.net> > > 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! > Trent: Could to try to apply this change and see if rcirc behaves the > way you would prefer it to? I initially tried commenting that call out entirely. (with-eval-after-load "rcirc" (defun rcirc-print (process sender response target text &optional activity) ⋮ ;; squeeze spaces out of text before rcirc-text ;;(fill-region (point-min) (point-max)) ⋮ )) Then in an already-open irc connection, I joined a new channel #twb-irc-test and then typed this: 13:52 *** twb JOIN 13:52 *** MODE +Cnst 13:52 *** NAMES @twb > This is a long line blah blah blah blah blah blah blah blah blah blah blah blah blah. Here are five spaces in a row " ". rcirc should not change my input AT ALL. It is very annoying to have my words changed. It is especially annoying to have them changed DIFFERENTLY for what other people hear, versus what I hear myself saying! When I pressed RET, this is what happened: 13:52 *** twb JOIN 13:52 *** MODE +Cnst 13:52 *** NAMES @twb 13:56 <twb> This is a long line blah blah blah blah blah blah blah blah blah blah blah blah blah. Here are five spaces in a row " ". rcirc should not change my input AT ALL. It is very annoying to have my words changed. It is especially annoying to have them changed DIFFERENTLY for what other people hear, versus what I hear myself saying! So, this is DEFINITELY the problem call. Thanks for narrowing it down, I was tearing my hair out! Now let me try it again with your suggested edit (fill-region -> canonically-space-region). In the existing buffer, I hit M-p RET. That has broken my input. It is not wrapped, but it has changed my whitespace to be wrong. 13:56 <twb> This is a long line blah blah blah blah blah blah blah blah blah blah blah blah blah. Here are five spaces in a row " ". rcirc should not change my input AT ALL. It is very annoying to have my words changed. It is especially annoying to have them changed DIFFERENTLY for what other people hear, versus what I hear myself saying! 13:57 <twb> This is a long line blah blah blah blah blah blah blah blah blah blah blah blah blah. Here are five spaces in a row " ". rcirc should not change my input AT ALL. It is very annoying to have my words changed. It is especially annoying to have them changed DIFFERENTLY for what other people hear, versus what I hear myself saying! This is far less noticable, but is definitely annoying and wrong if I paste a table into a #flood channel. For example, with neither fill-region nor canonically-space-region, 13:59 <twb> RECSIZE COMPRESS RATIO REFQUOTA QUOTA USED USEDDS USEDSNAP REFER NAME 13:59 <twb> 1M zstd 5.83x 8G 64G 4.69G 277M 951M 277M heavy/heavy/var/log 13:59 <twb> 128K zstd 3.22x 4G 16G 2.97G 1.14G 1.83G 1.14G heavy/omega/var/log With canonically-space-region, 13:59 <twb> RECSIZE COMPRESS RATIO REFQUOTA QUOTA USED USEDDS USEDSNAP REFER NAME 13:59 <twb> 1M zstd 5.83x 8G 64G 4.69G 277M 951M 277M heavy/heavy/var/log 13:59 <twb> 128K zstd 3.22x 4G 16G 2.97G 1.14G 1.83G 1.14G heavy/omega/var/log With fill-region (current emacs-28 behaviour), 14:00 <twb> RECSIZE COMPRESS RATIO REFQUOTA QUOTA USED USEDDS USEDSNAP REFER NAME 14:00 <twb> 1M zstd 5.83x 8G 64G 4.69G 277M 951M 277M heavy/heavy/var/log 14:00 <twb> 128K zstd 3.22x 4G 16G 2.97G 1.14G 1.83G 1.14G heavy/omega/var/log I don't understand why anyone would EVER want this, but I think I will be happy if the fill-region/canonically-space-region is just wrapped in (when rcirc-fill-flag #). That will let me easily opt-out, without affecting anyone else. Is that sensible? PS: quite often I'll go up to an earlier line I've said, and either hit RET (rcirc-send-input) to re-send it as-is, or M-p M-p M-p M-p RET, or copy-paste-edit it in the > prompt. I *think* this fill-region is screwing me up badly in that workflow, because it ends up re-sending one IRC message for each filled line, rather than one IRC message per original input line. I haven't tested that extensively, so it might be a red herring.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.