Is mcomplete.el still relevant?

Is mcomplete.el still relevant?

[Minejima Yuji]

Hi, there.
I'm the author of mcomplete.el package which does minibuffer completion with prefix and substring matching.
http://homepage1.nifty.com/bmonkey/emacs/elisp/mcomplete.el

I've been away from Emacs and Elisp for several years now. But I decided to
 come back. Back then, some people toled me that they loved mcomplete.el.

But time flies like an arrow, I'm not sure if it's still relevant to the current
Emacs environment.

Does some other package overtake its functionality? Or does Emacs no longer need it because it already does the same thing on its own?

If there're people who still use mcomplete.el, I think I'll update it.

--
Yuji http://homepage1.nifty.com/bmonkey/index-en.html

Re: Is mcomplete.el still relevant?

[Jambunathan K]

> If there're people who still use mcomplete.el, I think I'll update it.

I had used mcomplete (and IIRC bcomplete as well) before and I loved it.

I no longer have these as part of my load path.  I also don't seem to
miss them.  (Hopefully it says something.)

Thanks for mcomplete btw.
-- 

Re: Is mcomplete.el still relevant?

[Le Wang]

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

Hi Minejima,

On Thu, Jul 26, 2012 at 3:18 AM, Minejima Yuji <yuji.minejima@gmail.com>wrote:

> Hi, there.
> I'm the author of mcomplete.el package which does minibuffer completion
> with prefix and substring matching.
> http://homepage1.nifty.com/bmonkey/emacs/elisp/mcomplete.el
>
> I've been away from Emacs and Elisp for several years now. But I decided to
>  come back. Back then, some people toled me that they loved mcomplete.el.
>

I have very fond memories of using mcomplete.  And I still carry it around,
although it hasn't been loaded as part of my Emacs init for some time.

Thank you for contributing your time to improve my Emacs experience!


> But time flies like an arrow, I'm not sure if it's still relevant to the
> current
> Emacs environment.
>
> Does some other package overtake its functionality? Or does Emacs no
> longer need it because it already does the same thing on its own?
>

I believe ido, which is a part of Emacs 24 has very similar functionality.
Although helm is the completion package I've settled on.

https://github.com/emacs-helm/helm

-- 
Le

[-- Attachment #2: Type: text/html, Size: 1722 bytes --]

Re: Is mcomplete.el still relevant?

[Sohail Somani]

On 25/07/2012 8:25 PM, Le Wang wrote:
>
> I believe ido, which is a part of Emacs 24 has very similar
> functionality.  Although helm is the completion package I've settled on.

Do you know how to get ido fuzzy matching with helm? This is my current 
issue :)

Sohail

Re: Is mcomplete.el still relevant?

[Le Wang]

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

On Thu, Jul 26, 2012 at 9:32 AM, Sohail Somani <sohail@taggedtype.net>wrote:

> Do you know how to get ido fuzzy matching with helm? This is my current
> issue :)


I'm not sure what this is.  Best to ask Thierry on github.  (and explain
what you mean while you're at it).

-- 
Le

[-- Attachment #2: Type: text/html, Size: 581 bytes --]

Re: Is mcomplete.el still relevant?

[Eric Abrahamsen]

On Thu, Jul 26 2012, Le Wang wrote:

> On Thu, Jul 26, 2012 at 9:32 AM, Sohail Somani <sohail@taggedtype.net
>> wrote:
>
>     Do you know how to get ido fuzzy matching with helm? This is my
>     current issue :)
>
>
> I'm not sure what this is.  Best to ask Thierry on github.  (and
> explain what you mean while you're at it).

Not that anyone asked me, but in a way fuzzy matching is one of the main
reasons I use Emacs. You type a _non-contiguous_ string of letters, and
ido-mode (or whatever else), gradually narrows the possible matches down
to one. That (plus the way emacs fills in the blanks for you at the M-x
prompt) made me realize that "usability" and swooshy window animations
are quite unrelated concepts. I saw a variable called `ido-everywhere'
and though, "yes please!".

-- 
GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.11)
 of 2012-07-23 on pellet

Re: Is mcomplete.el still relevant?

[Sohail Somani]

On 26/07/2012 6:56 AM, Eric Abrahamsen wrote:
> On Thu, Jul 26 2012, Le Wang wrote:
>
>> On Thu, Jul 26, 2012 at 9:32 AM, Sohail Somani <sohail@taggedtype.net
>>> wrote:
>>
>>      Do you know how to get ido fuzzy matching with helm? This is my
>>      current issue :)
>>
>>
>> I'm not sure what this is.  Best to ask Thierry on github.  (and
>> explain what you mean while you're at it).
>
> Not that anyone asked me, but in a way fuzzy matching is one of the main
> reasons I use Emacs. You type a _non-contiguous_ string of letters, and
> ido-mode (or whatever else), gradually narrows the possible matches down
> to one. That (plus the way emacs fills in the blanks for you at the M-x
> prompt) made me realize that "usability" and swooshy window animations
> are quite unrelated concepts. I saw a variable called `ido-everywhere'
> and though, "yes please!".

So yeah, I just saw ido-everywhere too. Thanks!

But still doesn't work with helm. Le sigh...

Sohail

Re: Is mcomplete.el still relevant?

[Tassilo Horn]

Sohail Somani <sohail@taggedtype.net> writes:

>>>      Do you know how to get ido fuzzy matching with helm? This is my
>>>      current issue :)
>>>
>>>
>>> I'm not sure what this is.  Best to ask Thierry on github.  (and
>>> explain what you mean while you're at it).
>>
>> Not that anyone asked me, but in a way fuzzy matching is one of the
>> main reasons I use Emacs. You type a _non-contiguous_ string of
>> letters, and ido-mode (or whatever else), gradually narrows the
>> possible matches down to one. That (plus the way emacs fills in the
>> blanks for you at the M-x prompt) made me realize that "usability"
>> and swooshy window animations are quite unrelated concepts. I saw a
>> variable called `ido-everywhere' and though, "yes please!".
>
> So yeah, I just saw ido-everywhere too. Thanks!
>
> But still doesn't work with helm. Le sigh...

Helm always uses regexp matching which is more powerful/exact but
probably less convenient than fuzzy matching.  But there seems to be a
customization option to influence matching a bit.  You may want to
fiddle around with that.

,----[ C-h v helm-mp-matching-method RET ]
| helm-mp-matching-method is a variable defined in `helm-match-plugin.el'.
| Its value is multi3
| 
| Documentation:
| Matching method for helm match plugin.
| You can set here different methods to match candidates in helm.
| Here are the possible value of this symbol and their meaning:
| - multi1: Respect order, prefix of pattern must match.
| - multi2: Same but with partial match.
| - multi3: The best, multiple regexp match, allow negation.
| - multi3p: Same but prefix must match.
| Default is multi3.
| 
| You can customize this variable.
`----

Bye,
Tassilo

Re: Is mcomplete.el still relevant?

[Sohail Somani]

On 26/07/2012 9:35 AM, Tassilo Horn wrote:
> Helm always uses regexp matching which is more powerful/exact but
> probably less convenient than fuzzy matching.  But there seems to be a
> customization option to influence matching a bit.  You may want to
> fiddle around with that.

Thanks, this looks helpful!

Sohail

Re: Is mcomplete.el still relevant?

[Christopher Schmidt]

Minejima Yuji <yuji.minejima@gmail.com> writes:
> Does some other package overtake its functionality? Or does Emacs no
> longer need it because it already does the same thing on its own?

mcomplete seems to implement a subset of Icicles[1] and icomplete.
Icicles is not a standard package, though.

        Christopher

[1] http://homepage1.nifty.com/bmonkey/emacs/elisp/mcomplete.el

Re: Is mcomplete.el still relevant?

[Christopher Schmidt]

Christopher Schmidt <christopher@ch.ristopher.com> writes:
> [1] http://homepage1.nifty.com/bmonkey/emacs/elisp/mcomplete.el
      http://www.emacswiki.org/emacs/Icicles

        Christopher

Re: Is mcomplete.el still relevant?

[Minejima Yuji]

Thanks for all the kind answers.

I've never heard of icicles, I'll give it a try.

Also on Japanese BBS, I've heard that the completion system of Emacs has changed a little since version 23. So I'll examin it first.

--
Yuji.