[SVN] r7208 (HTML)

[Allan Odgaard]

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.