indirect-buffers and text-properties

indirect-buffers and text-properties

[Phillip Lord]

I've been playing with indirect buffers which I have managed to ignore
for many years, and finding them very useful for a variety of things.

One property that seems very useful is that they can be in different
major modes, while still sharing the same contents. This strikes me as a
particularly useful property of indirect buffers which I would like to
experiment with.

One problem, however, is that as well as the text, indirect buffers
share the text-properties; so anything based on text-properties is
shared. The most notable example here is fontification; syntax
highlighting is the same in the two buffers regardless of major mode.
So, for example, if you have a lisp-mode buffer with an latex-mode
indirect buffer, the lisp-mode buffer looks like latex mode (for reasons
I haven't worked out yet, auctex seems to win most of the time,
regardless of which is direct and which is indirect).

I had a quick look at the code, and this doesn't appear to be
deliberate, but rather a by-product of copying the text; although, given
that my knowledge of C is basically zero, this is pure guess work.

So, question, anyone know why the text-properties get shared with
indirect-buffers and is it possible to stop?

Phil

Re: indirect-buffers and text-properties

[Stefan Monnier]

> So, question, anyone know why the text-properties get shared with
> indirect-buffers and is it possible to stop?

To change that, you'd have to change the underlying C code.
Probably a non-trivial change.

My recommendation: stay away from indirect-buffers.
They are an attractive-nuisance.


        Stefan

Re: indirect-buffers and text-properties

[Phillip Lord]

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

>> So, question, anyone know why the text-properties get shared with
>> indirect-buffers and is it possible to stop?
>
> To change that, you'd have to change the underlying C code.
> Probably a non-trivial change.

That was my impression. Ah, well, unfortunate.

> My recommendation: stay away from indirect-buffers.
> They are an attractive-nuisance.

Really? I've started using them because they enable me to have the point
in two places at once; for example, in the pre-amble and the body of a
latex documented. Of course, you can do this with two windows, but this
is too sensitive to window configuration; if you remove one of the
windows, then you lose the position of point (in favour of the still
visible window). Indirect buffers seem to be a nice solution for this.

Even as it stands, having the same content in two different modes seems
very powerful; instead of using one of the various multi-mode options, I
was thinking of having a single document in two side-by-side windows,
one for changing the code (in one mode) and one for changing the
comments (in another).

Phil

Re: indirect-buffers and text-properties

[Stefan Monnier]

> Really? I've started using them because they enable me to have the point
> in two places at once; for example, in the pre-amble and the body of a
[...]
> visible window). Indirect buffers seem to be a nice solution for this.

That would be using a definition of "nice" very different from the one
I'm familiar with ;-)

BTW, you might like to M-x report-emacs-bug and request exactly this
feature for "preserving window-specific point".  It can probably be
implemented in a *much* lighter way than by using indirect-buffers.

> Even as it stands, having the same content in two different modes seems
> very powerful;

It is very powerful, but as you've seen indirect-buffers only work to
some extent for that purpose and the problems you bump into are largely
unsolvable.  So it's not going in the right direction.

I think they really fit perfectly the definition of attractive-nuisance.


        Stefan

Re: indirect-buffers and text-properties

[Andreas Röhler]

Am 30.01.2014 14:27, schrieb Stefan Monnier:
>> So, question, anyone know why the text-properties get shared with
>> indirect-buffers and is it possible to stop?
>
> To change that, you'd have to change the underlying C code.
> Probably a non-trivial change.
>
> My recommendation: stay away from indirect-buffers.
> They are an attractive-nuisance.
>

It might be of interest how org-mode, resp. org-babel handles this.

M-x org-edit-src-code
uses an indirect buffer, but fontifies correctly.

Re: indirect-buffers and text-properties

[Nicolas Richard]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> M-x org-edit-src-code
> uses an indirect buffer, but fontifies correctly.

It is not an indirect buffer in my version, it uses generate-new-buffer.

-- 
Nico.

Re: indirect-buffers and text-properties

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Really? I've started using them because they enable me to have the point
>> in two places at once; for example, in the pre-amble and the body of a
> [...]
>> visible window). Indirect buffers seem to be a nice solution for this.
>
> That would be using a definition of "nice" very different from the one
> I'm familiar with ;-)
>
> BTW, you might like to M-x report-emacs-bug and request exactly this
> feature for "preserving window-specific point".  It can probably be
> implemented in a *much* lighter way than by using indirect-buffers.

I would, but I am not sure what the correct behavour is.

Consider:

  Window 1 (point at beg)
  ----
  Window 2 (point at end)

C-x 1

  Window 1 (point at beg)


C-x 2

  Window 1 (point at beg)
  ----
  Window 2 (point at beg)


If one of the two windows is indirect, at least point is preserved
somewhere, so I can get back to it.


>
>> Even as it stands, having the same content in two different modes seems
>> very powerful;
>
> It is very powerful, but as you've seen indirect-buffers only work to
> some extent for that purpose and the problems you bump into are largely
> unsolvable.  So it's not going in the right direction.
>
> I think they really fit perfectly the definition of attractive-nuisance.

Okay, I have to accept your word on this, but I can't see another
solution in my head. The best I have come up with is to hook into the
change-functions, and link two (otherwise independent buffers) together
so that the text in both is identical. AFAICT this is tractable, at
least if I only edit one of them. 

So, I'd have something like `make-indirect-view' which would open an
indirect buffer, in a new window, read-only, but in a different mode.
Then `swap-modes' which would take the major mode of the editable
buffer, and the uneditable buffer and swap the two. Finally, somelike
`sync-indirect-view' would display make the two display the same parts.

Seems like a reasonable amount of work to do, but could be usuable.

Phil

Re: indirect-buffers and text-properties

[Stefan Monnier]

>>> Really? I've started using them because they enable me to have the point
>>> in two places at once; for example, in the pre-amble and the body of a
>> [...]
>>> visible window). Indirect buffers seem to be a nice solution for this.
>> That would be using a definition of "nice" very different from the one
>> I'm familiar with ;-)
>> BTW, you might like to M-x report-emacs-bug and request exactly this
>> feature for "preserving window-specific point".  It can probably be
>> implemented in a *much* lighter way than by using indirect-buffers.
> I would, but I am not sure what the correct behavour is.
> Consider:
>   Window 1 (point at beg)
>   ----
>   Window 2 (point at end)
> C-x 1
>   Window 1 (point at beg)

> C-x 2
>   Window 1 (point at beg)
>   ----
>   Window 2 (point at beg)

> If one of the two windows is indirect, at least point is preserved
> somewhere, so I can get back to it.

We could stash the window-point to some buffer-local variable
buffer-other-points when the window is removed, and when the buffer is
displayed in a new window, we could check if buffer-other-points holds
other locations and reuse them.  And/or provide a new command to cycle
through those buffer-other-points.  And/or use the mark-ring instead of
buffer-other-points and just let the user use mark-ring navigation to
return to the previous position.

> Okay, I have to accept your word on this, but I can't see another
> solution in my head. The best I have come up with is to hook into the
> change-functions, and link two (otherwise independent buffers) together
> so that the text in both is identical.  AFAICT this is tractable, at
> least if I only edit one of them.

I tend to this the "multiple major-mode in a single buffer" option would
work better.

But in any case, there is no simple solution like "indirect-buffer".

Each of the major modes that participate in a mixed-mode buffer needs to
be written in a way that is aware of the fact that there can be other
modes on other parts of the buffer.


        Stefan

Re: indirect-buffers and text-properties

[Andreas Röhler]

Am 30.01.2014 16:36, schrieb Nicolas Richard:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>> M-x org-edit-src-code
>> uses an indirect buffer, but fontifies correctly.
>
> It is not an indirect buffer in my version, it uses generate-new-buffer.
>

Ah, thanks. When having a look into again, seems it's not used for languages,
while `org-tree-to-indirect-buffer' has it.

Re: indirect-buffers and text-properties

[Phillip Lord]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> Am 30.01.2014 16:36, schrieb Nicolas Richard:
>> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>> M-x org-edit-src-code
>>> uses an indirect buffer, but fontifies correctly.
>>
>> It is not an indirect buffer in my version, it uses generate-new-buffer.
>>
>
> Ah, thanks. When having a look into again, seems it's not used for languages,
> while `org-tree-to-indirect-buffer' has it.

It's also not quite what I want. With org-edit-src-code when you edit
the code, it pops up a buffer in the correct mode, then you edit but
only in this buffer -- the org mode buffer is unchanged, then it is
"commited" back to org.

I really want to see the two parts simultaneously, for the entire
buffer, but in two modes.

Phil

Re: indirect-buffers and text-properties

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I would, but I am not sure what the correct behavour is.
>> Consider:
>>   Window 1 (point at beg)
>>   ----
>>   Window 2 (point at end)
>> C-x 1
>>   Window 1 (point at beg)
>
>> C-x 2
>>   Window 1 (point at beg)
>>   ----
>>   Window 2 (point at beg)
>
>> If one of the two windows is indirect, at least point is preserved
>> somewhere, so I can get back to it.
>
> We could stash the window-point to some buffer-local variable
> buffer-other-points when the window is removed, and when the buffer is
> displayed in a new window, we could check if buffer-other-points holds
> other locations and reuse them.  And/or provide a new command to cycle
> through those buffer-other-points.  And/or use the mark-ring instead of
> buffer-other-points and just let the user use mark-ring navigation to
> return to the previous position.

I think the cycling might be the best way; so when a window disappears,
point is stored just before it goes. It would be rather like registers
but automatic. In fact, I do use registers for this, but find it works
poorly because I have to remember that I am going to want to go back to
something.

Having a buffer automatically do this when a new window is displayed
might be difficult; I think it would need an awful lot of DWIM
semantics, and I am not sure what these would be.


>> Okay, I have to accept your word on this, but I can't see another
>> solution in my head. The best I have come up with is to hook into the
>> change-functions, and link two (otherwise independent buffers) together
>> so that the text in both is identical.  AFAICT this is tractable, at
>> least if I only edit one of them.
>
> I tend to this the "multiple major-mode in a single buffer" option would
> work better.
>
> But in any case, there is no simple solution like "indirect-buffer".
>
> Each of the major modes that participate in a mixed-mode buffer needs to
> be written in a way that is aware of the fact that there can be other
> modes on other parts of the buffer.


Indeed. I shall look at these solutions before I go further; but
fiddling with major modes to make them work together is also a costly
exercise.

Phil

Re: indirect-buffers and text-properties

[Stefan Monnier]

> Having a buffer automatically do this when a new window is displayed
> might be difficult; I think it would need an awful lot of DWIM
> semantics, and I am not sure what these would be.

Stashing point when undisplaying a buffer can be done automatically
without harming anyone.  The DWIM semantics would only show up if/when
the user wants to use one of those stashed points.

> Indeed. I shall look at these solutions before I go further; but
> fiddling with major modes to make them work together is also
> a costly exercise.

I know, but that's what needs to happen: someone should take the
experience of mmm-mode, mumamo, and friends and come up with some set of
"rules" which major modes should follow so that these things can
work reliably.

Once that's done, it's only a matter of going around and adapting the
existing major modes to those rules, and providing some infrastructure
so that new major modes can follow those rules easily.


        Stefan

Re: indirect-buffers and text-properties

[Phillip Lord]

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

>> Having a buffer automatically do this when a new window is displayed
>> might be difficult; I think it would need an awful lot of DWIM
>> semantics, and I am not sure what these would be.
>
> Stashing point when undisplaying a buffer can be done automatically
> without harming anyone.  The DWIM semantics would only show up if/when
> the user wants to use one of those stashed points.
>
>> Indeed. I shall look at these solutions before I go further; but
>> fiddling with major modes to make them work together is also
>> a costly exercise.
>
> I know, but that's what needs to happen: someone should take the
> experience of mmm-mode, mumamo, and friends and come up with some set of
> "rules" which major modes should follow so that these things can
> work reliably.
>
> Once that's done, it's only a matter of going around and adapting the
> existing major modes to those rules, and providing some infrastructure
> so that new major modes can follow those rules easily.

I'd agree. I need to get a clear idea of how these modes work. I am not
even sure what "two modes in one buffer" looks like.

Phil