[SVN] r7208 (HTML)

[Allan Odgaard]

On 12. May 2007, at 21:35, Thomas Aylott (subtleGradient) wrote:

> Yes, the codecompletion thing uses the normal escape completion  
> list for all those reasons.
> 	I hadn't realized that that thing was deprecated at the time I  
> created the codecompletion library.
> 	I'm not sure how I would have know that.

Stuff which is not in the manual (or release notes) is normally  
because I have not committed to the functionality (or “removed” it).

> I guess the only solution that would work across the board would be  
> to extend all the escape completion preference files to  write that  
> list to an environment variable as you suggested before. There are  
> a lot of people using the codecompletion library now and that would  
> require all of them to change their stuff to match.

I was on vacation when you added this code completion stuff,  
otherwise I would have voiced my objections before we got into the  
situation of “a lot of people use it”… ;)

> So that would require something like this if I wanted it to work in  
> both escape completions and menu completions? [...]

Yes, but you didn’t relate to my question of this actually adding  
value to the escape completion.

Roughly half the completions are 3 letters or less. Since you at  
least need to type one letter to guide the escape completion, and  
then hit escape, we are down to (best case) two letters, for (on  
average) getting 3 letters inserted, except with 90 tags and only 26  
letters, there are (on average) 3 candidates per completion, meaning  
on average you press escape 1.5 times.

So we’re looking at hitting 2.5 characters to get 3 letters -- very  
rough estimates here, but you should get the picture. I.e. is this  
stuff usable as escape completion?

And if not, does it maybe detract value from completing words (prose)  
with escape, since we inject 90 non-words into the carpus.

> [...]
> Obviously with a change to the codecompletion library to parse  
> TM_COMPLETIONS instead of reading the plist directly.
>
> If scoped to invalid.illegal.incomplete.html <>
> 	Then they would not be in anyone's way.

If used as a variable, you just do ENV['TM_COMPLETION_LIST'].split(/, 
\s*/) from Ruby (to get the list) and then set the proper scope  
selector in TextMate for each of the completion preferences.

Then we also only need one command, rather than a command per bundle  
(or per scope, as it seems is currently the case).

So advantages:
  1) only one command, not a command per bundle/scope
  2) simpler code to read the list (no file I/O / plist parsing)
  3) not going to be a problem for the user to update completions for  
bundles not in ~/Library
  4) the completions do not poison the normal ⎋ completion carpus

Disadvantages:
  1) the completions you setup for this command are not available  
via ⎋