bug#22520: 25.0.50; unhighlight-regexp shows the scary guts of char-folding to the user

bug#22520: 25.0.50; unhighlight-regexp shows the scary guts of char-folding to the user

[Dima Kogan]

Hi. I'm running a very recent (1-week-old) build of emacs from

  https://github.com/emacs-mirror/emacs/commit/da976cf

I've been periodically seeing the issue described below, but just now
figured out how to trigger it. It's sorta not a bug, I guess, but it
REALLY looks alarming to an unsuspecting user


1. Create a file t.el containing a single line
(message "\nDatabase directory: ")

2. emacs -Q t.el

3. C-s m (to isearch for "m")

4. M-s h r enter (to highlight "m" with the default face)

5. M-s h u

Step 5 should offer to unhighlight "m", but it offers garbage-looking
text instead. Upon closer inspection, it looks like the crazy garbage is
actually the regexp that char-folding produces when you look for "m". I
don't think this is what the user should see. As one consequence of
this, trying to unhighlight simply "m" doesn't work, even though that's
what the user asked to highlight in the first place.

Another possible side effect of this is that highlighting

  Database directory:

doesn't work: hi-lock goes through the motions but nothing ends up being
highlighted. Turning off char-folding fixes that.

Thanks!

bug#22520: 25.0.50; unhighlight-regexp shows the scary guts of char-folding to the user

[Kaushal Modi]

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

I confirm this bug.

To recreate this, it is important to note that you do not exit isearch in
step 3.

> 3. C-s m (to isearch for "m")

From within isearch, do the below Step 4.

> 4. M-s h r enter (to highlight "m" with the default face)

And this is what I get: http://i.imgur.com/ZaLpzID.png

Here is my emacs build info:

Emacs version: GNU Emacs 25.0.90.1 (x86_64-unknown-linux-gnu, GTK+ Version
2.24.23)
 of 2016-01-31, built using commit 43cb9f8ff378100ec31cb576faf347a87a05ba5d.

./configure options:
  --prefix=/home/kmodi/usr_local/apps/6/emacs/emacs-25
'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include
-I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-ggdb3 -O0'
'CXXFLAGS=-ggdb3 -O0' 'LDFLAGS=-L/home/kmodi/usr_local/6/lib
-L/home/kmodi/usr_local/6/lib64 -ggdb3'

Features:
  XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11

[-- Attachment #2: Type: text/html, Size: 1289 bytes --]

bug#22520: 25.0.50; unhighlight-regexp shows the scary guts of char-folding to the user

[Juri Linkov]

> I confirm this bug.
>
> To recreate this, it is important to note that you do not exit isearch in
> step 3.

The effect is same as supplying this regexp directly:
M-s h r \(?:m[̣́̇]\|[mᵐḿṁṃⅿⓜｍ𝐦𝑚𝒎𝓂𝓶𝔪𝕞𝖒𝗆𝗺𝘮𝙢𝚖]\) RET RET

>> 3. C-s m (to isearch for "m")
>
> From within isearch, do the below Step 4.
>
>> 4. M-s h r enter (to highlight "m" with the default face)
>
> And this is what I get: http://i.imgur.com/ZaLpzID.png

To avoid displaying this frightening regexp, you can type ‘C-u M-s h u’.

PS: Sorry for not removing "C-x w" bindings so far - I had no courage to annoy
the users of the existing bindings when they discover them not working anymore.
At least, we could try to come up with a better justification for removal,
such as using "C-x w" for another feature.

bug#22520: 25.0.50; unhighlight-regexp shows the scary guts of char-folding to the user

[Juri Linkov]

> 1. Create a file t.el containing a single line
> (message "\nDatabase directory: ")
>
> 2. emacs -Q t.el
>
> 3. C-s m (to isearch for "m")
>
> 4. M-s h r enter (to highlight "m" with the default face)
>
> 5. M-s h u
>
> Step 5 should offer to unhighlight "m", but it offers garbage-looking
> text instead. Upon closer inspection, it looks like the crazy garbage is
> actually the regexp that char-folding produces when you look for "m". I
> don't think this is what the user should see. As one consequence of
> this, trying to unhighlight simply "m" doesn't work, even though that's
> what the user asked to highlight in the first place.

Unlike bug#21180, it's much harder to conceal the innards of hi-lock.
Its regexps will keep pouring in from all places.

> Another possible side effect of this is that highlighting
>
>   Database directory:
>
> doesn't work: hi-lock goes through the motions but nothing ends up being
> highlighted. Turning off char-folding fixes that.

Actually “Database directory:” is not highlighted due to case-folding.
After toggling case-folding with ‘M-s c’ and preserving the capital D,
it's highlighted correctly.

bug#22520: 25.0.50; unhighlight-regexp shows the scary guts of char-folding to the user

[Juri Linkov]

tags 22520 fixed
close 22520 28.0.50
thanks

Fortunately, both points are now implemented in bug#40337.

>> 1. Create a file t.el containing a single line
>> (message "\nDatabase directory: ")
>>
>> 2. emacs -Q t.el
>>
>> 3. C-s m (to isearch for "m")
>>
>> 4. M-s h r enter (to highlight "m" with the default face)
>>
>> 5. M-s h u
>>
>> Step 5 should offer to unhighlight "m", but it offers garbage-looking
>> text instead. Upon closer inspection, it looks like the crazy garbage is
>> actually the regexp that char-folding produces when you look for "m". I
>> don't think this is what the user should see. As one consequence of
>> this, trying to unhighlight simply "m" doesn't work, even though that's
>> what the user asked to highlight in the first place.
>
> Unlike bug#21180, it's much harder to conceal the innards of hi-lock.
> Its regexps will keep pouring in from all places.
>
>> Another possible side effect of this is that highlighting
>>
>>   Database directory:
>>
>> doesn't work: hi-lock goes through the motions but nothing ends up being
>> highlighted. Turning off char-folding fixes that.
>
> Actually “Database directory:” is not highlighted due to case-folding.
> After toggling case-folding with ‘M-s c’ and preserving the capital D,
> it's highlighted correctly.