Re: table.el

05 Jan 2003 15:11:58 +0200: Ville Skyttä <scop(a)xemacs.org&gt; wrote: I now exactly understand what the problem is. However, it is an expected problem. This behavior is not specific to XEmacs but also to Emacs. The problem is that current table.el expects correct table structure while what you did actually by typing "foobar" into the table border broke the table structure. It is possible to make the code more robust for this particular case in ad hoc fashion but error handling in general to cope with broken table is difficult. A section in the emacs lisp info explains this better than I did above. Following is that page. -Tak File: elisp, Node: Not Intervals, Prev: Fields, Up: Text Properties Why Text Properties are not Intervals ------------------------------------- Some editors that support adding attributes to text in the buffer do so by letting the user specify "intervals" within the text, and adding the properties to the intervals. Those editors permit the user or the programmer to determine where individual intervals start and end. We deliberately provided a different sort of interface in Emacs Lisp to avoid certain paradoxical behavior associated with text modification. If the actual subdivision into intervals is meaningful, that means you can distinguish between a buffer that is just one interval with a certain property, and a buffer containing the same text subdivided into two intervals, both of which have that property. Suppose you take the buffer with just one interval and kill part of the text. The text remaining in the buffer is one interval, and the copy in the kill ring (and the undo list) becomes a separate interval. Then if you yank back the killed text, you get two intervals with the same properties. Thus, editing does not preserve the distinction between one interval and two. Suppose we "fix" this problem by coalescing the two intervals when the text is inserted. That works fine if the buffer originally was a single interval. But suppose instead that we have two adjacent intervals with the same properties, and we kill the text of one interval and yank it back. The same interval-coalescence feature that rescues the other case causes trouble in this one: after yanking, we have just one interval. One again, editing does not preserve the distinction between one interval and two. Insertion of text at the border between intervals also raises questions that have no satisfactory answer. However, it is easy to arrange for editing to behave consistently for questions of the form, "What are the properties of this character?" So we have decided these are the only questions that make sense; we have not implemented asking questions about where intervals start or end. In practice, you can usually use the text property search functions in place of explicit interval boundaries. You can think of them as finding the boundaries of intervals, assuming that intervals are always coalesced whenever possible. See *Note Property Search::. Emacs also provides explicit intervals as a presentation feature; see *Note Overlays::.