bug#11360: ERC completion case-sensitive

bug#11360: ERC completion case-sensitive

[Antoine Levitt]

Hi,

ERC nickname completion got case sensitive a couple of commits ago (two
days at most, I'd say), while it wasn't before. Can someone fix it?

Antoine

bug#11360: ERC completion case-sensitive

[Stefan Monnier]

> ERC nickname completion got case sensitive a couple of commits ago (two
> days at most, I'd say), while it wasn't before.  Can someone fix it?

It was probably me, but I fail to see how/where that happened.
Can you give me a recipe to reproduce the problem starting from `emacs -Q'?


        Stefan

bug#11360: ERC completion case-sensitive

[Antoine Levitt]

05/05/12 05:11, Stefan Monnier
>> ERC nickname completion got case sensitive a couple of commits ago (two
>> days at most, I'd say), while it wasn't before.  Can someone fix it?
>
> It was probably me, but I fail to see how/where that happened.
> Can you give me a recipe to reproduce the problem starting from `emacs -Q'?
>
>
>         Stefan

Hi,

emacs -Q
M-x erc
Confirm irc.freenode.net
Confirm 6667
pick a random nick, no password
type /join #emacs
Pick someone in the users list with a nickname that begins with a caps
(for instance, Test), and type the first characters in his name in lower
case (for instance tes), then tab.

It used to complete to the capitalized nickname. What I think happened
is that this is now controlled by completion-ignore-case while it used
to be controlled by an erc-specific setting. I think a good way to
proceed is to introduce an erc-completion-ignore-case that defaults to
t, and ignore case in erc completion if either
erc-completion-ignore-case or completion-ignore-case is t. A specific
setting seems like a good idea because presumably some people will want
case-insensitive completion in erc but not elsewhere.

bug#11360: ERC completion case-sensitive

[Stefan Monnier]

> erc-completion-ignore-case or completion-ignore-case is t. A specific
> setting seems like a good idea because presumably some people will want
> case-insensitive completion in erc but not elsewhere.

There are 2 notions of "case-sensitivity" when it comes to completion:
- whether the case is semantically significant in the end result
  (i.e. is "FirstName" another user than "firstname"?).
- whether the user wants "FirstName" be considered as a valid candidate
  for completion of "fir".

The current completion code somewhat conflates the two, but in terms of
"what should Emacs do" the difference is important.  Of course, the
second consideration only applies when the first is true.

So: is the case semantically significant, here?


        Stefan

bug#11360: ERC completion case-sensitive

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> erc-completion-ignore-case or completion-ignore-case is t. A specific
>> setting seems like a good idea because presumably some people will want
>> case-insensitive completion in erc but not elsewhere.
>
> There are 2 notions of "case-sensitivity" when it comes to completion:
> - whether the case is semantically significant in the end result
>   (i.e. is "FirstName" another user than "firstname"?).
> - whether the user wants "FirstName" be considered as a valid candidate
>   for completion of "fir".
>
> The current completion code somewhat conflates the two, but in terms of
> "what should Emacs do" the difference is important.  Of course, the
> second consideration only applies when the first is true.
>
> So: is the case semantically significant, here?

irc retains case, but it doesn't use it to distinguish.  That is, if you
have a nick "Larsi", you can't have a nick "larsi".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11360: ERC completion case-sensitive

[Stefan Monnier]

>>> erc-completion-ignore-case or completion-ignore-case is t. A specific
>>> setting seems like a good idea because presumably some people will want
>>> case-insensitive completion in erc but not elsewhere.
>> 
>> There are 2 notions of "case-sensitivity" when it comes to completion:
>> - whether the case is semantically significant in the end result
>> (i.e. is "FirstName" another user than "firstname"?).
>> - whether the user wants "FirstName" be considered as a valid candidate
>> for completion of "fir".
>> 
>> The current completion code somewhat conflates the two, but in terms of
>> "what should Emacs do" the difference is important.  Of course, the
>> second consideration only applies when the first is true.
>> 
>> So: is the case semantically significant, here?

> irc retains case, but it doesn't use it to distinguish.  That is, if you
> have a nick "Larsi", you can't have a nick "larsi".

Thanks, so we should indeed use completion-table-case-fold (and make it
work).


        Stefan


PS: but in the mean time, setting completion-ignore-case buffer-locally
is the better fix for emacs-25.

bug#11360: Case sensitive ERC nick completion regression

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 160 bytes --]

Has anybody looked into this bug in more detail since the original report?
This is happening to me too, and it does seem like a regression since Emacs
24.2.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#11360: Case sensitive ERC nick completion regression

[Stefan Monnier]

> Has anybody looked into this bug in more detail since the original report?
> This is happening to me too, and it does seem like a regression since Emacs
> 24.2.

I just installed a patch by Stephen Berman which might help.


        Stefan

bug#11360: Case sensitive ERC nick completion regression

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Has anybody looked into this bug in more detail since the original report?
>> This is happening to me too, and it does seem like a regression since Emacs
>> 24.2.
>
> I just installed a patch by Stephen Berman which might help.

When I try to do nick completion in erc now, it seems like it's case
sensitive again, so I think it probably worked.  And I'm closing this
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11360: Case sensitive ERC nick completion regression

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

On Dec 27, 2015, at 10:26 PM, Lars Ingebrigtsen wrote:

>When I try to do nick completion in erc now, it seems like it's case
>sensitive again, so I think it probably worked.  And I'm closing this
>report.

Sorry, I don't understand.  I want case-insensitive completion of nicks.

Cheers.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#11360: Case sensitive ERC nick completion regression

[Lars Ingebrigtsen]

Barry Warsaw <barry@python.org> writes:

> On Dec 27, 2015, at 10:26 PM, Lars Ingebrigtsen wrote:
>
>>When I try to do nick completion in erc now, it seems like it's case
>>sensitive again, so I think it probably worked.  And I'm closing this
>>report.
>
> Sorry, I don't understand.  I want case-insensitive completion of nicks.

Sorry; I misread your message.

I've now been following the completion code down the rabbit hole, and
via approx. 23 indirections, the completion is actually done by
`try-completions'.  And that respects the `completion-ignore-case'
variable.

However, TAB is bound to `completion-at-point', which does not allow any
way to have that variable be bound.  So I think we'll just have to bind
TAB to an erc function that binds that variable, and then call
`completion-at-point'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11360: Case sensitive ERC nick completion regression

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

On Feb 04, 2016, at 05:45 PM, Lars Ingebrigtsen wrote:

>I've now been following the completion code down the rabbit hole, and via
>approx. 23 indirections, the completion is actually done by
>`try-completions'.  And that respects the `completion-ignore-case' variable.
>
>However, TAB is bound to `completion-at-point', which does not allow any way
>to have that variable be bound.  So I think we'll just have to bind TAB to an
>erc function that binds that variable, and then call `completion-at-point'.

Thanks Lars.  I remember trying to chase the rabbit too when I originally
reported the problem, but quickly lost my sanity.

I think you're right about binding TAB to a special function.

Cheers,
-Barry

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#11360: (no subject)

[Carlos Pita]

I'm having the same problem with the latest pretest.

Even worst, when using bitlbee, tab completion on an empty line gives:

FirstName
SecondName
....

But tab completion after /query gives:

firstname
secondname
....

This is not only visually inconsistent but, as the completion is case
sensitive, then that a given prefix successfully completes depends on
where the completion was triggered.

Best regards
--
Carlos

bug#11360: none

[Carlos Pita]

I've been debugging a bit. Below is a fix for the case inconsistency
issue.

The case inconsistency is due to the fact that users are hashed into
erc-server-users using (erc-downcase nick). But then
pcomplete-erc-all-nicks builds the completion list from the hash
keys. This is wrong because the keys are the downcased nicks, not the
real nicks themselves. This is also inconsistent with the way
pcomplete-erc-nicks works (this one does use the real nick).

Changing (erc-server-user-nickname user) for nick in
pcomplete-erc-all-nicks will fix this one:

(defun pcomplete-erc-all-nicks (&optional postfix)
  "Returns a list of all nicks on the current server."
  (let (nicks)
    (erc-with-server-buffer
      (maphash (lambda (nick user)
                 (setq nicks (cons
                              (concat (erc-server-user-nickname user) postfix)
                              nicks)))
               erc-server-users))
      nicks))

Best regards
--
Carlos

Carlos Pita <carlosjosepita@gmail.com> writes:

> I'm having the same problem with the latest pretest.
>
> Even worst, when using bitlbee, tab completion on an empty line gives:
>
> FirstName
> SecondName
> ....
>
> But tab completion after /query gives:
>
> firstname
> secondname
> ....
>
> This is not only visually inconsistent but, as the completion is case
> sensitive, then that a given prefix successfully completes depends on
> where the completion was triggered.
>
> Best regards
> --
> Carlos