unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: "Trent W. Buck" <trentbuck@gmail.com>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, 57376@debbugs.gnu.org
Subject: bug#57376: 28.1; rcirc-fill-flag ignored after 27->28 upgrade
Date: Sat, 27 Aug 2022 08:14:29 +0000	[thread overview]
Message-ID: <875yiedrx6.fsf@posteo.net> (raw)
In-Reply-To: <YwmYcRdgysNT2C5y@hera.lan> (Trent W. Buck's message of "Sat, 27 Aug 2022 14:10:01 +1000")

"Trent W. Buck" <trentbuck@gmail.com> writes:

>
> 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!

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 <eliz@gnu.org>
        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?





  reply	other threads:[~2022-08-27  8:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24  8:25 bug#57376: 28.1; rcirc-fill-flag ignored after 27->28 upgrade Trent W. Buck
2022-08-24 11:45 ` Lars Ingebrigtsen
2022-08-25 15:34   ` Philip Kaludercic
2022-08-27  4:10     ` Trent W. Buck
2022-08-27  8:14       ` Philip Kaludercic [this message]
2022-08-27 13:22         ` Lars Ingebrigtsen
2022-08-27 13:37           ` Philip Kaludercic
2022-09-24 14:58             ` Lars Ingebrigtsen
2022-09-24 15:51               ` Philip Kaludercic
2022-09-25  8:31               ` Philip Kaludercic
2022-09-26  0:33                 ` Trent W. Buck
2022-10-06 10:34                 ` Philip Kaludercic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875yiedrx6.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=57376@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=trentbuck@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).