[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ERC completion

From: Stefan Monnier
Subject: Re: ERC completion
Date: Thu, 28 Apr 2011 21:50:09 -0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>>> Sorry, it isn't ignored. But rather, erc-pcompletions-at-point always
>>> return non-nil, even when it does not complete anything, so that my
>>> customization
>>> (setq erc-complete-functions '(erc-pcompletions-at-point
>>> my-dabbrev-expand))
>>> does not work as expected. (the intent is to have dabbrev take over if
>>> I'm not completing a nick)
>> Hmm, does the patch below help?

> It's looks like it's a step in the right direction, but it does not fix
> the problem: "completions" is still non-nil, and includes every nick,
> even those that don't begin by the word before point.

I see.  The problem is that completion-at-point-functions is meant to
first decide what kind of completion should take place at point,
regardless of whether the text at point might match any one of those
completions (and determining whether or not it matches would need to pay
attention to completion-styles and completion-in-region-function, ...,
i.e. do a dry-run of completion-in-region).  Note that the decision
should take place separately from the completion itself since we want to
be able to do things like completion-help-at-point.

IIUC in your case, you seem to want to use "nick completion if such
a completion exists, or else fallback on dabbrev".

I'm not sure how best provide that kind of behavior (other than by
trying to merge the two entries using something like

> Also, while on the subject of ERC completions, it seems an extra space
> is appended after erc-pcomplete-nick-postfix, originating from the same
> commit.

Hmm... can you show me exactly what you've done, what was the result
with the code and what is the result with the new code?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]