On 12. Jun 2007, at 02:11, Chris Thomas wrote:
Some quick, broad comments:
- Subversion++ is a great idea -- I'd use this capability regularly
- Git bundle is a great idea
- More sharing is abstractly a great idea
Selection: Most commands have logic to check if there is a
selection (and then various variations of how to decode
TM_SELECTED_FILES into an array), a project folder, a current
directory, etc.
Maybe this should be higher level than SCM?
Yeah, I think you’re right. I btw forgot to mention one other twist
on the selection logic: filtering out selected files in selected
folders.
Paths: Paths need to be pretty printed, that means, if we run on
the project folder, they should be relative to this one, if we run
on a selection, preferably they should be relative to the nearest
common ancestor of the selection, finally they should fall back to
being shown with the home folder abbreviated using a tilde — many
commands presently have some custom logic that sort of does the
above (but not quite, and each one re-invents the wheel).
This, too, might be useful at a higher level than SCM.
Agree, yes.
I’ll try to come up with some good names for these modules. I think
we need two-level namespaces like we did with TextMate::UI, otherwise
we’ll end with hundreds of methods under TextMate.
Status: I know many svn commands have their own mapping of letter
→ status text and foreground/background color. This should be
encapsulated into a SCM::Status class where instances are mostly
created by name (and can then be queried about color, etc.)
I haven't tried to fix this in the past because the solution would
have to somehow map into Objective-C for the commit window. A
tm_dialog-based commit window will simplify the task, but some code
probably needs to be integrated into the dialog plugin. Bindings
fixes in Leopard may make this easier.
Yes, I think we need to introduce a system for lazy-loading classes,
i.e. so we can have more advanced stuff “part of TM” but not
suffering from having to always load it at startup. Presumably many
of the current plug-ins could also benefit from lazy-loading
(probably giving a menu item “trigger” in their Info.plist).
A related question... how is this going to map into TM 2.x? Will
2.0 allow bundles to annotate files in the project view?
Yes, my current model is that anyone can set attributes on files.
These attributes can be used to change the rendering of files and
also becomes part of the file’s scope -- so in practice there is a
svn handler which is notified about which files are opened and shown
in the file browser, and it will fetch svn status for these and set
“scm.svn” for all files under svn control,
“scm.status.modified” for those which are modified, etc.
In the scope “attr.” is added as a prefix and we can thus set the
scope selector for all the commands in the Subversion bundle to
“attr.scm.svn” (and have the same activation key for all SCM
systems). Additionally we can inject the diff grammar into
“attr.scm.status.conflict”, etc.
So basically there is only one new thing related to SCM integration
(and it’s not specifically tied to SCM), though it will also be
possible to associate action menus to files (ideal for SCM also). But
the current command-driven system for handling SCM will be the same,
and so we can re-use the current stuff, we just need to write a
status-handler for each SCM system (to annotate files) plus setup an
action menu.
_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/mailman/listinfo/textmate-dev
