Field implementation

Jerry James <[email protected]> Wed, 14 Jul 2004 16:24:44 -0500
Newsgroups gmane.emacs.xemacs.design
Message-ID <[email protected]>
I would like to submit my field implementation so I can get on with
syncing comint.el so that I can get my newer GDB interface one of these
days.  Some decisions need to be made about where to put various pieces,
though.

1) Where should field.el go?  I suggest the xemacs-base package,
   although that is not without its problems (see below).

2) Where should the texi for field.el go?  Currently the other stuff in
   the xemacs-base package is documented in core.  I can do that too,
   although that would require patches for both 21.4 and 21.5.

3) The stickiest point yet: field.el is not all there is.  We have to
   worry about what parts of Emacs are using fields.  In particular, the
   following Emacs C functions call constrain-to-field:

   forward-word
   line-beginning-position
   line-end-position

   The following Emacs Lisp functions call constrain-to-field:

   comint-line-beginning-position (how I got into this mess)
   delete-horizontal-space
   forward-paragraph
   forward-sentence
   just-one-space
   line-move-finish
   minibuffer-avoid-prompt

   The following Emacs C functions call one of the other field functions
   to create, delete, examine the contents of, or manipulate fields:

   minibuffer-prompt-end

   And likewise for the following Emacs Lisp functions:

   choose-completion-string
   comint-backward-matching-input
   comint-get-old-input-default
   comint-replace-by-expanded-history
   comint-show-output
   dabbrev--goto-start-of-abbrev
   isearch-complete-edit
   isearch-ring-advance-edit
   PC-do-completion
   widget-end-of-line

   Plus the widget stuff (wid-edit.el) has a bunch of wrappers around
   the field interface, and there may be yet other code that deals with
   the 'field property directly without calling any of these functions.
   How should we deal with this?  Some of these functions are in core
   for us, some are in dumped Lisp, some are in packages, some we don't
   have at all, ...  As far as the comint.el field usages go, it won't
   work unless we also change line-beginning-position (point-at-bol),
   line-end-position (point-at-eol), and forward-word, all builtin
   functions.  This would mean patches to 21.4 and 21.5, even though
   this is not a bug fix, and a dependency from core C functions on
   packaged Lisp code.  This also means that the new comint.el would
   have to be released *before* any release of 21.4 or 21.5 containing
   that dependency.

It might be simpler to dump field.el.  Opinions?
-- 
Jerry James
http://www.ittc.ku.edu/~james/