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 ⎋
_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/mailman/listinfo/textmate-dev
