[TxMt] Re: C Library bundle MONSTER

[Charilaos Skiadas]

On Dec 6, 2006, at 8:15 PM, William D. Neumann wrote:
> On Wed, 6 Dec 2006, Jacob Rus wrote:
>
>> Three reasons:
>>
>> 1. It serves very little useful need.
>
> The need it serves seems more to be providing useful documentation  
> regarding the types and purpose of the parameters than to save on  
> typing. Which, according to section 7.1 of the textmate help is a  
> valid reason for using a snippet.

perhaps for using *a* snippet, not *1299* snippets.

The "documentation" part can be served much more simply with a flat  
text file with 4-5 lines for each command, so that a quick lookup in  
that file can tell you a lot more and more detailed information about  
the function in question. It could even be accompanied with a link to  
more online documentation perhaps.

This is the job for the various ctrl-H documentation commands, not  
for 5.3MB worth of snippets. (by comparison, all the repository is  
48MB).

>> 2. The things which are in the subversion repository represent the  
>> consensus of the TextMate community.
>
> Really?  Since when?  I don't remember getting any ballots to help  
> judge the consensus.  And as far as I can tell, yours is the only  
> complaint so far against the C Library bundle.  Do your wishes now  
> equal community consensus?

Sure you have gotten ballots, you can review commands and voice your  
opinion. Theoretically you can even go right in there in the bundles  
and change things, you have commit access IIRC (though of course you  
should avoid messing with bundles you are not the maintainer of,  
unless you really really know what you are doing). A lot of such  
discussion takes place in the channel all the time. In this  
particular case, there are a number of main maintainers against this  
bundle, including myself, Jacob Rus (jacobolous), Kevin Ballard  
(Eridius) and Michael Sheets (Infininight).

There is a fair amount of thought being given before something is  
added to the repository, and we try to keep things in a similar form.

We appreciate the effort that went into this bundle, but we think  
there are better and simpler ways to implement equivalent  
functionality. We do encourage contributions to the repository, but  
ideally with some discussion first. We do try to keep the bundles at  
a high standard.

>> 3. It is not impossibly difficult to make a completion command  
>> which is vastly more useful, can be pushed into the existing C  
>> bundle (meaning I don't need to go to my list and filter something  
>> else out), works the way users coming from other editors would  
>> expect it to, is more flexible (i.e. can be adapted for  
>> unanticipated libraries), and is just in every respect better.
>
> "It doesn't work as well as it could" <> "compelling reason to  
> delete".  I think most folk here would agree that the current  
> syntax definition system isn't working as well as it could.  Should  
> we just go ahead and scrap all bundles that contain a syntax  
> definition?

It doesn't work at all I would say, but creating a command with  
similar functionality is trivial.
We can create even better functionality with a single command that  
reads the current word, and then uses a dictionary read from a  
property list to match this word among the keys, and insert the  
appropriate text based on the value for the key. The advantage would  
be further that we could have the command even partially match keys,  
so that typing say "conv" will provide a popup of all the conversion  
commands. The popup could perhaps even use a possible command  
"description" to offer more details to the user.

This command can be done in about 10 lines of Ruby, and the  
corresponding dictionary file can be in a format that allows the user  
to add their own commands to this list. This has already been done in  
the LaTeX bundle, with the two "Insert ... Based on Current Word"  
commands, which use the configuration file that the user can edit to  
their heart's content via the "Edit Configuration File" command. It's  
simple to do, all the commands are defined in the same file and  
adding 20 new snippets amounts to simply adding 20 lines to this one  
file.

We could even, with a couple more lines of code, simulate this  
daedalus of  nested menus via a series of tm_dialog screens.

I'll stop here for now.

> William D. Neumann

Haris