GNU bug report logs - #50005
28.0.50; silence a couple byte-compiler warnings in ERC

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50005 in the body.
You can then email your comments to 50005 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; silence a couple byte-compiler warnings in ERC
Date: Wed, 11 Aug 2021 06:57:26 -0700

[Message part 1 (text/plain, inline)]

Tags: patch

Hi, the commit log for this bug mentions two warnings. The one
concerning regexp-opt.el doesn't actually show up in make output
currently, but it's emitted under fairly mundane circumstances.
Moreover, the actual offending function, `erc-lurker-maybe-trim',
doesn't really behave as advertised, so I've tried tackling that here
as well.

As for `erc-with-all-buffers-of-server': out of deference to existing
code, I've left the "eval only once" stuff in play, even though a quick
survey of use cases at various call sites shows it's not really needed.
I also didn't bother with other possible tweaks, like (for example)
using `macroexp-copyable-p' for the `macroexp-let2' test param, which
would omit the superfluous let-binding of symbol expressions (variables)
in expanded code.

I guess I figured if we're going that far, we might as well replace the
call to `erc-buffer-filter' with a `dolist' or similar or even redo the
filter itself (and friends) completely. But if you buy into any of the
nonsense I've been spewing in other bugs [1], then you'll agree all of
that can wait because ERC has more pressing concerns. Thanks.

P.S. I also snuck in a tweak to an existing ERC test so it'll play nicer
with others; hope that's okay.


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48598
    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49860


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-08-09 built on localhost
Repository revision: aeec97fae0ccfcc4dc406a5e0e4c0a94b834cac4
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Fedora 34 (Workstation Edition)

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 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:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-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:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type 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 elisp-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 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 lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 51538 6355)
 (symbols 48 6607 1)
 (strings 32 18255 1368)
 (string-bytes 1 616656)
 (vectors 16 14292)
 (vector-slots 8 185252 10153)
 (floats 8 21 47)
 (intervals 56 205 0)
 (buffers 992 10))

[0001-Fix-mistake-in-test-for-erc-ring-previous-command.patch (text/x-patch, attachment)]

[0002-Fix-a-couple-byte-compiler-warnings-in-erc.el.patch (text/x-patch, attachment)]

Message #8 received at 50005 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 50005 <at> debbugs.gnu.org
Subject: bug#50005: 28.0.50; silence a couple byte-compiler warnings in ERC
Date: Thu, 12 Aug 2021 10:15:45 +0200

>  (defcustom erc-lurker-ignore-chars "`_"
>    "Characters at the end of a nick to strip for activity tracking purposes.
> -
> +The usual rules regarding ]^\\ and - in \"character alternatives\ apply.

Oops (two typos), but thanks for illustrating the problems with:

> +      (string-trim-right nick (concat "[" erc-lurker-ignore-chars "]+"))

Attempting to construct character alternatives by hand is usually a mistake; it's just too error-prone. Better use rx or regexp-opt instead:

 (rx-to-string `(+ (in ,@(string-to-list erc-lurker-ignore-chars))) t)

or

 (concat (regexp-opt (mapcar #'char-to-string erc-lurker-ignore-chars)) "+")

Message #11 received at 50005 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Amin Bandali <bandali <at> gnu.org>, 50005 <at> debbugs.gnu.org
Subject: Re: bug#50005: 28.0.50; silence a couple byte-compiler warnings in ERC
Date: Thu, 12 Aug 2021 03:56:45 -0700

[Message part 1 (text/plain, inline)]

Mattias Engdegård <mattiase <at> acm.org> writes:

> Oops (two typos), but thanks for illustrating the problems with:

Thanks, I spotted the weird double-quote mismatch thing earlier, but I
guess I'm still missing something else? Sorry, I'm quite blind/dumb, as
I'm sure you've gathered.

Anyway, I suppose, if we're using `rx-to-string' or `regexp-opt', then
that entire line can just be 86ed.

>  (rx-to-string `(+ (in ,@(string-to-list erc-lurker-ignore-chars))) t)
>
> or
>
>  (concat (regexp-opt (mapcar #'char-to-string erc-lurker-ignore-chars)) "+")

So, I take this to mean there's no problem with requiring (autoloading)
rx.el (or regexp-opt.el), right? I mean, I'd really like to use rx forms
elsewhere in ERC. So if nobody has a problem with it, let's do it! (Cc.
bandali.)

And I guess the `string-to-list' is necessary because

  (rx-to-string '(+ (in "abc")) t)
   ⇒ "[a-c]+"

is still interpreted as a set of character alternatives, whereas

  (rx-to-string '(+ (in ?a ?- ?c)) t)
   ⇒ "[ac-]+"

combines individual character args into just such a set. Thanks for
pointing that out. I'm sure I would have missed that.

Do you use ERC, Mattias? If so, are you available to review more
patches? I'm obviously quite ignorant in the ways of Emacs but am
pushing hard to improve ERC. Some might say that's a recipe for
embarrassment/disaster (though I'm pretty sure I already crossed that
first bridge ages ago).

So what do you say, can you help? I of course would welcome the
experience and obviously don't mind sharing (or even surrendering
complete) credit for anything. (Guess you'd have to weight any potential
cap feathers/plaudits against the indelible smirch of being associated
with the likes of me.) But let me know either way! Thanks.

[0001-Fix-mistake-in-test-for-erc-ring-previous-command.patch (text/x-patch, attachment)]

[0002-Fix-a-couple-byte-compiler-warnings-in-erc.el.patch (text/x-patch, attachment)]

Message #14 received at 50005 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: "J.P." <jp <at> neverwas.me>
Cc: Amin Bandali <bandali <at> gnu.org>, 50005 <at> debbugs.gnu.org
Subject: Re: bug#50005: 28.0.50; silence a couple byte-compiler warnings in ERC
Date: Thu, 12 Aug 2021 13:52:16 +0200

12 aug. 2021 kl. 12.56 skrev J.P. <jp <at> neverwas.me>:

> Thanks, I spotted the weird double-quote mismatch thing earlier, but I
> guess I'm still missing something else?

The string made it look like backslash were a special character inside [...]. It isn't; only ^, ] and - are special, each with their own quirky rules. (Other regexp systems have different rules.)

> So, I take this to mean there's no problem with requiring (autoloading)
> rx.el (or regexp-opt.el), right?

Correct. Your original problem was the use of `regexp-opt-charset` which is not autoloaded (and somewhat of an internal function to regexp-opt.el, but that's debatable). Using plain `regexp-opt` is fine.
Most ordinary uses of rx will not even require rx.el to be loaded at runtime since the macros are expanded during compilation, but `rx-to-string` is a plain function, autoloaded.

> And I guess the `string-to-list' is necessary because
> 
>  (rx-to-string '(+ (in "abc")) t)
>   ⇒ "[a-c]+"
> 
> is still interpreted as a set of character alternatives, whereas
> 
>  (rx-to-string '(+ (in ?a ?- ?c)) t)
>   ⇒ "[ac-]+"
> 
> combines individual character args into just such a set.

If you meant (in "a-c") in your first example then yes, quite right -- the hyphen is special inside strings of the rx `in` construct, but it's not special as a character argument. No other characters are special.

> Do you use ERC, Mattias? If so, are you available to review more
> patches?

I'm afraid I rarely use it and know nothing about its innards so I'm probably not the right person to ask -- only came by to help out with some regexpy things. I have nothing clever to say about your other changes, sorry!

> I'm obviously quite ignorant in the ways of Emacs but am
> pushing hard to improve ERC. Some might say that's a recipe for
> embarrassment/disaster (though I'm pretty sure I already crossed that
> first bridge ages ago).

I'd say it's a good sign! Just dive in.

> So what do you say, can you help?

Wish I could but time probably doesn't permit, sorry. There are much more experienced hands about. Of course I'll be happy to answer specifics about parts that I happen to know something about.

Message #17 received at 50005 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Amin Bandali <bandali <at> gnu.org>, 50005 <at> debbugs.gnu.org
Subject: Re: bug#50005: 28.0.50; silence a couple byte-compiler warnings in ERC
Date: Thu, 12 Aug 2021 06:35:31 -0700

Mattias Engdegård <mattiase <at> acm.org> writes:

> The string made it look like backslash were a special character inside
> [...]. It isn't;

Thanks, and sorry you had to explain that. Sad as it is, I'm fairly
certain I even read as much in the Info manual only moments before
defiling that doc string:

  You cannot use ‘\’ to escape these three characters, since ‘\’ is not
  special here.

> Most ordinary uses of rx will not even require rx.el to be loaded at
> runtime since the macros are expanded during compilation

Again, thanks. Although I should know this instinctively by now, I too
often forget it when deep in the weeds.

> If you meant (in "a-c") in your first example then yes, quite right

Um, yeah, sure, let's go with that! ;)

> Wish I could but time probably doesn't permit, sorry.

Darn, well I definitely appreciate your insights on this one and the
effort made relating them (frustrating as that might have been).

> Of course I'll be happy to answer specifics about parts that I happen
> to know something about.

You may live to regret those words. (Thanks again.)

Message #20 received at 50005 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 50005 <at> debbugs.gnu.org
Subject: Re: bug#50005: 28.0.50; silence a couple byte-compiler warnings in ERC
Date: Sun, 12 Sep 2021 05:03:40 -0700

[Message part 1 (text/plain, inline)]

v3. Added a missing test dependency.

(Note: the first attachment just shows the changes from the last set and
is not itself a patch.)

[0000-v2-v3.diff (text/x-patch, attachment)]

[0001-Fix-mistake-in-test-for-erc-ring-previous-command.patch (text/x-patch, attachment)]

[0002-Fix-a-couple-byte-compiler-warnings-in-erc.el.patch (text/x-patch, attachment)]

Message #23 received at 50005 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 50005 <at> debbugs.gnu.org
Subject: Re: bug#50005: 28.0.50; silence a couple byte-compiler warnings in ERC
Date: Thu, 16 Sep 2021 15:25:41 +0200

"J.P." <jp <at> neverwas.me> writes:

> v3. Added a missing test dependency.

Thanks; applied to Emacs 28.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.