Font-lock in a comint derived mode

Font-lock in a comint derived mode

[Björn Lindqvist]

Hi!

I wonder if there is some guidelines on how to make font-lock and a
comint interpreter work smoothly together? Or if there is any existing
3rd party mode in which those two features of Emacs are combined and
which I can look at? Why doesn't regular font-locking "just, work"?
Because I wan't to highlight strings, so if the inferior process
outputs {"hi":"there"} those two string literals should be in color.
But then, if you have the following conversation:

>>> print "stray\""
stray"
>>>

then font-lock thinks there is an unterminated string and everything
will be font-locked in the string face. Maybe there is a way to stop
font-lock from "running through" the interpreter prompts?


-- 
mvh/best regards Björn Lindqvist

Re: Font-lock in a comint derived mode

[Ian Zimmerman]

On 2015-08-06 11:48 +0200, Björn Lindqvist wrote:

> Why doesn't regular font-locking "just work"?

WDYM by "regular" font-locking?  font-lock depends on the major mode to
provide the syntactic patterns to highlight.  In your case, I'm guessing
that the major mode is Python mode, and that it is applied not only to
bona fide Python code but also to the inferior Python interaction
buffer.  That is a mistake, IMO.  (I don't know if that is done by the
Emacs module or by you.)  If highlighting is desired in the interaction
buffer, it should have its own more conservative rules, which can take
into account restrictions such a you suggested:

> then font-lock thinks there is an unterminated string and everything
> will be font-locked in the string face. Maybe there is a way to stop
> font-lock from "running through" the interpreter prompts?

-- 
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

Re: Font-lock in a comint derived mode

[Björn Lindqvist]

2015-08-06 17:03 GMT+02:00 Ian Zimmerman <itz@buug.org>:
> On 2015-08-06 11:48 +0200, Björn Lindqvist wrote:
>
>> Why doesn't regular font-locking "just work"?
>
> If highlighting is desired in the interaction
> buffer, it should have its own more conservative rules, which can take
> into account restrictions such a you suggested:

Correct. I tried to explain why regular font-locking doesn't "just
work" and you need a more conservative approach. But it's not easy to
come up with an approach that is conservative enough not to have
highlighting leaking due to unterminated strings and similar problems,
and radical enough to font-lock normal strings. It's hard and a lot of
work which is why I'm looking for prior art in this area. Almost
anyone who has written a comint-mode must have considered the same
problem I'm describing.


-- 
mvh/best regards Björn Lindqvist

Re: Font-lock in a comint derived mode

[Stefan Monnier]

> and radical enough to font-lock normal strings. It's hard and a lot of
> work which is why I'm looking for prior art in this area. Almost

IIUC python.el does just that.


        Stefan