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/