bug#54406: 28.0.91; rcirc text wrapping

bug#54406: 28.0.91; rcirc text wrapping

[Ken Raeburn]

 
I’ve got automatic filling of text disabled in rcirc; I use 
variable-pitch-mode for more pleasant readability, and 
visual-line-mode and wrap-prefix to get line breaks based on the 
window width.  Or, at least, I did in previous releases. 
 
        (custom-set-variables 
         ;; custom-set-variables was added by Custom.  ;; If you 
         edit it by hand, you could mess it up, so be careful.  ;; 
         Your init file should contain only one such instance.  ;; 
         If there is more than one, they won't work right. 
         …STUFF…  '(rcirc-authinfo '(…STUFF…))  '(rcirc-fill-flag 
         nil) '(rcirc-keywords '(…STUFF…))  '(rcirc-log-flag t) 
         '(rcirc-reconnect-delay 0) '(rcirc-server-alist 
           '((…WORK STUFF…) 
             ("irc.gnome.org" :nick "raeburn" :port 6697 :channels 
              ("#gnucash") :encryption tls) 
             ("irc.libera.chat" :nick "raeburn" :port 6697 
             :channels 
              ("#rcirc" "#vdo" "#fedora" "#rhel" "#fedora-x86" 
              "#fedora-ppc" "#fedora-arm" "#fedora-s390x" 
              "#fedora-laptops" "#emacs" "#ansible" "#gnus" 
              "#org-mode") :encryption tls))) 
         '(rcirc-time-format "%FT%T ") '(rcirc-track-minor-mode t) 
         …STUFF… 
 
 
        (defun kr-rcirc-markup-text-function (sender response) 
          (put-text-property (point) (point-max) 'wrap-prefix " 
          ")) 
        (add-to-list 'rcirc-markup-text-functions 
        'kr-rcirc-markup-text-function t) 
 
        (require 'smart-quotes) (defun kr-rcirc-mode-hook () 
          (variable-pitch-mode 1) (visual-line-mode 1) 
          (smart-quotes-mode 1)) 
        (add-hook 'rcirc-mode-hook 'kr-rcirc-mode-hook) 
 
Now, in Emacs 28.0.91, I still get the variable pitch, and 
visual-line mode applies while I’m entering input, but it appears 
that all messages displayed get wrapped at 70 columns 
(fill-column) even though I’ve got rcirc-fill-flag set to nil. 
This includes not just user messages but also control messages 
like JOIN, QUIT, NAMES, and so on.  I’ve enabled debugging and 
looked at the “*rcirc debug*” buffer and confirmed that the 
strings there do not have the line breaks, including in the 
messages I send, even though they have line breaks when displayed 
back to me after sending. 
 
        2022-03-15T15:59:42 *** sbluhm QUIT Ping timeout: 181 
        seconds
        2022-03-15T16:06:09 *** NAMES @+chris @fell @gncbot @jralls +aj +bertbob +CDB-Man_ +chrko
             +eb +flips +g5pw +knielsen +kyew +mapreri +mauritslamers +miklcct
             +NoobAlice +oztunan +phebus +potatosal +raeburn +reactormonk[m]
             …

Presumably I can work around this by also setting fill-column locally to
some insanely high value, but I shouldn’t need to since rcirc-fill-flag
is documented as turning that functionality off.  (I just checked, it’s
nil in both channel and server buffers.)

Ken




In GNU Emacs 28.0.91 (build 1, x86_64-redhat-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d scroll bars)
 of 2022-01-11 built on 7efb8fbccc97436880211dbad44871a1
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Fedora Linux 35 (Workstation Edition)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=lucid
 --with-gpm=no --with-modules --with-harfbuzz --with-cairo --with-json
 --with-native-compilation build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2
 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  rcirc-track-minor-mode: t
  display-time-mode: t
  desktop-save-mode: t
  global-edit-server-edit-mode: t
  which-function-mode: t
  icomplete-mode: t
  shell-dirtrack-mode: t
  global-hi-lock-mode: t
  hi-lock-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/raeburn/.emacs.d/elpa/systemtap-mode-20151122.1940/systemtap-mode hides /usr/share/emacs/site-lisp/systemtap-mode
/home/raeburn/.emacs.d/elpa/p4-20150721.1937/p4 hides /usr/share/emacs/site-lisp/perforce/p4
/home/raeburn/.emacs.d/elpa/transient-20211101.2251/transient hides /usr/share/emacs/28.0.91/lisp/transient

Features:
(ind-util quail gnus-cite gnus-async gnus-bcklg gnus-ml with-editor
loadhist shortdoc help-fns radix-tree term/xterm xterm gnus-topic
nndraft nnmh nnfolder utf-7 gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg nntp gnus-cache make-mode align qp shadow emacsbug
tramp-cmds cl-print ielm mailalias smtpmail sendmail mail-extr cal-move
sort url-cache url-http url-gw url-auth cperl-mode grep vc-hg vc-bzr
ispell cus-edit pp cus-start misearch multi-isearch gnutls
network-stream nsm add-log reveal perl-mode face-remap dired-aux python
tramp-sh yaml-mode mule-util dockerfile-mode mhtml-mode css-mode color
js sgml-mode facemenu ruby-mode sh-script smie executable texinfo
texinfo-loaddefs bug-reference rst compile org-element avl-tree
generator ol-eww eww xdg url-queue thingatpt mm-url ol-rmail ol-mhe
ol-irc ol-info ol-gnus nnselect gnus-search eieio-opt speedbar ezimage
dframe ol-docview doc-view image-mode exif ol-bibtex ol-bbdb ol-w3m
ol-doi org-link-doi vc-git diff-mode vc-dispatcher cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
view jka-compr ob-shell comp comp-cstr warnings cl-extra help-mode rcirc
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr kinsoku
svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud
nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range
message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg
rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader gnus-win gnus nnheader gnus-util rmail
rmail-loaddefs rfc2047 rfc2045 ietf-drums text-property-search
mail-utils mm-util mail-prsvr wid-edit time desktop frameset cus-load
kr-init docker-tramp tramp-cache vagrant-tramp dash tramp tramp-loaddefs
trampver tramp-integration files-x tramp-compat parse-time ls-lisp
org-protocol org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete org-list org-faces
org-entities noutline outline org-version ob-emacs-lisp ob-core ob-eval
org-table oc-basic bibtex iso8601 time-date ol org-keys oc org-compat
org-macs org-loaddefs format-spec find-func cal-menu calendar
cal-loaddefs edit-server advice smart-quotes easy-mmode which-func imenu
icomplete server term disp-table shell pcomplete ehelp comint ansi-color
ring hi-lock finder-inf rx info package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
x-toolkit x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 13715676 653146)
 (symbols 48 49891 51)
 (strings 32 457765 52495)
 (string-bytes 1 12986322)
 (vectors 16 100405)
 (vector-slots 8 2906528 621136)
 (floats 8 580 768)
 (intervals 56 1053258 9997)
 (buffers 992 243))

bug#54406: 28.0.91; rcirc text wrapping

[Ken Raeburn]

Aha, debugging printfs to the rescue. :-)

I made a little tweak to rcirc-print, and added some logging advice to
rcirc-markup-fill and rcirc-fill-paragraph, then just sat back and
waited for some #emacs traffic; this is the one that triggered:

            (save-restriction
              (narrow-to-region (point) (point))
              (insert (propertize (rcirc-format-response-string process sender response
                                                              nil text)
                                'rcirc-msgid (rcirc-get-tag "msgid"))
		      (propertize "\n" 'hard t))

              ;; squeeze spaces out of text before rcirc-text
              ;; ADDED MESSAGE CALL:
	      (message "rcirc-print(process=%S sender=%S response=%S target=%S text=%S activity=%S)\n\tfilling region: buffer=%S region=%S flag=%S"
		       process sender response target text activity
		       (current-buffer)
		       (buffer-substring (point-min) (point-max))
		       rcirc-fill-flag)
              (fill-region (point-min) (point-max))

rcirc-print(process=#<process irc.libera.chat> sender=#("userxy" 0 6 (font-lock-face (rcirc-other-nick))) response="PRIVMSG" target="#emacs" text="a bunch of text here" activity=t)
	filling region: buffer=#<buffer #emacs@irc.libera.chat> region=#("<userxy> a bunch of text here
" 0 1 (rcirc-msgid nil) 1 7 (font-lock-face (rcirc-other-nick) rcirc-msgid nil) 7 9 (rcirc-msgid nil) 9 96 (rcirc-text "a bunch of text here" rcirc-msgid nil) 96 97 (hard t)) flag=nil

(For privacy, I’ve replaced the sender name with a same-length dummy,
and replaced the message text, though mine is shorter so the text
properties probably don’t work out.)

The old version in 27.1 did:

 	    ;; 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)))

where fill-start is set to

  (marker-position rcirc-prompt-start-marker)

evaluated before inserting the new text.  The new version seems to be
filling the entire narrowed region containing the just-inserted text.

As an experiment, I’m trying

              (fill-region (point-min)
			   (1- (or (next-single-property-change (point-min)
								'rcirc-text)
				   (point-max))))

and it seems to do what I want so far, both for NAMES messages and user
messages.

The property change is also looked up by the goto-char immediately
following the fill-region, so perhaps they could be reversed and the new
position used as a boundary.

Though, it seems to be filling the part of the rcirc-response-formats
formatted string that comes before the message text, and it’s not clear
to me that unconditionally filling that is the right thing, if
rcirc-fill-flag is nil. *shrug* I’m not a terribly experienced IRC user,
maybe it is generally desired.

Ken

P.S. The indentation of the “when” blocks following the goto-char could
use cleaning up.

bug#54406: 28.0.91; rcirc text wrapping

[Lars Ingebrigtsen]

Ken Raeburn <raeburn@redhat.com> writes:

> The old version in 27.1 did:
>
>  	    ;; 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)))
>
> where fill-start is set to
>
>   (marker-position rcirc-prompt-start-marker)
>
> evaluated before inserting the new text.  The new version seems to be
> filling the entire narrowed region containing the just-inserted text.

So I guess this was changed in:

commit 849e71fd83fa8796198035464897bf2f28f6226c
Author:     Philip Kaludercic <philipk@posteo.net>
AuthorDate: Wed Jun 9 17:55:55 2021 +0200

I've added Philip to the CCs; perhaps he has some comments.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#54406: 28.0.91; rcirc text wrapping

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ken Raeburn <raeburn@redhat.com> writes:
>
>> The old version in 27.1 did:
>>
>>  	    ;; 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)))
>>
>> where fill-start is set to
>>
>>   (marker-position rcirc-prompt-start-marker)
>>
>> evaluated before inserting the new text.  The new version seems to be
>> filling the entire narrowed region containing the just-inserted text.
>
> So I guess this was changed in:
>
> commit 849e71fd83fa8796198035464897bf2f28f6226c
> Author:     Philip Kaludercic <philipk@posteo.net>
> AuthorDate: Wed Jun 9 17:55:55 2021 +0200
>
> I've added Philip to the CCs; perhaps he has some comments.

It seems this was just a misunderstanding on what the "squeeze"-code
does.  The reason it had to be changed is so that messages with
time-stamps could be received out-of-order.  I am guessing (but would
have to look into it in more detail) that the intention could be
implemented more elegantly than by calling fill-region on a specific
region.

-- 
	Philip Kaludercic

bug#54406: 28.0.91; rcirc text wrapping

[Philip Kaludercic]

Philip Kaludercic <philipk@posteo.net> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Ken Raeburn <raeburn@redhat.com> writes:
>>
>>> The old version in 27.1 did:
>>>
>>>  	    ;; 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)))
>>>
>>> where fill-start is set to
>>>
>>>   (marker-position rcirc-prompt-start-marker)
>>>
>>> evaluated before inserting the new text.  The new version seems to be
>>> filling the entire narrowed region containing the just-inserted text.
>>
>> So I guess this was changed in:
>>
>> commit 849e71fd83fa8796198035464897bf2f28f6226c
>> Author:     Philip Kaludercic <philipk@posteo.net>
>> AuthorDate: Wed Jun 9 17:55:55 2021 +0200
>>
>> I've added Philip to the CCs; perhaps he has some comments.
>
> It seems this was just a misunderstanding on what the "squeeze"-code
> does.  The reason it had to be changed is so that messages with
> time-stamps could be received out-of-order.  I am guessing (but would
> have to look into it in more detail) that the intention could be
> implemented more elegantly than by calling fill-region on a specific
> region.

The call has been removed with b2283409fbe4324ee2fb50b385a9b6cc3458693c.
Should we close the report or does Ken want to try it out first to
confirm that everything works?

bug#54406: 28.0.91; rcirc text wrapping

[Philip Kaludercic]

Philip Kaludercic <philipk@posteo.net> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> Ken Raeburn <raeburn@redhat.com> writes:
>>>
>>>> The old version in 27.1 did:
>>>>
>>>>  	    ;; 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)))
>>>>
>>>> where fill-start is set to
>>>>
>>>>   (marker-position rcirc-prompt-start-marker)
>>>>
>>>> evaluated before inserting the new text.  The new version seems to be
>>>> filling the entire narrowed region containing the just-inserted text.
>>>
>>> So I guess this was changed in:
>>>
>>> commit 849e71fd83fa8796198035464897bf2f28f6226c
>>> Author:     Philip Kaludercic <philipk@posteo.net>
>>> AuthorDate: Wed Jun 9 17:55:55 2021 +0200
>>>
>>> I've added Philip to the CCs; perhaps he has some comments.
>>
>> It seems this was just a misunderstanding on what the "squeeze"-code
>> does.  The reason it had to be changed is so that messages with
>> time-stamps could be received out-of-order.  I am guessing (but would
>> have to look into it in more detail) that the intention could be
>> implemented more elegantly than by calling fill-region on a specific
>> region.
>
> The call has been removed with b2283409fbe4324ee2fb50b385a9b6cc3458693c.
> Should we close the report or does Ken want to try it out first to
> confirm that everything works?

Ping?

bug#54406: 28.0.91; rcirc text wrapping

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

>> The call has been removed with b2283409fbe4324ee2fb50b385a9b6cc3458693c.
>> Should we close the report or does Ken want to try it out first to
>> confirm that everything works?
>
> Ping?

No further updates within 4 months, so I'm closing this now.

If this is still an issue, please reopen.