Re: Simple isearch concerns

[Juri Linkov]

>> May I suggest that you merge just the `isearch-buffer-local' change at
>> this point, and then wait for my patch doing the minibuffer part?
>
> Testing shows that the `isearch-buffer-local' change works fine,
> with only one deficiency: as (info "(elisp) Searching Keymaps") says
> get-char-property takes precedence over emulation-mode-map-alists.

Actually, there are more problems: buffer-local design doesn't work for
multi-buffer isearch.

The current design is not without flaws either: when multi-buffer
isearch visits another buffer, it removes the isearch menu, because
isearch-mode is already buffer-local.  And isearch-mode can't be globalized,
because both minor-mode-alist and minor-mode-map-alist already contain
isearch keys that should not be active globally in other buffers.

While rewriting isearch for a new design (with a new option for 
backward-compatibility),
three basic aspects should be taken into consideration - mode, keymap, hooks:

1. mode - currently buffer-local and can't be globalized,
   so multi-buffer isearch should be fixed anyway to enable
   isearch-mode when visiting a new buffer and disable afterwards.

2. keymap - the current global overriding-terminal-local-map
   can be replaced by the global emulation-mode-map-alists
   that depends on the buffer-local value of isearch-mode.

   After fixing multi-buffer isearch to enable isearch-mode
   in visited buffers, keymap in emulation-mode-map-alists
   will enable isearch keys in the next buffer.

   Also a new feature should be designed to give precedence to
   some modes in emulation-mode-map-alists over get-char-property.

3. hooks - currently global hooks when turned into buffer-local
   should be enabled/disabled when multi-buffer isearch visits
   the next buffer.

4. additionally to support multiple isearch sessions in different buffers
   at the same time, isearch state variables could be buffer-local.