bug#19843: comint-mode obliterates previous faces with `comint-highlight-prompt'

bug#19843: comint-mode obliterates previous faces with `comint-highlight-prompt'

[Jeff Gran]

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

I believe this is easy to reproduce. I'm happy to help with additional 
info if needed.

In shell-mode, I have a PS1 that has ansi-color control codes in it. But 
it is obliterated by the `comint-highlight-prompt' face.

In previous versions of emacs, the comint-highlight-prompt was an 
overlay, however this commit:

https://github.com/emacs-mirror/emacs/commit/74c5d24c74e3167db6e3ee01831584c99905bb70

...changed it to just apply the face instead of overlaying it. It 
mentions Bug#14744, but I'm not sure what that is. I preferred having it 
overlay.

However, earlier than that there was a `defcustom' option that switched 
the comint-highlight-prompt on or off altogether, which is probably the 
best solution. Again, not sure why that was ever removed, except that 
maybe that author in 2002 decided that using an overlay that could be 
set to nil accomplishes the same goal, which is the option of having or 
not having a prompt highlight face applied.

See 
https://github.com/emacs-mirror/emacs/commit/8b1d2946a2f9e6779c405ee81f0162470d2eb79b

When I type "C-u C-x =" on the characters that should be colored in my 
prompt, I see that there is ansi-color-face property, but it is not 
visible because the face is applied on top of it:

There are text properties here:
   ansi-color-face      (foreground-color . "#3AaCbf")
   field                output
   font-lock-face       comint-highlight-prompt
   fontified            t
   front-sticky         (read-only)
   inhibit-line-move-field-capture t
   read-only            t
   rear-nonsticky       t


I think the best solution is probably to put the boolean custom options 
back in so that the user can specify whether they want the font-face 
applied or not.

-- 
Jeff Gran


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