Re: [ace] How can I perform custom dynamic highlighting?

[Harutyun Amirjanyan]

have a look at https://github.com/ajaxorg/ace/blob/master/demo/kitchen-sink/token_tooltip.js
and https://github.com/ajaxorg/ace/blob/master/tool/mode_creator.html
for usage example
also if you need them to be colored differently without hovering you
will need to add custom syntax

[Harutyun Amirjanyan]

having a marker layer that accepts dom nodes might be handy,
but how will that help the mode to add tooltips?
currently modes only provide a tokenizer and can't add any markers
maybe we can add a onSetEdior, onRemoveEdior callbacks to the modes,
which could turn on and off additional functionality (like adding
tooltips or keyboard handlers e.g zen-coding)

[Louis-Dominique Dubeau]

Oops... I replied privately to Harutyun without realizing it. In case someone searches for a solution to their problem and stumbles upon this thread, let me summarize very briefly the exchanges that occurred privately:

• I pointed out that a mode can add markers by starting a worker, which passes back information to thread in which the Ace editor lives.
  
  
• I've mentioned a hackish method I use now to add tooltips. I create objects which use marker.js draw[...]Marker() functions and hack the html into submission, like this:    subhtml = subhtml.join("").replace(/<div /g, "<div title='ABCD' ").replace(/style='/g, "style='pointer-events:auto;"); (Of course, I'll want something other than "ABCD" for actual tooltip text.)
  
  
• I've also brought up the idea that creating an object from a class derived from Tokenizer rather than a stock Tokenizer object could give my mode the opportunity to add markers at tokenization time. Harutyun pointed out that Tokenizer.getLineTokens() is called unpredictably. By itself, the unpredictability of the calls does not matter to me but I still have to ditch my idea of deriving from Tokenizer because line number information is not passed to Tokenizer.getLineTokens(), and I absolutely need line number information to know which part of the document I'm processing.
  

[Harutyun Amirjanyan]

> ditch my idea of deriving from Tokenizer because line number information is
> not passed to Tokenizer.getLineTokens(), and I absolutely need line number
> information to know which part of the document I'm processing.

for things that need row number i'd suggest to look into deriving from
background_tokenizer since it manages token cache and there is one
background_tokenizer for each session.

[Louis-Dominique Dubeau]

On Thursday, February 21, 2013 12:35:47 PM UTC-5, Harutyun Amirjanyan wrote:

for things that need row number i'd suggest to look into deriving from
background_tokenizer since it manages token cache and there is one
background_tokenizer for each session.

I'll keep that in mind. I've got a prototype mode working like this:

• my_mode.js:
• Does what all modes do: creates a tokenizer with appropriate rules, etc.
  
• It also creates a worker which runs a worker in my_mode_worker.js
  
• my_mode_worker.js:
• Works in a way similar to the worker in mirror.js in that it keeps its own copy of the document and updates it on change events.
• Creates a new tokenizer instance of the same class, and same rules as used in my_mode.js.
• Runs the tokenizer on lines the local copy of the document.
• Performs analysis of the token sequence to find errors.
• Sends the errors back to an event listener in my_mode.js, which creates markers to show problems to the user. These markers are <div> elements with @title set to the text of the tooltip I want. This is not flexible at all in terms of look or tooltip behavior. Flexibility here would require the possibility to have markers' update method produce DOM objects rather than text HTML (as mentioned earlier in this thread).