<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On May 14, 2007, at 6:29 AM, Allan Odgaard wrote:</DIV><BLOCKQUOTE type="cite"><DIV>On 12. May 2007, at 21:35, Thomas Aylott (subtleGradient) wrote:</DIV> <DIV><BR></DIV> <BLOCKQUOTE type="cite"><DIV>Yes, the codecompletion thing uses the normal escape completion list for all those reasons.</DIV> <DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>I hadn't realized that that thing was deprecated at the time I created the codecompletion library.</DIV> <DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>I'm not sure how I would have know that.</DIV> </BLOCKQUOTE><DIV><BR></DIV> <DIV>Stuff which is not in the manual (or release notes) is normally because I have not committed to the functionality (or “removed” it).</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'll keep that in mind next time.</DIV><BR><BLOCKQUOTE type="cite"> <BLOCKQUOTE type="cite"><DIV>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.</DIV> </BLOCKQUOTE><DIV><BR></DIV> <DIV>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”… ;)</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Right right, sorry about that.</DIV><BR><BLOCKQUOTE type="cite"> <BLOCKQUOTE type="cite"><DIV>So that would require something like this if I wanted it to work in both escape completions and menu completions? [...]</DIV> </BLOCKQUOTE><DIV><BR></DIV> <DIV>Yes, but you didn’t relate to my question of this actually adding value to the escape completion.</DIV> <DIV><BR></DIV> <DIV>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.</DIV> <DIV><BR></DIV> <DIV>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?</DIV> <DIV><BR></DIV> <DIV>And if not, does it maybe detract value from completing words (prose) with escape, since we inject 90 non-words into the carpus.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Sorry, I had already seen the error of my ways and agreed with this pretty obvious logic.</DIV><DIV><SPAN class="Apple-style-span">That's why I suggested using the <B>invalid.illegal.incomplete.html</B> 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.</SPAN></DIV><BR><BLOCKQUOTE type="cite"> <BLOCKQUOTE type="cite"><DIV>[...]</DIV> <DIV>Obviously with a change to the codecompletion library to parse TM_COMPLETIONS instead of reading the plist directly.</DIV> <DIV><BR></DIV> <DIV>If scoped to invalid.illegal.incomplete.html <></DIV> <DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Then they would not be in anyone's way.</DIV> </BLOCKQUOTE><DIV><BR></DIV> <DIV>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.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Right, that was what I was planning.</DIV><BR><BLOCKQUOTE type="cite"> <DIV>Then we also only need one command, rather than a command per bundle (or per scope, as it seems is currently the case).</DIV> <DIV><BR></DIV> <DIV>So advantages:</DIV> <DIV> 1) only one command, not a command per bundle/scope</DIV> <DIV> 2) simpler code to read the list (no file I/O / plist parsing)</DIV> <DIV> 3) not going to be a problem for the user to update completions for bundles not in ~/Library</DIV> <DIV> 4) the completions do not poison the normal ⎋ completion carpus</DIV> <DIV><BR></DIV> <DIV>Disadvantages:</DIV> <DIV> 1) the completions you setup for this command are not available via ⎋</DIV> </BLOCKQUOTE></DIV><BR><DIV>Yes, I agree that if we do it with the environment variable we should be able to have a single simple command.</DIV><DIV>Then anything that requires a different list of completions can have a separate completion command or could simply inject values into that environment variable.</DIV><DIV>CSS and Ruby both have more complex completion commands.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>HTML isn't a great example of how this should work since the completions list is really crappy.</DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>thomas Aylott — <B>subtleGradient </B>— CrazyEgg — sixteenColors</DIV></DIV></BODY></HTML>