From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: npostavs@users.sourceforge.net Newsgroups: gmane.emacs.bugs Subject: bug#24633: highlight-region func using (window-hscroll) in :align-to spec can cause inf loop Date: Sat, 22 Oct 2016 15:27:42 -0400 Message-ID: <87y41grxox.fsf@users.sourceforge.net> References: <87vax5vuoj.fsf@users.sourceforge.net> <834m4nhz1t.fsf@gnu.org> <874m4mwyj2.fsf@users.sourceforge.net> <837f9ihg8l.fsf@gnu.org> <87y41yved9.fsf@users.sourceforge.net> <83y41yfwam.fsf@gnu.org> <87lgxxvh6o.fsf@users.sourceforge.net> <83h98lg0cn.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477164508 8105 195.159.176.226 (22 Oct 2016 19:28:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 22 Oct 2016 19:28:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: 24633@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 22 21:28:24 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1by1xi-0008QB-MD for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Oct 2016 21:28:10 +0200 Original-Received: from localhost ([::1]:38455 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1by1xl-0001Id-2h for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Oct 2016 15:28:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1by1xe-0001IY-PB for bug-gnu-emacs@gnu.org; Sat, 22 Oct 2016 15:28:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1by1xa-00065S-Py for bug-gnu-emacs@gnu.org; Sat, 22 Oct 2016 15:28:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59436) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1by1xa-00065L-LQ for bug-gnu-emacs@gnu.org; Sat, 22 Oct 2016 15:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1by1xa-0006AH-AC for bug-gnu-emacs@gnu.org; Sat, 22 Oct 2016 15:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Oct 2016 19:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24633 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24633-submit@debbugs.gnu.org id=B24633.147716443323643 (code B ref 24633); Sat, 22 Oct 2016 19:28:02 +0000 Original-Received: (at 24633) by debbugs.gnu.org; 22 Oct 2016 19:27:13 +0000 Original-Received: from localhost ([127.0.0.1]:46602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1by1wm-00069F-QE for submit@debbugs.gnu.org; Sat, 22 Oct 2016 15:27:13 -0400 Original-Received: from mail-it0-f53.google.com ([209.85.214.53]:36665) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1by1wk-000690-M6 for 24633@debbugs.gnu.org; Sat, 22 Oct 2016 15:27:11 -0400 Original-Received: by mail-it0-f53.google.com with SMTP id e187so66064969itc.1 for <24633@debbugs.gnu.org>; Sat, 22 Oct 2016 12:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=3hWA0wC6ge1aXyB0z2mGXZLbZ3X76JsEuCpbYOOFTec=; b=czDPBxIX0wg2rbXkobueMtVQKdNUFQ+NDbLMJgiVynq1yFKZjMahQpRwy1y5NsBmoc 9jMtas5HO8YZDtShvzpPkDQk1s3Yi6DAjAK4YzrE/lNXoVSXp76UluIlDx/7gSRy+KCp E0zb0TK7y9A7/xfAlKcX1ccUv38wWGQqRCdk0NkpEVuX2sechLG3HPS3ICBiepYZGywS aMYZp88qiUjUPvkkFnmPL+TZ3rEC6cVrf4MDZEXcQlyJLHmA99sb0vIAmvf7KvcxIlTx WHMWdSDcg7dAJpm2dMUi7cA7KRtT0gB993k/8h6WY8r8v/6TkLeCbLKAGDWZK/YYKsiV cSTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=3hWA0wC6ge1aXyB0z2mGXZLbZ3X76JsEuCpbYOOFTec=; b=Zl1X31OYtV+Bqf5Zaq26WVHHw/CBlFRAnfwY572uVNXSzaES9CbJam1MJfbo9i2LqL 6U1LW5xONrkz6DeV7LnvY4QZnCmVBr1ZLIMbrB5x/t/9bPUo9oZOESetLazq2pM7ZHN2 NF6kWZGgphUSe9P6DKsy7nP1oedNwo2MZxDYK9M0iotHS+L5tk6tY6txfTaUZvPDbMFG i80I7YiBeVPXIQBGRP4OrMajCHWXfTEyddJc+6LnY2cVj8zESMwlc5OrbGO7DHgsQDV7 X3MjQOaxVzpfaN0cyqLhNi/Odcq/qIQbiVm+/bv6YDbq7XZ0AoQpse56GxrfGVVEsgcB uzIQ== X-Gm-Message-State: ABUngvebxRwmvIP2XdK9tYyqr7Td5Gd91te08L4mdBvpKJF7vS6NM1/747OXkMxR4A+LfQ== X-Received: by 10.36.74.143 with SMTP id k137mr4554876itb.107.1477164425003; Sat, 22 Oct 2016 12:27:05 -0700 (PDT) Original-Received: from zony ([45.2.7.130]) by smtp.googlemail.com with ESMTPSA id 141sm1656753itu.15.2016.10.22.12.27.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 22 Oct 2016 12:27:04 -0700 (PDT) In-Reply-To: <83h98lg0cn.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Oct 2016 15:42:32 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:124850 Archived-At: Eli Zaretskii writes: >> From: npostavs@users.sourceforge.net >> Cc: 24633@debbugs.gnu.org >> Date: Sun, 09 Oct 2016 08:29:51 -0400 >> >> Anyway, it doesn't seem worth going through this complexity. I just >> wonder if there is some way to stop bad lisp code from triggering a hard >> lockup. Can the display engine notice if it's looping and throw some >> kind of error? Maybe unset pre-redisplay-functions? > > I don't see how we could detect loops in general. But for the > particular case of infinite hscrolling, we could perhaps count the > number of times hscroll_windows was called and returned a non-zero > value, and forcibly stop the loop after some reasonable number of > iterations. I tried adding a counter in redisplay_internal, it prevents having a tight loop in C. Actually, the behaviour becomes like the split window case: there is additional hscrolling each time the cursor blinks, but it can be interrupted with C-g. That seems adequate behaviour to me, what do you think? diff --git c/src/xdisp.c i/src/xdisp.c index ba6518b..3bf3fd8 100644 --- c/src/xdisp.c +++ i/src/xdisp.c @@ -13528,6 +13528,9 @@ redisplay_internal (void) bool polling_stopped_here = false; Lisp_Object tail, frame; + enum { MAX_HSCROLL_RETRIES = 16 }; + int hscroll_retries = 0; + /* True means redisplay has to consider all windows on all frames. False, only selected_window is considered. */ bool consider_all_windows_p; @@ -14044,8 +14047,12 @@ redisplay_internal (void) if (!f->already_hscrolled_p) { f->already_hscrolled_p = true; - if (hscroll_windows (f->root_window)) - goto retry_frame; + if (hscroll_retries <= MAX_HSCROLL_RETRIES + && hscroll_windows (f->root_window)) + { + hscroll_retries++; + goto retry_frame; + } } /* If the frame's redisplay flag was not set before @@ -14143,8 +14150,12 @@ redisplay_internal (void) if (FRAME_VISIBLE_P (sf) && !FRAME_OBSCURED_P (sf)) { - if (hscroll_windows (selected_window)) - goto retry; + if (hscroll_retries <= MAX_HSCROLL_RETRIES + && hscroll_windows (selected_window)) + { + hscroll_retries++; + goto retry; + } XWINDOW (selected_window)->must_be_updated_p = true; pending = update_frame (sf, false, false); @@ -14164,8 +14175,12 @@ redisplay_internal (void) XWINDOW (mini_window)->must_be_updated_p = true; pending |= update_frame (mini_frame, false, false); mini_frame->cursor_type_changed = false; - if (!pending && hscroll_windows (mini_window)) - goto retry; + if (!pending && hscroll_retries <= MAX_HSCROLL_RETRIES + && hscroll_windows (mini_window)) + { + hscroll_retries++; + goto retry; + } } } >> >> >> According to `(elisp) Pixel Specification', >> >> >> >> >> >> The form NUM specifies a fraction of the default frame font height >> >> >> or width. The form `(NUM)' specifies an absolute number of pixels. >> >> > >> >> > I admire your courage in reading that documentation and then writing >> >> > stuff like the above, which the documentation doesn't mention even >> >> > remotely. >> >> >> >> Uh, not sure how to read this, is it irony? >> > >> > Only a little. I find this area severely under-documented. >> >> The grammar in the doc seems complete to me. > > Do you really think that a formal grammar, whether accurate/complete > or not, is a good way of describing a feature? The formal grammar plus the informal description of what the parts mean seems a perfectly fine description for _this_ feature.