From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dima Kogan Newsgroups: gmane.emacs.bugs Subject: bug#20498: 25.0.50; PATCH: break potential infinite loop in (line-move-to-column) Date: Tue, 05 May 2015 01:29:14 -0700 Message-ID: <87383b5s9z.fsf@secretsauce.net> References: <87k2wp8nji.fsf@secretsauce.net> <834mnsto2o.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430815347 32475 80.91.229.3 (5 May 2015 08:42:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 May 2015 08:42:27 +0000 (UTC) Cc: 20498@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 05 10:42:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YpYQe-00005z-LW for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 May 2015 10:42:12 +0200 Original-Received: from localhost ([::1]:37515 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpYQd-0007Pc-7o for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 May 2015 04:42:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpYQa-0007PU-8a for bug-gnu-emacs@gnu.org; Tue, 05 May 2015 04:42:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpYQU-00039M-JX for bug-gnu-emacs@gnu.org; Tue, 05 May 2015 04:42:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52580) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpYQU-00039B-Fy for bug-gnu-emacs@gnu.org; Tue, 05 May 2015 04:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YpYQT-0000uS-Vh for bug-gnu-emacs@gnu.org; Tue, 05 May 2015 04:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dima Kogan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 May 2015 08:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20498 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20498-submit@debbugs.gnu.org id=B20498.14308153043441 (code B ref 20498); Tue, 05 May 2015 08:42:01 +0000 Original-Received: (at 20498) by debbugs.gnu.org; 5 May 2015 08:41:44 +0000 Original-Received: from localhost ([127.0.0.1]:34322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpYQB-0000tO-90 for submit@debbugs.gnu.org; Tue, 05 May 2015 04:41:43 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:56222) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpYQ8-0000tB-F7 for 20498@debbugs.gnu.org; Tue, 05 May 2015 04:41:41 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D825D20A78 for <20498@debbugs.gnu.org>; Tue, 5 May 2015 04:41:39 -0400 (EDT) Original-Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 05 May 2015 04:41:39 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=secretsauce.net; h=cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=dJYXN cxPgYD8Lb2Bwmuojhvua4Q=; b=g2lDx4sz77xtqk4qIDnBXLZW5zhzlQmJLf8sy fTIGj5Mf+xfQjCtY4/BlzB7k/bempRTNahb55hP99sXAuhbWhoYCoPeL5WhDceTq YD2OGkBy2Ga+BtJ0pWt1Gek02udT1vqGHvCOrBFgUwf5/ubI8GDIxGEyW9QgbrFS RHY8B4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=dJYXNcxPgYD8Lb2Bwmuojhvua4Q=; b=em1nP TuMDYh+/2u1h1WYOzYcdlKNbbGRq2Je83WeoKgBiLsmyCiBaryLE25YJ9Ci1NGkG zQZjH46JJ7GF7gP76XOjpmL1EOuY+t41gKuKMtwk4GYZ/CGdiD4snxIKrHHLnIUz /PF29mmXMls8ODlc2WKiK03+nrCV0pgvnOXRn4= X-Sasl-enc: eA74WKtHn2bMU132/VtmgY+Cu05ZywQfvlc/x+LPGq09 1430815299 Original-Received: from shorty.local (unknown [104.35.103.243]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F917C0001A; Tue, 5 May 2015 04:41:39 -0400 (EDT) Original-Received: from ip6-localhost ([::1] helo=shorty) by shorty.local with esmtp (Exim 4.84) (envelope-from ) id 1YpYRU-0002kt-5J; Tue, 05 May 2015 01:43:04 -0700 In-reply-to: <834mnsto2o.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:102494 Archived-At: Eli Zaretskii writes: >> From: Dima Kogan >> Date: Sun, 03 May 2015 12:32:33 -0700 >> >> (line-move-to-column) has a loop that can become infinite: >> >> (while (and ...) >> (goto-char (previous-char-property-change (point) line-beg))) >> >> If (= (point) line-beg) then the (goto-char) does nothing, and the >> condition in the while never changes. > > The full fragment is this: > > (let ((line-beg (line-beginning-position))) > (while (and (not (bolp)) (invisible-p (1- (point)))) > (goto-char (previous-char-property-change (point) line-beg)))))))) > > So if (= (point) line-beg), then 'bolp' will return t, and we will > break from the loop. Am I missing something? > >> I'm seeing this in the wild with ERC and erc-fill-mode disabled. > > Can you dig deeper into the problem, and tell the details about this > infloop? 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. (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.