@Jacob Carlborg: ===
For the autocompletion and language grammar. How about implementing and API that can be used by libraries like lib clang and similar.
What do you mean exactly? Offering an API so that Dialog2 can be used from other applications, too? Btw.: the anchored docs mockup you posted to the GitHub issue[1] looks awesome. Should definitely be the way to go.
Peter
On 2013-03-25 19:00, Peter Geil wrote:
What do you mean exactly? Offering an API so that Dialog2 can be used from other applications, too?
No, I mean that currently TextMate uses its own lexer and parser to do syntax highlight, autocompletion and similar features. For example, the autocompletion is very simple, it just cycles through all symbols in the current file matching what the user has already typed.
Instead we could create an API which allows TextMate to call external libraries, think libclang, to get autocompletion and the syntax highlight. This would allow for a accurate autocompletion based on the current symbol. This would be implemented as a plugin for TextMate using a common API making it possible to add this for any language.
Example:
struct FooBar { int bar char* foo; };
FooBar f; int i = f.|
"|" would be the position of the cursor. When performing autocompletion here TextMate would call libclang, via some API, to the get autocompletion. The result would not contain all symbols in the file, instead it would only contain symbols that would be legal according to the current language and context. In this case "bar" and "foo". Or possibly only "bar" since "i" is declared as "int".
Other features that could take advantage of this is:
* Go to definition * Outline "view" * Show generate documentation
On Mon, Mar 25, 2013 at 8:30 PM, Jacob Carlborg doob@me.com wrote:
Instead we could create an API which allows TextMate to call external
libraries, think libclang, to get autocompletion and the syntax highlight. This would allow for a accurate autocompletion based on the current symbol. This would be implemented as a plugin for TextMate using a common API making it possible to add this for any language.
While I guess internal changes would would be necessary to support a variety of parsers, I don't think increased autocompletion accuracy requires a new API, or am I mistaken? I think a bundle command could could just take the entire file contents plus the caret position as input for a script. Script could parse the source code by itself, then return some suggestions (using Dialog2).
Related: What bundles currently make use of Dialog2? I'd like to see it in action for myself.
-- Meryn
On 2013-03-26 00:39, Meryn Stol wrote:
While I guess internal changes would would be necessary to support a variety of parsers, I don't think increased autocompletion accuracy requires a new API, or am I mistaken? I think a bundle command could could just take the entire file contents plus the caret position as input for a script. Script could parse the source code by itself, then return some suggestions (using Dialog2).
I guess the script could invoke libclang or similar. But it doesn't sound like a good idea to have to invoke an external process each time you want autocompletion and certainly not for syntax highlighting. That would be really, REALLY slow. A lexer needs to be extremely fast.
Just for the record avian-missing uses a preference to intercept the completion:
https://github.com/elia/avian-missing.tmbundle/blob/master/Preferences/Compl...
Elia
On Mar 26, 2013, at 9:56 AM, Jacob Carlborg doob@me.com wrote:
On 2013-03-26 00:39, Meryn Stol wrote:
While I guess internal changes would would be necessary to support a variety of parsers, I don't think increased autocompletion accuracy requires a new API, or am I mistaken? I think a bundle command could could just take the entire file contents plus the caret position as input for a script. Script could parse the source code by itself, then return some suggestions (using Dialog2).
I guess the script could invoke libclang or similar. But it doesn't sound like a good idea to have to invoke an external process each time you want autocompletion and certainly not for syntax highlighting. That would be really, REALLY slow. A lexer needs to be extremely fast.
-- /Jacob Carlborg
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 2013-03-26 10:26, Elia Schito wrote:
Just for the record avian-missing uses a preference to intercept the completion:
https://github.com/elia/avian-missing.tmbundle/blob/master/Preferences/Compl...
Bundles will execute some kind of script. Which will create a new process. Autocompletion syntax highlighting and similar features need to be very, very fast. I don't want to wait a whole second for for an autocompletion list to show up.
Bundles will execute some kind of script. Which will create a new process. Autocompletion syntax highlighting and similar features need to be very, very fast. I don't want to wait a whole second for for an autocompletion list to show up.
I think delegating syntax highlighting up to simple bundle commands seems a bit far-fetched. I don't know if it's even possible to update text with new colors.
As for auto-completions: For me, getting php function suggestions (alt-esc) works absolutely instantly, while it uses a plain Ruby script. Do you notice any lag?
Given the instantaneous results I get, I don't think starting the ruby interpreter can be the source of slow-downs. Without knowing any more, I'd put the blame at first on a slow hard drive. I have an SSD.
On 2013-03-26 13:53, Meryn Stol wrote:
Bundles will execute some kind of script. Which will create a new process. Autocompletion syntax highlighting and similar features need to be very, very fast. I don't want to wait a whole second for for an autocompletion list to show up.I think delegating syntax highlighting up to simple bundle commands seems a bit far-fetched. I don't know if it's even possible to update text with new colors.
What's why I'm talking about plugins and not bundles. This would allow TextMate to basically call functions in libclang (and similar) directly.
As for auto-completions: For me, getting php function suggestions (alt-esc) works absolutely instantly, while it uses a plain Ruby script. Do you notice any lag?
No, but it will perform a very basic completion result. libclang does semantic analyzing to give a very correct completion result, based on the actual types.
Given the instantaneous results I get, I don't think starting the ruby interpreter can be the source of slow-downs. Without knowing any more, I'd put the blame at first on a slow hard drive. I have an SSD.
When lexing (used for syntax highlighting), every instructs count.
libclang does semantic analyzing to give a very correct completion result,
based on the actual types. If starting a process in general does not cause noticeable latency (as exemplified by the php suggestions), then how would any analysis of code be any faster if it happened within the TextMate process? The actual work that needs to be done would be the same, no?
It is somehow really expensive to initialize libclang inside a program? (I do not have any experience with it) One other way the whole process could be more efficient is by keeping the entire "parse tree" (or so) of the current source code in memory, and keep it up-to-date while editing (i.e. per keystroke, update the parse tree). Is that what you have in mind? Or what else?
Again, I think you're right that for syntax highlighting, things could better happen in-process.
-- View this message in context: http://textmate.1073791.n5.nabble.com/Help-funding-my-TextMate-2-code-sprint... Sent from the textmate users mailing list archive at Nabble.com.
On 2013-03-26 15:16, Meryn Stol wrote:
If starting a process in general does not cause noticeable latency (as exemplified by the php suggestions), then how would any analysis of code be any faster if it happened within the TextMate process? The actual work that needs to be done would be the same, no?
Perhaps it's not a problem.
It is somehow really expensive to initialize libclang inside a program? (I do not have any experience with it)
No.
One other way the whole process could be more efficient is by keeping the entire "parse tree" (or so) of the current source code in memory, and keep it up-to-date while editing (i.e. per keystroke, update the parse tree). Is that what you have in mind? Or what else?
That would probably be useful.
Again, I think you're right that for syntax highlighting, things could better happen in-process.
Right.
On 26 Mar 2013, at 0:39, Meryn Stol wrote:
Related: What bundles currently make use of Dialog2? I'd like to see it in action for myself.
The PHP and Objective-C bundles both use the popup menu of the Dialog plug-in.
Below is a comment I previously wrote related to pop-ups.
I should add that personally I would like to extend the snippet syntax to be more capable, which is what is used for the first two examples below.
Though for the big window with inline documentation, the dialog plug-in is likely more suitable.
----------8<----------
For a simple pop-up you can use snippet syntax a la: ${1|first,second,…,last|}. E.g. in Objective-C you can try prop⇥ between @interface…@end to see it in action.
A more dynamic version of this is the fixup⇥ tab trigger for the Git commit grammar, this generates the snippet so it has a list of the last 10 commit summaries (prefixed with `fixup!`).
A more flexible system is the TextMate::UI.complete API which has some inline documentation here https://github.com/textmate/bundle-support.tmbundle/blob/master/Support/shar...
An example of this can be tested by inserting [NSDictionary dic‸] in an Objective-C file and press ⌥⎋ (‸ indicates caret position).
-
Allan Odgaard -
Elia Schito -
Jacob Carlborg -
Meryn Stol -
Peter Geil