bug#16904: 24.3; [PATCH] ff-find-other-file and friends now work with indirect clone buffers

[Dima Kogan]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Multiple narrowing within the same buffer is indeed not supported, but
> we could easily add commands to "hide everything but the current region"
> which are per-window, where "hide" means "make invisible" rather than
> making it completely inaccessible as narrowing does.

Is the intent for this to replace narrowing? I think it would be
confusing to have two very similar but subtly different mechanisms for
doing the same thing.


> Not sure what you mean by separate kill rings, since kill-ring is
> a global variable.

Yes, you're right. Never mind on that one.


> As for separate mark-rings, I'm not sure what alternative I can offer.
> Maybe we could have some kind of new command `pop-to-nearest-mark'?

Maybe. That's brittle, though. The nearest mark COULD be in the other
window's section of the buffer, depending on exactly how the split is
set up.

Here's another way in which an indirect view into a buffer is better
than another window: iswitchb (and maybe other C-x b methods too) sorts
already-visible windows last. This usually results in way more typing
when trying to switch in this way. Here's a concrete example:

1. say you're looking at a buffer 'file' in a window that's taking up
the whole frame

2. C-x 3. Now you have two windows. Both show 'file'.

3. C-x b [enter]. We just switched to some other buffer (doesn't matter
which) in one of the windows. I'm assuming iswitchb here

4. C-x b [enter]. Same keys as before, entered again. Normally this
would switch back to the previously-active buffer, but since this buffer
is already visible, it'll default to some other buffer. You'll have to
type enough of the buffer name to uniquely identify it, before iswitchb
will recognize it.


>> The only issues I've encountered have to do with various functions not
>> recognizing that those buffers have a backing file.  Those are
>> ff-find-other-file, vc-diff, etc. I suspect that making
>> (buffer-file-name) work for indirect buffers would resolve a lot of
>> these, but I don't know enough about the internals to propose that.
>
> Changing only the buffer-file-name function is too risky: it would make
> it behave subtly differently from the buffer-file-name variable, and
> since this subtlety only appears with indirect-buffers (remember:
> rarely tested), it's a recipe for bugs.

Hmmm. You could set the buffer-file-name variable when the indirect
buffer is created. I guess I just don't know about (and haven't seen
any) fundamental breakage in indirect buffers, so my current instinct is
to try to fix it, rather than switch to something else entirely. Most of
the issues I've seen are small things, like modules that use
(buffer-file-name).


> Changing ff-find-other-file and friends to handle this problem is much
> safer.  The problem with it is that I don't really want to go down that
> slope, because there are many other such "minor bugs", depending on your
> particular use case, so fixing them leads to adding a lot of support
> code spread all over the place, and all this for a half-broken, rarely
> used feature.

Completely agree. I just don't know enough about the core to be able to
submit useful patches there, so this patch did the easy thing.

What issues are there with indirect buffers? The default C-x 4 c binding
makes an indirect clone, so it's not THAT obscure.

dima