[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20498: 25.0.50; PATCH: break potential infinite loop in (line-move-t
From: |
Eli Zaretskii |
Subject: |
bug#20498: 25.0.50; PATCH: break potential infinite loop in (line-move-to-column) |
Date: |
Sat, 09 May 2015 16:08:32 +0300 |
> From: Dima Kogan <dima@secretsauce.net>
> Cc: 20498@debbugs.gnu.org
> Date: Tue, 05 May 2015 01:29:14 -0700
>
> Hi. Thank you very much for double-checking. It indeed looks like (bolp)
> should cover this case. It doesn't however. When ERC misbehaves in this
> way I observe both
>
> (= (line-beginning-position) (point)) --> t
> (bolp) --> nil
>
> This sounds wrong. Looking at the buffer with my eyes, the point is not
> at the beginning of the line, so it LOOKS like the (bolp) result is
> correct.
>
> The docs for (line-beginning-position) state that this function respects
> field boundaries. If I ignore those explicitly then I see the correct
> behavior:
>
> (let ((inhibit-field-text-motion t))
> (line-beginning-position)) ---> correct start of line
>
> So the correct patch would replace (line-beginning-position) to the
> above expression. This is trivial, and I'm not actually attaching a
> patch. If you want me to, tell me.
Thanks, I pushed such a change.
> (line-beginning-position) is used in quite a few places in emacs, and
> I'm wondering if in many of those uses the intent is to ignore fields.
I don't know, but I guess they will discover this in due time.