unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Font-lock in a comint derived mode
@ 2015-08-06  9:48 Björn Lindqvist
  2015-08-06 15:03 ` Ian Zimmerman
  0 siblings, 1 reply; 4+ messages in thread
From: Björn Lindqvist @ 2015-08-06  9:48 UTC (permalink / raw)
  To: help-gnu-emacs

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Font-lock in a comint derived mode
  2015-08-06  9:48 Font-lock in a comint derived mode Björn Lindqvist
@ 2015-08-06 15:03 ` Ian Zimmerman
  2015-08-07 14:43   ` Björn Lindqvist
  0 siblings, 1 reply; 4+ messages in thread
From: Ian Zimmerman @ 2015-08-06 15:03 UTC (permalink / raw)
  To: help-gnu-emacs

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.




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Font-lock in a comint derived mode
  2015-08-06 15:03 ` Ian Zimmerman
@ 2015-08-07 14:43   ` Björn Lindqvist
  2015-08-07 16:37     ` Stefan Monnier
  0 siblings, 1 reply; 4+ messages in thread
From: Björn Lindqvist @ 2015-08-07 14:43 UTC (permalink / raw)
  To: help-gnu-emacs

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Font-lock in a comint derived mode
  2015-08-07 14:43   ` Björn Lindqvist
@ 2015-08-07 16:37     ` Stefan Monnier
  0 siblings, 0 replies; 4+ messages in thread
From: Stefan Monnier @ 2015-08-07 16:37 UTC (permalink / raw)
  To: help-gnu-emacs

> 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




^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-08-07 16:37 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-06  9:48 Font-lock in a comint derived mode Björn Lindqvist
2015-08-06 15:03 ` Ian Zimmerman
2015-08-07 14:43   ` Björn Lindqvist
2015-08-07 16:37     ` Stefan Monnier

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).