Text fields

[Jerry James]

"Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>>>>>> "Jerry" == Jerry James <james at xemacs.org> writes:
>
>     Jerry> The cause is that make-frame on an x-device makes a bunch
>     Jerry> of calls to create the menu items.  Deep in that code is a
>     Jerry> call to forward-word, which now calls contrain-to-field.
>
> I guess one real solution is to fix it so that the menu items don't
> get created until after initialization leaves that critical section.
> We could also arrange that informative messages get queued until just
> before we enter the top-level loop, at which point we either have a
> frame to princ to, or know that we aren't going to bet one any time
> soon.
>
> Workarounds: I guess you could wrap that make-frame code with a check
> for an autoload definition and if so defun constrain-to-field to do
> nothing, then fmakunbound?  But you'll probably run into something else.
>
> Another possible temporary workaround would be to use
>
> ;;;###autoload(defun constrain-to-field (&rest args) (load "field") \
> (apply #'constrain-to-field args))
>
> (defun constrain-to-field (...) ...)
>
> in field.el, but that's really horrible, fixing the unbroken code.

It's probably no surprise that I don't really like any of those
solutions.  I suspect you don't either.

> How useful is field.el without making the basic functions aware of
> fields?  If it's "not very", maybe we should just put it into core and
> tell 21.4 users they lose on this feature.

That would be the cleanest way to go.  We need to think about this
carefully before jumping, though.  The field implementation was written
to support an upcoming comint.el synch, which I am working on in order
to get GUD working, so that I can port the newest GDB support stuff.
Just how much does the field interface get exercised by all this stuff?
There's the problem: I don't really know.  I may wind up with wonderful
GDB support for the latest 21.5 and broken GDB support for all earlier
versions.

Let me do a few experiments and report back.  If the field stuff turns
out to be optional for the GUD/GDB stuff I want do to, then I'll vote
for moving field.el into core.
-- 
Jerry James
http://www.ittc.ku.edu/~james/