bug#73524: 29.4; bug-reference-mode matches regexp case-insensitively

bug#73524: 29.4; bug-reference-mode matches regexp case-insensitively

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 4909 bytes --]

bug-reference-bug-regexp is matched case-insensitively, while both its
default value and the example regexp "\\([Bb]ug[#-]\\([0-9]+\\)\\)"
from the "Bug Reference" section of the manual indicate otherwise.

To reproduce, save attached file as bugref.txt, then:
$ emacs -Q bugref.txt

It will correctly highlight "bug-1234" and "Bug-5678" but also
"bUg-9012" which shouldn't be matched by the regexp.


In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.18.2) of 2024-09-27 built on localhost
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: Gentoo Linux

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --datarootdir=/usr/share
 --disable-silent-rules --docdir=/usr/share/doc/emacs-29.4
 --htmldir=/usr/share/doc/emacs-29.4/html --libdir=/usr/lib64
 --program-suffix=-emacs-29 --includedir=/usr/include/emacs-29
 --infodir=/usr/share/info/emacs-29 --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-file-notification=inotify --with-pdumper --enable-acl
 --with-dbus --with-modules --with-gameuser=:gamestat --with-libgmp
 --with-gpm --without-native-compilation --without-json
 --without-kerberos --without-kerberos5 --with-lcms2 --with-xml2
 --without-mailutils --without-selinux --without-sqlite3 --with-gnutls
 --without-libsystemd --with-threads --without-tree-sitter
 --without-wide-int --with-sound=alsa --with-zlib --with-x
 --without-pgtk --without-ns --without-gconf --with-gsettings
 --without-toolkit-scroll-bars --with-xpm --with-xft --with-cairo
 --with-harfbuzz --with-libotf --with-m17n-flt --with-x-toolkit=lucid
 --with-xaw3d --with-gif --with-jpeg --with-png --with-rsvg --with-tiff
 --without-webp --with-imagemagick --with-dumping=pdumper
 'CFLAGS=-march=native -ggdb -O2 -pipe -fno-fast-math -ffp-contract=off'
 CPPFLAGS= 'LDFLAGS=-Wl,-O1 -Wl,--as-needed
 -Wl,-z,pack-relative-relocs''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG LCMS2 LIBOTF LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF X11 XAW3D XDBE XIM XINPUT2
XPM LUCID ZLIB

Important settings:
  value of $LC_CTYPE: en_GB.UTF-8
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: POSIX
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  bug-reference-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils vc-hg
vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs log-view pcvs-util vc-git
diff-mode easy-mmode vc cl-loaddefs cl-lib vc-dispatcher bug-reference
byte-opt gv bytecomp byte-compile rmc iso-transl tooltip cconv 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 nadvice seq simple cl-generic
indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 54606 8541)
 (symbols 48 7145 0)
 (strings 32 21703 1671)
 (string-bytes 1 606203)
 (vectors 16 13609)
 (vector-slots 8 188733 15492)
 (floats 8 38 39)
 (intervals 56 355 0)
 (buffers 976 13))


[-- Attachment #2: bugref.txt --]
[-- Type: text/plain, Size: 203 bytes --]

bug-1234
Bug-5678
bUg-9012
foo-3456

Local Variables:
eval: (bug-reference-mode 1)
bug-reference-bug-regexp: "\\([Bb]ug[#-]\\([0-9]+\\)\\)"
bug-reference-url-format: "https://project.org/issues/%s"
End:

bug#73524: 29.4; bug-reference-mode matches regexp case-insensitively

[Eli Zaretskii]

> From: Ulrich Mueller <ulm@gentoo.org>
> Date: Sat, 28 Sep 2024 08:24:26 +0200
> 
> bug-reference-bug-regexp is matched case-insensitively, while both its
> default value and the example regexp "\\([Bb]ug[#-]\\([0-9]+\\)\\)"
> from the "Bug Reference" section of the manual indicate otherwise.
> 
> To reproduce, save attached file as bugref.txt, then:
> $ emacs -Q bugref.txt
> 
> It will correctly highlight "bug-1234" and "Bug-5678" but also
> "bUg-9012" which shouldn't be matched by the regexp.

I'm not sure I see the harm in that (e.g., what if someone made a
mistake while typing the commit log message? these are immutable with
Git once pushed), but I've added Tassilo to this discussion in case he
has an opinion.

bug#73524: 29.4; bug-reference-mode matches regexp case-insensitively

[Ulrich Mueller]

>>>>> On Sat, 28 Sep 2024, Eli Zaretskii wrote:

>> It will correctly highlight "bug-1234" and "Bug-5678" but also
>> "bUg-9012" which shouldn't be matched by the regexp.

> I'm not sure I see the harm in that (e.g., what if someone made a
> mistake while typing the commit log message? these are immutable with
> Git once pushed), but I've added Tassilo to this discussion in case he
> has an opinion.

IIUC behaviour depends on case-fold-search in the buffer. If that's
flipped, the string will no longer match. IMHO it's better to notice
such typos immediately, instead of being surprised by them later.

If case-independent matching is desired, the regexp can explicitly
allow it.

bug#73524: 29.4; bug-reference-mode matches regexp case-insensitively

[Tassilo Horn]

Ulrich Mueller <ulm@gentoo.org> writes:

Hi!

>>> It will correctly highlight "bug-1234" and "Bug-5678" but also
>>> "bUg-9012" which shouldn't be matched by the regexp.
>
>> I'm not sure I see the harm in that (e.g., what if someone made a
>> mistake while typing the commit log message? these are immutable with
>> Git once pushed), but I've added Tassilo to this discussion in case
>> he has an opinion.
>
> IIUC behaviour depends on case-fold-search in the buffer. If that's
> flipped, the string will no longer match. IMHO it's better to notice
> such typos immediately, instead of being surprised by them later.
>
> If case-independent matching is desired, the regexp can explicitly
> allow it.

Indeed, the matching depends on case-fold-search.  Its value is a
personal preference, so it's advisable to write the regexp such that it
doesn't depend on that setting if you do it publically, e.g., in a
.dir-locals.el.  Bug#123 and bug#123 are both likely while buG#123 is
not.  (That said, I think I don't follow that advice myself in the
auto-setup routines...)

In the wild, bug references are almost always case-insensitive because
URLs are.  So one could say that maybe there should be a
bug-reference-case-fold-search defcustom (defaulting to t) in order to
decouple it from case-fold-search.

WDYT?

Bye,
  Tassilo

bug#73524: 29.4; bug-reference-mode matches regexp case-insensitively

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  73524@debbugs.gnu.org
> Date: Sat, 28 Sep 2024 18:24:16 +0200
> 
> In the wild, bug references are almost always case-insensitive because
> URLs are.  So one could say that maybe there should be a
> bug-reference-case-fold-search defcustom (defaulting to t) in order to
> decouple it from case-fold-search.

If we want to always match case-insensitively in bug-reference, then
we could bind case-fold-search to t in bug-reference-fontify, no?

bug#73524: 29.4; bug-reference-mode matches regexp case-insensitively

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> In the wild, bug references are almost always case-insensitive
>> because URLs are.  So one could say that maybe there should be a
>> bug-reference-case-fold-search defcustom (defaulting to t) in order
>> to decouple it from case-fold-search.
>
> If we want to always match case-insensitively in bug-reference, then
> we could bind case-fold-search to t in bug-reference-fontify, no?

Sure, if we are convinced that there's really no scenario where bug
references are case-sensitive.  I would think this is very uncommon but
not impossible.

Bye,
  Tassilo

bug#73524: 29.4; bug-reference-mode matches regexp case-insensitively

[Ulrich Mueller]

>>>>> On Sat, 28 Sep 2024, Tassilo Horn wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>>> In the wild, bug references are almost always case-insensitive
>>> because URLs are.  So one could say that maybe there should be a
>>> bug-reference-case-fold-search defcustom (defaulting to t) in order
>>> to decouple it from case-fold-search.
>> 
>> If we want to always match case-insensitively in bug-reference, then
>> we could bind case-fold-search to t in bug-reference-fontify, no?

> Sure, if we are convinced that there's really no scenario where bug
> references are case-sensitive.  I would think this is very uncommon but
> not impossible.

What about the other examples in the default, i.e. "RFE" and "PR"?
I'm not completely convinced that matching their lower-case form would
be a good thing.

bug#73524: 29.4; bug-reference-mode matches regexp case-insensitively

[Eli Zaretskii]

> From: Ulrich Mueller <ulm@gentoo.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  73524@debbugs.gnu.org
> Date: Sat, 28 Sep 2024 19:25:19 +0200
> 
> >>>>> On Sat, 28 Sep 2024, Tassilo Horn wrote:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> If we want to always match case-insensitively in bug-reference, then
> >> we could bind case-fold-search to t in bug-reference-fontify, no?
> 
> > Sure, if we are convinced that there's really no scenario where bug
> > references are case-sensitive.  I would think this is very uncommon but
> > not impossible.
> 
> What about the other examples in the default, i.e. "RFE" and "PR"?
> I'm not completely convinced that matching their lower-case form would
> be a good thing.

I see in binutils-gdb repository most "PR" are in upper-case, but
all.  Example:

  commit ecb915b4de7569027ad78bd3e24873bb92cb8e32
  Author:     Nelson Chu <nelson@rivosinc.com>
  AuthorDate: Mon Sep 12 09:26:52 2022 +0800
  Commit:     Nelson Chu <nelson@rivosinc.com>
  CommitDate: Mon Sep 12 11:31:41 2022 +0800

      RISC-V: PR28509, the default visibility symbol cannot be referenced by R_RIS

      When generating the shared object, the default visibility symbols may bind
      externally, which means they will be exported to the dynamic symbol table,
      and are preemptible by default.  These symbols cannot be referenced by the
      non-pic R_RISCV_JAL and R_RISCV_RVC_JUMP.  However, consider that linker
      may relax the R_RISCV_CALL relocations to R_RISCV_JAL or R_RISCV_RVC_JUMP,
      if these relocations are relocated to the plt entries, then we won't report
      error for them.  Perhaps we also need the similar checks for the
      R_RISCV_BRANCH and R_RISCV_RVC_BRANCH relocations.

      After applying this patch, and revert the following glibc patch,
      riscv: Fix incorrect jal with HIDDEN_JUMPTARGET
      https://sourceware.org/git/?p=glibc.git;a=commit;h=68389203832ab39dd0dbaabbc

      I get the expected errors as follows,
      ld: relocation R_RISCV_RVC_JUMP against `__sigsetjmp' which may bind externa    ld: relocation R_RISCV_JAL against `exit' which may bind externally can not

      Besides, we also have similar changes for libgcc,
      RISC-V: jal cannot refer to a default visibility symbol for shared object
      https://github.com/gcc-mirror/gcc/commit/45116f342057b7facecd3d05c2091ce3a77

      bfd/
	      pr 28509
	      * elfnn-riscv.c (riscv_elf_relocate_section): Report errors when
	      makeing a shard object, and the referenced symbols of R_RISCV_JAL
	      relocations are default visibility.  Besides, we should handle most
	      of the cases here, so don't need the unresolvable check later for
	      R_RISCV_JAL and R_RISCV_RVC_JUMP.
      ld/
	      pr 28509
	      * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
	      * testsuite/ld-riscv-elf/lib-nopic-01a.s: Removed.
	      * testsuite/ld-riscv-elf/lib-nopic-01b.d: Likewise.
	      * testsuite/ld-riscv-elf/lib-nopic-01b.s: Likewise.
	      * testsuite/ld-riscv-elf/shared-lib-nopic-01.d: New testcase.
	      * testsuite/ld-riscv-elf/shared-lib-nopic-01.s: Likewise.
	      * testsuite/ld-riscv-elf/shared-lib-nopic-02.d: Likewise.
	      * testsuite/ld-riscv-elf/shared-lib-nopic-02.s: Likewise.
	      * testsuite/ld-riscv-elf/shared-lib-nopic-03.d: Likewise.
	      * testsuite/ld-riscv-elf/shared-lib-nopic-03.s: Likewise.
	      * testsuite/ld-riscv-elf/shared-lib-nopic-04.d: Likewise.
	      * testsuite/ld-riscv-elf/shared-lib-nopic-04.s: Likewise.

Not sure about RFE (where is that used?)

bug#73524: 29.4; bug-reference-mode matches regexp case-insensitively

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> If we want to always match case-insensitively in bug-reference,
>> >> then we could bind case-fold-search to t in bug-reference-fontify,
>> >> no?
>> 
>> > Sure, if we are convinced that there's really no scenario where bug
>> > references are case-sensitive.  I would think this is very uncommon
>> > but not impossible.
>> 
>> What about the other examples in the default, i.e. "RFE" and "PR"?
>> I'm not completely convinced that matching their lower-case form
>> would be a good thing.
>
> I see in binutils-gdb repository most "PR" are in upper-case, but
> all.
> [...]
> Not sure about RFE (where is that used?)

Request for enhancement?

Anyway, I also think that bug#123 is probably better matched
case-insensitively while RFC 2616 or CVE-2024-5742 are commonly
all-caps.  But in the end it's a user's choice if she prefers to have a
false positive or a false negative when something is or just looks like
a bug reference.  I'd rather have a false positive but that's just me.

So I'd vote for a defcustom bug-reference-case-fold-search defaulting to
t that users can set according to their preference or conventions.

And I wouldn't read too much into the default value of
bug-reference-bug-regexp.  It's just a value that works for us (Emacs or
other GNU projects using debbugs).

Bye,
  Tassilo