You are, of course, proving my statement that the simple category
approach is simpler. :)
On Feb 16, 2007, at 12:47 PM, Allan Odgaard wrote:
build -- some sort of build system (Makefile, SCons, …)
framework -- a framework (OpenGL, Rails, Django, Qt, …)
gtd -- some sort of GTD (GTD, GTDAlt, TODO, …)
mac -- mac-specific (AppleScript, Xcode, …)
mail -- related to emails (Mail, …)
markup -- markup language (XML, Textile, reST, …)
programming -- programming language (Ruby, C, …)
prose -- structured text (LaTeX, Markdown, …)
scm -- revision control system (Subversion, CVS, …)
utility -- stuff which is useful tools (Math, Remind, …)
web -- web related (HTML, Symfoni, PHP, …)
For broad categories, for use as the root of a displayed bundle
hierarchy, the list should be somewhat smaller (and, I think, more
specific):
applications -- interfaces to the outside (blogging, web search,
Terminal, Mail? …)
build -- some sort of build system (Makefile, SCons, …)
file formats -- data files, not 'markup' (plist, iCalendar, sshd,
Tabular, …)
framework -- a framework (OpenGL, Rails, Django, Qt, …)
markup -- markup language (XML, Textile, LaTeX, Markdown,
tablature, …)
productivity -- (GTD, GTDAlt, TODO, Remind …)
source code -- programming language (Ruby, C, …)
scm -- revision control system (Subversion, CVS, …)
tools -- generic commands for text manipulation (Math, …)
That gives you three more categories than you originally listed, by
breaking out the utilities category into applications, file formats,
productivity, and tools. I don't think there's value in distinguishing
marked-up prose languages from markup languages, the overlap is too
wide.
Do we want to tag for compiled, script / interpreted? Probably not…
Do we want to tag for procedural, OO, functional, …? Might be
useful. E.g. how many functional languages do we have support for?
etc.
I would say not. You can end up in a debate over, for example, the
features required for a true OO language, or for a true functional
language. Does Ruby get the 'functional' tag? Does C++ get the 'OO' tag?
Also, each language should be tagged with its own name, so that
supporting bundles can be tagged with it as well. So for example
seeing all bundles tagged ‘python’ will show all bundles which are
somehow related to Python.
The app could also add the name of the bundle to the tag list
internally.
Question: what about bundles containing multiple things? Do we just
add multiple tags, do we split the bundle (nah…), or do we maybe tag
individual commands (confusing)? For example the Ruby bundle has a
command for running rake, does that mean it should be tagged
‘build’ (to indicate that the bundle is for a build system)?
Tag for the user of the bundle. Ruby is for Ruby programming. Rake is
still Ruby code.
It's possible this is better implemented through an external
mechanism rather than directly in bundles.
I don’t follow that. What do you mean?
Instead of tags in the bundle, use a file listing bundles needed for
one particular task, the "Rails Development" file would include Ruby,
Rails, HTML. This would probably be simpler for user customization in
a dynamically-switched-subset scenario.
I don't know. It does get complicated. Maybe it's better to hold off
until the need is clear.
Chris
_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/mailman/listinfo/textmate-dev
