From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Trent W. Buck" Newsgroups: gmane.emacs.bugs Subject: bug#57376: 28.1; rcirc-fill-flag ignored after 27->28 upgrade Date: Sat, 27 Aug 2022 14:10:01 +1000 Message-ID: References: <87y1vekpyl.fsf@gmail.com> <875yihoofa.fsf@gnus.org> <871qt4qquo.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22913"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 57376@debbugs.gnu.org To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 27 06:11:24 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 1oRnAK-0005my-AV for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Aug 2022 06:11:24 +0200 Original-Received: from localhost ([::1]:55790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oRnAI-0006BY-VZ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Aug 2022 00:11:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53384) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oRn9z-0006BB-EU for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 00:11:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36978) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oRn9y-0000bo-3b for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 00:11:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oRn9x-0005tl-Qu for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 00:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Trent W. Buck" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Aug 2022 04:11: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.166157341622588 (code B ref 57376); Sat, 27 Aug 2022 04:11:01 +0000 Original-Received: (at 57376) by debbugs.gnu.org; 27 Aug 2022 04:10:16 +0000 Original-Received: from localhost ([127.0.0.1]:54958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRn9E-0005sF-1J for submit@debbugs.gnu.org; Sat, 27 Aug 2022 00:10:16 -0400 Original-Received: from mail-pj1-f51.google.com ([209.85.216.51]:39549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRn9B-0005ru-3e for 57376@debbugs.gnu.org; Sat, 27 Aug 2022 00:10:14 -0400 Original-Received: by mail-pj1-f51.google.com with SMTP id i8-20020a17090a65c800b001fd602afda2so3398285pjs.4 for <57376@debbugs.gnu.org>; Fri, 26 Aug 2022 21:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc; bh=EzAtFM0qxi6DoicoQxvQStKi7/vWj6Zbm6tMf/pgMWQ=; b=jzAFUyg4CTBWcvuvVAgY/v0/DXDsmLYTWBcNfem3NCOchpwEjn7EmQImDW9ywpY5IS XGktd7KGTcfuRSi78capb8TMIo2ZkpTOv3DY60L2B3/F1FqRP7hYoHawJv2vwWp4jSxw 3efMjL9ilN93EML+/iw20ZSo0yfrFC3Awh72NY7tIPmc9AU4C/+W0UhIAf84OqG2meQN WsDBKHc2BulnNWCjv1lkRv+wxudW/uTP895COHj/LTGKNmNbDpW1E8JCAAREDf7/rIV/ U3yvOp5tRhTl3ITidqWeuAE/w1EQTs1SrpoUdqgQ1ri5VDpARmiV9b2HiZK8K7fXu7mN 8LtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc; bh=EzAtFM0qxi6DoicoQxvQStKi7/vWj6Zbm6tMf/pgMWQ=; b=Gn/xJgsiNFQKrjt2l7itUkdiA5DtaSRfLD4N7LAv1QBa8TbaHvIeWAI9m38pZsVGsD 7C94jrC5jJjhsTEwBA3Wbg+RYf0YkonZsb+M1fOqQF8OOOakgeBWJkA7Y5SvWfUkHR7a ADbkFJtyLb1jsmFXlHlLbDuk8dRdPZm3lOlJXdOLDEfF5GsrKKZ+VfFxrUTHmNp9qHK5 llvRhp+TSA5B1kczA9OGDACtBPSOUo3ozH/bce4f4Ul3E4SqxLbMUMsng0BnM5C3wZ6B dSzJ0u+xVdBanFtyKdEb9J5ZykMKtsL7ItE77G0ElQQBKCHzfk5d5U8CMnQ2Q8fEXewZ LLnA== X-Gm-Message-State: ACgBeo2SvTNhZ3vux1XfFWmq0BGLANV5VjGnuXVvNkhdNItVWWLwXC56 Ez0zQuVnpzb1yWgiPvApWNrzQP5prN0= X-Google-Smtp-Source: AA6agR5byPky3QiUtfXfbNT/Wn9nFu8NNpxSF0bXBC7T/2YZIkB3WUODkFkhw4TZ/YaquvbteXl1Yw== X-Received: by 2002:a17:903:248b:b0:172:a790:3206 with SMTP id p11-20020a170903248b00b00172a7903206mr6562771plw.139.1661573406961; Fri, 26 Aug 2022 21:10:06 -0700 (PDT) Original-Received: from localhost (159-196-230-25.9fc4e6.mel.nbn.aussiebb.net. [159.196.230.25]) by smtp.gmail.com with ESMTPSA id v186-20020a6261c3000000b00535ebc6cd4bsm2539170pfb.218.2022.08.26.21.10.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Aug 2022 21:10:06 -0700 (PDT) Content-Disposition: inline In-Reply-To: <871qt4qquo.fsf@posteo.net> 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:240873 Archived-At: 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! > 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 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 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 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 RECSIZE COMPRESS RATIO REFQUOTA QUOTA USED USEDDS USEDSNAP REFER NAME 13:59 1M zstd 5.83x 8G 64G 4.69G 277M 951M 277M heavy/heavy/var/log 13:59 128K zstd 3.22x 4G 16G 2.97G 1.14G 1.83G 1.14G heavy/omega/var/log With canonically-space-region, 13:59 RECSIZE COMPRESS RATIO REFQUOTA QUOTA USED USEDDS USEDSNAP REFER NAME 13:59 1M zstd 5.83x 8G 64G 4.69G 277M 951M 277M heavy/heavy/var/log 13:59 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 RECSIZE COMPRESS RATIO REFQUOTA QUOTA USED USEDDS USEDSNAP REFER NAME 14:00 1M zstd 5.83x 8G 64G 4.69G 277M 951M 277M heavy/heavy/var/log 14:00 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.