help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: indirect-buffers and text-properties


From: Phillip Lord
Subject: Re: indirect-buffers and text-properties
Date: Fri, 31 Jan 2014 09:52:09 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]