* [mmaug@yahoo.com: font-lock applied to comint prompts]
@ 2006-11-22 13:17 Richard Stallman
0 siblings, 0 replies; 8+ messages in thread
From: Richard Stallman @ 2006-11-22 13:17 UTC (permalink / raw)
It's possible that this is something that fundamentally cannot be
fixed, but maybe not. Would someone please take a look, DTRT, and
then ack?
------- Start of forwarded message -------
To: emacs-pretest-bug@gnu.org
From: Michael Mauger <mmaug@yahoo.com>
Date: Mon, 20 Nov 2006 21:04:08 +0000 (UTC)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: font-lock applied to comint prompts
X-Spam-Status: No, score=2.2 required=5.0 tests=FORGED_YAHOO_RCVD
autolearn=no version=3.0.4
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
* emacs -Q
* M-x shell RET
(assuming sh-type command interpreter)
* in *shell* buffer:
$ PS1='x -y $ '
x -y $ ls -l >/dev/null
x -y $
Once the ls command is entered on the second line, the -y in the
prompt gets highlighted the same way that the -l in the ls command
gets highlighted.
doing `C-u C-x =' on the `y' in the prompt on the last line gives:
character: y (121, #o171, #x79, U+0079)
charset: ascii (ASCII (ISO646 IRV))
code point: #x79
syntax: w which means: word
category: a:ASCII l:Latin
buffer code: #x79
file code: #x79 (encoded by coding system iso-latin-1-unix)
display: by this font (glyph code)
-outline-Bitstream Vera Sans Mono-normal-i-normal-normal-11-82-96-96-c-*-
iso8859-1 (#x79)
There is an overlay here:
From 240 to 247
font-lock-face comint-highlight-prompt
There are text properties here:
face font-lock-comment-face
field output
fontified t
inhibit-line-move-field-capture t
rear-nonsticky t
Doing the same on the second, now fontified, prompt gives:
character: y (121, #o171, #x79, U+0079)
charset: ascii (ASCII (ISO646 IRV))
code point: #x79
syntax: w which means: word
category: a:ASCII l:Latin
buffer code: #x79
file code: #x79 (encoded by coding system iso-latin-1-unix)
display: by this font (glyph code)
-outline-Bitstream Vera Sans Mono-normal-r-normal-normal-11-82-96-96-c-*-
iso8859-1 (#x79)
There are text properties here:
face font-lock-comment-face
field output
font-lock-face comint-highlight-prompt
fontified t
inhibit-line-move-field-capture t
rear-nonsticky t
I've seen this in other comint-like buffers as well (*sql*). Is there
a way to protect/prevent the prompt string from being font-lock'd?
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/etc/DEBUG for instructions.
In GNU Emacs 22.0.90.1 (i386-mingw-nt5.1.2600)
of 2006-11-16 on ASSHOLE1
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.2) --cflags -
Ic:/devel/GnuWin32/include --ldflags -Lc:/devel/GnuWin32/lib -
Lc:/devel/GnuWin32/bin'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENU
locale-coding-system: cp1252
default-enable-multibyte-characters: t
Major mode: Shell
Minor modes in effect:
auto-insert-mode: t
server-mode: t
show-paren-mode: t
recentf-mode: t
global-hl-line-mode: t
hl-line-mode: t
cua-mode: t
shell-dirtrack-mode: t
encoded-kbd-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
s <backspace> <backspace> P S 1 = ' i f SPC $ ' <return>
M-p <left> SPC <end> <return> l s SPC <backspace> <backspace>
<backspace> c a t SPC < / d e v / n u l l <return>
i f SPC <backspace> <backspace> <backspace> M-p M-p
<left> <left> <left> <left> <left> <left> - <return>
M-p M-p <return> M-p M-p <left> <left> <left> <left>
<left> <left> <left> c a t SPC <return> M-p M-p <return>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <menu-bar> <help-menu> <report-emacs-bug>
Recent messages:
Char: Q (81, #o121, #x51) point=4941 of 4944 (100%) column=1
History item: 1 [2 times]
History item: 2
History item: 1
History item: 2
History item: 1
History item: 2
History item: 1
History item: 2
Loading emacsbug...done
_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------
^ permalink raw reply [flat|nested] 8+ messages in thread
* [mmaug@yahoo.com: font-lock applied to comint prompts]
@ 2006-11-30 3:21 Richard Stallman
2006-12-01 0:02 ` Michael Mauger
0 siblings, 1 reply; 8+ messages in thread
From: Richard Stallman @ 2006-11-30 3:21 UTC (permalink / raw)
[I sent this message a week ago but did not get a response.]
It's possible that this is something that fundamentally cannot be
fixed, but maybe not. Would someone please take a look, DTRT, and
then ack?
------- Start of forwarded message -------
To: emacs-pretest-bug@gnu.org
From: Michael Mauger <mmaug@yahoo.com>
Date: Mon, 20 Nov 2006 21:04:08 +0000 (UTC)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: font-lock applied to comint prompts
X-Spam-Status: No, score=2.2 required=5.0 tests=FORGED_YAHOO_RCVD
autolearn=no version=3.0.4
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
* emacs -Q
* M-x shell RET
(assuming sh-type command interpreter)
* in *shell* buffer:
$ PS1='x -y $ '
x -y $ ls -l >/dev/null
x -y $
Once the ls command is entered on the second line, the -y in the
prompt gets highlighted the same way that the -l in the ls command
gets highlighted.
doing `C-u C-x =' on the `y' in the prompt on the last line gives:
character: y (121, #o171, #x79, U+0079)
charset: ascii (ASCII (ISO646 IRV))
code point: #x79
syntax: w which means: word
category: a:ASCII l:Latin
buffer code: #x79
file code: #x79 (encoded by coding system iso-latin-1-unix)
display: by this font (glyph code)
-outline-Bitstream Vera Sans Mono-normal-i-normal-normal-11-82-96-96-c-*-
iso8859-1 (#x79)
There is an overlay here:
From 240 to 247
font-lock-face comint-highlight-prompt
There are text properties here:
face font-lock-comment-face
field output
fontified t
inhibit-line-move-field-capture t
rear-nonsticky t
Doing the same on the second, now fontified, prompt gives:
character: y (121, #o171, #x79, U+0079)
charset: ascii (ASCII (ISO646 IRV))
code point: #x79
syntax: w which means: word
category: a:ASCII l:Latin
buffer code: #x79
file code: #x79 (encoded by coding system iso-latin-1-unix)
display: by this font (glyph code)
-outline-Bitstream Vera Sans Mono-normal-r-normal-normal-11-82-96-96-c-*-
iso8859-1 (#x79)
There are text properties here:
face font-lock-comment-face
field output
font-lock-face comint-highlight-prompt
fontified t
inhibit-line-move-field-capture t
rear-nonsticky t
I've seen this in other comint-like buffers as well (*sql*). Is there
a way to protect/prevent the prompt string from being font-lock'd?
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/etc/DEBUG for instructions.
In GNU Emacs 22.0.90.1 (i386-mingw-nt5.1.2600)
of 2006-11-16 on ASSHOLE1
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.2) --cflags -
Ic:/devel/GnuWin32/include --ldflags -Lc:/devel/GnuWin32/lib -
Lc:/devel/GnuWin32/bin'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENU
locale-coding-system: cp1252
default-enable-multibyte-characters: t
Major mode: Shell
Minor modes in effect:
auto-insert-mode: t
server-mode: t
show-paren-mode: t
recentf-mode: t
global-hl-line-mode: t
hl-line-mode: t
cua-mode: t
shell-dirtrack-mode: t
encoded-kbd-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
s <backspace> <backspace> P S 1 = ' i f SPC $ ' <return>
M-p <left> SPC <end> <return> l s SPC <backspace> <backspace>
<backspace> c a t SPC < / d e v / n u l l <return>
i f SPC <backspace> <backspace> <backspace> M-p M-p
<left> <left> <left> <left> <left> <left> - <return>
M-p M-p <return> M-p M-p <left> <left> <left> <left>
<left> <left> <left> c a t SPC <return> M-p M-p <return>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <menu-bar> <help-menu> <report-emacs-bug>
Recent messages:
Char: Q (81, #o121, #x51) point=4941 of 4944 (100%) column=1
History item: 1 [2 times]
History item: 2
History item: 1
History item: 2
History item: 1
History item: 2
History item: 1
History item: 2
Loading emacsbug...done
_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [mmaug@yahoo.com: font-lock applied to comint prompts]
2006-11-30 3:21 [mmaug@yahoo.com: font-lock applied to comint prompts] Richard Stallman
@ 2006-12-01 0:02 ` Michael Mauger
2006-12-01 2:05 ` Miles Bader
2006-12-01 13:37 ` Richard Stallman
0 siblings, 2 replies; 8+ messages in thread
From: Michael Mauger @ 2006-12-01 0:02 UTC (permalink / raw)
Richard Stallman wrote:
>
> [I sent this message a week ago but did not get a response.]
>
> It's possible that this is something that fundamentally cannot be
> fixed, but maybe not. Would someone please take a look, DTRT, and
> then ack?
>
>
> ------- Start of forwarded message -------
> To: emacs-pretest-bug@gnu.org
> From: Michael Mauger <mmaug@yahoo.com>
> Date: Mon, 20 Nov 2006 21:04:08 +0000 (UTC)
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Subject: font-lock applied to comint prompts
> X-Spam-Status: No, score=2.2 required=5.0 tests=FORGED_YAHOO_RCVD
> autolearn=no version=3.0.4
>
> Please write in English if possible, because the Emacs maintainers
> usually do not have translators to read other languages for them.
>
> Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing
> list.
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
>
> * emacs -Q
> * M-x shell RET
> (assuming sh-type command interpreter)
> * in *shell* buffer:
>
> $ PS1='x -y $ '
> x -y $ ls -l >/dev/null
> x -y $
>
> Once the ls command is entered on the second line, the -y in the
> prompt gets highlighted the same way that the -l in the ls command
> gets highlighted.
>
> doing `C-u C-x =' on the `y' in the prompt on the last line gives:
> character: y (121, #o171, #x79, U+0079)
> charset: ascii (ASCII (ISO646 IRV))
> code point: #x79
> syntax: w which means: word
> category: a:ASCII l:Latin
> buffer code: #x79
> file code: #x79 (encoded by coding system iso-latin-1-unix)
> display: by this font (glyph code)
> -outline-Bitstream Vera Sans
> Mono-normal-i-normal-normal-11-82-96-96-c-*-
> iso8859-1 (#x79)
>
> There is an overlay here:
> From 240 to 247
> font-lock-face comint-highlight-prompt
>
>
> There are text properties here:
> face font-lock-comment-face
> field output
> fontified t
> inhibit-line-move-field-capture t
> rear-nonsticky t
>
> Doing the same on the second, now fontified, prompt gives:
> character: y (121, #o171, #x79, U+0079)
> charset: ascii (ASCII (ISO646 IRV))
> code point: #x79
> syntax: w which means: word
> category: a:ASCII l:Latin
> buffer code: #x79
> file code: #x79 (encoded by coding system iso-latin-1-unix)
> display: by this font (glyph code)
> -outline-Bitstream Vera Sans
> Mono-normal-r-normal-normal-11-82-96-96-c-*-
> iso8859-1 (#x79)
>
> There are text properties here:
> face font-lock-comment-face
> field output
> font-lock-face comint-highlight-prompt
> fontified t
> inhibit-line-move-field-capture t
> rear-nonsticky t
>
> I've seen this in other comint-like buffers as well (*sql*). Is there
> a way to protect/prevent the prompt string from being font-lock'd?
>
>
The following patch seems to fix the problem by adding the face property to
the overlay as well.
*** emacs/lisp/comint.el Thu Nov 30 01:14:03 2006
--- emacs/lisp/comint.el.new Thu Nov 30 18:34:47 2006
***************
*** 1787,1792 ****
--- 1787,1794 ----
(setq comint-last-prompt-overlay
(make-overlay prompt-start (point)))
(overlay-put comint-last-prompt-overlay
+ 'face 'comint-highlight-prompt)
+ (overlay-put comint-last-prompt-overlay
'font-lock-face 'comint-highlight-prompt))))
(goto-char saved-point)))))))
--
View this message in context: http://www.nabble.com/-mmaug%40yahoo.com%3A-font-lock-applied-to-comint-prompts--tf2729392.html#a7630872
Sent from the Emacs - Dev mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [mmaug@yahoo.com: font-lock applied to comint prompts]
2006-12-01 0:02 ` Michael Mauger
@ 2006-12-01 2:05 ` Miles Bader
2006-12-01 13:37 ` Richard Stallman
1 sibling, 0 replies; 8+ messages in thread
From: Miles Bader @ 2006-12-01 2:05 UTC (permalink / raw)
Cc: Emacs-devel
Michael Mauger <mmaug@yahoo.com> writes:
> The following patch seems to fix the problem by adding the face property to
> the overlay as well.
That's not correct though -- using `font-lock-face' instead of `face'
was intentional, to allow highlighting to be toggled using M-x font-lock.
I suppose the right solution is to make the font-lock expressions used
by comint avoid any region that's inside a prompt, but I don't know how
to do that.
-Miles
--
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.' [NYT]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [mmaug@yahoo.com: font-lock applied to comint prompts]
2006-12-01 0:02 ` Michael Mauger
2006-12-01 2:05 ` Miles Bader
@ 2006-12-01 13:37 ` Richard Stallman
2006-12-19 6:31 ` Michael Mauger
1 sibling, 1 reply; 8+ messages in thread
From: Richard Stallman @ 2006-12-01 13:37 UTC (permalink / raw)
Cc: Emacs-devel
There reason for the font-lock-face property is so that it won't
actually appear on the display unless Font-Lock mode is enabled.
In effect, it is a way to "manually" implement fotification
in a certain major mode. Your change would override this
and display the face even if Font-Lock mode is disabled.
That's not correct.
Since comint uses font-lock-face instead of specifying fontification
rules, it surprises me that the `face' property is placed on anything.
Maybe that comes from Shell mode, from shell-font-lock-keywords.
That seems like an inconsistency, somewhat. Maybe that is the cause
of the problem.
If you can put the `face' property on the overlay
only when the text it is over has a `face' property,
then I think it will be correct, because when Font-Lock is off
it won't do anything. Could you do it that way?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [mmaug@yahoo.com: font-lock applied to comint prompts]
2006-12-01 13:37 ` Richard Stallman
@ 2006-12-19 6:31 ` Michael Mauger
2006-12-20 13:01 ` Richard Stallman
2006-12-20 22:09 ` Stefan Monnier
0 siblings, 2 replies; 8+ messages in thread
From: Michael Mauger @ 2006-12-19 6:31 UTC (permalink / raw)
Cc: Emacs-devel
--- Richard Stallman <rms@gnu.org> wrote:
> If you can put the `face' property on the overlay
> only when the text it is over has a `face' property,
> then I think it will be correct, because when Font-Lock is off
> it won't do anything. Could you do it that way?
>
[Sorry for the delay -- I've been offline for a bit]
I tried this and it's no-go. The face due to font-lock isn't getting applied until after the
prompt is processed in the output filter. I'm far beyond my expertise here so I'll drop this.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [mmaug@yahoo.com: font-lock applied to comint prompts]
2006-12-19 6:31 ` Michael Mauger
@ 2006-12-20 13:01 ` Richard Stallman
2006-12-20 22:09 ` Stefan Monnier
1 sibling, 0 replies; 8+ messages in thread
From: Richard Stallman @ 2006-12-20 13:01 UTC (permalink / raw)
Cc: Emacs-devel
> If you can put the `face' property on the overlay
> only when the text it is over has a `face' property,
> then I think it will be correct, because when Font-Lock is off
> it won't do anything. Could you do it that way?
I tried this and it's no-go. The face due to font-lock isn't getting applied until after the
prompt is processed in the output filter.
I don't understand the description of the problem -- could you spell
it out more?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [mmaug@yahoo.com: font-lock applied to comint prompts]
2006-12-19 6:31 ` Michael Mauger
2006-12-20 13:01 ` Richard Stallman
@ 2006-12-20 22:09 ` Stefan Monnier
1 sibling, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2006-12-20 22:09 UTC (permalink / raw)
Cc: rms, Emacs-devel
>> If you can put the `face' property on the overlay
>> only when the text it is over has a `face' property,
>> then I think it will be correct, because when Font-Lock is off
>> it won't do anything. Could you do it that way?
> I tried this and it's no-go. The face due to font-lock isn't getting
> applied until after the prompt is processed in the output filter. I'm far
> beyond my expertise here so I'll drop this.
Why not do the opposite: check the presence of a font-lock-face char
property before returning a non-nil face in font-lock-keywords.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-12-20 22:09 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-30 3:21 [mmaug@yahoo.com: font-lock applied to comint prompts] Richard Stallman
2006-12-01 0:02 ` Michael Mauger
2006-12-01 2:05 ` Miles Bader
2006-12-01 13:37 ` Richard Stallman
2006-12-19 6:31 ` Michael Mauger
2006-12-20 13:01 ` Richard Stallman
2006-12-20 22:09 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2006-11-22 13:17 Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).