bug#57376: 28.1; rcirc-fill-flag ignored after 27->28 upgrade

[Trent W. Buck]

Philip Kaludercic wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> >
> > "Trent W. Buck" <trentbuck@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@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.