Re: narrow-to-region for a rectangle

[C K Kashyap <ckkashyap@gmail.com>]

Thanks for the pointer Jambunathan.
Yeah, I guess this horse has been more than beaten to death :)
Regards,
Kashyap


On Wed, Jun 5, 2013 at 12:20 PM, Jambunathan K <kjambunathan@gmail.com>wrote:

> C K Kashyap <ckkashyap@gmail.com> writes:
>
> > This is what I've come up with. I'd really appreciate some feedback.
>
> Others have provided feedback and they are all good.  If it gets the job
> done, you should bother (yourself and others) no more.
>
> If one is interested in working with rectangles - edit text (with
> filling, justification, what not), narrow it (and have regexp matchers
> ^, $ do the expected) then one can look at table.el and extract portions
> of it to the Emacs "core".
>
> Remember, rectangle is but a table cell (possibly with no "geometric
> rectangle" surrounding it.)
>
> ,---- From commentary section of table.el
> |
> | ;; The most difficult part of dealing with table editing in Emacs
> | ;; probably is how to realize localized rectangular editing effect.
> | ;; Emacs has no rectangular narrowing mechanism.  Existing rect package
> | ;; provides basically kill, delete and yank operations of a rectangle,
> | ;; which internally is a mere list of strings.
> |
> | ;; A simple approach for realizing the localized virtual rectangular
> | ;; operation is combining rect package capability with a temporary
> | ;; buffer.  Insertion and deletion of a character to a table cell can be
> | ;; trapped by a function that copies the cell rectangle to a temporary
> | ;; buffer then apply the insertion/deletion to the temporary contents.
> | ;; Then it formats the contents by filling the paragraphs in order to
> | ;; fit it into the original rectangular area and finally copy it back to
> | ;; the original buffer.
> |
> | ;; This simplistic approach has to bear with significant performance
> | ;; hit. As cell grows larger the copying rectangle back and forth
> | ;; between the original buffer and the temporary buffer becomes
> | ;; expensive and unbearably slow.  It was completely impractical and an
> | ;; obvious failure.
> |
> | ;; An idea has been borrowed from the original Emacs design to overcome
> | ;; this shortcoming.  When the terminal screen update was slow and
> | ;; expensive Emacs employed a clever algorithm to reduce actual screen
> | ;; update by removing redundant redrawing operations.  Also the actual
> | ;; redrawing was done only when there was enough idling time.  This
> | ;; technique significantly improved the previously mentioned undesirable
> | ;; situation.  Now the original buffer's rectangle is copied into a
> | ;; cache buffer only once.  Any cell editing operation is done only to
> | ;; the cache contents.  When there is enough idling time the original
> | ;; buffer's rectangle is updated with the current cache contents.  This
> | ;; delayed operation is implemented by using Emacs's timer function.  To
> | ;; reduce the visual awkwardness introduced by the delayed effect the
> | ;; cursor location is updated in real-time as a user types while the
> | ;; cell contents remains the same until the next idling time.  A key to
> | ;; the success of this approach is how to maintain cache coherency.  As
> | ;; a user moves point in and out of a cell the table buffer contents and
> | ;; the cache buffer contents must be synchronized without a mistake.  By
> | ;; observing user action carefully this is possible however not easy.
> | ;; Once this mechanism is firmly implemented the rest of table features
> | ;; grew in relatively painless progression.
> |
> | ;; Those users who are familiar with Emacs internals appreciate this
> | ;; table package more.  Because it demonstrates how extensible Emacs is
> | ;; by showing something that appears like a magic.  It lets you
> | ;; re-discover the potential of Emacs.
> |
> `----
>