[ I received this as a private email. Readding xtla-el-dev in Cc ]
Stefan Reichör said:
>
> * We provide an additional emacs interface for already established
> interfaces so we need to pick a different (less intuitive) prefix.
true
> So my idea was, provide the intuitive correct symbol and register
> a prefix for the lisp namespace.
I understand this, but I think the fix is worth than the problem. The
symbol itself ('hg for example) will rarely be used, and both developers
and users will have to deal with the prefix much more often (M-x
xhg-bla-bla RET).
> If we can merge the established
> code in our codebase, we can change the prefix, but the symbol name
> can stay.
I think we can
1) start with our xblabla- prefix
2) When we have something not ridiculous, invite the other developers, and
possibly "absorb" the existing codebase and remove the "x" in the prefix.
> * I don't know, how to activate the baz- aliases. How can I do that?
If you follow the installation instructions this should be done
automatically. It's ;;;###autoload-ed code in xtla-baz.el.
However, we have aliases for functions, but not for variables. At some
point, we may s/\<tla-/baz-/ and completely get rid of this tla- prefix.
>> Also, I think dvc-current-active-dvc shouldn't be in dvc-core.el :
>> It's part of the unification layer that goes on top of the other
>> back-ends (and mostly used for the UI).
>>
>> It could go in dvc-unified.el for example.
>
> Yes and no.
>
> yes: because it is part of the unification layer as you said
> no: because it is THE core function that decides, which dvc to use.
The question is: when do you need to decide automatically which backend to
use? You only need this in the unification layer. Otherwise, M-x
baz-missing RET will use baz, M-x xhg-merge RET will use xgh, etc, without
the need for dvc-current-active-dvc.
--
Matthieu
