all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.