First, Jan great work on Espresso. It is poised to be the best text editor on mac, since it is so extensible.
I have been working on an Erlang sugar, which I will drop at some point in github, but I would like to get it to a fairly complete state first.
My problems are several: first I cannot seem to get CodeSense features to work, partially because the Code Sense in Espresso works like a black box: i cannot see what I am doing wrong. Partially it is my fault since I am not a CSS guru.
Second: it seems that the PlaceholderThemes are completely ignored. I know this because I can define a @body { } element and it gets ignored. This is annoying since I do not want the syntax class definitions in the Erlang bundle to conform to the HTML/XML/CSS naming conventions defined someplace else.
Third, and most important: there are no provisions for dynamic project-centric indexing. Now, I know that Espresso is an “web” editor, which means (X)?HTML/XML/CSS but still you see people coding Ruby sugars and other goodies. It will be nice to be able to index a project and be able to provide code sense for that…. which , using the current implementation, turns out to be kind of simple. All you need, I think, is to look in a “hidden” project directory which contains a CodeSenseLibrary and a CodeSenseProviders directories, which in turn have the necessary files. The only other thing then that you need is a piece of plug-in cocoa that can kick off a process/thread to build these files.
For CodeSense, Espresso currently only offers static completion repositories. As you’ve discovered, this is a more significant problem for programming languages than it is for “fixed-feature” formats like HTML and CSS. As such, you can only complete a standard set of things like functions. We plan to address the dynamic case in the future, but the completion targeting will remain the same (selector based). To test your selectors, the Syntax Inspector (Text > Show Syntax Inspector) is invaluable. You can also find a selector reference on the Wiki. Feel free to post improvement requests for the selector documentation in the suggestions thread!
Syntax definitions conventions: you’re not obligated to follow the conventions exactly, you should create a structure that makes most sense for your particular language (Erlang in this case). Placeholder themes allow you to target those specific rules (if you have some way to uniquely identify zones produced by your syntax; adding a .erlang fragment to your zones is an easy way to accomplish that.)
Placeholder themes: @body is ignored for all placeholder themes, it is reserved for the user syntax themes. Placeholder themes should only define rules for specific syntax zones a sugar offers. To test out a syntax theme, it’s easier to first start by adding to a user theme, then moving the sugar-specific rules into a placeholder theme.
Ok, then how about a feature to allow reloading of sugars with a Cocoa API hook for that? Seems like a small enhancement.
Then upon user request a file can be indexed, and a CodeSenseLibrary can be generated (and installed in the correct Library/Application Support/Espresso/Sugars/[DIR]) location, and the above mentioned API call can be called to refresh the sugar (and thus code completion library) ?
I’m looking forward to this as well, I had assumed I was going to have to do some horrible Cocoa hackery to make this work.
I dont lie the suggestion above for implementation - as with everything else I suggest around here, I’d really like to see something low-level, more based on the Syntaxes than anything.
Specifically, we already have these things selected for our syntaxes and itemizers. Why not hook into that? For instance, I already have Ruby’s function definions fully exposed to Espresso through the extensive Syntaxes and Itemizes I’ve written. Why not allow me to say that all zones matching ‘sourcecode.ruby function.definition name’ be automatically be loaded into an internal psueso-CodeSense thingie, such that all such function names would be tab-completable? Same could be done for variables, etc…
Dynamic code sense is a must for me. Once you’ve used it, you can’t go back to typing everything. I’m really excited about Espresso and would love to start using it now, but without dynamic code sense I can’t :(
Would it be possible to for a cocoa sugar to do code sense indexing *before* code sense is actually loaded? (on launch)
Something like this:
0. Espresso is launched
1. Espresso loads Cocoa sugar bundle + classes (but not code sense yet)
2. Espresso sends a message to a class in the cocoa sugar, to request that it makes any changes to code sense *now*
3. Cocoa sugar indexes and updates code sense (if needed)
4. Code sense is loaded
This way nothing has to be reloaded. Obviously it’s not ideal but I don’t think it would be that difficult to implement - as a stopgap at least.
Specifically, we already have these things selected for our syntaxes and itemizers. Why not hook into that? For instance, I already have Ruby’s function definions fully exposed to Espresso through the extensive Syntaxes and Itemizes I’ve written. Why not allow me to say that all zones matching ‘sourcecode.ruby function.definition name’ be automatically be loaded into an internal psueso-CodeSense thingie, such that all such function names would be tab-completable? Same could be done for variables, etc…
Specifically, we already have these things selected for our syntaxes and itemizers. Why not hook into that? For instance, I already have Ruby’s function definions fully exposed to Espresso through the extensive Syntaxes and Itemizes I’ve written. Why not allow me to say that all zones matching ‘sourcecode.ruby function.definition name’ be automatically be loaded into an internal psueso-CodeSense thingie, such that all such function names would be tab-completable? Same could be done for variables, etc…
This sounds like a fantastic solution to me.
This is still a ‘fantastic’ performance hit, though. The lag when you first open a file (which you may not have experience, if you haven’t tried a big file or a complicated Sugar)? Yeah. It’d have to do that - times the number of files in your project. In other words, Espresso would have to load, parse, and store every file of a given type (for instance, every Ruby file as defined by Ruby.sugar’s Languages.xml) that exists in your project.
Now, if it were to happen at all, I would like to see it happen as described above - it’d be fast, and we’d be able to use frameworks that already exist. But for performance reasons, I’d almost like to see it not happen at all - or at least, be optional, to be enabled by the Sugar developer.
I didn’t realize people were requesting that all files in their project be indexed for autocompletion. That’s mildly ridiculous. I was thinking the syntax-based completion additions would be based off the open file. Obviously, having included files indexed as well would be ideal, but if the performance problems were prohibitive it isn’t something I’d personally miss too much.
Another possibility would be maintaining an index of possible autocompletions for a project in the project file or something, and only updating that as the files were updated, but that would have it’s own issues (particularly with staying up to date if someone else edited a file or you edited a file in a different program).
I didn’t realize people were requesting that all files in their project be indexed for autocompletion. That’s mildly ridiculous. I was thinking the syntax-based completion additions would be based off the open file. Obviously, having included files indexed as well would be ideal, but if the performance problems were prohibitive it isn’t something I’d personally miss too much.
Yeah, it’s really between two things, from a user’s point of view: partial autocompletion, that has a hit-and-miss chance of actually auto-completing what you’re typing (specifically tied to what file it was defined/whatever in), or full autocompletion, that brings in the language’s features (via Language.sugar), library’s features (via Library.sugar that extends Language.sugar), your project’s features (via full dynamic indexing of the project, or at least files included into the current file), and your current file’s features (via full dynamic indexing of the current file).
The first would be for-sure confusing from a user’s point of view, the second would be possibly-in-certain-circumstances slow from a user’s point of view. The real decision to be made, if some sort of indexing features are implemented, is whether your user be annoyed or confused. Unless you can think of a better way that makes them neither d-:
George the Flea - 01 January 2009 07:24 PM
Another possibility would be maintaining an index of possible autocompletions for a project in the project file or something, and only updating that as the files were updated, but that would have it’s own issues (particularly with staying up to date if someone else edited a file or you edited a file in a different program).
Yeah, the specific details of implementation vary, there are quite a few possible ways to do ‘full dynamic indexing’ - none of them are really ideal. Incremental indexing with semi-permanent storage would be inconsistent at best and useless at worst; pre-indexing of the entire project with real-time indexing of the current file would be slow to boot and slow to interact with; pre-indexing of the entire project with pre-indexing of the current file and incremental, periodic re-indexing of the current file would be initially slow, slow to interact with, and often inaccurate when adding/modifying/removing things and then immediately working with them.
Unless there’s a better way I’m not thinking of, full-project indexing doesn’t seem ideal. Out of all of the options, if you were to implement it, I think I’d personally prefer (as a user) full-project pre-indexing, persistent storage in the projectfile (which could be versioned, but ugh), and incremental periodic updating of the index.
Seeing as I’m not a big autocompletion user, I doubt I’d really be bothered by a lack of project indexing, though dynamic indexing of the current file would be nice.
This is just me musing out of complete ignorance, but I wonder if the Spotlight index would be at all useful for autocompletion. Spotlight indexes full text for just about everything, and although it wouldn’t allow Espresso to be smart about context and what specifically the user is autocompleting, it might be one way to grab indexed keywords out of a small portion of the file system.
Or this might just be me displaying my ignorance of the Spotlight methods.
As you guys have discovered, the performance issue is the biggie here. The current CodeSense system works very well for library type completion, which is quite useful in a range of situations but becomes somewhat useless when you start using “real” programming languages. Current file indexing is not enough 99% of the time, so the only alternative is full project indexing. Let’s just say that there are a lot of other things to be done first
Oh, and Ian: unfortunately Spotlight is not really useful in any way.
Hi, I’m currently using Zend Studio as my development environment.
But once I saw espresso, Damn, It’s all so tidy - even when it’s beta.
But without smart code sense, it is useless for real developers, my question is - will it be smart and good as Zend studio’s?
Can it be done with the current framework that you build for the sugars?
I looked over the thread and I saw the performance issue, Zend studio resolved that with a simple hidden ’.project’ file, I think you can do that too.
B.T.W - I really love the way it synchronize with the server.
