[SVN] r7208 (HTML)

[Thomas Aylott (subtleGradient)]

On May 12, 2007, at 4:38 AM, Allan Odgaard wrote:
> On 11. May 2007, at 20:40, Thomas Aylott (subtleGradient) wrote:
>
>>> Also, this is using the “completions” preference key, but it  
>>> is not really meant for TM’s basic completion system, right?
>>>
>>> I.e. it’s just a data file which places itself in a location  
>>> otherwise used for TM’s scope specific preferences and then  
>>> loaded via the deprecated TM_BUNDLE_PATH environment variable!?!
>>>
>>> These are data files and should be stored e.g. under  
>>> TM_BUNDLE_SUPPORT.
>>
>> No, it's for both.
>>
>> I thought we decided we'd leave it asis until 2.0?
>
> No, I said I won’t do any (additional) completion API before after  
> 2.0.
>
> But I still do not like stuff that uses TM_BUNDLE_PATH (this  
> variable has been deprecated for a year or so, and will go in 2.0).
>
> If the intent, by masquerading the list as a preference item is,  
> that it’s easier for the user to edit, then this will often not be  
> the case, since your command will read it from the default bundle,  
> where a potentially edited item will end up in ~/Library.
>
> I didn’t know that your completion lists were also supposed to add  
> suggestions to ⎋-completion — but e.g. for HTML there are 41  
> tags of 3 or less letters. Is this really desired to have available  
> when cycling with ⎋? Say I want to complete one of my own words  
> starting with ‘d’ (in HTML), now your recent change just gave me  
> dd, del, dfn, dir, div, dl, and dt, to also cycle through, as  
> candidates for ‘d’.
>
> I rarely write HTML, so I can’t say how much of interference this  
> is in practice, but from a purely speculative POV, I find it hard  
> to see the value in augmenting ⎋-completion with all the 103 or so  
> standard tag names, as they are rather short, and I assume most  
> people use the same subset of just 10 or so of them.

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.

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.

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

{	completions = ( 'a', 'abbr', 'acronym', 'address' );
	shellVariables = (
		{	name = 'TM_COMPLETIONS';
			value = 'a,abbr,acronym,address';
		},
	);
}

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.

	thomas Aylott — subtleGradient — CrazyEgg — sixteenColors