From: Junio C Hamano <hidden> Date: 2016-06-15 22:53:36
Jonathan Nieder [off-list ref] writes:
Felipe Contreras wrote:
quoted
On Mon, Apr 16, 2012 at 11:09 PM, Jonathan Nieder [off-list ref] wrote:
quoted
Felipe Contreras wrote:
quoted
quoted
quoted
I would like to see a completion script that actually has a function
supposed to be exported and that still uses the _ prefix anyway.
The /etc/bash_completion library itself exports lots and lots of
functions with a _ prefix.
We are not making a bash_completion library; I mean a bash completion
script (other than the library).
Ok. If you refuse to put two and two together, then I will (as usual
when this happens) just be a little passive aggressive and annoyed and
let you talk to other people.
I have been assuming that bash_completion library is a sort of metaproject
whose sole purpose is to supply a framework for completion scripts for
other packages like Git to be plugged easily and give niceties like lazy
loading to avoid inflicting undue latencies to the end users.
Earlier I said "Ok" to you based on that assumption; somebody may have his
own git_complete that rebuilds a test integration branch (i.e. completes
it) and having the name git_complete exported by us will indirectly affect
her fingers if she installs bash_completion and Git package on her system.
But that assumption may not be correct, or even if it is correct, Felipe
may be missing that part, so it may not be "refusing to add two and two",
but could be "learned two, but do not know the number of the other side of
addition".
From: Felipe Contreras <hidden> Date: 2016-06-15 22:53:36
On Mon, Apr 16, 2012 at 11:51 PM, Junio C Hamano [off-list ref] wrote:
Earlier I said "Ok" to you based on that assumption; somebody may have his
own git_complete that rebuilds a test integration branch (i.e. completes
it) and having the name git_complete exported by us will indirectly affect
her fingers if she installs bash_completion and Git package on her system.
She might have had the same problem if she named it _git_complete.
That might be unlinkely, but I also find it unlikely that anybody
would have a git_complete function. In fact, I find it unlikely that
people would write shell functions like that; it's much easier to
write scripts and put them in $PATH.
Even more, I just added a foobar() function in my profile, and I also
added a foobar() function in /etc/bash_completion.d/git. I don't see
my function replaced in any way, even after typing and completing
'git' commands. I don't know how that's possible, but that's why I
don't like to take these types of claims as face value.
Cheers.
--
Felipe Contreras
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:53:36
Felipe Contreras wrote:
Even more, I just added a foobar() function in my profile, and I also
added a foobar() function in /etc/bash_completion.d/git. I don't see
my function replaced in any way, even after typing and completing
'git' commands. I don't know how that's possible, but that's why I
don't like to take these types of claims as face value.
What version of the bash_completion library do you use? Lazy-loading
was introduced in version 1.90.
If you put
foobar() {
echo hi
}
. /etc/bash_completion
then is your private foobar unclobbered?
To answer your demand before for a function in the public interface of
a completion script, not library, which respects or does not respect
the bash-completion convention: see the public _rpm_installed_packages
helper from the rpm completion script[1].
If you don't like the convention or think that I have misunderstood
it, I can understand that and would recommend that you suggest a
different one and get it adopted and documented by the bash_completion
project.
Jonathan
[1] http://lists.alioth.debian.org/pipermail/bash-completion-devel/2012-March/004359.html
From: Felipe Contreras <hidden> Date: 2016-06-15 22:53:36
On Tue, Apr 17, 2012 at 1:44 AM, Jonathan Nieder [off-list ref] wrote:
Felipe Contreras wrote:
quoted
Even more, I just added a foobar() function in my profile, and I also
added a foobar() function in /etc/bash_completion.d/git. I don't see
my function replaced in any way, even after typing and completing
'git' commands. I don't know how that's possible, but that's why I
don't like to take these types of claims as face value.
What version of the bash_completion library do you use? Lazy-loading
was introduced in version 1.90.
1.99
If you put
foobar() {
echo hi
}
. /etc/bash_completion
then is your private foobar unclobbered?
Yes, in that case it does, but that's not the default behavior, at
least not in my system, and I doubt anybody would define their
functions before loading library scripts.
To answer your demand before for a function in the public interface of
a completion script, not library, which respects or does not respect
the bash-completion convention: see the public _rpm_installed_packages
helper from the rpm completion script[1].
What makes you think this is public? It's under the section '# helper
functions', which doesn't seem to be public. Plus, it's repeated in
rpm, rpmbuild, and rpmbuild-md5.
The fact that somebody uses it doesn't mean it's public.
Cheers.
--
Felipe Contreras
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:53:36
Felipe Contreras wrote:
What makes you think this is public? It's under the section '# helper
functions', which doesn't seem to be public. Plus, it's repeated in
rpm, rpmbuild, and rpmbuild-md5.
Ok, you win. I hadn't realized we were having a debate, but now I do,
and you have won.
Can we get back to making the completion script nicer for human
beings that have been using it, please?
The following summary may sound annoyed, because I am. On the other
hand I know you mean well and am grateful for your work.
I have said that the convention for bash completion scripts is to
precede all exposed identifier names with an underscore. You
mentioned some old counterexamples that have been grandfathered in.
You mentioned that you do not trust me. Your bash completion script
gets loaded immediately instead of being lazy-loaded, probably because
it is not in /usr/share/bash-completion/completions/. You claimed
that nobody would _ever_ ask for bash completion support at the end of
their .profile and after their custom functions in .profile that do
something unrelated, though I used to do that for a long time and
Debian's default .bashrc loads /etc/bash_completion at the end, too.
I still maintain that namespaces are useful and we should follow the
conventional ones when they exist. What is the next step?
Jonathan
From: Felipe Contreras <hidden> Date: 2016-06-15 22:53:36
On Tue, Apr 17, 2012 at 2:16 AM, Jonathan Nieder [off-list ref] wrote:
Felipe Contreras wrote:
quoted
What makes you think this is public? It's under the section '# helper
functions', which doesn't seem to be public. Plus, it's repeated in
rpm, rpmbuild, and rpmbuild-md5.
Ok, you win. I hadn't realized we were having a debate, but now I do,
and you have won.
I thought we were trying to agree on a good name for possibly the
first (or second, depending how you count) public function. It's
important to choose a good name because we can't just change it again
in a month.
You are the one who brought the argument that even public functions
have the '_' prefix, so it's *your* responsibility to substantiate
that argument. I don't think it would be easy to find a precedent like
this, but you can prove me wrong by providing the evidence; so far, I
don't think that has happened.
Can we get back to making the completion script nicer for human
beings that have been using it, please?
Sure, but we need some sort of git_completion function if we want to
make it easy for people to define aliases for git commands. And this
is a known issue that has been brought in the past.
The following summary may sound annoyed, because I am. On the other
hand I know you mean well and am grateful for your work.
I have said that the convention for bash completion scripts is to
precede all exposed identifier names with an underscore. You
mentioned some old counterexamples that have been grandfathered in.
You mentioned that you do not trust me. Your bash completion script
gets loaded immediately instead of being lazy-loaded, probably because
it is not in /usr/share/bash-completion/completions/. You claimed
that nobody would _ever_ ask for bash completion support at the end of
their .profile and after their custom functions in .profile that do
something unrelated,
I did not claim such thing. I said that I *doubted* it, not that it
was most definitely the case.
though I used to do that for a long time and
Debian's default .bashrc loads /etc/bash_completion at the end, too.
I see. That would be troublesome indeed (if somebody chose to add the
function before that line, and not at the end), *if* somehow they used
git_completion in their scripts.
I still maintain that namespaces are useful and we should follow the
conventional ones when they exist. What is the next step?
What about this?
if ! type git_complete >/dev/null 2>&1; then
git_complete ()
{
echo "WARNING: This function is not meant for public use; the name" \
"might change. Use __git_complete for now."
__git_complete "$@"
}
else
type git_complete | grep -q "WARNING" ||
echo "git_complete is already being used, please notify
git@vger.kernel.org, to" \
"avoid overriding this function in the future."
fi
We can use that for 1.7.11, and if nobody complains remove the
warnings for 1.7.12.
--
Felipe Contreras
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:53:36
Felipe Contreras wrote:
You are the one who brought the argument that even public functions
have the '_' prefix, so it's *your* responsibility to substantiate
that argument.
No, honestly it isn't my responsibility to waste time arguing with
you. What kind of crazy world would work that way?
And I did not mean to bring up any argument. I only meant to bring up
the _datum_ that, at least in the context of the bash_completion
project, that is the current convention. And then you started trying
to tell me that I had the facts wrong! You might even be right, but
you haven't shown any sign of trying to check that, by, say, asking
someone from the bash_completion project what convention they use.
I'm sick of this. Call it whatever you want. I don't know why you
think this is productive.
Still annoyed,
Jonathan
From: Felipe Contreras <hidden> Date: 2016-06-15 22:53:37
On Tue, Apr 17, 2012 at 10:36 AM, Jonathan Nieder [off-list ref] wrote:
Felipe Contreras wrote:
quoted
You are the one who brought the argument that even public functions
have the '_' prefix, so it's *your* responsibility to substantiate
that argument.
No, honestly it isn't my responsibility to waste time arguing with
you. What kind of crazy world would work that way?
And I did not mean to bring up any argument. I only meant to bring up
the _datum_ that, at least in the context of the bash_completion
project, that is the current convention. And then you started trying
to tell me that I had the facts wrong! You might even be right, but
you haven't shown any sign of trying to check that, by, say, asking
someone from the bash_completion project what convention they use.
I don't understand. I'm proposing the name 'git_complete', I thought
you were arguing against it. If you were only providing random facts,
then we can just ignore them, and it would be OK, right? But I'm
pretty sure you would be angry as well if I just ignored that fact.
Sure, it would be nice to follow bash_completion project's convention
for these kinds of functions, if they had any, and might be useful to
ask them what they think. But we don't *have* to. And nobody is
arguing that we should ask them. Right? Or are you?
I'm sick of this. Call it whatever you want. I don't know why you
think this is productive.
We don't have to agree on any name right now. I believe it's worth
waiting before deciding on a name for a public function like this, and
try to get some consensus.
But throwing arguments on the air, and they get angry when they get
counter-argued is not helpful. If we are going to discuss, lets
discuss, but that doesn't seem to be what you want. You want me to
blindly use the name you propose without saying a word? Blindly accept
your argument... follow orders?
I took your argument seriously and looked for evidence myself, and in
the absence of evidence I'm still not throwing it away, I'm assuming
it has merit and added code to make sure we don't override some user
function that has the same name. That would solve the problem you
raised, and it would help us find out if this is indeed a real issue,
or a theoretical one, and at the same time making sure people don't
rely too much on this function for the moment.
I believe this is very scientific-like; you make a hypothesis, we make
an experiment, and then we can find out the results, and only then
make a decision.
I don't know what else I can do to move this forward.
Cheers.
--
Felipe Contreras
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:53:37
Felipe Contreras wrote:
Sure, it would be nice to follow bash_completion project's convention
for these kinds of functions, if they had any, and might be useful to
ask them what they think. But we don't *have* to. And nobody is
arguing that we should ask them. Right? Or are you?
No, I really am not arguing that we should ask them. Because we (or
at least I) already know at least what their convention was a few
years ago. However, I do encourage anyone curious to ask them instead
of making up arguments about why the answer is obvious.
[...]
But throwing arguments on the air, and they get angry when they get
counter-argued is not helpful. If we are going to discuss, lets
discuss, but that doesn't seem to be what you want. You want me to
blindly use the name you propose without saying a word?
I do not think it is fair to call your position blind. I really would
be happier if you were able to listen, and, instead of throwing out
protests and debating points, to talk about your real concerns.
I am guessing (but you never said!) that you find the name
__git_complete ugly. That's fine. I even agree. I have mentioned
that there is a namespace that your proposed alternative violates.
Your response is... to refuse to believe that what I said is true or
relevant?
How am I supposed to have a reasonable discussion after that?
This is not a debating floor. When I give what I think is relevant
information, I am not requesting "please misinterpret me and shoot me
down".
Ciao,
Jonathan
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:53:37
Felipe Contreras wrote:
I took your argument seriously and looked for evidence myself, and in
the absence of evidence I'm still not throwing it away, I'm assuming
it has merit and added code to make sure we don't override some user
function that has the same name. That would solve the problem you
raised
Ah. All that talking, but I was not addressing your actual point.
I though you didn't believe that the namespace adopted by the
bash_completion project was "identifiers starting with underscore,
plus a few old identifiers that have been grandfathered in".
But in fact, you just don't like namespace conventions.
Now I'm exhausted so I have no time to explain why a project that
involves implicitly including scripts from a wide variety of authors
into a flat namespace shared with others might end up using a
convention to manage that namespace. But at least the world seems a
little saner. Sorry for the wasted time.
Please, next time just say what you mean instead of leaving me talking
about something irrelevant.