Matthieu Moy <[EMAIL PROTECTED]> writes:
> Mark Triggs <[EMAIL PROTECTED]> writes:
>
>> * A directory (the inventory's root directory)
>> * A bunch of rules of the form (tag (op1 op2 ...)). The idea behind
>> this is that when the user is in the inventory buffer and says
>> "remove the file at point", dvc-inventory-mode can make sure that
>> the file's tag supports being removed. In the above, I'm allowing
>> modified files ("M"), added files ("A") and unchanged files ("") to
>> be removed, but not unknown files ("?").
>
> This is surely a good idea, but indeed, it applies to status as well.
> At the moment, the ewoc list of the status actually contains the
> letter to display, as a 1-char string. It would probably be better to
> have something cleaner instead, like a list of symbols - or tag -
> ('modified 'added 'unknown, ... possibly some back-end dependant), and
> let the ewoc printer convert this into a string for the
> user-interface.
>
> This way, the other functions could also easily check that the tag
> allows this operation.
>
> Oh, BTW, a conflicts resolution interface is also on my TODO-list, and
> it also fits exactly in this (but you feed the list with bzr conflicts
> instead of bzr unknowns).
Thanks for the explanations in your messages. I think I'm gradually
coming to grips with how DVC is arranged.
So, it seems like there are a lot of these little "file lists" floating
around: diff has one, status has one, tla-inventory has one, conflicts
management will soon have one. So what we want is some sort of generic
file list that takes:
* A list of symbols (tags), perhaps a pretty-printed version of the
tag, and a bunch of properties for that tag. So a definition might
look like (unknown "?" (add ignore)).
* A bunch of entries of the form (tag name)
Then, ewoc would do the actual rendering of these lists, and there'd be
functions that let you perform queries on the file list (e.g. get the
property list of a tag, get the entry at the point, etc.).
--
Mark Triggs
<[EMAIL PROTECTED]>
_______________________________________________
Xtla-el-dev mailing list
[email protected]
https://mail.gna.org/listinfo/xtla-el-dev
