On Tue, Sep 04, 2001 at 10:39:00AM -0500, Jeremy Nelson wrote:
> Thanks for being willing to report a bug in epic, but unfortunately, I do
> not believe this is an epic issue. If you have any further questions, feel
> free to ask.
You are right. Splitfire and sheep have these bugs, while if I coax epic into
starting without loading scripts, the completion behaviour is correct. I have
reassigned this bug to the splitfire package.
> When you invoke command_completion (handled by the command_completion()
> function, natch), it looks to see if the input line begins with either a
> slash or one of the command characters:
>
> [....]
> if (!(cmdchars = get_string_var(CMDCHARS_VAR)))
> cmdchars = DEFAULT_CMDCHARS;
>
> if (*com == '/' || strchr(cmdchars, *com))
> {
> [....]
>
> So if you directly invoke COMMAND_COMPLETION, it works quite happily if your
> command character is not /. I have tested this to make sure.
>
> Some scripts try to be "smart" about tab completion and do content-sensitive
> multiplexing. The alias might do something like this:
>
> bind ^I parse_command {
> if (left(1 $L) == [/]) {
> parsekey command_completion
> } else {
> [... do nickname completion ...]
> }
> }
>
> This should be changed to:
>
> bind ^I parse_command {
> if (index($left(1 $L) $K) > -1) {
> parsekey command_completion
> } else {
> [... do nickname completion ...]
> }
> }
>
> The change here is that we compare the first character on the input line
> [$left(1 $L)] to the command characters [$index(... $K)]. $index returns
> -1 if the character was not found, and > -1 if found. This is better than
> just comparing the first character to the slash.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
PGP signature
