Add advices only when isearch-mb mode is active about isearch-mb

[minad]

Btw, why do you need the isearch-mb--session variable, isn't isearch-mb-mode sufficient?

[minad]

Instead of the isearch-mb--no-search property my recommendation would also be to use a list variable instead. This keeps all the commands at a single place. I think that's better than scattering the configuration over properties. Properties should only be preferred if it matters for performance reasons. But this is a matter of preference.

[minad]

Regarding the advices, maybe it is also possible to add them in the isearch-mb--setup and remove them when the isearch is terminated.

[astoff]

Yes, that's not unreasonable. I was debating how exactly to do, both about the time to apply the advices and whether or not to use symbol plists...

Did you bring this up because of the message in emacs-devel about unload-feature? Do you agree it's a bug that it doesn't remove the unloaded advices, since nobody else will care to do it?

The functions mentioned in https://github.com/astoff/isearch-mb#interaction-with-other-isearch-extensions could also be added to these lists either in isearch-mb directly or by the user.

Allowing the user to change the list rules out the option to add the advices only when activating the global minor mode, so I'm not sure I want to go that way.

Btw, why do you need the isearch-mb--session variable, isn't isearch-mb-mode sufficient?

isearch-mb-mode is global, but iserach-mb--session shouldn't kick in for the minibuffer. Earlier I had made iserch-mb-mode a globalized minor mode, but then I thought it's overkill, since I couldn't find a major mode where it doesn't work.

[minad]

I was debating how exactly to do, both about the time to apply the advices and whether or not to use symbol plists...

What do you mean by using symbol plists?

Did you bring this up because of the message in emacs-devel about unload-feature? Do you agree it's a bug that it doesn't remove the unloaded advices, since nobody else will care to do it?

Yes, this motivated me to look into why the advices lead to problems after all. I think it is a bug in isearch-mb. The advices should only be added when isearch-mb-mode is active or even only temporarily when both isearch-mb and isearch are active.

Allowing the user to change the list rules out the option to add the advices only when activating the global minor mode, so I'm not sure I want to go that way.

Why? The only issue is that you have to adjust the lists before enabling the mode. This should be documented in the readme. The big advantage of adding the user advices in that way is that isearch-mb will take care of cleanly setting up/tearing down the advices for the user depending on if isearch-mb is activated or not. Otherwise the user would have to do this themselves.

Generally advices are a bit unpopular as API exposed to users and it is better to hide this somehow.

[minad]

isearch-mb-mode is global, but iserach-mb--session shouldn't kick in for the minibuffer. Earlier I had made iserch-mb-mode a globalized minor mode, but then I thought it's overkill, since I couldn't find a major mode where it doesn't work.

It is a good decision to have only the global isearch-mb-mode and not both a local and global mode. But I still don't understand why you necessarily need this session variable? Would it be sufficient to check minibufferp and isearch-mb-mode instead? This is not a big deal to have this variable, but it may be interesting to see how the most minimal implementation of the isearch-mb functionality would look (also given the mailing list discussions). For this reason it is good if we can get rid of this additional state variable.

[astoff]

What do you mean by using symbol plists?

Yes. I said it to fast, but I meant that I was debating about both of the issues you brought up :-)

I think it is a bug in isearch-mb.

It may or may not be kosher, but adding advices globally is a common practice... I'm okay with removing the advices when disabling the mode, but doing this on every search seems unnecessary.

Generally advices are a bit unpopular as API exposed to users and it is better to hide this somehow.

You are probably right about that. It doesn't make a lot of sense to me personally, but it's better to follow the conventions.

[minad]

It may or may not be kosher, but adding advices globally is a common practice...

I am not sure where you have seen this, but at least in my quality standards I consider this a malpractice or even a bug.

I'm okay with removing the advices when disabling the mode, but doing this on every search seems unnecessary.

Okay, this is what my patches did before removing the session variable. My idea was then to also encode the session variable state in the installation state of the advices, getting rid of the unnecessary variable on the way :)

It doesn't make a lot of sense to me personally, but it's better to follow the conventions.

I agree that recommending advices to users is sometimes okay. I also do that. In this case here I think it is safer to have a uniform method to setup the advices (as I proposed with using the advice list variables isearch-mb--with-buffer etc). The advantage is that then isearch-mb gains some freedom with respect to how, when and where it likes to install the advices. If we expect the user to do the advice installation themselves they have to follow the internal implementation closely.