all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* eshell and after-change-functions
@ 2010-07-20 22:33 Jan Moringen
  2010-07-21 15:49 ` Stefan Monnier
  0 siblings, 1 reply; 3+ messages in thread
From: Jan Moringen @ 2010-07-20 22:33 UTC (permalink / raw
  To: emacs-devel

Hi,

while working on a new feature for Rudel (an environment for realtime
collaborative editing in Emacs, [1]), I encountered a problem that has
its root cause in some eshell code, which I can't understand. 

The feature in question is sharing interactive buffers like comint,
slime and, well, eshell with other users. The problem is that Rudel
relies on `after-change-functions' to monitor buffer changes and
propagate them to peers, but eshell let-binds this variable to nil in
`eshell-send-input' and `eshell-output-filter'. This prevents buffer
changes performed in these functions from being propagated and
de-synchronizes the session. I cannot find a specific reason for
disabling all after-change functions in the ehsell code and was
wondering if somebody knows why this is necessary. If it is not
necessary, could this maybe be changed?

Thanks in advance.

Kind regards,
Jan

[1] http://rudel.sourceforge.net




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: eshell and after-change-functions
  2010-07-20 22:33 eshell and after-change-functions Jan Moringen
@ 2010-07-21 15:49 ` Stefan Monnier
  2010-07-21 17:31   ` Jan Moringen
  0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2010-07-21 15:49 UTC (permalink / raw
  To: Jan Moringen; +Cc: John Wiegley, emacs-devel

> The feature in question is sharing interactive buffers like comint,
> slime and, well, eshell with other users. The problem is that Rudel
> relies on `after-change-functions' to monitor buffer changes and
> propagate them to peers, but eshell let-binds this variable to nil in
> `eshell-send-input' and `eshell-output-filter'. This prevents buffer
> changes performed in these functions from being propagated and
> de-synchronizes the session. I cannot find a specific reason for
> disabling all after-change functions in the ehsell code and was
> wondering if somebody knows why this is necessary. If it is not
> necessary, could this maybe be changed?

Have you tried to remove the offending let-binding and see what effect
it has on Eshell's behavior?
The commit logs don't give any help about the reason for these bindings,
and looking at the code I can't figure it out myself either, so unless
John remembers why they were added, we'll be forced to just "try and
pray".


        Stefan



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: eshell and after-change-functions
  2010-07-21 15:49 ` Stefan Monnier
@ 2010-07-21 17:31   ` Jan Moringen
  0 siblings, 0 replies; 3+ messages in thread
From: Jan Moringen @ 2010-07-21 17:31 UTC (permalink / raw
  To: Stefan Monnier; +Cc: John Wiegley, emacs-devel

Hi Stefan.

> > The feature in question is sharing interactive buffers like comint,
> > slime and, well, eshell with other users. The problem is that Rudel
> > relies on `after-change-functions' to monitor buffer changes and
> > propagate them to peers, but eshell let-binds this variable to nil in
> > `eshell-send-input' and `eshell-output-filter'. This prevents buffer
> > changes performed in these functions from being propagated and
> > de-synchronizes the session. I cannot find a specific reason for
> > disabling all after-change functions in the ehsell code and was
> > wondering if somebody knows why this is necessary. If it is not
> > necessary, could this maybe be changed?
> 
> Have you tried to remove the offending let-binding and see what effect
> it has on Eshell's behavior?

Removing the let-binding solves the problem for Rudel. A brief test did
not reveal any problems with eshell either, but a more experienced
developer should be the judge of that.

> The commit logs don't give any help about the reason for these bindings,
> and looking at the code I can't figure it out myself either, so unless
> John remembers why they were added, we'll be forced to just "try and
> pray".

Thanks. This would be very hard or even impossible to work around by
sensible means.

Jan




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-07-21 17:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-20 22:33 eshell and after-change-functions Jan Moringen
2010-07-21 15:49 ` Stefan Monnier
2010-07-21 17:31   ` Jan Moringen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.