On Dec 6, 2006, at 8:15 PM, William D. Neumann wrote:
On Wed, 6 Dec 2006, Jacob Rus wrote:
Three reasons:
- 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).
- 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.
- 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