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

[Stefan Monnier]

[ Replying to the bug only is fine, thanks.  CC-ing me is fine as well.
  Even sending me an extra copy like you did is fine.  I'm easy to please.  ]

> I wasn't aware that use of indirect buffers is frowned-upon.

It's not exactly frowned-upon, but it suffers from many problems/bugs
some of which are basically impossible to fix.  Part of the problem is
that this is a rarely used feature, so it's not well tested, and the
other part is that it works at a very low level and hence often lacks
higher-level info about is intended.

> I usually use it to simultaneously look at different places in the same
> file. Most of the time this is some long source code thing. It's nice to
> have separate kill rings, mark rings, narrowing, etc.

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.

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

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'?

> 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.

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.


        Stefan