On May 14, 2007, at 6:29 AM, Allan Odgaard wrote:
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'll keep that in mind next time.
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”… ;)
Right right, sorry about that.
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.
Sorry, I had already seen the error of my ways and agreed with this
pretty obvious logic.
That's why I suggested using the invalid.illegal.incomplete.html
scope. If those are the only escape completions available they could
be useful. More likely to be useful in a menu than regular escape
completions though. You're too right.
[...]
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.
Right, that was what I was planning.
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 ⎋
Yes, I agree that if we do it with the environment variable we should
be able to have a single simple command.
Then anything that requires a different list of completions can have
a separate completion command or could simply inject values into that
environment variable.
CSS and Ruby both have more complex completion commands.
HTML isn't a great example of how this should work since the
completions list is really crappy.
But CSS is a great example of how it should work. There's a single
definite list of completions for each scope. The list of escape
completions and menu completions should be the same.
I hate the thought of duplicating lists for both escape completions
and menu completions. But I guess that gives us the option of having
a different list for each. HTML is a good example of things you'd
want in the menu but not the escape list.
thomas Aylott — subtleGradient — CrazyEgg — sixteenColors
_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/mailman/listinfo/textmate-dev
