I have the following issue with comint, it could be a bug. It holds true in different derived modes, such as python or gdb. How to see the strange behavior:

  1. run-python
  2. Enter some stuff: M-20 a, don't press RET
  3. Eval (- (line-end-position) (line-beginning-position)). It returns 20, which is correct.
  4. Move point before >>>. C-a won't work, do C-p C-a C-n instead.
  5. Eval (- (line-end-position) (line-beginning-position)). It returns 4, which is wrong.

Could someone explain this behavior? And if it's not a bug, what's the work-around to get 20 instead of 4?

1 Answer 1


Could someone explain this behavior?

The documentation of line-end-position has a note at the end that explains this behavior:

This function constrains the returned position to the current field unless that would be on a different line than the original, unconstrained result. If N is nil or 1, and a rear-sticky field ends at point, the scan stops as soon as it starts. To ignore field boundaries bind inhibit-field-text-motion to t.

Same for line-beginning-position.

So, in your example

(let ((inhibit-field-text-motion t)) (- (line-end-position) (line-beginning-position)))

consistently evaluates to 24 at any position on that line (4 characters of the prompt and 20 as).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.