This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 119659 - Allow to use SettingsNames.IDENTIFIER_ACCEPTOR for each language embedded in a document
Summary: Allow to use SettingsNames.IDENTIFIER_ACCEPTOR for each language embedded in ...
Status: NEW
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Milutin Kristofic
Keywords: API
Depends on:
Blocks: 89428 122933
  Show dependency tree
Reported: 2007-10-22 15:26 UTC by Marek Fukala
Modified: 2019-02-12 13:56 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Marek Fukala 2007-10-22 15:26:15 UTC
Currently the SettingsNames.IDENTIFIER_ACCEPTOR implementation is bound to the top level language mimetype of an editor.
It is not possible to use more acceptors for different languages in one document.

For example in JSP we would like to use different acceptors for JSP tags, java code, html code, expression language. 

The implementations of the acceptors should be collected by mimelookup based on the current language mimetype got by
lexer API for the clicked position.
Comment 1 Vitezslav Stejskal 2007-10-22 15:59:39 UTC
Yes, we will have to support this. As a workaround you could implement your own BaseKit.selectIdentifierAction, which
could do something smarter depending on where the caret is in a document.
Comment 2 Vitezslav Stejskal 2007-11-08 09:27:29 UTC
I'm just wandering if this could be lexer-based. Idea: instead of asking modules to supply Acceptor implementation the
BK.selectIA would simply drill down through the TokenHierarchy to the bottom level token and selected it. For the
purpose of BK.selectIA an identifier is pretty much the same as a token. Additionally, the action could limit the
selection by whitespace to make it work reasonably well in comments, javadoc, etc. Languages that need something special
could simply reimplement the action on their own.

Do you think this could work or am I missing something important?
Comment 3 Miloslav Metelka 2007-11-08 14:56:28 UTC
Yes, I was thinking about it too but I'm a bit skeptical since the tokens would likely need to publish some additional
information if we want to retain the current functionality. There are two acceptors: IDENTIFIER_ACCEPTOR and
WHITESPACE_ACCEPTOR (and the rest of all the other characters). So the Ctrl+Left/Right action jumps to boundaries of
chunks of characters of the three groups. With tokens we would either have to categorize the tokens in a similar way or
jump over token boundaries but then e.g. jumping beyond ';' with Ctrl+Right

    list.add(new Integer(5|));

would take 3 presses instead of the current single one.

Instead of single-char-acceptor I would rather pass something like

    wordBoundary(CharSequence text, int startOffset, boolean backwardSearch);

For embeddings the text could correspond to the nested language section. If not found we could return -1 instead of
0/text.length() (not sure whether we would like to always have a word boundary at an embedded section boundary).
Comment 4 Marek Fukala 2008-11-19 10:47:42 UTC
any plans here?
Comment 5 letrollpoilu 2019-02-12 13:56:45 UTC
Is it now possible to add identifiers to languages? I'm struggling a lot with SCSS, it's not selecting the text I want when double clicking, but it's working all good on CSS.