emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug in ielm: patch. Related problem with end-of-line.


From: Luc Teirlinck
Subject: bug in ielm: patch. Related problem with end-of-line.
Date: Sun, 22 Sep 2002 21:44:30 -0500 (CDT)

C-c RETURN in ielm on the first input line copies the old prompt to
the current input instead of the old input.  This is related to some
strange subtleties with end-of-line.  The patch below fixes the ielm
bug.  It does so by treating the ielm header as output.  I believe
this makes sense anyway and is consistent with what M-x run-lisp does.

However, the patch fixes one symptom of a more general problem with
end-of-line (as well as maybe with some of its friends), without
really solving the more general problem itself.

The output of C-h v end-of-line contains the following line:

if N is nil or 1, and point starts at a field boundary, point does not
move.

This is not quite accurate: there is an exception.  Point does not
move *unless* the previous character has a non-nil rear-nonsticky
text-property *and* a text-property field eq to boundary.  Then point
*does* move over the field.  Comint and its derived modes rely heavily
on this exception.

The problem with ielm was that ielm-get-old-input uses
comint-skip-prompt which uses end-of-line at the beginning of a
prompt.  At the second and later prompts, comint-skip-prompt indeed
skips over the prompt, because point is not at a field boundary if
there is preceding output, and because of the above mentionned
exception, if the output was flushed.  However, because the current
ielm header has no text properties, the beginning of the first prompt
is at an "unexceptional" field boundary and point remains "frozen",
leading to the bug.  My patch treats the header as output.  Now the
first prompt is no longer at a field boundary and the bug is gone.

Not all problems are gone, however.  The ielm-type patch can be applied
to any comint-buffer with a header.  Some, like M-x run-lisp, already
treat the header as output.  The one remaining problem occurs at the
beginning of the buffer, header or no header.

In comint buffers with headers, treated as output, there now is the
problem that C-e at the beginning of the buffer stays put instead of
moving to the end of the line.  This is less serious than copying an
old (read-only) prompt into the current input, but is still annoying.
(For ordinary output, the exceptional text-property combination
assures proper C-e functionning, even at the beginning of the output.)

For *shell* buffers the problem is worse.  They start with a prompt.
One, in its own right not too serious, but still confusing, problem is
inconsistent C-e behavior.  Go to a shell buffer, with at least two
prompts.  Do C-e at the first prompt.  Point stays put.  However, at
all other prompts, C-e moves over the prompt to the input field.

Much more serious than this are the potential related problems with
end-of-line called from programs.  Although I currently know of no
concrete bugs resulting from the situation, other than the
inconsistent C-e behavior, the danger for future (or undiscovered
present) bugs is very great.  Indeed, any calling of end-of-line, with
inhibit-field-text-motion eq to nil, at the beginning of a prompt in a
*shell*-type buffer, without checking whether the prompt is the first
prompt or not, is a bug: either it expects point to move over the
prompt and then it malfunctions when called at the first prompt, or it
expects point to stay put and then it malfunctions at all other
prompts.

One solution would be a special text-property at the beginning of the
buffer, determining whether the beginning of the buffer should be
treated as a field boundary (for purposes of C-e and friends) or
not. That would solve all above small actual (C-e at the beginning of
a comint buffer) and potential larger problems.  I do not know how
easy or difficult this would be to implement.  Another solution would
be not to introduce any new text properties, but to allow
text-properties "at position 0", which of course would only be
relevant for inheritance and problems of the above type.  Maybe the
problem can be solved in an easier way.

On a related note, finding documentation for text properties seems to
be quite non-trivial.  My patch uses a text property
inhibit-line-move-field-capture.  I am sure it must be used, because
it is used for all comint output fields, but I was unable to find any
information about that property in the C-h n output or in the latest
CVS Elisp manual, or in the documentation strings of several
field-motion related functions, or anywhere else.  Where can I find
some documentation about this text property?

Next, change log and patch:

Change log:

2002-09-22  Luc Teirlinck  <address@hidden>

       * ielm.el (inferior-emacs-lisp-mode): Treat the header as output.

Patch:


===File ~/ielm-diff=========================================
cd /usr/local/share/emacs/21.3.50/lisp/
diff -c /usr/local/share/emacs/21.3.50/lisp/ielmold.el 
/usr/local/share/emacs/21.3.50/lisp/ielm.el
*** /usr/local/share/emacs/21.3.50/lisp/ielmold.el      Thu Sep 19 10:35:10 2002
--- /usr/local/share/emacs/21.3.50/lisp/ielm.el Sun Sep 22 18:02:21 2002
***************
*** 510,515 ****
--- 510,518 ----
      ;; Add a silly header
      (insert ielm-header)
      (ielm-set-pm (point-max))
+     (add-text-properties
+      1 (point-max)
+      '(rear-nonsticky t field output inhibit-line-move-field-capture t))
      (comint-output-filter (ielm-process) ielm-prompt)
      (set-marker comint-last-input-start (ielm-pm))
      (set-process-filter (get-buffer-process (current-buffer)) 
'comint-output-filter))

Diff finished at Sun Sep 22 19:05:41
============================================================




reply via email to

[Prev in Thread] Current Thread [Next in Thread]