"Matthieu MOY" <[EMAIL PROTECTED]> writes:
> [ I received this as a private email. Readding xtla-el-dev in Cc ]
Ah, the reason is probably that I try to setup the Mail-Copies-To
header in gnus now.
So it seems you answered my mail. And only I got the response, because
of "Mail-Copies-To: never"
Perhaps I should set the Mail-Followup-To too.
But that gets O.T. I removed the header again.
> 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.
O.k., I will use xhg as symbol.
>> * 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.
Ah, the reason was, that I didn't load xtla-baz. Still using tla here
at work...
> 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.
My vision is to provide global keybindings for the top layer.
So there will be functions like:
dvc-changes
dvc-commit
dvc-log
dvc-status
...
And that dvc function will pick the current dvc via dvc-current-active-dvc
It will be even possible to put a tree in several dvc's and provide
the function dvc-select-current-dvc
So there are the specific functions that can be called xhg-*, baz-*
and there are common functions that can be called via dvc-*
The benefit for the user is, that he can switch to a differnet dvc and
the emacs frontend stays the same for common functions and specific
functions are still available.
Stefan.
