Re: table.el

[Tak Ota]

Mon, 3 Dec 2001 01:46:56 -0700 (MST): Richard Stallman <address@hidden> wrote:

> It seems that the wrapper mechanism has a lot of advantages
> over using advice.  I knew it had some advantages, but you
> have discovered others.
> 
> But there is still the question of whether table.el needs either of
> the two mechanisms, or whether some other existing mechanism will
> do the job.

I spent sometime rethinking about this.  What the current table advice
does to those original commands (functions) is to set up a special
environment (set buffer to a cell cache buffer, etc.) then to let the
original function (unmodified) do its work and finally to clean up
(filling paragraph, restore current buffer, etc.)

Possible choice of implementation for this is:

1. advising each function
2. adding run-hooks at the beginning and end of each function
3. adding a wrapper to each function

1 is already implemented as self contained manner in table.el.  2 is
doable but really not elegant.  3 is equivalent to 2 but is cleaner.

>       Otherwise, the current buffer is temporarily switched to
>     the cell cache buffer and the beg and end are translated from the
>     original buffer's locations to the cache buffer's corresponding
>     locations.  Then the original `kill-region' is invoked in the cache
>     buffer.
> 
> Could you get the same job by running kill-region in the user's
> buffer, seeing what part was killed, and then operating similarly on
> the cache buffer?  Maybe you could do this with
> after-change-functions.

It is difficult.  `kill-region' was just an example.  For another
example, `forward-word' does not leave a trace of its execution in
terms of change of the buffer contents.

>       When it is done the pre-processing kicks in and the content
>     of the cache buffer is reformatted by filling paragraphs and the
>     current buffer is restored.
> 
> What mechanism do you use to invoke this pre-processing?

advice is the mechanism.

>       At the end a timer is set so that the new
>     cache content is reflected to the original buffer eventually.
> 
> I am not sure I understand this.  Do you mean that the timer copies
> updated data from the cache into the user's buffer?

That is correct.

> If so, it does not sound good to let that happen on a timer.  Would it
> be better to do that in the after-change-functions?  Or in
> post-command-hook?  Using post-command-hook would be much like using a
> timer except that there would be no delay.

Timer method was chosen intentionally in order to introduce some short
delay.  As long as the cache contents is modified continuously the
timer is repetitively canceled and reset before the previous one
expires.  This consolidates several cache changes in vicinity in time
with a single update operation.  It is important to provide adequate
responsiveness especially when the size of table cell grows large.
The copy operation between cache buffer and user buffer becomes quite
expensive.  Without this consolidation mechanism by using timer it was
unbearably slow at least on my PII 366 machine.

-Tak