Bugzilla – Full Text Bug Listing
| Summary: | ContentAssist#getPrefixStart should compute based on whitespace boundries | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Michael Rennie <Michael_Rennie> | ||||
| Component: | Editor | Assignee: | Michael Rennie <Michael_Rennie> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | mamacdon | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 7.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 442395 | ||||||
| Attachments: |
|
||||||
(In reply to Michael Rennie from comment #0) > This fixes the problem: > > /\S/i.test(model.getText(index - 1, index)) > > unless there is some special reason I am missing that the assist prefix > needs to be so restrictive... But...it introduces a problem with our JS content assist for 'this.'. Perhaps there just needs to be a way to have the client report at what prefix the insertion should start? Rather than again calling getPrefixStart. Yeah, it would be convenient if a content assist provider could just provide a regex that the engine should use to figure out the prefix instead of assuming [A-Za-z0-9_] all the time. Created attachment 246270 [details]
proposed fix
Perhaps a better idea would be to leave all the default stuff as-is and allow providers to tag their proposals with the prefix used. If the prefix exists on the proposal its used, otherwise the default (current computation) is used.
Slienio noticed I was not correctly resetting the default prefix in the patch, I pushed the updated fix to master: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=7203944d2468ca44c6a329bd60f2f710db26497d |
While trying to add content assist template support for JSDoc I kept finding that the prefixes and offsets were always wrong. For a snippet like: /** * @description Object of error types * @since 7.0 * @re^<- activate content assist here */ var ErrorTypes = { The prefix would be 're' which of course would insert a bad completion. Even after fixing (hack) the prefix, the linked mode for the template would be off by one - the '@' I had to 'fix'. The problem is in the regex in ContentAssist#getPrefixStart: while (index > 0 && /[A-Za-z0-9_]/.test(model.getText(index - 1, index))) { it should match anything not a whitespace char. This fixes the problem: /\S/i.test(model.getText(index - 1, index)) unless there is some special reason I am missing that the assist prefix needs to be so restrictive...