How to explain this strange comint behavior?

Question

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?

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).