emacs-devel
[Top][All Lists]
Advanced

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

Re: table.el


From: Tak Ota
Subject: Re: table.el
Date: Sun, 25 Nov 2001 20:46:43 -0800 (PST)

From: Richard Stallman <address@hidden>
Date: Sun, 25 Nov 2001 17:28:01 -0700 (MST)
Subject: Re: table.el

> Instead of using advice, it would be better for us to add
> code to the actual functions delete-region... so that in
> table mode it can do the right thing.
> 
> This is cleaner because people looking at the definition of
> delete-region etc., trying to see what it does, will come across
> a conditional saying "if table-mode then...", and they will realize
> that something special is happening.
> 
> Otherwise, they will be likely to go on debugging based on the source
> code, not realizing that the function has advice.  They could spend an
> hour being puzzled by this.

I wonder if you could read it from the commentary section touching
upon the advice use in table.el, I was really hesitated letting people
use that.

> Do you want to make changes to those 12 functions for table mode?

I'd love to.  While I was writing table.el changing existing elisp
code or needless to say modifying emacs source was not in my mind at
all.

> This code does not have to be special-purpose and limited to table
> mode.  For instance, you could make hook variables for those functions
> to call.  Then table.el could set the hook variables to suitable
> functions.  This might be useful for some other features as well as
> table.el.

Let me have some time to come up with a proposal for the generic
extension to those functions.

After these changes I'll keep the old advice only for the sake of
backward compatibility.

> A few weeks ago, someone proposed on this list a feature for
> discontinuous regions.  That was intended, I think, for the sake of
> rectangles, but maybe table.el could use it too.  If that works out,
> it could be the cleanest and most general solution.

That would be the ultimate foundation for the table handling.  I
consider that feature revolutionary.  However, from the experience of
writing this table script I think it won't be as easy as it first
appears.  For example, when new characters are inserted in the
rectangle region how should the rectangle grow?  The existing linear
region has no choice but to grow in one dimension.  The new system
somehow must make reasonable decision to grow in which dimension.
Writing table.el has been a continuous process of reconciling on each
encountering odd case.

-Tak



reply via email to

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