From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Aug 2013 18:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 15045@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.137589836217876 (code B ref -1); Wed, 07 Aug 2013 18:00:02 +0000 Received: (at submit) by debbugs.gnu.org; 7 Aug 2013 17:59:22 +0000 Received: from localhost ([127.0.0.1]:45995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7813-0004eF-Gc for submit@debbugs.gnu.org; Wed, 07 Aug 2013 13:59:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34749) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7811-0004dy-0O for submit@debbugs.gnu.org; Wed, 07 Aug 2013 13:59:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V780t-0001Wz-Km for submit@debbugs.gnu.org; Wed, 07 Aug 2013 13:59:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-99.2 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID,USER_IN_WHITELIST autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V780t-0001Wi-Ha for submit@debbugs.gnu.org; Wed, 07 Aug 2013 13:59:11 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V780q-0003TD-P9 for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2013 13:59:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V780m-0001Lp-Ud for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2013 13:59:08 -0400 Received: from mail-ob0-x244.google.com ([2607:f8b0:4003:c01::244]:47598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V780m-0001Lb-NH for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2013 13:59:04 -0400 Received: by mail-ob0-f196.google.com with SMTP id wc20so790642obb.7 for ; Wed, 07 Aug 2013 10:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bvt43c+9kCsdS/Qca7hPUaCJ3RxVqKuHHcQ+CPdS4T0=; b=ZINr0HfTF24/ZIqAGC1UwbpFwF3ovX2BviI9OX01ld0Uxug1XiGXmFDnILEg9hrcfp no3vopAQEHKtnwnfWMzI8RKgnwuwag08+FadCwJLicby4VGlJUe7LW2+ALntjQ+lLTXv gplY76MSkP/DukdcWs//SgTz3sFfqkuoXLzAOMpL+DPfqABDUytNpxDzUm2kfyXcdsQy Ac/DFNCJiQ8bfaHXsNCaaJEJ1P7krU30Rb075V1GJyWEv4SXlIhkhqjhc6fWf2W7yBJl 2P3ypHTZqFoiyVS4LOFKnBNPIiNPuKaNxs9enYKsQv0jpWwe5EMFYq+Wu2TBBnGJzzUO kjvw== MIME-Version: 1.0 X-Received: by 10.182.76.38 with SMTP id h6mr3443896obw.74.1375898343107; Wed, 07 Aug 2013 10:59:03 -0700 (PDT) Received: by 10.76.89.194 with HTTP; Wed, 7 Aug 2013 10:59:03 -0700 (PDT) Date: Wed, 7 Aug 2013 13:59:03 -0400 Message-ID: From: Barry OReilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) See this thread for the original description: http://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00328.html The short of it is that I occasionally witness point jump to elsewhere in the buffer while I'm editing and then back again. The change of point is visually apparent in the display. This has consequences such as causing undesired scrolling while editing. To debug it, I used a change like this: diff --git a/src/editfns.c b/src/editfns.c index 50bde90..039e13f 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -234,6 +234,8 @@ The return value is POSITION. */) (register Lisp_Object position) { ptrdiff_t pos; + bool noninteractive_old =3D noninteractive; + noninteractive =3D true; if (MARKERP (position) && current_buffer =3D=3D XMARKER (position)->buffer) @@ -245,7 +247,19 @@ The return value is POSITION. */) SET_PT_BOTH (ZV, ZV_BYTE); else SET_PT_BOTH (pos, marker_byte_position (position)); - + int btI =3D 0; + Lisp_Object theBacktrace; + do + { + theBacktrace =3D Fbacktrace_frame( make_number(btI) ); + ++btI; + Fprin1(theBacktrace, Qnil); + printf("\017\n"); + } while( ! EQ(theBacktrace, Qnil) ); + { struct timespec debug_ts; char debug_dateStr[20]; { clock_gettime(CLOCK_REALTIME, &debug_ts); struct tm mytm; localtime_r(&debug_ts.tv_sec, &mytm); strftime(debug_dateStr, 20, "%Y-%m-%dT%H:%M:%S", &mytm); } + printf( "%s.%09ld|pid:%d|tid:%ld|%s|%d| DEBUG: goto-char marker pos=3D%ld\n", // TODO: debugging + debug_dateStr, debug_ts.tv_nsec, getpid(), pthread_self(), __FILE__, __LINE__, pos ); fflush(stdout); } + noninteractive =3D noninteractive_old; return position; } @@ -253,6 +267,19 @@ The return value is POSITION. */) pos =3D clip_to_bounds (BEGV, XINT (position), ZV); SET_PT (pos); + int btI =3D 0; + Lisp_Object theBacktrace; + do + { + theBacktrace =3D Fbacktrace_frame( make_number(btI) ); + ++btI; + Fprin1(theBacktrace, Qnil); + printf("\017\n"); + } while( ! EQ(theBacktrace, Qnil) ); + { struct timespec debug_ts; char debug_dateStr[20]; { clock_gettime(CLOCK_REALTIME, &debug_ts); struct tm mytm; localtime_r(&debug_ts.tv_sec, &mytm); strftime(debug_dateStr, 20, "%Y-%m-%dT%H:%M:%S", &mytm); } + printf( "%s.%09ld|pid:%d|tid:%ld|%s|%d| DEBUG: goto-char position pos=3D%ld\n", // TODO: debugging + debug_dateStr, debug_ts.tv_nsec, getpid(), pthread_self(), __FILE__, __LINE__, pos ); fflush(stdout); } + noninteractive =3D noninteractive_old; return position; } I got a reproduction with these debug statements. I was editing a Makefile in comments at about buffer position 3396 and observed point temporarily jump to the beginning of the comment block at position 3084. I filtered the output for calls to go to position 3084 around the time I witnessed this: [backtrace A] 2013-08-01T10:37:28.119778000|pid:10485|tid:2342111488|editfns.c|281| DEBUG: goto-char position pos=3D3084 [backtrace B] 2013-08-01T10:37:28.412962000|pid:10485|tid:2342111488|editfns.c|261| DEBUG: goto-char marker pos=3D3084 [backtrace C] 2013-08-01T10:37:29.715413000|pid:10485|tid:2342111488|editfns.c|281| DEBUG: goto-char position pos=3D3084 Strangly, the backtrace A and B are 35 and 45 empty (except my Ctrl-O chars) stack frames respectively. Backtrace C is: (t semantic-make-lexer 3083 3257 nil nil)^O (t semantic-lex 3083 3257 nil)^O (t semantic-parse-region-default 3083 3257 nil nil nil)^O (t semantic-parse-region 3083 3257 nil)^O (t semantic-edits-incremental-parser-1)^O parser error: %S" error-message-string t] 4)))] 3)^O (t semantic-parse-changes-default)^O (t semantic-parse-changes)^O (t semantic-fetch-tags)^O (t byte-code "=C0 *=C1" [semantic-fetch-tags nil] 1)^O (t semantic-idle-scheduler-refresh-tags)^O (t byte-code "=C6^X=C7p=C7=C6=C8=C9=CA \"\"\"^Y=C6^ZESC=C6^\^M;^\^@=CB^M!^^#^N$^^@=CC=CD!<= U+0085>+^@^N^M?^^@^N%?^^@^N#E^@^M;E^@=CE^M!= R^@^N#^^@=CB^M=C6=CF#^^@^N&=D0X^ ^M;=AD^@=CB^M!^^#^N$=EF^@=CC=CD!=BC^@^N^M?= =EF^@^N%?=EF^@^N#=D6^@^M;=D6^@=CE^M!=E3^@^N= #=EF^@=CB^M=C6=CF#=EF^@^N&=D0X=EF^@=D1 ^N&W) ^A^N(=FE^@=D2 ^A=D3=DA=DB ^Ap^KB^S)^N*A^V*^?^@*^K^Q)^N,=C6^^-^^*o^A^N= *@^V-^N+>^A=D6 8^A=D7 >^A=D8^N+=DC\"^N.I^A=DD=DE^N-\"^N(U^A^N- Z^A=D3=DF=E0 e-scheduler-queue service semantic-idle-scheduler-verbose-flag] 8)^O (t semantic-idle-core-handler)^O (t semantic-idle-scheduler-function)^O (t apply semantic-idle-scheduler-function nil)^O (t byte-code "r=C2=C3H\")=C1" [timer apply 5 6] 4)^O (t timer-event-handler [t 0 1 0 t semantic-idle-scheduler-function nil idle 0])^O nil^O I can see the call to goto-char in define-lex (the macro which creates semantic-make-lexer). However, there is a save-excursion in effect at the semantic-idle-core-handler frame, so this goto-char wouldn't seem to be the same goto-char I observe in the display. I'm not sure about the empty backtraces. Is the code I used to print backtraces valid? In my many runs, empty backtraces are very rare. I have since started using Fbacktrace() instead of the more long winded code above. Unfortunately I'm having a reproduction drought in the past week. One additional observation not previously noted is that I see this bug much more often when editing comments or strings. However, I'm fairly sure I've seen it when editing straight code too. In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.4) of 2013-06-18 on psd15 Windowing system distributor `The X.Org Foundation', version 11.0.70101000 System Description: Red Hat Enterprise Linux Client release 5.4 (Tikanga) Configured using: `configure --prefix=3D/redacted/user/boreilly/sw/emacs-install-trunk-20899d085afe6252= 0113b5acbfe3dbba57823dc9 --with-gif=3Dno' Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=3Dnone locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: outline-minor-mode: t global-whitespace-mode: t global-ede-mode: t global-semanticdb-minor-mode: t global-semantic-idle-scheduler-mode: t semantic-mode: t evil-mode: t evil-local-mode: t global-undo-tree-mode: t undo-tree-mode: t show-paren-mode: t delete-selection-mode: t global-auto-revert-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e p o r t - Recent messages: Loading redacted Loading redacted Loading whitespace...done 2013-08-07T13:47:52.565183 Loading tags file: redacted Starting a new list of tags tables 2013-08-07T13:47:52.716876 Finished loading init file. 2013-08-07T13:47:52.723671 Inside my-prog-mode-hook 2013-08-07T13:47:52.732424 Inside my-emacs-lisp-mode-hook for buffer *scrat= ch* For information about GNU Emacs and the GNU system, type C-h C-a. 2013-08-07T13:47:52.748012 ---------------- Finished with my-emacs-startup-hook. ---------------- Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils noutline outline easy-mmode my-config warnings semantic/lex-spp etags package cl-macs whitespace cus-start cus-load my-proj ede/cpp-root ede/speedbar ede/files ede ede/base ede/auto ede/source eieio-speedbar speedbar sb-image dframe eieio-custom wid-edit semantic/db-mode semantic/idle semantic/bovine/gcc semantic/dep semantic/ia semantic/analyze/refs semantic/db-find semantic/db-ref semantic/senator semantic/decorate pulse semantic/analyze semantic/sort semantic/scope semantic/analyze/fcn semantic/db gv eieio-base semantic/ctxt semantic/format ezimage semantic/tag-ls semantic/find semantic/util-modes easymenu semantic/util semantic semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp byte-compile cconv eieio-core mode-local cedet evil evil-integration evil-maps evil-commands evil-types evil-search evil-ex evil-macros evil-repeat evil-states evil-core evil-common windmove rect evil-digraphs evil-vars ring edmacro kmacro undo-tree diff goto-chg rainbow-delimiters my-util advice help-fns electric paren delsel autorevert cl nadvice cl-lib time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Aug 2013 18:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137590021422068 (code B ref 15045); Wed, 07 Aug 2013 18:31:01 +0000 Received: (at 15045) by debbugs.gnu.org; 7 Aug 2013 18:30:14 +0000 Received: from localhost ([127.0.0.1]:46033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V78Uv-0005jr-EP for submit@debbugs.gnu.org; Wed, 07 Aug 2013 14:30:14 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:60340) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V78Us-0005iz-Kp for 15045@debbugs.gnu.org; Wed, 07 Aug 2013 14:30:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="20877379" Received: from 75-119-243-106.dsl.teksavvy.com (HELO pastel.home) ([75.119.243.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 07 Aug 2013 14:29:58 -0400 Received: by pastel.home (Postfix, from userid 20848) id 8D76566AF2; Wed, 7 Aug 2013 14:30:04 -0400 (EDT) From: Stefan Monnier Message-ID: References: Date: Wed, 07 Aug 2013 14:30:04 -0400 In-Reply-To: (Barry OReilly's message of "Wed, 7 Aug 2013 13:59:03 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > The short of it is that I occasionally witness point jump to elsewhere > in the buffer while I'm editing and then back again. So it's "displayed at A" then "displayed at B" then "displayed at A again"? what happens between each one of those 3 displays? If "nothing", then I suspect there's something like a `sit-for' somewhere that causes a redisplay in the middle of the command (i.e. in the middle of a save-excursion). Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Aug 2013 18:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Barry OReilly , 15045@debbugs.gnu.org Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137590097223827 (code B ref 15045); Wed, 07 Aug 2013 18:43:02 +0000 Received: (at 15045) by debbugs.gnu.org; 7 Aug 2013 18:42:52 +0000 Received: from localhost ([127.0.0.1]:46066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V78h9-0006CF-9B for submit@debbugs.gnu.org; Wed, 07 Aug 2013 14:42:51 -0400 Received: from randomsample.de ([83.169.19.17]:38246) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V78h5-0006C5-L2 for 15045@debbugs.gnu.org; Wed, 07 Aug 2013 14:42:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=mQwGUsUiLqY8Yqk/rEGae8X9i2wqwyHp2af8v1x8UGc=; b=bjv1OsYNBY5wv2mJtA81Pm5/JwMIqxnHB+5we2H9J0lYlFRqxalf4gJorSQmnrdtY8msxtTv5173bruQR8HLeiABTWytE4z5iTjR26MdcKD1Eo+4VIkFTInxwCg1ndik; Received: from dslc-082-083-057-223.pools.arcor-ip.net ([82.83.57.223] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V78h3-0008Ne-5T; Wed, 07 Aug 2013 20:42:45 +0200 From: David Engster In-Reply-To: (Stefan Monnier's message of "Wed, 07 Aug 2013 14:30:04 -0400") References: User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Mail-Copies-To: never Date: Wed, 07 Aug 2013 20:42:44 +0200 Message-ID: <87pptptk9n.fsf@engster.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Stefan Monnier writes: >> The short of it is that I occasionally witness point jump to elsewhere >> in the buffer while I'm editing and then back again. > > So it's "displayed at A" then "displayed at B" then "displayed at > A again"? what happens between each one of those 3 displays? > > If "nothing", then I suspect there's something like a `sit-for' > somewhere that causes a redisplay in the middle of the command (i.e. in > the middle of a save-excursion). I sometimes see this as well, and yes, "nothing" happens between those three displays. I also think there's a redisplay triggered by another background task while Semantic does its idle parsing stuff. I surely won't rule out that we're missing a save-excursion somewhere in Semantic, but I think that if this were the case, it should happen much more often. I wonder which background tasks could trigger such redisplays. Maybe an update of the mode-line? How could I debug this? The problem is that this happens maybe every 15 minutes or so... -David From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Aug 2013 19:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: 15045@debbugs.gnu.org, Stefan Monnier Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13759039081680 (code B ref 15045); Wed, 07 Aug 2013 19:32:02 +0000 Received: (at 15045) by debbugs.gnu.org; 7 Aug 2013 19:31:48 +0000 Received: from localhost ([127.0.0.1]:46100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V79SV-0000R2-8j for submit@debbugs.gnu.org; Wed, 07 Aug 2013 15:31:47 -0400 Received: from mail-oa0-f53.google.com ([209.85.219.53]:45064) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V79SS-0000Qf-Lh for 15045@debbugs.gnu.org; Wed, 07 Aug 2013 15:31:45 -0400 Received: by mail-oa0-f53.google.com with SMTP id k18so4110380oag.40 for <15045@debbugs.gnu.org>; Wed, 07 Aug 2013 12:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=prAJEQykXyI8cyocCUwtspWwMA/067DKvqQWoiqTucQ=; b=h8MNT03nuc8avNTt42QoBGgtSsnN4yOqlxuFn5NDHKztxVrLDSLn8RCA+LFRZmRo8v hw9qr3qdUf5O2XgZqEGn4b7gizuNBvFQoyKpxuAoAB8GWnWWipSdx4CZBaCXyCqxNE27 O2DK+K/JWYFFgJH96LRz36vaH6Q2FPA99gEzGQB+xxoq6DIswlhNJ7gh8AB1PLCLq+sK UBqmXBWARVQplxnweYzYJXWWjj0xRDeGdYlcLymIzrIRqSPnZIS+2BP7oLX0Y72dH1IF sCsmF15k7/nkAQ49RDpq6nujos+kosFoKd5qr518So18CvTP8BYDtCo3/7nBPXr+er1P ow6w== MIME-Version: 1.0 X-Received: by 10.60.35.40 with SMTP id e8mr1830234oej.34.1375903898756; Wed, 07 Aug 2013 12:31:38 -0700 (PDT) Received: by 10.76.89.194 with HTTP; Wed, 7 Aug 2013 12:31:38 -0700 (PDT) In-Reply-To: <87pptptk9n.fsf@engster.org> References: <87pptptk9n.fsf@engster.org> Date: Wed, 7 Aug 2013 15:31:38 -0400 Message-ID: From: Barry OReilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > So it's "displayed at A" then "displayed at B" then "displayed at A > again"? what happens between each one of those 3 displays? No. A, B, and C are backtraces. Specifically, the backtraces printed when goto-char went to the offending position at the beginning of the comment block. I don't know which of the three is the one I see actually displayed. The timestamps are too close together for me to be certain. I'm interested to see if I get more empty backtraces at the next reproduction. I don't know what they could mean. > If "nothing", then I suspect there's something like a `sit-for' > somewhere that causes a redisplay in the middle of the command (i.e. > in the middle of a save-excursion). Ahh, I didn't know about sit-for. It might explain what I'm seeing. I added a debug statement to Fredisplay. In a simple run (no reproduction of the bug yet), I get a few of these: 2013-08-07T15:18:09.576922000|pid:11494|tid:47776720943360|dispnew.c|5822| DEBUG: redisplay redisplay() sit-for(0) jit-lock-deferred-fontify() apply(jit-lock-deferred-fontify nil) byte-code("r=C1=08=C2H=08=C3H\"=88)=C1=87" [timer apply 5 6] 4) timer-event-handler([t 0 0 10000 t jit-lock-deferred-fontify nil idle 0]) I don't suppose there are ways deferred jit lock would execute during Semantic lexing? Anyway, next time I see the bug, I expect I'll get better data. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Aug 2013 19:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org, deng@randomsample.de Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13759046523345 (code B ref 15045); Wed, 07 Aug 2013 19:45:02 +0000 Received: (at 15045) by debbugs.gnu.org; 7 Aug 2013 19:44:12 +0000 Received: from localhost ([127.0.0.1]:46114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V79eV-0000rt-Vu for submit@debbugs.gnu.org; Wed, 07 Aug 2013 15:44:12 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:45830) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V79eT-0000rW-9J for 15045@debbugs.gnu.org; Wed, 07 Aug 2013 15:44:10 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MR600100E952G00@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Wed, 07 Aug 2013 22:44:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR60014SETE1B40@a-mtaout20.012.net.il>; Wed, 07 Aug 2013 22:44:02 +0300 (IDT) Date: Wed, 07 Aug 2013 22:44:15 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <831u65uvzk.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87pptptk9n.fsf@engster.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 7 Aug 2013 15:31:38 -0400 > From: Barry OReilly > Cc: 15045@debbugs.gnu.org > > > So it's "displayed at A" then "displayed at B" then "displayed at A > > again"? what happens between each one of those 3 displays? > > No. A, B, and C are backtraces. Specifically, the backtraces printed > when goto-char went to the offending position at the beginning of the > comment block. I don't know which of the three is the one I see > actually displayed. The timestamps are too close together for me to be > certain. > > I'm interested to see if I get more empty backtraces at the next > reproduction. I don't know what they could mean. > > > If "nothing", then I suspect there's something like a `sit-for' > > somewhere that causes a redisplay in the middle of the command (i.e. > > in the middle of a save-excursion). > > Ahh, I didn't know about sit-for. It might explain what I'm seeing. > > I added a debug statement to Fredisplay. In a simple run (no > reproduction of the bug yet), I get a few of these: > > 2013-08-07T15:18:09.576922000|pid:11494|tid:47776720943360|dispnew.c|5822| > DEBUG: redisplay > redisplay() > sit-for(0) > jit-lock-deferred-fontify() > apply(jit-lock-deferred-fontify nil) > byte-code("rÁÂHÃH\"ˆ)Á‡" [timer apply 5 6] 4) > timer-event-handler([t 0 0 10000 t jit-lock-deferred-fontify nil idle 0]) > > I don't suppose there are ways deferred jit lock would execute during > Semantic lexing? I think the jit-lock you see is the result of the scrolling, not its reason. > Anyway, next time I see the bug, I expect I'll get better data. In the discussion that you cite at the beginning of this bug report, I suggested a different approach to finding out the culprit, by using the redisplay tracing facility. Can you try that and post the results? It might give better clues. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Aug 2013 20:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 15045@debbugs.gnu.org, deng@randomsample.de Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137590798110639 (code B ref 15045); Wed, 07 Aug 2013 20:40:02 +0000 Received: (at 15045) by debbugs.gnu.org; 7 Aug 2013 20:39:41 +0000 Received: from localhost ([127.0.0.1]:46139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7AWC-0002lT-5v for submit@debbugs.gnu.org; Wed, 07 Aug 2013 16:39:41 -0400 Received: from mail-ob0-f175.google.com ([209.85.214.175]:50189) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7AW7-0002ks-Pn for 15045@debbugs.gnu.org; Wed, 07 Aug 2013 16:39:37 -0400 Received: by mail-ob0-f175.google.com with SMTP id xn12so2820744obc.20 for <15045@debbugs.gnu.org>; Wed, 07 Aug 2013 13:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QVIWoHMhkj5CXlVYhB+/ZDL5c0ElThxWYk/7uZIuWyo=; b=JwEgEfnOLaERW3wDwWHN7hnzOhptCrxKxxsbfuTd7ZUIoc8RdOcdowOomUtHCPvKQ2 pJHVS8WYDVVSffQw4FrvK6VOepG4fGyUQk4EntZMtXiEQOZ1ILukzrUdbLoV+N1j30dW iF00HHhwW6M02cAjB6+I1+cotp9r87b+NXCJEsWvYlojtOgaieZBXWJKKlA5GjWWIRzY fti0mpilR09PihpSL8oYy6EiLqN5FqBdcGvTc59xNNLFS+T5MMdqK3s2s79klwYTICxB zTZ5GOQ/L/oxBqS45EW3r9OGzibkLXzn7AewhdoVEiM+Mrf2JlTvZ15qu5DE3qptnXam zOlw== MIME-Version: 1.0 X-Received: by 10.60.43.73 with SMTP id u9mr1886870oel.105.1375907969878; Wed, 07 Aug 2013 13:39:29 -0700 (PDT) Received: by 10.76.89.194 with HTTP; Wed, 7 Aug 2013 13:39:29 -0700 (PDT) In-Reply-To: <831u65uvzk.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <831u65uvzk.fsf@gnu.org> Date: Wed, 7 Aug 2013 16:39:29 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/mixed; boundary=001a11c2e5f4c9d27b04e3618910 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c2e5f4c9d27b04e3618910 Content-Type: text/plain; charset=ISO-8859-1 > In the discussion that you cite at the beginning of this bug report, > I suggested a different approach to finding out the culprit, by > using the redisplay tracing facility. Can you try that and post the > results? It might give better clues. Though I can't reproduce it at will, I do have a trace-redisplay from when I saw the bug in a Java file. Specifically, I saw point move inappropriately, but redisplay didn't need to scroll. It's attached in case you find it useful. --001a11c2e5f4c9d27b04e3618910 Content-Type: text/plain; charset=US-ASCII; name="trace-redisplay-pt-move.txt" Content-Disposition: attachment; filename="trace-redisplay-pt-move.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hk2ytnlz0 MHgxMTA4ZjQwICgqQnVmZmVyIExpc3QqKTogc2FtZSB3aW5kb3cgc3RhcnQKMHgxMTA4ZjQwICgq QnVmZmVyIExpc3QqKTogMQpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg3KQpyZWRpc3Bs YXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKCpCdWZmZXIgTGlzdCopOiBzYW1lIHdpbmRvdyBzdGFy dAoweDExMDhmNDAgKCpCdWZmZXIgTGlzdCopOiAxCmV4cG9zZV9mcmFtZSAoMTUzOCwgMCwgMTYs IDE0KQpleHBvc2Vfd2luZG93ICgxNTM4LCAwLCAxNiwgMTQpCnJlZGlzcGxheV9wcmVzZXJ2ZV9l Y2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4 MTEwOGY0MCAoKkJ1ZmZlciBMaXN0Kik6IGN1cnNvciBtb3ZlbWVudApyZWRpc3BsYXlfcHJlc2Vy dmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJuYWwg MAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBzYW1lIHdpbmRvdyBzdGFydAoweDExMDhmNDAg KFJlZGFjdGVkLmphdmEpOiAxCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDExKQpyZWRp c3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBzYW1lIHdpbmRvdyBz dGFydAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiAxCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hv X2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2Fy ZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEg KDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgp CnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJl ZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0 ZWQuamF2YSk6IGN1cnNvciBtb3ZlbWVudApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4 KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpy ZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFj dGVkLmphdmEpOiBjdXJzb3IgbW92ZW1lbnQKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAo OCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkK cmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRh Y3RlZC5qYXZhKTogY3Vyc29yIG1vdmVtZW50CnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEg KDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDkp CnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVk YWN0ZWQuamF2YSk6IHNhbWUgd2luZG93IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6 IDEKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoMikKcmVkaXNwbGF5X2ludGVybmFsIDAK MHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogQQoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiB0 cnlfd2luZG93X2lkIDMKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5 X2ludGVybmFsIDAKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2lu dGVybmFsIDAKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVy bmFsIDAKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogc2Ft ZSB3aW5kb3cgc3RhcnQKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogMQpleHBvc2VfZnJhbWUg IGdhcmJhZ2VkCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6 IHNhbWUgd2luZG93IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IDEKcmVkaXNwbGF5 X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogc2FtZSB3aW5kb3cgc3RhcnQK MHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogMQpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVh ICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4 KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpy ZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRp c3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiB0cnlfd2luZG93X2lk IDMKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAK MHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogdHJ5X3dpbmRvd19pZCAzCnJlZGlzcGxheV9wcmVz ZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2 ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5hbCAw CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IGN1cnNvciBtb3ZlbWVudApyZWRpc3BsYXlfcHJl c2VydmVfZWNob19hcmVhICgyKQpyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFj dGVkLmphdmEpOiB0cnlfd2luZG93X2lkIDMKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAo OCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkK cmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRh Y3RlZC5qYXZhKTogY3Vyc29yIG1vdmVtZW50CnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEg KDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgp CnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJl ZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0 ZWQuamF2YSk6IGN1cnNvciBtb3ZlbWVudApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4 KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpy ZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRp c3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3Bs YXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlf aW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50 ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJu YWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwg MApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApy ZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBzYW1lIHdpbmRv dyBzdGFydAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiAxCnJlZGlzcGxheV9wcmVzZXJ2ZV9l Y2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hv X2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2Fy ZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0 MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUgd2luZG93IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQu amF2YSk6IDEKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoMikKcmVkaXNwbGF5X2ludGVy bmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogQQoweDExMDhmNDAgKFJlZGFjdGVkLmph dmEpOiB0cnlfd2luZG93X2lkIDMKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVk aXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNw bGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5q YXZhKTogc2FtZSB3aW5kb3cgc3RhcnQKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogMQpyZWRp c3BsYXlfcHJlc2VydmVfZWNob19hcmVhICgyKQpyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhm NDAgKFJlZGFjdGVkLmphdmEpOiBBCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHRyeV93aW5k b3dfaWQgMwpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJu YWwgMApyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBzYW1l IHdpbmRvdyBzdGFydAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiAxCnJlZGlzcGxheV9wcmVz ZXJ2ZV9lY2hvX2FyZWEgKDIpCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0 ZWQuamF2YSk6IEEKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogdHJ5X3dpbmRvd19pZCAzCnJl ZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlz cGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUgd2luZG93IHN0 YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IDEKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9f YXJlYSAoMikKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTog QQoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiB0cnlfd2luZG93X2lkIDMKcmVkaXNwbGF5X3By ZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X2ludGVy bmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogc2FtZSB3aW5kb3cgc3RhcnQKMHgxMTA4 ZjQwIChSZWRhY3RlZC5qYXZhKTogMQpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICgyKQpy ZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBBCjB4MTEwOGY0 MCAoUmVkYWN0ZWQuamF2YSk6IHRyeV93aW5kb3dfaWQgMwpyZWRpc3BsYXlfcHJlc2VydmVfZWNo b19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19h cmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhm NDAgKFJlZGFjdGVkLmphdmEpOiBzYW1lIHdpbmRvdyBzdGFydAoweDExMDhmNDAgKFJlZGFjdGVk LmphdmEpOiAxCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDIpCnJlZGlzcGxheV9pbnRl cm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IEEKMHgxMTA4ZjQwIChSZWRhY3RlZC5q YXZhKTogdHJ5X3dpbmRvd19pZCAzCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJl ZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0 ZWQuamF2YSk6IHNhbWUgd2luZG93IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IDEK cmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoMikKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgx MTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogQQoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiB0cnlf d2luZG93X2lkIDMKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2lu dGVybmFsIDAKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVy bmFsIDAKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFs IDAKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogc2FtZSB3 aW5kb3cgc3RhcnQKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogMQpyZWRpc3BsYXlfcHJlc2Vy dmVfZWNob19hcmVhICgyKQpyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVk LmphdmEpOiBBCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHRyeV93aW5kb3dfaWQgMwpyZWRp c3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3Bs YXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBzYW1lIHdpbmRvdyBzdGFy dAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiAxCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2Fy ZWEgKDIpCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IEEK MHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogdHJ5X3dpbmRvd19pZCAzCnJlZGlzcGxheV9wcmVz ZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5h bCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUgd2luZG93IHN0YXJ0CjB4MTEwOGY0 MCAoUmVkYWN0ZWQuamF2YSk6IDEKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoMikKcmVk aXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogQQoweDExMDhmNDAg KFJlZGFjdGVkLmphdmEpOiB0cnlfd2luZG93X2lkIDMKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9f YXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4 ZjQwIChSZWRhY3RlZC5qYXZhKTogc2FtZSB3aW5kb3cgc3RhcnQKMHgxMTA4ZjQwIChSZWRhY3Rl ZC5qYXZhKTogMQpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICgyKQpyZWRpc3BsYXlfaW50 ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBBCjB4MTEwOGY0MCAoUmVkYWN0ZWQu amF2YSk6IHRyeV93aW5kb3dfaWQgMwpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpy ZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRp c3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVk LmphdmEpOiBzYW1lIHdpbmRvdyBzdGFydAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiAxCnJl ZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDIpCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEw OGY0MCAoUmVkYWN0ZWQuamF2YSk6IEEKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogdHJ5X3dp bmRvd19pZCAzCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRl cm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5h bCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUg d2luZG93IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IDEKcmVkaXNwbGF5X3ByZXNl cnZlX2VjaG9fYXJlYSAoMikKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3Rl ZC5qYXZhKTogQQoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiB0cnlfd2luZG93X2lkIDMKcmVk aXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNw bGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5 X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogc2FtZSB3aW5kb3cgc3RhcnQK MHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogMQpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVh ICgyKQpyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBBCjB4 MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHRyeV93aW5kb3dfaWQgMwpyZWRpc3BsYXlfcHJlc2Vy dmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJuYWwg MAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBzYW1lIHdpbmRvdyBzdGFydAoweDExMDhmNDAg KFJlZGFjdGVkLmphdmEpOiAxCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDIpCnJlZGlz cGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IEEKMHgxMTA4ZjQwIChS ZWRhY3RlZC5qYXZhKTogdHJ5X3dpbmRvd19pZCAzCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2Fy ZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0 MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUgd2luZG93IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQu amF2YSk6IDEKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoMikKcmVkaXNwbGF5X2ludGVy bmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogQQoweDExMDhmNDAgKFJlZGFjdGVkLmph dmEpOiB0cnlfd2luZG93X2lkIDMKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRh Y3RlZC5qYXZhKTogQQoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiB0cnlfd2luZG93X2lkIDMK cmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogc2FtZSB3aW5k b3cgc3RhcnQKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogMQpyZWRpc3BsYXlfcHJlc2VydmVf ZWNob19hcmVhICgyKQpyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmph dmEpOiBBCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHRyeV93aW5kb3dfaWQgMwpyZWRpc3Bs YXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlf aW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBzYW1lIHdpbmRvdyBzdGFydAow eDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiAxCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEg KDIpCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IEEKMHgx MTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogdHJ5X3dpbmRvd19pZCAzCnJlZGlzcGxheV9wcmVzZXJ2 ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9l Y2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4 MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUgd2luZG93IHN0YXJ0CjB4MTEwOGY0MCAoUmVk YWN0ZWQuamF2YSk6IDEKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoMikKcmVkaXNwbGF5 X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogQQoweDExMDhmNDAgKFJlZGFj dGVkLmphdmEpOiB0cnlfd2luZG93X2lkIDMKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAo OCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChS ZWRhY3RlZC5qYXZhKTogc2FtZSB3aW5kb3cgc3RhcnQKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZh KTogMQpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICgyKQpyZWRpc3BsYXlfaW50ZXJuYWwg MAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBBCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6 IHRyeV93aW5kb3dfaWQgMwpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3Bs YXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmph dmEpOiBzYW1lIHdpbmRvdyBzdGFydAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiAxCnJlZGlz cGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDIpCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0 MCAoUmVkYWN0ZWQuamF2YSk6IEEKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogdHJ5X3dpbmRv d19pZCAzCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5h bCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUg d2luZG93IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IDEKcmVkaXNwbGF5X3ByZXNl cnZlX2VjaG9fYXJlYSAoMikKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3Rl ZC5qYXZhKTogQQoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiB0cnlfd2luZG93X2lkIDMKcmVk aXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNw bGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogc2FtZSB3aW5kb3cgc3Rh cnQKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogMQpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19h cmVhICgyKQpyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBB CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHRyeV93aW5kb3dfaWQgMwpyZWRpc3BsYXlfcHJl c2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJu YWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBzYW1lIHdpbmRvdyBzdGFydAoweDExMDhm NDAgKFJlZGFjdGVkLmphdmEpOiAxCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDIpCnJl ZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IEEKMHgxMTA4ZjQw IChSZWRhY3RlZC5qYXZhKTogdHJ5X3dpbmRvd19pZCAzCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hv X2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEw OGY0MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUgd2luZG93IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0 ZWQuamF2YSk6IDEKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoMikKcmVkaXNwbGF5X2lu dGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogQQoweDExMDhmNDAgKFJlZGFjdGVk LmphdmEpOiB0cnlfd2luZG93X2lkIDMKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkK cmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRh Y3RlZC5qYXZhKTogc2FtZSB3aW5kb3cgc3RhcnQKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTog MQpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICgyKQpyZWRpc3BsYXlfaW50ZXJuYWwgMAow eDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBBCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHRy eV93aW5kb3dfaWQgMwpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlf aW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEp OiBzYW1lIHdpbmRvdyBzdGFydAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiAxCnJlZGlzcGxh eV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDIpCnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAo UmVkYWN0ZWQuamF2YSk6IEEKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogdHJ5X3dpbmRvd19p ZCAzCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAw CnJlZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUgd2lu ZG93IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IDEKcmVkaXNwbGF5X3ByZXNlcnZl X2VjaG9fYXJlYSAoMikKcmVkaXNwbGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5q YXZhKTogQQoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiB0cnlfd2luZG93X2lkIDMKcmVkaXNw bGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5 X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogc2FtZSB3aW5kb3cgc3RhcnQK MHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogMQpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVh ICgyKQpyZWRpc3BsYXlfaW50ZXJuYWwgMAoweDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBBCjB4 MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHRyeV93aW5kb3dfaWQgMwpyZWRpc3BsYXlfcHJlc2Vy dmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVf ZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJuYWwgMAow eDExMDhmNDAgKFJlZGFjdGVkLmphdmEpOiBzYW1lIHdpbmRvdyBzdGFydAoweDExMDhmNDAgKFJl ZGFjdGVkLmphdmEpOiAxCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDIpCnJlZGlzcGxh eV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IEEKMHgxMTA4ZjQwIChSZWRh Y3RlZC5qYXZhKTogdHJ5X3dpbmRvd19pZCAzCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEg KDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgp CnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDIpCnJl ZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUgd2luZG93 IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IDEKcmVkaXNwbGF5X2ludGVybmFsIDAK cmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVk aXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNw bGF5X2ludGVybmFsIDAKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogc2FtZSB3aW5kb3cgc3Rh cnQKMHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogMQpleHBvc2VfZnJhbWUgIGdhcmJhZ2VkCnJl ZGlzcGxheV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHNhbWUgd2luZG93 IHN0YXJ0CjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IDEKcmVkaXNwbGF5X2ludGVybmFsIDAK MHgxMTA4ZjQwIChSZWRhY3RlZC5qYXZhKTogc2FtZSB3aW5kb3cgc3RhcnQKMHgxMTA4ZjQwIChS ZWRhY3RlZC5qYXZhKTogMQpyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3Bs YXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlf aW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfcHJlc2VydmVfZWNob19h cmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRpc3BsYXlfaW50ZXJuYWwgMApleHBvc2Vf ZnJhbWUgKDIxMSwgMzMxLCAxMDE3LCAyMzkpCmV4cG9zZV93aW5kb3cgKDIxMSwgMzMxLCAxMDE3 LCAyMzkpCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5h bCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAw CnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJl ZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlz cGxheV9pbnRlcm5hbCAwCmV4cG9zZV9mcmFtZSAoMCwgMCwgNSwgOTc1KQpleHBvc2Vfd2luZG93 ICgwLCAwLCA1LCA5NTIpCmV4cG9zZV93aW5kb3cgKDAsIDk1MiwgNSwgMTQpCmV4cG9zZV9mcmFt ZSAoMTU1NSwgMCwgNSwgOTc1KQpleHBvc2VfZnJhbWUgKDIxMSwgMzMxLCAxMDE3LCAyMzkpCmV4 cG9zZV93aW5kb3cgKDIxMSwgMzMxLCAxMDE3LCAyMzkpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJl ZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlz cGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxh eV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9p bnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRl cm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxheV9pbnRlcm5h bCAwCnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgp CnJlZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJl ZGlzcGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlz cGxheV9pbnRlcm5hbCAwCnJlZGlzcGxheV9wcmVzZXJ2ZV9lY2hvX2FyZWEgKDgpCnJlZGlzcGxh eV9pbnRlcm5hbCAwCjB4MTEwOGY0MCAoUmVkYWN0ZWQuamF2YSk6IHRyeV93aW5kb3dfaWQgMwpy ZWRpc3BsYXlfcHJlc2VydmVfZWNob19hcmVhICg4KQpyZWRpc3BsYXlfaW50ZXJuYWwgMApyZWRp c3BsYXlfcHJlc2VydmVfZWNob19hcmVhICgyMCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNw bGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5 X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X3By ZXNlcnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X3ByZXNl cnZlX2VjaG9fYXJlYSAoOCkKcmVkaXNwbGF5X2ludGVybmFsIDAKcmVkaXNwbGF5X2ludGVybmFs IDAKcmVkaXNwbGF5X3ByZXNlcnZlX2VjaG9fYXJlYSAoOCkK --001a11c2e5f4c9d27b04e3618910-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Aug 2013 21:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org, David Engster Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137591060116222 (code B ref 15045); Wed, 07 Aug 2013 21:24:01 +0000 Received: (at 15045) by debbugs.gnu.org; 7 Aug 2013 21:23:21 +0000 Received: from localhost ([127.0.0.1]:46248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7BCS-0004DZ-My for submit@debbugs.gnu.org; Wed, 07 Aug 2013 17:23:21 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:21656) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7BCQ-0004DA-0F for 15045@debbugs.gnu.org; Wed, 07 Aug 2013 17:23:18 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABK/CFFLd/Nq/2dsb2JhbABEhke0boNZF3OCHgEBBAEjMyMFCwkCGgIYDgICFBgNJIgeBpNgmn+SToEji2yCaIETA6R6gV6DE4FT X-IPAS-Result: AgEFABK/CFFLd/Nq/2dsb2JhbABEhke0boNZF3OCHgEBBAEjMyMFCwkCGgIYDgICFBgNJIgeBpNgmn+SToEji2yCaIETA6R6gV6DE4FT X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="20911341" Received: from 75-119-243-106.dsl.teksavvy.com (HELO pastel.home) ([75.119.243.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 07 Aug 2013 17:23:05 -0400 Received: by pastel.home (Postfix, from userid 20848) id 180E362D75; Wed, 7 Aug 2013 17:23:12 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> Date: Wed, 07 Aug 2013 17:23:12 -0400 In-Reply-To: (Barry OReilly's message of "Wed, 7 Aug 2013 15:31:38 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> So it's "displayed at A" then "displayed at B" then "displayed at A >> again"? what happens between each one of those 3 displays? > No. A, B, and C are backtraces. A, B, and C are local variables whose meaning depends on the email in which they're used. Yours have nothing to do with mine. Sorry I reused the same identifiers in the same thread. > 2013-08-07T15:18:09.576922000|pid:11494|tid:47776720943360|dispnew.c|5822| > DEBUG: redisplay > redisplay() > sit-for(0) > jit-lock-deferred-fontify() > apply(jit-lock-deferred-fontify nil) > byte-code("r=C3=81=C3=82H=C3=83H\"=CB=86)=C3=81=E2=80=A1" [timer appl= y 5 6] 4) > timer-event-handler([t 0 0 10000 t jit-lock-deferred-fontify nil idle 0= ]) Running timers is pretty much the same as running redisplay: both are things that can happen either between commands or in things like `sit-for', so no, jit-lock is unlikely to be the culprit. Maybe a way to check that is: in Fredisplay, walk the specpdl stack looking for a save_excursion_restore where the saved position is different from the current value of point in that buffer. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 02:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org, deng@randomsample.de Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137592971829424 (code B ref 15045); Thu, 08 Aug 2013 02:42:01 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 02:41:58 +0000 Received: from localhost ([127.0.0.1]:46597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7GAo-0007eV-2A for submit@debbugs.gnu.org; Wed, 07 Aug 2013 22:41:58 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:59286) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7GAk-0007eF-Fs for 15045@debbugs.gnu.org; Wed, 07 Aug 2013 22:41:55 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MR600H00XXORE00@a-mtaout22.012.net.il> for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 05:41:47 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR600HX2Y5LRM00@a-mtaout22.012.net.il>; Thu, 08 Aug 2013 05:41:47 +0300 (IDT) Date: Thu, 08 Aug 2013 05:41:59 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83zjssucnc.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <831u65uvzk.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 7 Aug 2013 16:39:29 -0400 > From: Barry OReilly > Cc: deng@randomsample.de, 15045@debbugs.gnu.org > > > In the discussion that you cite at the beginning of this bug report, > > I suggested a different approach to finding out the culprit, by > > using the redisplay tracing facility. Can you try that and post the > > results? It might give better clues. > > Though I can't reproduce it at will, I do have a trace-redisplay from > when I saw the bug in a Java file. Specifically, I saw point move > inappropriately, but redisplay didn't need to scroll. It's attached in > case you find it useful. Can you identify the area in this trace where the unwarranted scroll was visible? From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 17:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 15045@debbugs.gnu.org, deng@randomsample.de Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13759816305733 (code B ref 15045); Thu, 08 Aug 2013 17:08:02 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 17:07:10 +0000 Received: from localhost ([127.0.0.1]:47702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Tg5-0001UN-JW for submit@debbugs.gnu.org; Thu, 08 Aug 2013 13:07:09 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:64398) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Tg3-0001Tl-Pz for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 13:07:08 -0400 Received: by mail-ob0-f172.google.com with SMTP id er7so4359703obc.31 for <15045@debbugs.gnu.org>; Thu, 08 Aug 2013 10:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6ZtXh6MIe80Qwz+3jt/d51hbFf+VssrHpgXeBekufs8=; b=SsWElNKbXafhr2kYtH1W/uK5C9oUuroAxdxShh6VprvixgyCVzqw7O6zZ4QHHSYhv1 d2P0m1c0BW2pwaali1zSApk2ZDuX9lmeF0IcJbWvv7muJTzidrSyxyNX60ZUdqGHkxvd AcwUU2oPTX8lENV+SVxsmH9pmb13tPifc6hhzxWC5PNu8fBqw9n69uDxh+5PzpJn9UsF bdjXOMfo7GS/Eei25H3j6d5+sAuN6FbgSkfT07XMR7UvHRBsi13wvTOZHEvjF9T1wmB7 8VPQgNh6L9ZWq0K7VbX6lhitVTkGvlS64WG4NmjK/GqiI72/gz68AW9jgyw4ny1trQ5Y TuAw== MIME-Version: 1.0 X-Received: by 10.182.142.104 with SMTP id rv8mr7168270obb.3.1375981622034; Thu, 08 Aug 2013 10:07:02 -0700 (PDT) Received: by 10.76.89.194 with HTTP; Thu, 8 Aug 2013 10:07:01 -0700 (PDT) In-Reply-To: <83zjssucnc.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <831u65uvzk.fsf@gnu.org> <83zjssucnc.fsf@gnu.org> Date: Thu, 8 Aug 2013 13:07:01 -0400 Message-ID: From: Barry OReilly Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli: > Can you identify the area in this trace where the unwarranted scroll > was visible? Barry: > but redisplay didn't need to scroll Undesired scrolling is a downstream symptom. Upstream from it is point visibly moving around inappropriately. I have scroll-margin set to 4, so when point briefly moves into the top scroll-margin, I get undesired scrolling. I don't know that I've seen point move to outside the visible part of the buffer. If so, then users with scroll-margin 0 won't see undesired scrolling, but would still see point moving around. Thus, I'm debugging the symptom of point moving. > A, B, and C are local variables whose meaning depends on the email > in which they're used. Ah, so it's not in "thread local storage". > in Fredisplay, walk the specpdl stack looking for a > save_excursion_restore where the saved position is different from > the current value of point in that buffer. Thanks for the tip. I tested this change and it seems to implement what you described. diff --git a/src/dispnew.c b/src/dispnew.c index 522a0e6..cf0103e 100644 --- a/src/dispnew.c +++ b/src/dispnew.c @@ -5815,6 +5815,32 @@ immediately by pending input. */) (Lisp_Object force) { ptrdiff_t count; + bool noninteractive_old = noninteractive; + noninteractive = true; + Lisp_Object curPtMarker = Fpoint_marker(); + union specbinding *pdl = specpdl_ptr; + while (pdl > specpdl) + { + --pdl; + if (pdl->kind == SPECPDL_UNWIND + && pdl->unwind.func == save_excursion_restore + && ! EQ (Fequal (XSAVE_OBJECT (pdl->unwind.arg, 0), curPtMarker), Qt)) + { + { struct timespec debug_ts; char debug_dateStr[20]; { clock_gettime(CLOCK_REALTIME, &debug_ts); struct tm mytm; localtime_r(&debug_ts.tv_sec, &mytm); strftime(debug_dateStr, 20, "%Y-%m-%dT%H:%M:%S", &mytm) + printf( "%s.%09ld|pid:%d|tid:%ld|%s|%d| DEBUG: Found save_excursion_restore with mismatched point markers ", // TODO: debugging + debug_dateStr, debug_ts.tv_nsec, getpid(), pthread_self(), __FILE__, __LINE__ ); } + Fprin1(XSAVE_OBJECT (pdl->unwind.arg, 0), Qnil); + Fprin1(curPtMarker, Qnil); + printf("\n"); + Fbacktrace(); + fflush(stdout); + } + } + /* { struct timespec debug_ts; char debug_dateStr[20]; { clock_gettime(CLOCK_REALTIME, &debug_ts); struct tm mytm; localtime_r(&debug_ts.tv_sec, &mytm); strftime(debug_dateStr, 20, "%Y-%m-%dT%H:%M:%S", &mytm); } */ + /* printf( "%s.%09ld|pid:%d|tid:%ld|%s|%d| DEBUG: redisplay \n", // TODO: debugging */ + /* debug_dateStr, debug_ts.tv_nsec, getpid(), pthread_self(), __FILE__, __LINE__ ); fflush(stdout); } */ + /* Fbacktrace(); */ + noninteractive = noninteractive_old; swallow_events (1); if ((detect_input_pending_run_timers (1) We'll see what I get next time it comes up. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 17:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , Barry OReilly , 15045@debbugs.gnu.org, "Eric M. Ludlam" Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137598248312079 (code B ref 15045); Thu, 08 Aug 2013 17:22:02 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 17:21:23 +0000 Received: from localhost ([127.0.0.1]:47725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Ttq-00038e-C0 for submit@debbugs.gnu.org; Thu, 08 Aug 2013 13:21:23 -0400 Received: from randomsample.de ([83.169.19.17]:43770) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Ttm-00038A-HJ for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 13:21:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=/tMC9Uv610l+ABjDFkns0PMcRxCmfk02SmaPoRJ1Pv8=; b=bL12v/i6F83nDItUG4WgEb+W5JmAq7xaZP3fnBrm6SD779JVuhrVlub1t6BFjzYVa64yc+mu9ZrFS5PAkYqEkUyGJ77bMTp1MXncQ7rQp03QO178wqeYko+3qEVOTneB; Received: from dslc-082-083-054-159.pools.arcor-ip.net ([82.83.54.159] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7Tth-00031V-PW; Thu, 08 Aug 2013 19:21:14 +0200 From: David Engster In-Reply-To: <87pptptk9n.fsf@engster.org> (David Engster's message of "Wed, 07 Aug 2013 20:42:44 +0200") References: <87pptptk9n.fsf@engster.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Date: Thu, 08 Aug 2013 19:21:12 +0200 Message-ID: <87eha4t7xz.fsf@engster.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) --=-=-= Content-Type: text/plain [Adding Eric to CC] David Engster writes: > Stefan Monnier writes: >>> The short of it is that I occasionally witness point jump to elsewhere >>> in the buffer while I'm editing and then back again. >> >> So it's "displayed at A" then "displayed at B" then "displayed at >> A again"? what happens between each one of those 3 displays? >> >> If "nothing", then I suspect there's something like a `sit-for' >> somewhere that causes a redisplay in the middle of the command (i.e. in >> the middle of a save-excursion). > > I sometimes see this as well, and yes, "nothing" happens between those > three displays. I also think there's a redisplay triggered by another > background task while Semantic does its idle parsing stuff. I think I tracked this down. I first instrumented `sit-for' to see which background tasks trigger it. On my machine, this happens by two things: `jit-lock-deferred-fontify', and `display-time-event-handler'. The display-time handler is called twice per minute: I have (display-time) in my .emacs, and every full minute the time gets updated in the mode-line. Also, it is called in the gnus-after-get-new-news-hook, and since I check for new mails in the background, it gets called through this, too. It's kinda hard to trigger this problem through jit-lock, since its idle time is much smaller than the one from Semantic. So I disabled it and tried to trigger the jump by stopping typing at roughly XX:XX:59. The semantic idle function kicks in after 1 second, and lo and behold, I saw a jump. It's still difficult to reproduce, but I managed to get two backtraces in the past hour, which are attached. As you can see, the display-time-event-handler does indeed interrupt the lexing phase. It does a `sit-for', the display jumps. Not sure what happens after that. Does the semantic-idle function resume? Anyway, somehow point gets back to its original position, and through `trace-redisplay', I saw the following on stderr: 0x7f35178 (test.cpp): same window start 0x7f35178 (test.cpp): 1 redisplay_preserve_echo_area (2) redisplay_internal 0 0x7f35178 (test.cpp): try_scrolling redisplay_preserve_echo_area (8) redisplay_internal 0 0x7f35178 (test.cpp): same window start 0x7f35178 (test.cpp): 1 0x7f35178 (test.cpp): try_scrolling redisplay_preserve_echo_area (8) I guess this just says that redisplay made point visible by scrolling, right? You might wonder how the display-time-event-handler can interrupt the Semantic lexer. In the two backtraces, you see that it calls `accept-process-output' and `input-pending-p'. This is hidden inside the macro `semantic-throw-on-input', which can be called in code wrapped inside `semantic-exit-on-input'; it's our poor-man's 'yield'. It's used extensively in the idle function code, and it's just there to do a non-local exit in case the user does something. However, now I know that it also allows other timers to run. If you look in the `define-lex' macro, you see that it calls `semantic-throw-on-input' after each identified token. The problem is that it does not restore the cursor position before that, so I guess the fix is simply to change this call to (save-excursion (goto-char starting-position) (semantic-throw-on-input 'lex)) Obviously, we will have to check all other calls to `semantic-throw-on-input' for this as well. However, I also wonder if display-time-event-handler couldn't just call `force-mode-line-update'; or does this repaint the whole display as well? -David --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=backtr1.txt sit-for(0) display-time-event-handler() apply(display-time-event-handler nil) byte-code("[snipped]" [timer apply 5 6] 4) timer-event-handler([t 20995 27860 0 60 display-time-event-handler nil nil 0]) accept-process-output() semantic-c-lexer(2886 7946 nil nil) semantic-lex(2886 7946 nil) semantic-parse-region-default(2886 7946 nil nil nil) semantic-parse-region-c-mode(2886 7946 nil nil nil) semantic-parse-region(2886 7946 nil) semantic-edits-incremental-parser-1() byte-code("[snipped]" [err message "incremental parser error: %S" error-message-string t] 4)))] 3) semantic-parse-changes-default() semantic-parse-changes() semantic-fetch-tags() byte-code("[snipped]" [semantic-fetch-tags nil] 1) semantic-idle-scheduler-refresh-tags() byte-code("[snipped]") semantic-idle-core-handler() semantic-idle-scheduler-function() apply(semantic-idle-scheduler-function nil) timer-event-handler([t 0 1 0 t semantic-idle-scheduler-function nil idle 0]) --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=backtr2.txt sit-for(0) display-time-event-handler() apply(display-time-event-handler nil) byte-code("[snipped]" [timer apply 5 6] 4) timer-event-handler([t 20995 36800 0 60 display-time-event-handler nil nil 0]) input-pending-p() semantic-c-lexer(2939 7944 nil nil) semantic-lex(2939 7944 nil) semantic-parse-region-default(2939 7944 bovine-inner-scope nil t) semantic-parse-region-c-mode(2939 7944 bovine-inner-scope nil t) semantic-parse-region(2939 7944 bovine-inner-scope nil t) semantic-get-local-variables-default() semantic-get-local-variables-c++-mode() semantic-get-local-variables() semantic-get-all-local-variables-default(nil) semantic-get-all-local-variables() byte-code("[snipped]" [scopecache eieio-oset localvar semantic-get-all-local-variables] 4) semantic-calculate-scope(7797) semantic-analyze-current-context-default(7797) semantic-analyze-current-context(7797) byte-code("[snipped]" [semantic-analyze-current-context] 2) semantic-idle-summary-current-symbol-info-context() semantic-idle-summary-current-symbol-info-default() semantic-idle-summary-current-symbol-info-c-mode() semantic-idle-summary-current-symbol-info() semantic-idle-summary-idle-function() funcall(semantic-idle-summary-idle-function) --=-=-=-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 17:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org, deng@randomsample.de Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137598400115885 (code B ref 15045); Thu, 08 Aug 2013 17:47:02 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 17:46:41 +0000 Received: from localhost ([127.0.0.1]:47735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7UIK-000489-UG for submit@debbugs.gnu.org; Thu, 08 Aug 2013 13:46:41 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:52008) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7UIG-00047t-Lk for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 13:46:38 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MR800H003NYOP00@a-mtaout23.012.net.il> for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 20:46:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR800HB0412OM20@a-mtaout23.012.net.il>; Thu, 08 Aug 2013 20:46:14 +0300 (IDT) Date: Thu, 08 Aug 2013 20:46:29 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83fvukt6ru.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <831u65uvzk.fsf@gnu.org> <83zjssucnc.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 8 Aug 2013 13:07:01 -0400 > From: Barry OReilly > Cc: deng@randomsample.de, 15045@debbugs.gnu.org > > Eli: > > Can you identify the area in this trace where the unwarranted scroll > > was visible? > > Barry: > > but redisplay didn't need to scroll > > Undesired scrolling is a downstream symptom. Upstream from it is point > visibly moving around inappropriately. I think you are wrong. Emacs moves point in its Lisp code all over the place, and that never causes any unwarranted scrolling, nor should it ever display point in anything but the final position -- unless the Lisp code itself forces redisplay. But even if you are right, knowing which parts of the display engine are involved in this will allow us to put breakpoints in a few strategic places, and produce backtraces, both in C and in Lisp, which will show which Lisp code triggers the problem. This is IMO better than trying to guess which Lisp primitives are involved in point movement, because you are likely to guess wrong. By contrast, redisplay is certainly involved, so using it will most probably show us the light much sooner and easier. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 18:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: Eli Zaretskii , Barry OReilly , 15045@debbugs.gnu.org, "Eric M. Ludlam" Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137598519318360 (code B ref 15045); Thu, 08 Aug 2013 18:07:01 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 18:06:33 +0000 Received: from localhost ([127.0.0.1]:47766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7UbY-0004m4-Qi for submit@debbugs.gnu.org; Thu, 08 Aug 2013 14:06:33 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:48301) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7UbX-0004lr-1s for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 14:06:31 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r78I6S2j011372; Thu, 8 Aug 2013 14:06:29 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id CDF5CB48E6; Thu, 8 Aug 2013 14:06:28 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> Date: Thu, 08 Aug 2013 14:06:28 -0400 In-Reply-To: <87eha4t7xz.fsf@engster.org> (David Engster's message of "Thu, 08 Aug 2013 19:21:12 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4664=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4664> : streams <1015097> : uri <1500854> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > sit-for(0) > display-time-event-handler() > apply(display-time-event-handler nil) > byte-code("[snipped]" [timer apply 5 6] 4) > timer-event-handler([t 20995 27860 0 60 display-time-event-handler nil nil 0]) > accept-process-output() > semantic-c-lexer(2886 7946 nil nil) Right, that would do it. What happens if you remove the calls to sit-for from time.el? Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 18:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , Barry OReilly , 15045@debbugs.gnu.org, "Eric M. Ludlam" Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137598561219133 (code B ref 15045); Thu, 08 Aug 2013 18:14:01 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 18:13:32 +0000 Received: from localhost ([127.0.0.1]:47774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7UiJ-0004yX-Km for submit@debbugs.gnu.org; Thu, 08 Aug 2013 14:13:31 -0400 Received: from randomsample.de ([83.169.19.17]:46964) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7UiH-0004yN-BA for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 14:13:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=AwzLXpoONalxsciIKZVb094TnBpcWLQn3lUV48pGijk=; b=d8dVYOXemTGg7Kq1VyOgeSm6ksp0ipsiGMaz46IDJsQVTgLeoImcPOx5ErvalGsAhEVZeKiYOMvvZvEGEdWIJSLqtwzF/vymfi1xl34YWtu8472hIfl+LnvFCe7qpAj/; Received: from dslc-082-083-054-159.pools.arcor-ip.net ([82.83.54.159] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7UiC-0004cz-Oi; Thu, 08 Aug 2013 20:13:24 +0200 From: David Engster In-Reply-To: (Stefan Monnier's message of "Thu, 08 Aug 2013 14:06:28 -0400") References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Date: Thu, 08 Aug 2013 20:13:23 +0200 Message-ID: <877gfwt5j0.fsf@engster.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Stefan Monnier writes: >> sit-for(0) >> display-time-event-handler() >> apply(display-time-event-handler nil) >> byte-code("[snipped]" [timer apply 5 6] 4) >> timer-event-handler([t 20995 27860 0 60 display-time-event-handler nil nil 0]) >> accept-process-output() >> semantic-c-lexer(2886 7946 nil nil) > > Right, that would do it. > What happens if you remove the calls to sit-for from time.el? I would have thought that the time in the mode-line does not get updated when Emacs is idle, but that does still work. So I've no idea why the sit-for is there. -David From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 20:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: Eli Zaretskii , 15045@debbugs.gnu.org, Stefan Monnier , "Eric M. Ludlam" Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137599221931970 (code B ref 15045); Thu, 08 Aug 2013 20:04:02 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 20:03:39 +0000 Received: from localhost ([127.0.0.1]:47899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7WQs-0008Ja-LX for submit@debbugs.gnu.org; Thu, 08 Aug 2013 16:03:38 -0400 Received: from mail-oa0-f41.google.com ([209.85.219.41]:46482) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7WQq-0008JK-G6 for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 16:03:36 -0400 Received: by mail-oa0-f41.google.com with SMTP id j6so6065125oag.28 for <15045@debbugs.gnu.org>; Thu, 08 Aug 2013 13:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TlnkkzYQY8YHUGMa2/KY0BCMbbsN+kZrNg2gNIsNk5s=; b=rIpRbzpXEqEUtWF8tInq+g5DHXFYnRZ3PMnfgc/SflAUBeNhtgGZzCzVpbO39iQNKP FM0Z1dGj6x2s1aEtsNwxgB5vyylJLvMN9AalM+eNXD5Fbl/QvlHZPLRw6RtUPXmKISex WR1fP3pPgpKD9rhBCEPYSTm0rADV2LPTEmK22TiJDVja3jY4r3hax4gR0CZTE1nlo3Fg qAoRmLw7l6QMLX3vBtylccVrrI3GVKjVyQ25uMtWlKpTJJxuIzu/wNF5+ntgJBcCBQKw DoWw4p9N8Ahan/n7Rwbnzdri4m+8oMvDuwB7SfIVxxZPyxLrxfuftKdeVgFbv5PZOQC2 K4Zg== MIME-Version: 1.0 X-Received: by 10.60.60.105 with SMTP id g9mr5666447oer.8.1375992210109; Thu, 08 Aug 2013 13:03:30 -0700 (PDT) Received: by 10.76.89.194 with HTTP; Thu, 8 Aug 2013 13:03:30 -0700 (PDT) In-Reply-To: <87eha4t7xz.fsf@engster.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> Date: Thu, 8 Aug 2013 16:03:30 -0400 Message-ID: From: Barry OReilly Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> Undesired scrolling is a downstream symptom. Upstream from it is >> point visibly moving around inappropriately. > I think you are wrong. Emacs moves point in its Lisp code all over > the place, and that never causes any unwarranted scrolling, nor > should it ever display point in anything but the final position -- > unless the Lisp code itself forces redisplay. My use of the adverb "visibly" was meant to indicate redisplay of point at other positions. Sorry to have confused you. > timer-event-handler([t 20995 27860 0 60 display-time-event-handler nil nil 0]) > accept-process-output() > semantic-c-lexer(2886 7946 nil nil) and > timer-event-handler([t 20995 36800 0 60 display-time-event-handler nil nil 0]) > input-pending-p() > semantic-c-lexer(2939 7944 nil nil) This is indeed a key finding. If arbitrary timers can execute during the lexer's call to accept-process-output or input-pending-p, then doesn't that mean jit-lock-deferred-fontify can run too? If removing timers' sit-for calls is the solution, then what's to become of jit-lock-deferred-fontify's call to sit-for? Doesn't deferred jit locking necessarily have to call redisplay? From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 20:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: Eli Zaretskii , 15045@debbugs.gnu.org, Stefan Monnier , "Eric M. Ludlam" Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13759938373055 (code B ref 15045); Thu, 08 Aug 2013 20:31:01 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 20:30:37 +0000 Received: from localhost ([127.0.0.1]:47907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Wqy-0000nA-21 for submit@debbugs.gnu.org; Thu, 08 Aug 2013 16:30:36 -0400 Received: from randomsample.de ([83.169.19.17]:47849) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Wqu-0000my-IB for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 16:30:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=jY8UU4oZGjEMgoD+ymmWOL4aCJO0DweMlzALnfYOX3w=; b=aeCrmHvuBySaCkF9Hq1zloyt8GvbDZGY8jlGGBRWKrCYt92VvR+jOmXwwqMw0dT8yWma0tXqJXG+IU9w5JN2jMeITDz4YLFy5UTsXekIINbgsVfbFraT/2T/1Tx1SUTs; Received: from dslc-082-083-054-159.pools.arcor-ip.net ([82.83.54.159] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7Wqp-0008HI-Mw; Thu, 08 Aug 2013 22:30:27 +0200 From: David Engster In-Reply-To: (Barry OReilly's message of "Thu, 8 Aug 2013 16:03:30 -0400") References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Date: Thu, 08 Aug 2013 22:30:26 +0200 Message-ID: <8738qksz6l.fsf@engster.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Barry OReilly writes: >> timer-event-handler([t 20995 27860 0 60 display-time-event-handler nil nil 0]) >> accept-process-output() >> semantic-c-lexer(2886 7946 nil nil) > > and > >> timer-event-handler([t 20995 36800 0 60 display-time-event-handler nil nil 0]) >> input-pending-p() >> semantic-c-lexer(2939 7944 nil nil) > > This is indeed a key finding. > > If arbitrary timers can execute during the lexer's call to > accept-process-output or input-pending-p, then doesn't that mean > jit-lock-deferred-fontify can run too? Under certain circumstances I guess it could, but usually, deferred jit-lock will happen after a keypress, and that would already make the Semantic idle function quit. > If removing timers' sit-for calls is the solution, then what's to > become of jit-lock-deferred-fontify's call to sit-for? That is not the solution, at least not in general. As I've written, I think the correct fix is for Semantic to make sure we restore point before calling `semantic-throw-on-input'. Or maybe we should do this in `semantic-exit-on-input'; I'm not sure. However, doing redisplay in timers is not nice. If it is not necessary, like maybe in the time-display handler, then it should be removed. > Doesn't deferred jit locking necessarily have to call redisplay? I would think so, too. -David From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 21:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , "Eric M. Ludlam" Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13759972149789 (code B ref 15045); Thu, 08 Aug 2013 21:27:01 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 21:26:54 +0000 Received: from localhost ([127.0.0.1]:47975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7XjR-0002Xp-Tx for submit@debbugs.gnu.org; Thu, 08 Aug 2013 17:26:54 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:57974) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7XjQ-0002Xb-4D for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 17:26:52 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r78LQo4o015950; Thu, 8 Aug 2013 17:26:50 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 1A761B48E6; Thu, 8 Aug 2013 17:26:50 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> Date: Thu, 08 Aug 2013 17:26:50 -0400 In-Reply-To: (Barry OReilly's message of "Thu, 8 Aug 2013 16:03:30 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4664=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4664> : streams <1015201> : uri <1501008> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > If arbitrary timers can execute during the lexer's call to > accept-process-output or input-pending-p, then doesn't that mean > jit-lock-deferred-fontify can run too? Yes. > If removing timers' sit-for calls is the solution, It's a workaround. > then what's to become of jit-lock-deferred-fontify's call to sit-for? > Doesn't deferred jit locking necessarily have to call redisplay? Yes, tho I guess if absolutely needed, we could probably arrange for jit-lock-deferred-fontify not to call sit-for. I'm not completely sure how that could work, but it doesn't sound impossible. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 21:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137599794811186 (code B ref 15045); Thu, 08 Aug 2013 21:40:01 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 21:39:08 +0000 Received: from localhost ([127.0.0.1]:48001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7XvH-0002uJ-Fg for submit@debbugs.gnu.org; Thu, 08 Aug 2013 17:39:07 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:52926) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7XvE-0002tk-5K for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 17:39:05 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MR800G00EJG5Y00@a-mtaout21.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 00:38:57 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR800GEJESV3360@a-mtaout21.012.net.il>; Fri, 09 Aug 2013 00:38:55 +0300 (IDT) Date: Fri, 09 Aug 2013 00:39:10 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83bo57uakh.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Barry OReilly , 15045@debbugs.gnu.org, > "Eric M. Ludlam" , Eli Zaretskii > Date: Thu, 08 Aug 2013 14:06:28 -0400 > > > sit-for(0) > > display-time-event-handler() > > apply(display-time-event-handler nil) > > byte-code("[snipped]" [timer apply 5 6] 4) > > timer-event-handler([t 20995 27860 0 60 display-time-event-handler nil nil 0]) > > accept-process-output() > > semantic-c-lexer(2886 7946 nil nil) > > Right, that would do it. > What happens if you remove the calls to sit-for from time.el? You cannot ensure redisplay without that. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 21:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137599846516095 (code B ref 15045); Thu, 08 Aug 2013 21:48:01 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 21:47:45 +0000 Received: from localhost ([127.0.0.1]:48026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Y3c-0004BW-Jq for submit@debbugs.gnu.org; Thu, 08 Aug 2013 17:47:44 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:46614) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Y3a-0004BH-0A for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 17:47:43 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MR800I00F11GR00@a-mtaout23.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 00:47:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR800IFZF789V90@a-mtaout23.012.net.il>; Fri, 09 Aug 2013 00:47:35 +0300 (IDT) Date: Fri, 09 Aug 2013 00:47:47 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <838v0bua64.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 8 Aug 2013 16:03:30 -0400 > From: Barry OReilly > Cc: Stefan Monnier , 15045@debbugs.gnu.org, > "Eric M. Ludlam" , Eli Zaretskii > > If arbitrary timers can execute during the lexer's call to > accept-process-output or input-pending-p, then doesn't that mean > jit-lock-deferred-fontify can run too? Not normally, because jit-lock-deferred-fontify runs off an idle timer, and Emacs is not idle in the situation you describe. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 21:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137599858316329 (code B ref 15045); Thu, 08 Aug 2013 21:50:02 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 21:49:43 +0000 Received: from localhost ([127.0.0.1]:48030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Y5W-0004FI-8R for submit@debbugs.gnu.org; Thu, 08 Aug 2013 17:49:42 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:39454) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Y5T-0004F4-Pg for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 17:49:40 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MR800E00F5HL700@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 00:49:33 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR800E79FAKKQ10@a-mtaout20.012.net.il>; Fri, 09 Aug 2013 00:49:33 +0300 (IDT) Date: Fri, 09 Aug 2013 00:49:48 +0300 From: Eli Zaretskii In-reply-to: <8738qksz6l.fsf@engster.org> X-012-Sender: halo1@inter.net.il Message-id: <837gfvua2r.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: David Engster > Cc: Stefan Monnier , 15045@debbugs.gnu.org, "Eric M. Ludlam" , Eli Zaretskii > Date: Thu, 08 Aug 2013 22:30:26 +0200 > > However, doing redisplay in timers is not nice. Why not? > > Doesn't deferred jit locking necessarily have to call redisplay? > > I would think so, too. But since jit-lock-deferred-fontify only happens when Emacs is idle, there's no problem with that, since Emacs enters redisplay also when it is idle. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 21:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137599902817156 (code B ref 15045); Thu, 08 Aug 2013 21:58:02 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 21:57:08 +0000 Received: from localhost ([127.0.0.1]:48039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7YCh-0004Se-K2 for submit@debbugs.gnu.org; Thu, 08 Aug 2013 17:57:07 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:47357) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7YCe-0004S8-Ma for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 17:57:05 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MR800I00FEFHH00@a-mtaout23.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 00:56:58 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR800IJ6FMXDS40@a-mtaout23.012.net.il>; Fri, 09 Aug 2013 00:56:58 +0300 (IDT) Date: Fri, 09 Aug 2013 00:57:13 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <834nazu9qe.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: David Engster , 15045@debbugs.gnu.org, > "Eric M. Ludlam" , Eli Zaretskii > Date: Thu, 08 Aug 2013 17:26:50 -0400 > > > If arbitrary timers can execute during the lexer's call to > > accept-process-output or input-pending-p, then doesn't that mean > > jit-lock-deferred-fontify can run too? > > Yes. No, I don't think so, because idle timers don't run. > > If removing timers' sit-for calls is the solution, > > It's a workaround. I think the right solution is to not call input-pending-p etc. during lexer run. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 22:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137600226222861 (code B ref 15045); Thu, 08 Aug 2013 22:52:01 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 22:51:02 +0000 Received: from localhost ([127.0.0.1]:48096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Z2r-0005wN-BF for submit@debbugs.gnu.org; Thu, 08 Aug 2013 18:51:01 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:10134) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Z2o-0005w8-B8 for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 18:50:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDSQuh3AGwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDSQuh3AGwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="21139360" Received: from 75-119-243-106.dsl.teksavvy.com (HELO pastel.home) ([75.119.243.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 08 Aug 2013 18:50:42 -0400 Received: by pastel.home (Postfix, from userid 20848) id E7EC0630B6; Thu, 8 Aug 2013 18:50:42 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <834nazu9qe.fsf@gnu.org> Date: Thu, 08 Aug 2013 18:50:42 -0400 In-Reply-To: <834nazu9qe.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Aug 2013 00:57:13 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> > If arbitrary timers can execute during the lexer's call to >> > accept-process-output or input-pending-p, then doesn't that mean >> > jit-lock-deferred-fontify can run too? >> Yes. > No, I don't think so, because idle timers don't run. You might be right, indeed. >> > If removing timers' sit-for calls is the solution, >> It's a workaround. > I think the right solution is to not call input-pending-p etc. during > lexer run. Not calling accept-process-output might be tricky. And not calling input-pending-p can also require very significant code changes (I think support for concurrency would help a lot here). Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2013 22:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137600228922907 (code B ref 15045); Thu, 08 Aug 2013 22:52:02 +0000 Received: (at 15045) by debbugs.gnu.org; 8 Aug 2013 22:51:29 +0000 Received: from localhost ([127.0.0.1]:48100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Z3J-0005xP-9M for submit@debbugs.gnu.org; Thu, 08 Aug 2013 18:51:29 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:41663) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Z3G-0005xB-6m for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 18:51:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDSSIHgbBLZEKA6R6gV6DEw X-IPAS-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDSSIHgbBLZEKA6R6gV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="21139394" Received: from 75-119-243-106.dsl.teksavvy.com (HELO pastel.home) ([75.119.243.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 08 Aug 2013 18:51:13 -0400 Received: by pastel.home (Postfix, from userid 20848) id F41A4630B6; Thu, 8 Aug 2013 18:51:17 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <83bo57uakh.fsf@gnu.org> Date: Thu, 08 Aug 2013 18:51:17 -0400 In-Reply-To: <83bo57uakh.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Aug 2013 00:39:10 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> Right, that would do it. >> What happens if you remove the calls to sit-for from time.el? > You cannot ensure redisplay without that. I don't know what scenario you have in mind. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: "Eric M. Ludlam" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 03:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: Eli Zaretskii , Barry OReilly , 15045@debbugs.gnu.org, Stefan Monnier Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137601881026831 (code B ref 15045); Fri, 09 Aug 2013 03:27:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 03:26:50 +0000 Received: from localhost ([127.0.0.1]:48452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7dLl-0006yh-Ta for submit@debbugs.gnu.org; Thu, 08 Aug 2013 23:26:50 -0400 Received: from mail-vb0-f49.google.com ([209.85.212.49]:50247) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7dLi-0006yR-1G for 15045@debbugs.gnu.org; Thu, 08 Aug 2013 23:26:46 -0400 Received: by mail-vb0-f49.google.com with SMTP id w16so3775540vbb.36 for <15045@debbugs.gnu.org>; Thu, 08 Aug 2013 20:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=I/E5M75B1qJAvz5aw9NeWTQeBnLyOWZAxEEDPoy9xxs=; b=a/bx532C296Fskmh04lRHeFFX3bkVh6Og73YPYX+/t6wYNp/D6nbnrTat8dkb69S1N MKvqwq9gGFQ7uJphCqeHoVqxRQHQqyRzj6Es/ctqLvGF02sp4Lo50Ck0CqRlYXTyNzSs fKNMKNO61h408fvAzvQDn5uTdNK6g/XGPn3Zpx0YZIPnwBCLuVuVTzb8DT4wcoE0ngbc Vd3aS+P+wQVv2sa5S5pSDx52g0ywHLHZBShC9/K/RdBEEZa794+vCk7SH/JGa6aNDm2w KfOoMbAfZ4urYPiD5cSFQZL+6J41sRDg1ueYL8B+MUloDLcJYiK9dSineygDoJnMzVCP Svww== X-Received: by 10.58.19.136 with SMTP id f8mr3111777vee.98.1376018800281; Thu, 08 Aug 2013 20:26:40 -0700 (PDT) Received: from [192.168.1.201] (pool-72-74-140-235.bstnma.fios.verizon.net. [72.74.140.235]) by mx.google.com with ESMTPSA id p10sm9550271vdi.7.2013.08.08.20.26.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 20:26:39 -0700 (PDT) Message-ID: <5204616D.4020702@siege-engine.com> Date: Thu, 08 Aug 2013 23:26:37 -0400 From: "Eric M. Ludlam" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre MIME-Version: 1.0 References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> In-Reply-To: <87eha4t7xz.fsf@engster.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 08/08/2013 01:21 PM, David Engster wrote: > [Adding Eric to CC] > > David Engster writes: > > It's kinda hard to trigger this problem through jit-lock, since its idle > time is much smaller than the one from Semantic. So I disabled it and > tried to trigger the jump by stopping typing at roughly XX:XX:59. The > semantic idle function kicks in after 1 second, and lo and behold, I saw > a jump. It's still difficult to reproduce, but I managed to get two > backtraces in the past hour, which are attached. > > As you can see, the display-time-event-handler does indeed interrupt the > lexing phase. It does a `sit-for', the display jumps. Not sure what > happens after that. Does the semantic-idle function resume? Anyway, > somehow point gets back to its original position, and through > `trace-redisplay', I saw the following on stderr: David, this is some impressing debugging. Thanks for investigating so thoroughly. > You might wonder how the display-time-event-handler can interrupt the > Semantic lexer. In the two backtraces, you see that it calls > `accept-process-output' and `input-pending-p'. This is hidden inside the > macro `semantic-throw-on-input', which can be called in code wrapped > inside `semantic-exit-on-input'; it's our poor-man's 'yield'. It's used > extensively in the idle function code, and it's just there to do a > non-local exit in case the user does something. However, now I know that > it also allows other timers to run. > > If you look in the `define-lex' macro, you see that it calls > `semantic-throw-on-input' after each identified token. The problem is > that it does not restore the cursor position before that, so I guess the > fix is simply to change this call to > > (save-excursion > (goto-char starting-position) > (semantic-throw-on-input 'lex)) I pulled up some of the bigger C files in Emacs, ran the lexer, and they all took less than .3 second to lex. It may also be safe to remove this interactive optimization and just depend on input checking that happens during parsing. The detriment is that if someone had a really big file, they might notice that Emacs stops responding if lexing takes a long time. Eric From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 05:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137602657411778 (code B ref 15045); Fri, 09 Aug 2013 05:37:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 05:36:14 +0000 Received: from localhost ([127.0.0.1]:48582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7fMz-00033q-VP for submit@debbugs.gnu.org; Fri, 09 Aug 2013 01:36:14 -0400 Received: from randomsample.de ([83.169.19.17]:54805) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7fMx-00033a-VC for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 01:36:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=DfU8kQzPUde22LRsXaM1xLnet2H38x49Qk/1B+WJvrY=; b=uY1BXv1Rem98jT4qf7P7OXeZpc7hMoU110CXAsJfWIcMo2DKKHk9QQ79hhyA48Lgu8NkqbxqsfWJKH3+okNAwDA8lNgVzVVwVT0xv1BViGuIUIwFJduBtQvfPruQ9k9N; Received: from dslc-082-083-054-159.pools.arcor-ip.net ([82.83.54.159] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7fMu-0005lX-Ra; Fri, 09 Aug 2013 07:36:09 +0200 From: David Engster In-Reply-To: <837gfvua2r.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Aug 2013 00:49:48 +0300") References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Date: Fri, 09 Aug 2013 07:36:07 +0200 Message-ID: <87y58bs9x4.fsf@engster.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> From: David Engster >> Cc: Stefan Monnier , >> 15045@debbugs.gnu.org, "Eric M. Ludlam" , Eli >> Zaretskii >> Date: Thu, 08 Aug 2013 22:30:26 +0200 >> >> However, doing redisplay in timers is not nice. > > Why not? Because doing redisplay is a user-visible side effect, and in general, timers shouldn't have those. AFAICS, any function that calls things like `accept-process-output', `input-pending-p' or `sit-for' inside a `save-excursion' might get an unwanted scrolling effect if point is temporarily moved to some invisible location. In fact, I just understood another bug in speck-mode (which is similar to flycheck). I sometimes had unwanted scrolls there, too, and I now saw that those also happen at every full minute while typing. >> > Doesn't deferred jit locking necessarily have to call redisplay? >> >> I would think so, too. > > But since jit-lock-deferred-fontify only happens when Emacs is idle, > there's no problem with that, since Emacs enters redisplay also when > it is idle. I thought that the jit-lock timer is a non-idle timer, but you are right. -David From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 07:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137603481028866 (code B ref 15045); Fri, 09 Aug 2013 07:54:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 07:53:30 +0000 Received: from localhost ([127.0.0.1]:48824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7hVo-0007VP-VV for submit@debbugs.gnu.org; Fri, 09 Aug 2013 03:53:29 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:45701) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7hVk-0007V1-LE for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 03:53:26 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MR90090077YX400@a-mtaout22.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 10:53:18 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR9009F778TMJ90@a-mtaout22.012.net.il>; Fri, 09 Aug 2013 10:53:17 +0300 (IDT) Date: Fri, 09 Aug 2013 10:53:33 +0300 From: Eli Zaretskii In-reply-to: <87y58bs9x4.fsf@engster.org> X-012-Sender: halo1@inter.net.il Message-id: <83zjsrs3k2.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: David Engster > Cc: gundaetiapo@gmail.com, monnier@iro.umontreal.ca, 15045@debbugs.gnu.org, eric@siege-engine.com > Date: Fri, 09 Aug 2013 07:36:07 +0200 > > >> However, doing redisplay in timers is not nice. > > > > Why not? > > Because doing redisplay is a user-visible side effect, and in general, > timers shouldn't have those. How else can a timer such as that of display-time do its thing? IOW, when the purpose of a timer is to cause something to be displayed, they have no alternative but to force redisplay. > AFAICS, any function that calls things like > `accept-process-output', `input-pending-p' or `sit-for' inside a > `save-excursion' might get an unwanted scrolling effect if point is > temporarily moved to some invisible location. You mean, because of timers that might get run and cause redisplay? Yes, that's possible. But the way to avoid this is to never call these when point is in a place the user won't expect. Forcing the Emacs community not to trigger redisplay inside timers is IMO _not_ the right way, because this is unnecessarily restrictive, and would disallow a whole bunch of useful features for no good reason. IOW, it's the caller of input-pending-p etc. that is the fault here, not the timers that it inadvertently lets run. > In fact, I just understood another bug in speck-mode (which is similar > to flycheck). I sometimes had unwanted scrolls there, too, and I now saw > that those also happen at every full minute while typing. Then there's the same bug there, that's all. Doing things in the background is hard in Emacs, so it's a small wonder some modes get it wrong. > >> > Doesn't deferred jit locking necessarily have to call redisplay? > >> > >> I would think so, too. > > > > But since jit-lock-deferred-fontify only happens when Emacs is idle, > > there's no problem with that, since Emacs enters redisplay also when > > it is idle. > > I thought that the jit-lock timer is a non-idle timer, but you are > right. There's no jit-lock timer. There are timers for jit-lock-stealth and for jit-lock-deferred-fontify (both optional features), and they are all idle timers. JIT Lock itself is not triggered by any timer, it is invoked by redisplay when a portion of text that is not fontified yet comes into view. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 07:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137603489329093 (code B ref 15045); Fri, 09 Aug 2013 07:55:01 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 07:54:53 +0000 Received: from localhost ([127.0.0.1]:48840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7hXA-0007ZA-8y for submit@debbugs.gnu.org; Fri, 09 Aug 2013 03:54:52 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:61561) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7hX6-0007Yi-BQ for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 03:54:49 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MR900J006GD2900@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 10:54:42 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR900I3I7B5QX90@a-mtaout20.012.net.il>; Fri, 09 Aug 2013 10:54:41 +0300 (IDT) Date: Fri, 09 Aug 2013 10:54:58 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83y58bs3hp.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <834nazu9qe.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: gundaetiapo@gmail.com, deng@randomsample.de, 15045@debbugs.gnu.org, eric@siege-engine.com > Date: Thu, 08 Aug 2013 18:50:42 -0400 > > > I think the right solution is to not call input-pending-p etc. during > > lexer run. > > Not calling accept-process-output might be tricky. > And not calling input-pending-p can also require very significant > code changes (I think support for concurrency would help a lot here). Then perhaps the code which calls them should make sure to move point to where the user expects it, before it does call those APIs. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 07:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137603501329452 (code B ref 15045); Fri, 09 Aug 2013 07:57:01 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 07:56:53 +0000 Received: from localhost ([127.0.0.1]:48849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7hZ6-0007ex-F4 for submit@debbugs.gnu.org; Fri, 09 Aug 2013 03:56:52 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:53962) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7hZ3-0007ec-HY for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 03:56:50 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MR900K007EGEW00@a-mtaout23.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 10:56:43 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR900KB57EIC560@a-mtaout23.012.net.il>; Fri, 09 Aug 2013 10:56:43 +0300 (IDT) Date: Fri, 09 Aug 2013 10:56:59 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83wqnvs3ec.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <83bo57uakh.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: deng@randomsample.de, gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com > Date: Thu, 08 Aug 2013 18:51:17 -0400 > > >> Right, that would do it. > >> What happens if you remove the calls to sit-for from time.el? > > You cannot ensure redisplay without that. > > I don't know what scenario you have in mind. Any one. Emacs enters redisplay for any number of reasons, but you can never be sure it will do so at any specific point unless you force redisplay at that point. As you well know, in general, while Lisp code runs, Emacs does not redisplay. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 09:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: Eli Zaretskii , gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13760395378237 (code B ref 15045); Fri, 09 Aug 2013 09:13:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 09:12:17 +0000 Received: from localhost ([127.0.0.1]:48930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7ik3-00028m-Ld for submit@debbugs.gnu.org; Fri, 09 Aug 2013 05:12:16 -0400 Received: from mout.gmx.net ([212.227.15.19]:55726) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7ik1-00028Y-OI for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 05:12:14 -0400 Received: from [62.47.33.45] ([62.47.33.45]) by mail.gmx.com (mrgmx003) with ESMTPA (Nemesis) id 0MXqaN-1VcGPZ3EcZ-00Wj0T for <15045@debbugs.gnu.org>; Fri, 09 Aug 2013 11:12:07 +0200 Message-ID: <5204B263.1060603@gmx.at> Date: Fri, 09 Aug 2013 11:12:03 +0200 From: martin rudalics MIME-Version: 1.0 References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> In-Reply-To: <87y58bs9x4.fsf@engster.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VWIGCWH5GcTgFi+orM+h+0ciaeJbS/+Bad9xf+Ehpi7QjNo0O4D r8d1lDt0+XiZ7wk/bNWKxBgagm9h466Sii+R6HUE1EWDWVhNmTEIbDEB++TFAs0qMFh9ZW1 fQvHHgCnUWHfotZx5KjDcU4mX8yHtvt7yQ9ns+ex8SULkhF9dMbYB/xBCxUuoydL2Ej5AsO usSYrjZbWEC4fPXRvwjEQ== X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > In fact, I just understood another bug in speck-mode (which is similar > to flycheck). I sometimes had unwanted scrolls there, too, and I now saw > that those also happen at every full minute while typing. What precisely is the bug in speck-mode? Is it that it doesn't restore `point' when input arrives? martin From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: "Eric M. Ludlam" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 11:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, David Engster Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13760490301158 (code B ref 15045); Fri, 09 Aug 2013 11:51:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 11:50:30 +0000 Received: from localhost ([127.0.0.1]:49054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7lDB-0000Ib-C5 for submit@debbugs.gnu.org; Fri, 09 Aug 2013 07:50:29 -0400 Received: from mail-vb0-f42.google.com ([209.85.212.42]:51722) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7lD9-0000IL-Ju for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 07:50:28 -0400 Received: by mail-vb0-f42.google.com with SMTP id e12so3995307vbg.1 for <15045@debbugs.gnu.org>; Fri, 09 Aug 2013 04:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3jIYIyrV1S7fyMY8VpAHR1u7/c8d9xEo2lWJKuAg8kQ=; b=LLIY4LQ9BaJdkkpKdZIAmxKHfSACJnOt54KvWV+tVdZmMc/+nJctRNVbVwjg74BcZY wtUflhpdTzu0Cnk1wntpTZ1qHMcgFFyCfy+W1xP7jVjPC9BlY+s//8kISB4iiNhKK1gM i56ET9Jj2X4chy7Gyia1FYMeXTefGc6beDRdRmTCzYMoHhbVkFLpPmqL6ZfNFYHY/Kj2 Ui21VW5FOGYcItNkQxoRfcRUfbVutRJ9jhh/yapLdczEbg4MbpcKSK9mmmCtG2U6Y/9p Y2GP6tRaEiFAysIBGbYTBETnsI5gU9xl8h/HUEC/vX0d9EXevA4So3aTdl+zezUv3VOb 3WCg== X-Received: by 10.52.52.132 with SMTP id t4mr4627616vdo.65.1376049021966; Fri, 09 Aug 2013 04:50:21 -0700 (PDT) Received: from [192.168.1.201] (pool-72-74-140-235.bstnma.fios.verizon.net. [72.74.140.235]) by mx.google.com with ESMTPSA id eg5sm10536163vdc.9.2013.08.09.04.50.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 04:50:20 -0700 (PDT) Message-ID: <5204D77B.2040900@siege-engine.com> Date: Fri, 09 Aug 2013 07:50:19 -0400 From: "Eric M. Ludlam" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre MIME-Version: 1.0 References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> In-Reply-To: <83zjsrs3k2.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 08/09/2013 03:53 AM, Eli Zaretskii wrote: >> AFAICS, any function that calls things like >> `accept-process-output', `input-pending-p' or `sit-for' inside a >> `save-excursion' might get an unwanted scrolling effect if point is >> temporarily moved to some invisible location. > > You mean, because of timers that might get run and cause redisplay? > Yes, that's possible. But the way to avoid this is to never call > these when point is in a place the user won't expect. Forcing the > Emacs community not to trigger redisplay inside timers is IMO _not_ > the right way, because this is unnecessarily restrictive, and would > disallow a whole bunch of useful features for no good reason. > > IOW, it's the caller of input-pending-p etc. that is the fault here, > not the timers that it inadvertently lets run. In my mind, to anyone using input-pending-p to deal with responsiveness in long running code, a timer that causes a redisplay is the source of the problem. In addition, it is clear that anyone with a sit-for in their timer will think that moving the point and calling input-pending-p is a bug. Even if we resolve which is the real bug, or at least the proposed solution here, people will still cause redisplays in timeres, and call input-pending-p in long running code, and those problems will need to be debugged again in the future. It seems like it would be more developer friendly for Emacs to enforce some kind of behavior with timers so as to remove this class of collision. Here are some random options: * In a timer, disallow dispatch of other timers until done. * Record redisplay requests in timers, and force redisplay when the timer exists. * In input-pending-p, dont' allow new timers to run, doc only talks about command input, not timers. * In timers, redisplay always assumes you don't want to move point and puts it back before the draw. It is clear to me that there are valid use cases for both redisplay in a timer, and input-pending-p being used in long-running programs. Adding funky restrictions to either seems untenable with the size of the Emacs dev community. It would be better to tackle the problem at its source. Eric From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 13:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Eric M. Ludlam" Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, deng@randomsample.de Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137605513912808 (code B ref 15045); Fri, 09 Aug 2013 13:33:01 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 13:32:19 +0000 Received: from localhost ([127.0.0.1]:49245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7mni-0003KV-Id for submit@debbugs.gnu.org; Fri, 09 Aug 2013 09:32:19 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:47262) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7mnf-0003KE-BU for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 09:32:16 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MR900L00MTXIZ00@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 16:31:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR900LQVMWD3XA0@a-mtaout20.012.net.il>; Fri, 09 Aug 2013 16:31:26 +0300 (IDT) Date: Fri, 09 Aug 2013 16:31:43 +0300 From: Eli Zaretskii In-reply-to: <5204D77B.2040900@siege-engine.com> X-012-Sender: halo1@inter.net.il Message-id: <83li4brnwg.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <5204D77B.2040900@siege-engine.com> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 09 Aug 2013 07:50:19 -0400 > From: "Eric M. Ludlam" > CC: David Engster , gundaetiapo@gmail.com, > monnier@iro.umontreal.ca, 15045@debbugs.gnu.org > > > IOW, it's the caller of input-pending-p etc. that is the fault here, > > not the timers that it inadvertently lets run. > > In my mind, to anyone using input-pending-p to deal with responsiveness > in long running code, a timer that causes a redisplay is the source of > the problem. Emacs is a complex piece of software. We cannot remove that complexity no matter how hard we try. And yes, this requires developers to be aware of what can happen when they call certain APIs. There's nothing new here. > Even if we resolve which is the real bug, or at least the proposed > solution here, people will still cause redisplays in timeres, and call > input-pending-p in long running code, and those problems will need to be > debugged again in the future. Again, nothing new. It's okay to propose solutions to these issues, but a "solution" which tells timers not to force redisplay is a non-starter, IMO, because some of them cannot do their thing without displaying something at specific times. > * In a timer, disallow dispatch of other timers until done. Sounds not a good idea to me, as too many useful features use timers, and users will be surprised to see them sometimes unable to run. > * Record redisplay requests in timers, and force redisplay when the > timer exists. Not good for timers that must display at certain times, with minimal delays. > * In input-pending-p, dont' allow new timers to run, > doc only talks about command input, not timers. What if input arrives because of a timer? > * In timers, redisplay always assumes you don't want to move point and > puts it back before the draw. Redisplay doesn't have any idea where is "back". When redisplay is entered, it finds point at a certain location. It has no idea where it was before, all it knows (in some cases, not all of them) is where point was in each window during the last redisplay cycle, which could be 5 msec ago or 5 min ago. > It is clear to me that there are valid use cases for both redisplay in a > timer, and input-pending-p being used in long-running programs. Adding > funky restrictions to either seems untenable with the size of the Emacs > dev community. It would be better to tackle the problem at its source. I'm sorry, but I don't see "the source" here. What is the source of the problem, in your opinion? In my opinion, the source of the problem is that application code moves point to a place it didn't intend the user to see, and then calls some APIs that trigger redisplay and reveal that location of point (and potentially even cause a scroll). The solution could be (a) avoid triggering redisplay, or (b) restore point before calling something that could cause redisplay. What other solutions do you envision that don't limit the basic features involved in this? From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 14:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137605700416768 (code B ref 15045); Fri, 09 Aug 2013 14:04:01 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 14:03:24 +0000 Received: from localhost ([127.0.0.1]:49735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7nHm-0004MN-S8 for submit@debbugs.gnu.org; Fri, 09 Aug 2013 10:03:23 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:34350) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7nHd-0004M3-Qz for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 10:03:18 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IfAQVWIxALNBIUGA0kiCTBLZEKA6R6gV6DEw X-IPAS-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IfAQVWIxALNBIUGA0kiCTBLZEKA6R6gV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="21214426" Received: from 75-119-243-106.dsl.teksavvy.com (HELO pastel.home) ([75.119.243.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 09 Aug 2013 10:03:01 -0400 Received: by pastel.home (Postfix, from userid 20848) id 6493D66AD4; Fri, 9 Aug 2013 10:03:05 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <83bo57uakh.fsf@gnu.org> <83wqnvs3ec.fsf@gnu.org> Date: Fri, 09 Aug 2013 10:03:05 -0400 In-Reply-To: <83wqnvs3ec.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Aug 2013 10:56:59 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> >> Right, that would do it. >> >> What happens if you remove the calls to sit-for from time.el? >> > You cannot ensure redisplay without that. >> I don't know what scenario you have in mind. > Any one. Emacs enters redisplay for any number of reasons, but you > can never be sure it will do so at any specific point unless you force > redisplay at that point. As you well know, in general, while Lisp > code runs, Emacs does not redisplay. Of course, but that's true in general. What makes it more true in display-time-event-handler? Remember that display-time-update (called just before the sit-for) ends with a call to force-mode-line-update. In practice, is there any important scenario where display-time-event-handler's sit-for is useful? Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 14:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Eric M. Ludlam" Cc: Eli Zaretskii , gundaetiapo@gmail.com, 15045@debbugs.gnu.org, David Engster Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137605709217041 (code B ref 15045); Fri, 09 Aug 2013 14:05:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 14:04:52 +0000 Received: from localhost ([127.0.0.1]:49739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7nJD-0004Qe-11 for submit@debbugs.gnu.org; Fri, 09 Aug 2013 10:04:51 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:47724) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7nJB-0004QE-Cx for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 10:04:49 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="21214661" Received: from 75-119-243-106.dsl.teksavvy.com (HELO pastel.home) ([75.119.243.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 09 Aug 2013 10:04:37 -0400 Received: by pastel.home (Postfix, from userid 20848) id 1D31566AD4; Fri, 9 Aug 2013 10:04:41 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <5204D77B.2040900@siege-engine.com> Date: Fri, 09 Aug 2013 10:04:41 -0400 In-Reply-To: <5204D77B.2040900@siege-engine.com> (Eric M. Ludlam's message of "Fri, 09 Aug 2013 07:50:19 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > In my mind, to anyone using input-pending-p to deal with responsiveness in Actually, now that I think about it. Why would input-pending-p run timers? That sounds wrong. Of course, fixing it won't change anything to the OP's problem since he also has backtraces where the problem is triggered via accept-process-output. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 14:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137605779418475 (code B ref 15045); Fri, 09 Aug 2013 14:17:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 14:16:34 +0000 Received: from localhost ([127.0.0.1]:49769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7nUX-0004nt-PX for submit@debbugs.gnu.org; Fri, 09 Aug 2013 10:16:34 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:58734) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7nUV-0004nd-Ld for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 10:16:32 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MR900L00OWQSE00@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 17:16:25 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR900L06OZARI20@a-mtaout20.012.net.il>; Fri, 09 Aug 2013 17:16:22 +0300 (IDT) Date: Fri, 09 Aug 2013 17:16:39 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <837gfvrltk.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <83bo57uakh.fsf@gnu.org> <83wqnvs3ec.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: deng@randomsample.de, gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com > Date: Fri, 09 Aug 2013 10:03:05 -0400 > > >> >> Right, that would do it. > >> >> What happens if you remove the calls to sit-for from time.el? > >> > You cannot ensure redisplay without that. > >> I don't know what scenario you have in mind. > > Any one. Emacs enters redisplay for any number of reasons, but you > > can never be sure it will do so at any specific point unless you force > > redisplay at that point. As you well know, in general, while Lisp > > code runs, Emacs does not redisplay. > > Of course, but that's true in general. What makes it more true in > display-time-event-handler? Why should we care? Good engineering does not build things on what "currently happens to work", because that will eventually break, given enough development. > Remember that display-time-update (called just before the sit-for) > ends with a call to force-mode-line-update. Whose effect no one really understands. > In practice, is there any important scenario where > display-time-event-handler's sit-for is useful? I never analyzed this to tell. And anyway, display-time is just one case of a timer that needs to force redisplay. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 14:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137605804518971 (code B ref 15045); Fri, 09 Aug 2013 14:21:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 14:20:45 +0000 Received: from localhost ([127.0.0.1]:49777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7nYa-0004vu-Sa for submit@debbugs.gnu.org; Fri, 09 Aug 2013 10:20:45 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:44547) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7nYX-0004ve-0P for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 10:20:42 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MR900J00OZW5C00@a-mtaout21.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 17:19:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR900JNOP4M5G00@a-mtaout21.012.net.il>; Fri, 09 Aug 2013 17:19:35 +0300 (IDT) Date: Fri, 09 Aug 2013 17:19:52 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <8361vfrlo7.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <5204D77B.2040900@siege-engine.com> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , David Engster , gundaetiapo@gmail.com, 15045@debbugs.gnu.org > Date: Fri, 09 Aug 2013 10:04:41 -0400 > > > In my mind, to anyone using input-pending-p to deal with responsiveness in > > Actually, now that I think about it. Why would input-pending-p > run timers? The code is very explicit: DEFUN ("input-pending-p", Finput_pending_p, Sinput_pending_p, 0, 0, 0, doc: /* Return t if command input is currently available with no wait. Actually, the value is nil only if we can be sure that no input is available; if there is a doubt, the value is t. */) (void) { if (!NILP (Vunread_command_events) || !NILP (Vunread_post_input_method_events) || !NILP (Vunread_input_method_events)) return (Qt); /* Process non-user-visible events (Bug#10195). */ process_special_events (); return (get_input_pending (READABLE_EVENTS_DO_TIMERS_NOW ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | READABLE_EVENTS_FILTER_EVENTS) ? Qt : Qnil); > That sounds wrong. Are you saying that using the READABLE_EVENTS_FILTER_EVENTS flag above is wrong? > Of course, fixing it won't change anything to the OP's problem since he > also has backtraces where the problem is triggered via > accept-process-output. Right. Emacs generally always runs timers when it waits. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 16:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13760646193749 (code B ref 15045); Fri, 09 Aug 2013 16:11:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 16:10:19 +0000 Received: from localhost ([127.0.0.1]:49962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7pGZ-0000yG-MJ for submit@debbugs.gnu.org; Fri, 09 Aug 2013 12:10:16 -0400 Received: from randomsample.de ([83.169.19.17]:45097) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7pGS-0000xx-I0 for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 12:10:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=PfaCMo+v/XNcc/V3/FIP/a6mVnVvpHBQQJI2gGRGNUU=; b=tAYVe1oQSmRjRjpl9XYZvO1KjqbY6fFNw0p+DI3xy3ogzK3AVyWbFv4rld626mfTRJ+YAmUREolE0BE+lF2Lz230b5/1m1++I3sT9olSYPVGD+geO91j9H7Vp+FvKOuM; Received: from dslc-082-083-054-159.pools.arcor-ip.net ([82.83.54.159] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7pGP-0000QO-2p; Fri, 09 Aug 2013 18:10:05 +0200 From: David Engster In-Reply-To: <83zjsrs3k2.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Aug 2013 10:53:33 +0300") References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Date: Fri, 09 Aug 2013 18:10:04 +0200 Message-ID: <87pptmsv4z.fsf@engster.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> From: David Engster >> Cc: gundaetiapo@gmail.com, monnier@iro.umontreal.ca, >> 15045@debbugs.gnu.org, eric@siege-engine.com > >> Date: Fri, 09 Aug 2013 07:36:07 +0200 >> >> >> However, doing redisplay in timers is not nice. >> > >> > Why not? >> >> Because doing redisplay is a user-visible side effect, and in general, >> timers shouldn't have those. > > How else can a timer such as that of display-time do its thing? IOW, > when the purpose of a timer is to cause something to be displayed, > they have no alternative but to force redisplay. As you know, Emacs does not have strict timers. If you say to Emacs: one minute from now, say 'foo', and Emacs happens to be busy one minute from now, nothing will happen until it waits again. So I wonder: with such a lenient definition of "timer", does the wait for the next redisplay really matter? After which idle time does redisplay kick in anyway? >> AFAICS, any function that calls things like >> `accept-process-output', `input-pending-p' or `sit-for' inside a >> `save-excursion' might get an unwanted scrolling effect if point is >> temporarily moved to some invisible location. > > You mean, because of timers that might get run and cause redisplay? Yes. > Yes, that's possible. But the way to avoid this is to never call > these when point is in a place the user won't expect. Forcing the > Emacs community not to trigger redisplay inside timers is IMO _not_ > the right way, because this is unnecessarily restrictive, and would > disallow a whole bunch of useful features for no good reason. I said: "doing redisplay in timers is not nice". I did not say that it should be forbidden (if that's even possible). However, I do propose the following: - Deleting the 'sit-for' in the display-time-event-handler, since I would think that it is the most likely suspect for a non-idle timer that does redisplay in a usual Emacs session. The force-mode-line-update should be enough, and even if it isn't: if the minute is updated half a second too late, we can live with that (we can already live with a displayed 'load' value that's up to a minute old). - In (info "(elisp) Timers"), the manual already discourages certain things in timers, like changing buffer content or waiting with `sit-for'. I think we should add something like this: "Also, enforcing a redisplay in non-idle timers is problematic, since they may run at times when other functions have moved point or narrowed the buffer temporarily. The redisplay would make these visible, leading to unwanted scrolling or sudden narrowing and subsequent widening of the buffer. You should rather try if waiting for the next redisplay after the timer has run is sufficient for your needs. If you just change the mode-line, use `force-mode-line-update' instead of a full redisplay." - We should add information to the documentation of `access-process-output' and `input-pending-p', like "Note that timers may run during this function, which may trigger a redisplay. So before calling this function, you should make sure that any temporary changes you made to point position or the buffer (like narrowing) are undone, as to not make these changes visible." As a sidenote: What "bunch of useful features" do you have in mind for non-idle timers that do redisplay? They shouldn't alter buffer content, so what can they do that would need immediate redisplay? Displaying some kind of progress/time indicator is pretty much the only thing I can come up with. > IOW, it's the caller of input-pending-p etc. that is the fault here, > not the timers that it inadvertently lets run. Until yesterday, I was completely unaware that `accept-process-output' or `input-pending-p' could run timers that do redisplay, and I think I'm in good company. The doc-strings do not mention it, so there must be lots of third-party code which does not pay attention to this, so we should try that this bug triggers as little as possible. >> In fact, I just understood another bug in speck-mode (which is similar >> to flycheck). I sometimes had unwanted scrolls there, too, and I now saw >> that those also happen at every full minute while typing. > > Then there's the same bug there, that's all. Yes. But it shows that this bug is easy to make, and it's hard to track down. Also, the bug is slightly different in that speck does not only alter point, but also narrows the buffer, which is even more scary than unwanted scrolling. >> I thought that the jit-lock timer is a non-idle timer, but you are >> right. > > There's no jit-lock timer. Yes. Sorry for being imprecise. I meant the jit-lock defer timer. -David From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 16:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: Eli Zaretskii , gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13760656415960 (code B ref 15045); Fri, 09 Aug 2013 16:28:01 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 16:27:21 +0000 Received: from localhost ([127.0.0.1]:49976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7pX6-0001Y3-HH for submit@debbugs.gnu.org; Fri, 09 Aug 2013 12:27:20 -0400 Received: from randomsample.de ([83.169.19.17]:54017) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7pX3-0001Xs-Aj for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 12:27:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=9GZ7tSWD71qkwJcaVRfrvgAhGlE/hZTtMfqUo74xAF4=; b=FKzZ6VjYOVn7tsE+u8Njw7/U6AeDmCo0O0mmBLNHHLRpo+FP9G6q77Ljq7HydESiV/u+kAI89bYI9VZoSMv/UfafXBmWkpXgqg6OMs9zXpeeWd/GETRK6lryjmiJh5Yw; Received: from dslc-082-083-054-159.pools.arcor-ip.net ([82.83.54.159] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7pX1-0000pz-9l; Fri, 09 Aug 2013 18:27:15 +0200 From: David Engster In-Reply-To: <5204B263.1060603@gmx.at> (martin rudalics's message of "Fri, 09 Aug 2013 11:12:03 +0200") References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <5204B263.1060603@gmx.at> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Date: Fri, 09 Aug 2013 18:27:14 +0200 Message-ID: <87iozesucd.fsf@engster.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) martin rudalics writes: >> In fact, I just understood another bug in speck-mode (which is similar >> to flycheck). I sometimes had unwanted scrolls there, too, and I now saw >> that those also happen at every full minute while typing. > > What precisely is the bug in speck-mode? Is it that it doesn't restore > `point' when input arrives? The main problem is that speck narrows the buffer before calling `accept-process-output'. If that happens while the time-display-event-handler runs, you suddenly see a narrowed buffer, which is soon widened again. Pretty scary. It's quite easy to reproduce, since speck runs much longer than the Semantic idle function. Here's a recipe: - Put a bunch of text in the kill ring - Create a new text buffer and activate speck - Activate `display-time' - At roughly XX:58, yank the text into the buffer and wait Here's the backtrace from a `debug' call in `sit-for': sit-for(0) display-time-event-handler() apply(display-time-event-handler nil) byte-code("" [timer apply 5 6] 4) timer-event-handler([t 20997 5988 0 60 display-time-event-handler nil nil 0]) accept-process-output(nil 0.01) speck-chunk() speck-multi-chunk() speck-chunks() speck-line() speck-window(t) speck-windows(t) apply(speck-windows t) byte-code("" [timer apply 5 6] 4) timer-event-handler([t 0 1 262453 nil speck-windows (t) idle 785000]) The fix would be to undo any narrowing and restore point before calling `accept-process-output'. -David From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 17:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: Eli Zaretskii , gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137606825011808 (code B ref 15045); Fri, 09 Aug 2013 17:11:01 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 17:10:50 +0000 Received: from localhost ([127.0.0.1]:50089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7qDB-00034N-Jb for submit@debbugs.gnu.org; Fri, 09 Aug 2013 13:10:49 -0400 Received: from mout.gmx.net ([212.227.15.19]:49715) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7qD9-000342-R3 for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 13:10:48 -0400 Received: from [62.47.50.97] ([62.47.50.97]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MRocn-1VaD0L2cen-00Sv2H for <15045@debbugs.gnu.org>; Fri, 09 Aug 2013 19:10:41 +0200 Message-ID: <5205228D.2040602@gmx.at> Date: Fri, 09 Aug 2013 19:10:37 +0200 From: martin rudalics MIME-Version: 1.0 References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <5204B263.1060603@gmx.at> <87iozesucd.fsf@engster.org> In-Reply-To: <87iozesucd.fsf@engster.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:FKtRoygGX5ffMQg8y3N4EL3jwzanzeJ5veFUTdo1JMABphNOaGA ITzGODlAPQ+Senc/LRJFZTkYBZtyyUCrC9rl0yXDlGP+xv0SnBQbf4T0eRYZje4O++HPkVF JzNe+5byfJdSzIFPIzy89wcHncDEMLnnUs7jtshnNNgWqMN9cvMP7fo3ub0wsG44xR7dmwR 9ihXqO25dsfkQMc3ju0WA== X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > The main problem is that speck narrows the buffer before calling > `accept-process-output'. If that happens while the > time-display-event-handler runs, you suddenly see a narrowed buffer, > which is soon widened again. Pretty scary. Very annoying, at least. > The fix would be to undo any narrowing and restore point before calling > `accept-process-output'. Very inconvenient, at least. Many thanks for the explanation and the investigative work, martin From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 17:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137606967415139 (code B ref 15045); Fri, 09 Aug 2013 17:35:01 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 17:34:34 +0000 Received: from localhost ([127.0.0.1]:50131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7qa9-0003w5-UY for submit@debbugs.gnu.org; Fri, 09 Aug 2013 13:34:34 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:36223) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7qa7-0003vr-S2 for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 13:34:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="21247042" Received: from 75-119-243-106.dsl.teksavvy.com (HELO ceviche.home) ([75.119.243.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 09 Aug 2013 13:34:19 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 94EF066433; Fri, 9 Aug 2013 13:34:25 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <83bo57uakh.fsf@gnu.org> <83wqnvs3ec.fsf@gnu.org> <837gfvrltk.fsf@gnu.org> Date: Fri, 09 Aug 2013 13:34:25 -0400 In-Reply-To: <837gfvrltk.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Aug 2013 17:16:39 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Why should we care? Good engineering does not build things on what > "currently happens to work", because that will eventually break, > given enough development. I care because if I don't have a positive reason to keep this call to sit-for I'm going to remove it. >> In practice, is there any important scenario where >> display-time-event-handler's sit-for is useful? Thanks. So as far as you know it's not any more useful than adding sit-for at the end of any other function. > And anyway, display-time is just one case of a timer that needs to > force redisplay. No disagreement here. This bug report just made me bump into this tangentially related call to sit-for which I'll be happy to remove. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 18:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137607243924271 (code B ref 15045); Fri, 09 Aug 2013 18:21:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 18:20:39 +0000 Received: from localhost ([127.0.0.1]:50202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rIk-0006JO-Fx for submit@debbugs.gnu.org; Fri, 09 Aug 2013 14:20:38 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:54249) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rIi-0006JG-BC for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 14:20:36 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r79IKXbb030525; Fri, 9 Aug 2013 14:20:34 -0400 Received: by ceviche.home (Postfix, from userid 20848) id DE8FC66422; Fri, 9 Aug 2013 14:08:13 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <5204D77B.2040900@siege-engine.com> <8361vfrlo7.fsf@gnu.org> Date: Fri, 09 Aug 2013 14:08:13 -0400 In-Reply-To: <8361vfrlo7.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Aug 2013 17:19:52 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV4665=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4665> : streams <1015708> : uri <1501874> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) >> That sounds wrong. > Are you saying that using the READABLE_EVENTS_FILTER_EVENTS flag above > is wrong? I think so: input-pending-p is not expected to wait, so I don't see any reason to run timers. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 18:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137607260524622 (code B ref 15045); Fri, 09 Aug 2013 18:24:01 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 18:23:25 +0000 Received: from localhost ([127.0.0.1]:50207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rLQ-0006P2-Ir for submit@debbugs.gnu.org; Fri, 09 Aug 2013 14:23:24 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:44087) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rLO-0006Oj-Be for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 14:23:22 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MRA0000006J7700@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 21:23:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MRA00NNG0EP4R90@a-mtaout20.012.net.il>; Fri, 09 Aug 2013 21:23:13 +0300 (IDT) Date: Fri, 09 Aug 2013 21:23:31 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83txiyrae4.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <83bo57uakh.fsf@gnu.org> <83wqnvs3ec.fsf@gnu.org> <837gfvrltk.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: deng@randomsample.de, gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com > Date: Fri, 09 Aug 2013 13:34:25 -0400 > > > Why should we care? Good engineering does not build things on what > > "currently happens to work", because that will eventually break, > > given enough development. > > I care because if I don't have a positive reason to keep this call to > sit-for I'm going to remove it. If you don't care about a bug report that will have you re-add it, feel free. > Thanks. So as far as you know it's not any more useful than adding > sit-for at the end of any other function. Only those that need to make sure their effect is displayed. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 18:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137607308125558 (code B ref 15045); Fri, 09 Aug 2013 18:32:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 18:31:21 +0000 Received: from localhost ([127.0.0.1]:50220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rT6-0006e8-EF for submit@debbugs.gnu.org; Fri, 09 Aug 2013 14:31:20 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:45627) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rT2-0006da-K4 for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 14:31:18 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MRA000000Q8AT00@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 21:31:10 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MRA0008D0RX5860@a-mtaout20.012.net.il>; Fri, 09 Aug 2013 21:31:10 +0300 (IDT) Date: Fri, 09 Aug 2013 21:31:27 +0300 From: Eli Zaretskii In-reply-to: <87pptmsv4z.fsf@engster.org> X-012-Sender: halo1@inter.net.il Message-id: <83siyira0w.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: David Engster > Cc: gundaetiapo@gmail.com, monnier@iro.umontreal.ca, 15045@debbugs.gnu.org, eric@siege-engine.com > Date: Fri, 09 Aug 2013 18:10:04 +0200 > > >> >> However, doing redisplay in timers is not nice. > >> > > >> > Why not? > >> > >> Because doing redisplay is a user-visible side effect, and in general, > >> timers shouldn't have those. > > > > How else can a timer such as that of display-time do its thing? IOW, > > when the purpose of a timer is to cause something to be displayed, > > they have no alternative but to force redisplay. > > As you know, Emacs does not have strict timers. If you say to Emacs: one > minute from now, say 'foo', and Emacs happens to be busy one minute from > now, nothing will happen until it waits again. So I wonder: with such a > lenient definition of "timer", does the wait for the next redisplay > really matter? Emacs very seldom is busy for a long time, so in practice you will see the 1-min timer do its thing pretty much on time. > After which idle time does redisplay kick in anyway? Redisplay doesn't count idle time to kick in, so there's no answer to your question. Redisplay is triggered by several reasons, one of them being waiting for keyboard input, which you might call "being idle", although that's not exactly accurate. > As a sidenote: What "bunch of useful features" do you have in mind for > non-idle timers that do redisplay? They shouldn't alter buffer content, > so what can they do that would need immediate redisplay? Displaying some > kind of progress/time indicator is pretty much the only thing I can come > up with. Any display-related feature, such as blinking something, displaying something ion the mode line or header line, etc. Altering a buffer can be one of the effects, btw, e.g. in a feature that shows the list of processes on a system and refreshes that list every second. > > IOW, it's the caller of input-pending-p etc. that is the fault here, > > not the timers that it inadvertently lets run. > > Until yesterday, I was completely unaware that `accept-process-output' > or `input-pending-p' could run timers that do redisplay, and I think I'm > in good company. The doc-strings do not mention it, so there must be > lots of third-party code which does not pay attention to this, so we > should try that this bug triggers as little as possible. I agree that the doc strings should make a prominent reference to this issue. > >> In fact, I just understood another bug in speck-mode (which is similar > >> to flycheck). I sometimes had unwanted scrolls there, too, and I now saw > >> that those also happen at every full minute while typing. > > > > Then there's the same bug there, that's all. > > Yes. But it shows that this bug is easy to make, and it's hard to track > down. It is also very rare. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 18:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137607348226349 (code B ref 15045); Fri, 09 Aug 2013 18:39:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 18:38:02 +0000 Received: from localhost ([127.0.0.1]:50225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rZZ-0006qs-F5 for submit@debbugs.gnu.org; Fri, 09 Aug 2013 14:38:01 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:33668) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rZS-0006qT-Kl for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 14:37:55 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MRA00J000U9U700@a-mtaout21.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 21:37:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MRA00JNE12YQ080@a-mtaout21.012.net.il>; Fri, 09 Aug 2013 21:37:47 +0300 (IDT) Date: Fri, 09 Aug 2013 21:38:04 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83pptmr9pv.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <5204D77B.2040900@siege-engine.com> <8361vfrlo7.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: eric@siege-engine.com, deng@randomsample.de, gundaetiapo@gmail.com, > 15045@debbugs.gnu.org > Date: Fri, 09 Aug 2013 14:08:13 -0400 > > >> That sounds wrong. > > Are you saying that using the READABLE_EVENTS_FILTER_EVENTS flag above > > is wrong? > > I think so: input-pending-p is not expected to wait, so I don't see any > reason to run timers. I think the only reason, as with all the other places where we run timers, is to make Emacs look appear more responsive, notwithstanding the on-going processing. (And I meant the READABLE_EVENTS_DO_TIMERS_NOW flag, of course.) From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 18:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, Stefan Monnier , eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137607371226849 (code B ref 15045); Fri, 09 Aug 2013 18:42:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 18:41:52 +0000 Received: from localhost ([127.0.0.1]:50241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rdH-0006yy-Nm for submit@debbugs.gnu.org; Fri, 09 Aug 2013 14:41:51 -0400 Received: from randomsample.de ([83.169.19.17]:47687) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rdE-0006yo-TP for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 14:41:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=HofkYeiW5KbbyF4E3tqjh62AsQTpExkY3fXPQotn45c=; b=nbNxlYJgWl6cMDiiPsMlmgAg5owSjcSTVXHfzrzAs/a3+ntRvIAepp7mn5UHsPOENu2Vu2HoQOJAT+5kiOOvjc6/0F4brkzCeJMBsolGe5CqAsJjZ0Ryrql9SOXTnZfo; Received: from dslc-082-083-054-159.pools.arcor-ip.net ([82.83.54.159] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7rdB-0004Fi-8b; Fri, 09 Aug 2013 20:41:45 +0200 From: David Engster In-Reply-To: <83pptmr9pv.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Aug 2013 21:38:04 +0300") References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <5204D77B.2040900@siege-engine.com> <8361vfrlo7.fsf@gnu.org> <83pptmr9pv.fsf@gnu.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Date: Fri, 09 Aug 2013 20:41:44 +0200 Message-ID: <877gfuso47.fsf@engster.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > I think the only reason, as with all the other places where we run > timers, is to make Emacs look appear more responsive, notwithstanding > the on-going processing. Is there some easy way to get a list of functions which may cause timers to run? IMHO all those functions would need a word of warning in their doc-string. -David From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 18:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: Eli Zaretskii , gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137607423931671 (code B ref 15045); Fri, 09 Aug 2013 18:51:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 18:50:39 +0000 Received: from localhost ([127.0.0.1]:50257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rlm-0008Ek-JD for submit@debbugs.gnu.org; Fri, 09 Aug 2013 14:50:38 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:44223 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rlk-0008EY-0m for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 14:50:36 -0400 Received: from [98.143.210.201] (port=52416 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1V7rli-00031N-C5; Fri, 09 Aug 2013 14:50:34 -0400 Received: by ceviche.home (Postfix, from userid 20848) id EC3BA66084; Fri, 9 Aug 2013 14:50:32 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> Date: Fri, 09 Aug 2013 14:50:32 -0400 In-Reply-To: <87pptmsv4z.fsf@engster.org> (David Engster's message of "Fri, 09 Aug 2013 18:10:04 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) I just removed the two calls to sit-for from time.el. We'll see if someone screams showing a scenario where they were useful. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 18:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: martin rudalics , gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137607430931825 (code B ref 15045); Fri, 09 Aug 2013 18:52:01 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 18:51:49 +0000 Received: from localhost ([127.0.0.1]:50261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rmu-0008HD-8Y for submit@debbugs.gnu.org; Fri, 09 Aug 2013 14:51:48 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:44242 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rms-0008H3-5j for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 14:51:46 -0400 Received: from [98.143.210.201] (port=52417 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1V7rmr-0003L4-Fs; Fri, 09 Aug 2013 14:51:45 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 7EEE766084; Fri, 9 Aug 2013 14:51:44 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <5204B263.1060603@gmx.at> <87iozesucd.fsf@engster.org> Date: Fri, 09 Aug 2013 14:51:44 -0400 In-Reply-To: <87iozesucd.fsf@engster.org> (David Engster's message of "Fri, 09 Aug 2013 18:27:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) >> What precisely is the bug in speck-mode? Is it that it doesn't restore >> `point' when input arrives? > The main problem is that speck narrows the buffer before calling > `accept-process-output'. Yes, that's a bug in speck-mode. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 20:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, monnier@IRO.UMontreal.CA, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137608138320097 (code B ref 15045); Fri, 09 Aug 2013 20:50:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 20:49:43 +0000 Received: from localhost ([127.0.0.1]:50433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7td1-0005E4-8Y for submit@debbugs.gnu.org; Fri, 09 Aug 2013 16:49:43 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:56608) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7tcx-0005Dm-Og for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 16:49:41 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MRA00F0072DGF00@a-mtaout22.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 23:49:32 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MRA00F6A76K3OB0@a-mtaout22.012.net.il>; Fri, 09 Aug 2013 23:49:32 +0300 (IDT) Date: Fri, 09 Aug 2013 23:49:50 +0300 From: Eli Zaretskii In-reply-to: <877gfuso47.fsf@engster.org> X-012-Sender: halo1@inter.net.il Message-id: <83mwoqr3m9.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <5204D77B.2040900@siege-engine.com> <8361vfrlo7.fsf@gnu.org> <83pptmr9pv.fsf@gnu.org> <877gfuso47.fsf@engster.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: David Engster > Cc: Stefan Monnier , eric@siege-engine.com, gundaetiapo@gmail.com, 15045@debbugs.gnu.org > Date: Fri, 09 Aug 2013 20:41:44 +0200 > > Eli Zaretskii writes: > > I think the only reason, as with all the other places where we run > > timers, is to make Emacs look appear more responsive, notwithstanding > > the on-going processing. > > Is there some easy way to get a list of functions which may cause timers > to run? Scanning the C sources is what I'd do. Not sure if that can go by the "easy way" handle, though. > IMHO all those functions would need a word of warning in their > doc-string. Yep. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 21:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: Eli Zaretskii , gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137608419324943 (code B ref 15045); Fri, 09 Aug 2013 21:37:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 21:36:33 +0000 Received: from localhost ([127.0.0.1]:50482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7uMK-0006UE-Sk for submit@debbugs.gnu.org; Fri, 09 Aug 2013 17:36:33 -0400 Received: from relais.videotron.ca ([24.201.245.36]:47273) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7uMJ-0006U6-08 for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 17:36:31 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ceviche.home ([24.201.64.104]) by VL-VM-MR006.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MRA00LT59CUJA70@VL-VM-MR006.ip.videotron.ca> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 17:36:30 -0400 (EDT) Received: by ceviche.home (Postfix, from userid 20848) id 08AC266422; Fri, 09 Aug 2013 17:36:30 -0400 (EDT) From: Stefan Monnier Message-id: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <5204D77B.2040900@siege-engine.com> <8361vfrlo7.fsf@gnu.org> <83pptmr9pv.fsf@gnu.org> <877gfuso47.fsf@engster.org> Date: Fri, 09 Aug 2013 17:36:30 -0400 In-reply-to: <877gfuso47.fsf@engster.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) >> I think the only reason, as with all the other places where we run >> timers, is to make Emacs look appear more responsive, notwithstanding >> the on-going processing. > Is there some easy way to get a list of functions which may cause timers > to run? IMHO all those functions would need a word of warning in their > doc-string. Basically, read-event, read-char, read-key-sequence (and friends), and accept-process-output and input-pending-p, plus any function that calls one of them (e.g. sit-for). Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 21:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137608479626004 (code B ref 15045); Fri, 09 Aug 2013 21:47:02 +0000 Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 21:46:36 +0000 Received: from localhost ([127.0.0.1]:50487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7uW3-0006lM-TD for submit@debbugs.gnu.org; Fri, 09 Aug 2013 17:46:36 -0400 Received: from relais.videotron.ca ([24.201.245.36]:44178) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7uW2-0006l7-0L for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 17:46:34 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ceviche.home ([24.201.64.104]) by VL-VM-MR004.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MRA008279TLQYA0@VL-VM-MR004.ip.videotron.ca> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 17:46:33 -0400 (EDT) Received: by ceviche.home (Postfix, from userid 20848) id 6025D66422; Fri, 09 Aug 2013 17:46:33 -0400 (EDT) From: Stefan Monnier Message-id: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <5204D77B.2040900@siege-engine.com> <8361vfrlo7.fsf@gnu.org> <83pptmr9pv.fsf@gnu.org> Date: Fri, 09 Aug 2013 17:46:33 -0400 In-reply-to: <83pptmr9pv.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) >> >> That sounds wrong. >> > Are you saying that using the READABLE_EVENTS_DO_TIMERS_NOW flag above >> > is wrong? >> I think so: input-pending-p is not expected to wait, so I don't see any >> reason to run timers. > I think the only reason, as with all the other places where we run > timers, is to make Emacs look appear more responsive, notwithstanding > the on-going processing. I suspect that the users of input-pending-p which care about running timers would be better served by (sit-for 0 t). Currently, it's 100% equivalent, but the intention is a lot more clear. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Aug 2013 09:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13761277755704 (code B ref 15045); Sat, 10 Aug 2013 09:43:01 +0000 Received: (at 15045) by debbugs.gnu.org; 10 Aug 2013 09:42:55 +0000 Received: from localhost ([127.0.0.1]:51067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V85hG-0001Tv-0x for submit@debbugs.gnu.org; Sat, 10 Aug 2013 05:42:54 -0400 Received: from randomsample.de ([83.169.19.17]:59314) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V85hC-0001Te-T2 for 15045@debbugs.gnu.org; Sat, 10 Aug 2013 05:42:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=66e/YGX35RRJsQSsSfFVjTBr+ZTsySlCAzybUjG/+Cc=; b=XjmX5o2x1WGctvEs7NDJAOeVV2gp1I0RXWcHNkApfu43eNmYFUpbSSkXi1xiOytigqtt3T3vK3w8ZgF1R8rwwTmx0RIQsQOZgYmf5lWSDnGijAUtYHn0Ucgopq/5wh9Z; Received: from dslc-082-083-054-159.pools.arcor-ip.net ([82.83.54.159] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V85h9-0004DH-Rs; Sat, 10 Aug 2013 11:42:48 +0200 From: David Engster In-Reply-To: (Stefan Monnier's message of "Fri, 09 Aug 2013 17:36:30 -0400") References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <5204D77B.2040900@siege-engine.com> <8361vfrlo7.fsf@gnu.org> <83pptmr9pv.fsf@gnu.org> <877gfuso47.fsf@engster.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Date: Sat, 10 Aug 2013 11:42:47 +0200 Message-ID: <87zjsprieg.fsf@engster.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Stefan Monnier writes: >>> I think the only reason, as with all the other places where we run >>> timers, is to make Emacs look appear more responsive, notwithstanding >>> the on-going processing. >> Is there some easy way to get a list of functions which may cause timers >> to run? IMHO all those functions would need a word of warning in their >> doc-string. > > Basically, read-event, read-char, read-key-sequence (and friends), and > accept-process-output and input-pending-p, I think we should mention this issue in their doc-strings. Should they all get same blurb like "This might run timers that trigger redisplay, so you should make sure that etc." or should they just get a short notice like "This function runs timers (see 'some-doc-string or info page').". > plus any function that calls one of them (e.g. sit-for). Those are at least a few hundred, so we cannot possibly alter all the doc-strings for those. -David From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Aug 2013 09:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13761284797035 (code B ref 15045); Sat, 10 Aug 2013 09:55:01 +0000 Received: (at 15045) by debbugs.gnu.org; 10 Aug 2013 09:54:39 +0000 Received: from localhost ([127.0.0.1]:51090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V85sc-0001pP-Vv for submit@debbugs.gnu.org; Sat, 10 Aug 2013 05:54:39 -0400 Received: from randomsample.de ([83.169.19.17]:36892) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V85sZ-0001pG-UR for 15045@debbugs.gnu.org; Sat, 10 Aug 2013 05:54:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=mkdHEeIQKT5sSWX0jn4Auud/FQiCrlgsg288toNWtfw=; b=G+c3ayym7dcsfsyaELPjVff9ffDGZrqp1GdsEjBi47uOc5tUN8P2W4n8fSfesdIAzGI3VzWEl4Xf4eyQB416BqV7xstzuag+i1P0KQhxTePhYiYAVvnq0/60dcxZYMeN; Received: from dslc-082-083-054-159.pools.arcor-ip.net ([82.83.54.159] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V85sX-0004aZ-Pe; Sat, 10 Aug 2013 11:54:33 +0200 From: David Engster In-Reply-To: <83siyira0w.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Aug 2013 21:31:27 +0300") References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Date: Sat, 10 Aug 2013 11:54:32 +0200 Message-ID: <87vc3drhuv.fsf@engster.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> From: David Engster >> Yes. But it shows that this bug is easy to make, and it's hard to track >> down. > > It is also very rare. I don't think the bug is rare. I do think that this bug being triggered is rare, since we don't have many non-idle timers in Emacs that trigger redisplay (are there others in Emacs core besides the display-time event handler?). It might be fun to work for a while with a dummy timer which triggers redisplay once a second or so. I also think this bug is seldomly reported because it's impossible to give a recipe if you don't know that it is a timer that triggers it (which is why I never bothered to report the bug in speck-mode). -David From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Aug 2013 10:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137613019910235 (code B ref 15045); Sat, 10 Aug 2013 10:24:02 +0000 Received: (at 15045) by debbugs.gnu.org; 10 Aug 2013 10:23:19 +0000 Received: from localhost ([127.0.0.1]:51124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V86KM-0002f1-TL for submit@debbugs.gnu.org; Sat, 10 Aug 2013 06:23:19 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:36366) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V86KJ-0002eh-PM for 15045@debbugs.gnu.org; Sat, 10 Aug 2013 06:23:17 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MRB00L008LJDH00@a-mtaout22.012.net.il> for 15045@debbugs.gnu.org; Sat, 10 Aug 2013 13:22:32 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MRB00LFA8TK4O80@a-mtaout22.012.net.il>; Sat, 10 Aug 2013 13:22:32 +0300 (IDT) Date: Sat, 10 Aug 2013 13:22:52 +0300 From: Eli Zaretskii In-reply-to: <87vc3drhuv.fsf@engster.org> X-012-Sender: halo1@inter.net.il Message-id: <83haexrgjn.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: David Engster > Cc: gundaetiapo@gmail.com, monnier@iro.umontreal.ca, 15045@debbugs.gnu.org, eric@siege-engine.com > Date: Sat, 10 Aug 2013 11:54:32 +0200 > > Eli Zaretskii writes: > >> From: David Engster > >> Yes. But it shows that this bug is easy to make, and it's hard to track > >> down. > > > > It is also very rare. > > I don't think the bug is rare. I do think that this bug being triggered > is rare, since we don't have many non-idle timers in Emacs that trigger > redisplay The last sentence exactly means that the bug is rare. > (are there others in Emacs core besides the display-time event > handler?). And so does this. > It might be fun to work for a while with a dummy timer which > triggers redisplay once a second or so. Customize display-time-interval to 1 (after restoring the sit-for that got deleted), and you've got that. I'm running for years with that variable customized to 5 sec, and never saw any unwarranted movement of point or scrolling. That's "rare" in my book. > I also think this bug is seldomly reported because it's impossible to > give a recipe if you don't know that it is a timer that triggers it > (which is why I never bothered to report the bug in speck-mode). The bug database is replete with problems that are not reproducible, so I'm quite sure people would report them regardless. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Aug 2013 18:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, David Engster , eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.137615801330968 (code B ref 15045); Sat, 10 Aug 2013 18:07:01 +0000 Received: (at 15045) by debbugs.gnu.org; 10 Aug 2013 18:06:53 +0000 Received: from localhost ([127.0.0.1]:52034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V8DYy-00083N-UF for submit@debbugs.gnu.org; Sat, 10 Aug 2013 14:06:53 -0400 Received: from mail-ob0-f169.google.com ([209.85.214.169]:62071) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V8DYw-000837-Be for 15045@debbugs.gnu.org; Sat, 10 Aug 2013 14:06:50 -0400 Received: by mail-ob0-f169.google.com with SMTP id wc20so7678004obb.28 for <15045@debbugs.gnu.org>; Sat, 10 Aug 2013 11:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w4eEG91zXBklDBM+rQ7Z764WCCtVZBA0E2CYouA4U1o=; b=HEuD3T0JZjIeapl6wlVhl7KNzpwy81F4RQDwXQfY8MduvoD1O/VQdzo+M6bz5o3g7i +BlTr5BrW0KquZDU7NIUwjwslxRNGEa8DEOLnmAF560P0LJuFaGphIA08aCFZSzLvnQ7 Vtmy/bGcWdzCjWzcmHJP0X3uMl5JOty+KVITmQGorAcoFymazx0RTQo5TZFq52ku6dlP kLveqzpiw2Cyyo5k0cXfqMeiM2kBdChCFnARfaZ9qaJZy/Rt0v3ZXjHdTgO+QzAcmtTp N84EY8VMRoaSJcfUO3OxL7yaeJoqVpm36jIAXNqPOl6wUsaOHVuGBMWvVPycwSwHOZW4 H0Ow== MIME-Version: 1.0 X-Received: by 10.60.133.233 with SMTP id pf9mr5011216oeb.46.1376158004187; Sat, 10 Aug 2013 11:06:44 -0700 (PDT) Received: by 10.76.89.194 with HTTP; Sat, 10 Aug 2013 11:06:44 -0700 (PDT) In-Reply-To: <83haexrgjn.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> Date: Sat, 10 Aug 2013 14:06:44 -0400 Message-ID: From: Barry OReilly Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >>> It is also very rare. >> I don't think the bug is rare. I do think that this bug being >> triggered is rare, since we don't have many non-idle timers in >> Emacs that trigger redisplay > That's "rare" in my book. Three people in this thread independently witnessed the bug. Given the proportion of Emacs users who follow the mailing lists, calling this rare is questionable. > are there others in Emacs core besides the display-time event > handler? I have never used display-time-mode, so another timer is involved, possibly non core. I don't see this bug nearly as often as David's "every 15 minutes". I would guess 10 times in the past several months. I'm running Emacs now with the debugging changes Stefan suggested: > in Fredisplay, walk the specpdl stack looking for a > save_excursion_restore where the saved position is different from > the current value of point in that buffer. as the change I posted: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15045#29 I did not witness the bug yesterday, but I did hit the debug statements a few times. In those cases the Fprin1 and Fbacktrace calls printed empty strings, and coincided with Emacs pausing for a few seconds. I don't know why I'd get empty strings. Maybe there's a flaw in that debugging code? From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Oct 2013 19:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 15045@debbugs.gnu.org, Stefan Monnier , David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13817791707460 (code B ref 15045); Mon, 14 Oct 2013 19:33:01 +0000 Received: (at 15045) by debbugs.gnu.org; 14 Oct 2013 19:32:50 +0000 Received: from localhost ([127.0.0.1]:49288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VVnsn-0001wD-UI for submit@debbugs.gnu.org; Mon, 14 Oct 2013 15:32:50 -0400 Received: from mail-ob0-f176.google.com ([209.85.214.176]:46433) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VVnsk-0001vY-Pf for 15045@debbugs.gnu.org; Mon, 14 Oct 2013 15:32:47 -0400 Received: by mail-ob0-f176.google.com with SMTP id wo20so5071788obc.21 for <15045@debbugs.gnu.org>; Mon, 14 Oct 2013 12:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DI5WH9EjLS0ckpXPdE84KKHveh+J4JqZQ9CDqOM5B+c=; b=Mw884mUWQ2fyCwqt7/JANYteDhr60ZRGH66cgSJpNb06wxfZz8arQ0eGOabp/IN2vY nWN6aLFTPAYc+9rn7S3N/5qK9Z3uwnj9RlHqa3ch1mUiklFnbfhUCcp5CZkyMjUJCSvs 4u+yjVZZ34tUJD5BuxOZCqNxixiPRIcBYbBT4NsYbEttYur04FbIxf1pm7lDw2Pkl1/r xTBRZWA7HBxTvOdUkn0m+IGsortlhfA5e5hcsRNZf2RtxChNvXoK6V+5pT5V6flz5/4K Mo1x1IRuqHaVXiHIepUaon8NYRn4jz5Rhy7CoifnRqpKHhcqy75hFZONViqAhgh4aVUz Sa/Q== MIME-Version: 1.0 X-Received: by 10.182.50.130 with SMTP id c2mr7926884obo.35.1381779160900; Mon, 14 Oct 2013 12:32:40 -0700 (PDT) Received: by 10.76.156.103 with HTTP; Mon, 14 Oct 2013 12:32:40 -0700 (PDT) In-Reply-To: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> Date: Mon, 14 Oct 2013 15:32:40 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=089e0158c6f00b2a7804e8b88864 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e0158c6f00b2a7804e8b88864 Content-Type: text/plain; charset=ISO-8859-1 > >> >> That sounds wrong. > >> > Are you saying that using the READABLE_EVENTS_DO_TIMERS_NOW flag above > >> > is wrong? > >> I think so: input-pending-p is not expected to wait, so I don't see any > >> reason to run timers. > > I think the only reason, as with all the other places where we run > > timers, is to make Emacs look appear more responsive, notwithstanding > > the on-going processing. > > I suspect that the users of input-pending-p which care about running > timers would be better served by (sit-for 0 t). Currently, it's 100% > equivalent, but the intention is a lot more clear. Given this has come up again separately in bug 15567, may I make the change to input-pending-p? diff --git a/src/keyboard.c b/src/keyboard.c index e0cd4d4..fdb7c7d 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -9962,8 +9962,7 @@ if there is a doubt, the value is t. */) /* Process non-user-visible events (Bug#10195). */ process_special_events (); - return (get_input_pending (READABLE_EVENTS_DO_TIMERS_NOW - | READABLE_EVENTS_FILTER_EVENTS) + return (get_input_pending (READABLE_EVENTS_FILTER_EVENTS) ? Qt : Qnil); } 'make check' passes. Eli Zaretskii: > What if input arrives because of a timer? If this is an issue, I propose input-pending-p return t if a timer is ready to run. Then the long running task would exit, unwind its save-excursion, then allow the timer to run. Perhaps this contorts the meaning of "input", but OTOH the documentation for input-pending-p already states that a false positive return can happen: Return t if command input is currently available with no wait. Actually, the value is nil only if we can be sure that no input is available; if there is a doubt, the value is t. Would you want this in the same changeset as the patch above? Or not worry about it until "someone screams"? --089e0158c6f00b2a7804e8b88864 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> >> >> That sounds wrong.
> >>= > Are you saying that using the READABLE_EVENTS_DO_TIMERS_NOW flag abov= e
> >> > is wrong?
> >> I think so: input-pendin= g-p is not expected to wait, so I don't see any
> >> reason to run timers.
> > I think the only reason, a= s with all the other places where we run
> > timers, is to make Em= acs look appear more responsive, notwithstanding
> > the on-going = processing.
>
> I suspect that the users of input-pending-p which care about r= unning
> timers would be better served by (sit-for 0 t).=A0 Currently= , it's 100%
> equivalent, but the intention is a lot more clear.<= br>
Given this has come up again separately in bug 15567, may I make thechange to input-pending-p?

diff --git a/src/keyboard.c b/src/keyboa= rd.c
index e0cd4d4..fdb7c7d 100644
--- a/src/keyboard.c
+++ b/src/= keyboard.c
@@ -9962,8 +9962,7 @@ if there is a doubt, the value is t.=A0 */)
=A0=A0= /* Process non-user-visible events (Bug#10195).=A0 */
=A0=A0 process_sp= ecial_events ();
=A0
-=A0 return (get_input_pending (READABLE_EVENTS_= DO_TIMERS_NOW
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 | READABLE_EVENTS_FILTER_EVENTS)
+=A0 return (get_input_pendin= g (READABLE_EVENTS_FILTER_EVENTS)
=A0=A0=A0=A0=A0=A0=A0=A0=A0 ? Qt : Qni= l);
=A0}
=A0
'make check' passes.

Eli Zaretskii: > What if input arrives because of a timer?

If this is an issue, = I propose input-pending-p return t if a timer is
ready to run. Then the = long running task would exit, unwind its
save-excursion, then allow the = timer to run. Perhaps this contorts the
meaning of "input", but OTOH the documentation for input-pending-= p
already states that a false positive return can happen:

=A0 Ret= urn t if command input is currently available with no wait.
=A0 Actually= , the value is nil only if we can be sure that no input is
=A0 available; if there is a doubt, the value is t.

Would you want t= his in the same changeset as the patch above? Or not
worry about it unti= l "someone screams"?

--089e0158c6f00b2a7804e8b88864-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Oct 2013 19:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138178028217631 (code B ref 15045); Mon, 14 Oct 2013 19:52:02 +0000 Received: (at 15045) by debbugs.gnu.org; 14 Oct 2013 19:51:22 +0000 Received: from localhost ([127.0.0.1]:49305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VVoAj-0004aD-FH for submit@debbugs.gnu.org; Mon, 14 Oct 2013 15:51:21 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:51950) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VVoAg-0004ZF-4G for 15045@debbugs.gnu.org; Mon, 14 Oct 2013 15:51:19 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MUO00C00CB3MV00@a-mtaout23.012.net.il> for 15045@debbugs.gnu.org; Mon, 14 Oct 2013 22:51:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MUO00CKACHAJJ60@a-mtaout23.012.net.il>; Mon, 14 Oct 2013 22:51:11 +0300 (IDT) Date: Mon, 14 Oct 2013 22:51:07 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83ppr7pr6c.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 14 Oct 2013 15:32:40 -0400 > From: Barry OReilly > Cc: David Engster , Stefan Monnier , > 15045@debbugs.gnu.org, Eric Ludlam > > Given this has come up again separately in bug 15567, may I make the > change to input-pending-p? > > diff --git a/src/keyboard.c b/src/keyboard.c > index e0cd4d4..fdb7c7d 100644 > --- a/src/keyboard.c > +++ b/src/keyboard.c > @@ -9962,8 +9962,7 @@ if there is a doubt, the value is t. */) > /* Process non-user-visible events (Bug#10195). */ > process_special_events (); > > - return (get_input_pending (READABLE_EVENTS_DO_TIMERS_NOW > - | READABLE_EVENTS_FILTER_EVENTS) > + return (get_input_pending (READABLE_EVENTS_FILTER_EVENTS) > ? Qt : Qnil); > } > > 'make check' passes. FWIW, I'm against such changes. You can never know how many places will be subtly broken by changes like that in such a popular interface. The original problem is rare enough, and should IMO be fixed in the code where it happens. Making changes like above on behalf of such marginal use cases is a tail wagging the dog. > Eli Zaretskii: > > What if input arrives because of a timer? > > If this is an issue, I propose input-pending-p return t if a timer is > ready to run. Likewise: too serious change in behavior for too obscure a reason. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Oct 2013 13:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Barry OReilly , 15045@debbugs.gnu.org, deng@randomsample.de, eric@siege-engine.com Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138184452723199 (code B ref 15045); Tue, 15 Oct 2013 13:43:02 +0000 Received: (at 15045) by debbugs.gnu.org; 15 Oct 2013 13:42:07 +0000 Received: from localhost ([127.0.0.1]:50719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VW4sw-000625-Gt for submit@debbugs.gnu.org; Tue, 15 Oct 2013 09:42:06 -0400 Received: from relais.videotron.ca ([24.201.245.36]:41329) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VW4st-00061w-64 for 15045@debbugs.gnu.org; Tue, 15 Oct 2013 09:42:03 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ceviche.home ([24.201.53.56]) by VL-VM-MR006.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MUP0039MQ225M90@VL-VM-MR006.ip.videotron.ca> for 15045@debbugs.gnu.org; Tue, 15 Oct 2013 09:42:02 -0400 (EDT) Received: by ceviche.home (Postfix, from userid 20848) id BBD1666087; Tue, 15 Oct 2013 09:42:03 -0400 (EDT) From: Stefan Monnier Message-id: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> Date: Tue, 15 Oct 2013 09:42:03 -0400 In-reply-to: <83ppr7pr6c.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > FWIW, I'm against such changes. You can never know how many places > will be subtly broken by changes like that in such a popular > interface. Hmm... I kind of agree with both: - this is a subtle change affecting behavior in a corner case and it's difficult to know which code might care about it. - nothing in input-pending-p indicates this is some kind of blocking/waiting operation which might hence correspond to a "yield point". On the contrary, the intuition behind input-pending-p would make you think that the whole point of it is to let you find out if there's input *without waiting*. So I tend to agree with Barry that input-pending-p should not run timers. Not just based on his particular problem case, but on the basis of what ideally input-pending-p should do. Arguably it shouldn't process_special_events either, tho obviously, removing this call would introduce a known breakage, so we should keep this for now (until we have a better fix for it). > The original problem is rare enough, and should IMO be fixed in the > code where it happens. It can be difficult to "fix" it there, because there's simply no other operation that lets you detect if there's input in the queue without running arbitrary code, so it can require non-trivial refactoring. >> > What if input arrives because of a timer? >> If this is an issue, I propose input-pending-p return t if a timer is >> ready to run. > Likewise: too serious change in behavior for too obscure a reason. 100% agreement. `input-pending-p' is meant to detect *user input*, and timers do not count as such (and input generated by timers doesn't count as "user input" either). Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Oct 2013 14:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138184636726434 (code B ref 15045); Tue, 15 Oct 2013 14:13:02 +0000 Received: (at 15045) by debbugs.gnu.org; 15 Oct 2013 14:12:47 +0000 Received: from localhost ([127.0.0.1]:51192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VW5Md-0006sI-4m for submit@debbugs.gnu.org; Tue, 15 Oct 2013 10:12:47 -0400 Received: from mail-oa0-f54.google.com ([209.85.219.54]:35412) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VW5Ma-0006s1-CK for 15045@debbugs.gnu.org; Tue, 15 Oct 2013 10:12:44 -0400 Received: by mail-oa0-f54.google.com with SMTP id n5so5900064oag.27 for <15045@debbugs.gnu.org>; Tue, 15 Oct 2013 07:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EXzfFtYDCajOZ7Upbjwi5cMb2AQmfYhrJCOqw8npOsQ=; b=huasCnhdtEtBiuNOCr/L4oikArslHNsoCXmEWlmmDBw4lY8P8PQnet5JqYToD4wMJj 0iOunqRB7z8cRoQ4w9+wpQB2BvuvU2iR5Plw2uPhyDsbZuFNalKdCKQWd+8P+RllWfLq 0g2AgvUUQIAtbmkzGydkk1vOeSuCufkEYI8pHtnVk8XpLpTob+lHXpTsXuEiBxHgw0ET W8xrcwV3LAjb+kF5y1Mo+pn8H7c47qxVir+JBYRei1U0SMM23PEitwGBLsSTFtO4VnU6 uKee47tcb/PAzhbBiv37RFrMBRcFGen9+3UNgcsPN9yBnZSKpXN9VvBU71IrMan92gUZ kSiw== MIME-Version: 1.0 X-Received: by 10.182.143.103 with SMTP id sd7mr1025773obb.70.1381846352233; Tue, 15 Oct 2013 07:12:32 -0700 (PDT) Received: by 10.76.156.103 with HTTP; Tue, 15 Oct 2013 07:12:32 -0700 (PDT) In-Reply-To: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> Date: Tue, 15 Oct 2013 10:12:32 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=e89a8ff1ce9ef58a4904e8c82c1c X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --e89a8ff1ce9ef58a4904e8c82c1c Content-Type: text/plain; charset=ISO-8859-1 > The original problem is rare enough You're wrong to call it rare. Dave Milter, David Engster, and I have seen it separately. It has occurred because of tasks in Semantic, Speck, and now NXML. That input-pending-p behaves this way is apparently surprising to the Elisp developer. It is even more surprising to the user upon witnessing such a jarring symptom. > So I tend to agree with Barry that input-pending-p should not run > timers. Not just based on his particular problem case, but on the > basis of what ideally input-pending-p should do. I don't claim the change solves the issue completely. This bug report would have to stay open because Semantic also calls accept-process-output while point is on an excursion. Since Stefan had said input-pending-p behavior seems wrong, I followed up in the hopes we can both correct a wrong and reduce how common this user-visible symptom is. --e89a8ff1ce9ef58a4904e8c82c1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> The original problem is rare enough

You're= wrong to call it rare. Dave Milter, David Engster, and I have
seen it s= eparately. It has occurred because of tasks in Semantic,
Speck, and now = NXML. That input-pending-p behaves this way is
apparently surprising to the Elisp developer. It is even more
surprising= to the user upon witnessing such a jarring symptom.

> So I tend = to agree with Barry that input-pending-p should not run
> timers. Not= just based on his particular problem case, but on the
> basis of what ideally input-pending-p should do.

I don't cl= aim the change solves the issue completely. This bug report
would have t= o stay open because Semantic also calls
accept-process-output while poin= t is on an excursion.

Since Stefan had said input-pending-p behavior seems wrong, I followed<= br>up in the hopes we can both correct a wrong and reduce how common thisuser-visible symptom is.

--e89a8ff1ce9ef58a4904e8c82c1c-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Oct 2013 16:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13818545447896 (code B ref 15045); Tue, 15 Oct 2013 16:30:02 +0000 Received: (at 15045) by debbugs.gnu.org; 15 Oct 2013 16:29:04 +0000 Received: from localhost ([127.0.0.1]:51612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VW7UV-00023H-Hx for submit@debbugs.gnu.org; Tue, 15 Oct 2013 12:29:03 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:61443) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VW7US-00022j-73 for 15045@debbugs.gnu.org; Tue, 15 Oct 2013 12:29:01 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MUP00100XFPL800@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Tue, 15 Oct 2013 19:28:52 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MUP00108XS4B080@a-mtaout20.012.net.il>; Tue, 15 Oct 2013 19:28:52 +0300 (IDT) Date: Tue, 15 Oct 2013 19:28:50 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83li1upkfx.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 15 Oct 2013 10:12:32 -0400 > From: Barry OReilly > Cc: Eli Zaretskii , David Engster , 15045@debbugs.gnu.org, > Eric Ludlam > > > The original problem is rare enough > > You're wrong to call it rare. Dave Milter, David Engster, and I have > seen it separately. For functionality so widely and freely used in every corner of Emacs, anything is "rare" in my book, except if it totally screws up Emacs for almost everyone. input-pending-p is all over the place, so if it were not "rare", we would be facing an outcry long ago. > That input-pending-p behaves this way is apparently surprising to > the Elisp developer. Yes, it _is_ surprising. But if every surprising behavior will necessarily lead to change in long entrenched behavior, Emacs will never be stable. > It is even more surprising to the user upon witnessing such a > jarring symptom. I didn't say that problem shouldn't be solved. I didn't say we should let users deal with this. So I find this remark unfair. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Oct 2013 17:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 15045@debbugs.gnu.org, Stefan Monnier , David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138185694711897 (code B ref 15045); Tue, 15 Oct 2013 17:10:02 +0000 Received: (at 15045) by debbugs.gnu.org; 15 Oct 2013 17:09:07 +0000 Received: from localhost ([127.0.0.1]:51731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VW87G-00035p-1r for submit@debbugs.gnu.org; Tue, 15 Oct 2013 13:09:06 -0400 Received: from mail-oa0-f43.google.com ([209.85.219.43]:37733) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VW87E-00035J-HV for 15045@debbugs.gnu.org; Tue, 15 Oct 2013 13:09:05 -0400 Received: by mail-oa0-f43.google.com with SMTP id i3so6039826oag.2 for <15045@debbugs.gnu.org>; Tue, 15 Oct 2013 10:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ebxHVepsZ9TS6GmvEdoMIOo4jyzV0KsoR82IrQ+CrhI=; b=GyYzgrv6lJlR7BqBrfvE3dJc9TRrXapf/w5OU+ch+cCewzfDRd8zagWuARAL7jQTdk O9IsUYPb6GOOwteMOFA+DsVlg9skUHUYo/5t/fbMpQblC4I/dVX1d7RdQPGBxUDoM6C9 jhiB5EkzxKVuBj7UpZISGV3cAgHDxFrwxvXaXMLybfmvq/j2lCQn/rP/P9EOtL3Ph4sJ q73PZZlMLWSleAzgDFNsLdFaB9uZbfZMXtpi7q84cvzKwa+PngKjgdjO6veAV0QyRzFP mOQbZOhZROcT0gU22so+hCnM1Ao4/qb0YOL1mOn1lGjz5GZjMkgsrGWxpu1gnyHXzeXE fdgg== MIME-Version: 1.0 X-Received: by 10.182.237.75 with SMTP id va11mr35981789obc.5.1381856938828; Tue, 15 Oct 2013 10:08:58 -0700 (PDT) Received: by 10.76.156.103 with HTTP; Tue, 15 Oct 2013 10:08:58 -0700 (PDT) In-Reply-To: <83li1upkfx.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Tue, 15 Oct 2013 13:08:58 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=e89a8ff1c99ef827c904e8caa3f7 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --e89a8ff1c99ef827c904e8caa3f7 Content-Type: text/plain; charset=ISO-8859-1 I'm thinking I should augment the patch so as the observable behavior of (sit-for 0) doesn't change. It would no longer run timers if only input-pending-p changes as described. Currently: (defun sit-for (seconds &optional nodisp obsolete) [...] (cond [...] ((input-pending-p) nil) ((<= seconds 0) (or nodisp (redisplay))) [...] I considered whether (<= seconds 0) could fall through to the t case instead. The read_char function has a complex implementation, so it's not clear doing so wouldn't change behavior. Is there another Lisp function that does timer_check and little else, which the (<= seconds 0) case could call? Should I write a new subr for it? Looking ahead to the concurrency branch, should (sit-for 0 t) and (thread-yield) have different behaviors? Or perhaps the former calls the latter? I don't see thread-yield checking for timers to run, should it? (And it didn't look like timers were split out into their own threads on the concurrency branch.) --e89a8ff1c99ef827c904e8caa3f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm thinking I should augment the patch so as the obse= rvable behavior
of (sit-for 0) doesn't change. It would no longer ru= n timers if only
input-pending-p changes as described. Currently:
=A0 (defun sit-for (seconds &optional nodisp obsolete)
=A0=A0=A0 [..= .]
=A0=A0=A0 (cond
=A0=A0=A0=A0 [...]
=A0=A0=A0=A0 ((input-pending= -p)
=A0=A0=A0=A0=A0 nil)
=A0=A0=A0=A0 ((<=3D seconds 0)
=A0=A0= =A0=A0=A0 (or nodisp (redisplay)))
=A0=A0=A0=A0 [...]

I considere= d whether (<=3D seconds 0) could fall through to the t case
instead. The read_char function has a complex implementation, so it'snot clear doing so wouldn't change behavior.

Is there another = Lisp function that does timer_check and little else,
which the (<=3D = seconds 0) case could call? Should I write a new subr
for it?

Looking ahead to the concurrency branch, should (sit-for 0 t= ) and
(thread-yield) have different behaviors? Or perhaps the former cal= ls
the latter? I don't see thread-yield checking for timers to run,<= br> should it? (And it didn't look like timers were split out into theirown threads on the concurrency branch.)

--e89a8ff1c99ef827c904e8caa3f7-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Oct 2013 18:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org, monnier@iro.umontreal.ca, deng@randomsample.de, eric@siege-engine.com Reply-To: Eli Zaretskii Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138186295921760 (code B ref 15045); Tue, 15 Oct 2013 18:50:01 +0000 Received: (at 15045) by debbugs.gnu.org; 15 Oct 2013 18:49:19 +0000 Received: from localhost ([127.0.0.1]:52039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VW9gE-0005es-OM for submit@debbugs.gnu.org; Tue, 15 Oct 2013 14:49:19 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:60774) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VW9gB-0005ec-Rx for 15045@debbugs.gnu.org; Tue, 15 Oct 2013 14:49:17 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MUQ0020048IJ900@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Tue, 15 Oct 2013 21:48:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MUQ002QD48O9OA0@a-mtaout20.012.net.il>; Tue, 15 Oct 2013 21:48:25 +0300 (IDT) Date: Tue, 15 Oct 2013 21:48:23 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83k3hepdzc.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 15 Oct 2013 13:08:58 -0400 > From: Barry OReilly > Cc: Stefan Monnier , David Engster , > 15045@debbugs.gnu.org, Eric Ludlam > > (defun sit-for (seconds &optional nodisp obsolete) > [...] > (cond > [...] > ((input-pending-p) > nil) > ((<= seconds 0) > (or nodisp (redisplay))) > [...] > > I considered whether (<= seconds 0) could fall through to the t case > instead. Maybe I'm missing something, but wouldn't that bypass redisplay? Currently, (sit-for 0) is a very popular method to trigger redisplay; changing that _will_ bite a lot of code out there. > The read_char function has a complex implementation, so it's not > clear doing so wouldn't change behavior. Are you assuming that read_char always redisplays? That's not true, AFAIK. > Is there another Lisp function that does timer_check and little else, > which the (<= seconds 0) case could call? Should I write a new subr > for it? Not sure I understand the question, sorry. From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Oct 2013 19:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 15045@debbugs.gnu.org, Stefan Monnier , David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138186477828852 (code B ref 15045); Tue, 15 Oct 2013 19:20:02 +0000 Received: (at 15045) by debbugs.gnu.org; 15 Oct 2013 19:19:38 +0000 Received: from localhost ([127.0.0.1]:52150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWA9Z-0007VI-Mf for submit@debbugs.gnu.org; Tue, 15 Oct 2013 15:19:37 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:58061) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWA9Y-0007V3-Ey for 15045@debbugs.gnu.org; Tue, 15 Oct 2013 15:19:36 -0400 Received: by mail-ob0-f170.google.com with SMTP id gq1so6393050obb.29 for <15045@debbugs.gnu.org>; Tue, 15 Oct 2013 12:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DVUN5ayj18HShKBI6Z5+4RCQ7ZAk4wmhMLf99+11xWg=; b=Es+UZYlQnDfAYJ+uHqY1HWy+NBLMcew8EHtrvSwI3LDxRbHG4K+vKa5CtQBZT9BHkw QNcf8AzFIigBEDPT3OBmfy6WVrs1eL+pu1ro+4XCrMjjcatnqwdLNEpJdMnFS1qeMWRK zcMRQtREB4QAPm3hPc1ru8fIg/3SCF85zUjuceos29V8ZNGbh09P6gLx8sDoYEIOeiAP Y9kzN8vSghDJQVUB5/Ay11GavUl/3rddZGyqUK41YLxE9tc8Ck63ytunUP7PPFwuMJQn AzkHk1l8tXSMNDMstNZczbBDi/nXD5UMDK2/V6LaNWqfa9vAagz23pTsODuQS00+7EPq LT6Q== MIME-Version: 1.0 X-Received: by 10.182.99.231 with SMTP id et7mr36724102obb.10.1381864770434; Tue, 15 Oct 2013 12:19:30 -0700 (PDT) Received: by 10.76.156.103 with HTTP; Tue, 15 Oct 2013 12:19:30 -0700 (PDT) In-Reply-To: <83k3hepdzc.fsf@gnu.org> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> <83k3hepdzc.fsf@gnu.org> Date: Tue, 15 Oct 2013 15:19:30 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=089e0158a92ec4fbee04e8cc76a8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e0158a92ec4fbee04e8cc76a8 Content-Type: text/plain; charset=ISO-8859-1 What I'm saying is that [...] ((input-pending-p) nil) ((<= seconds 0) (or nodisp (redisplay))) [...] would become [...] ((input-pending-p) nil) ((<= seconds 0) (to-be-determined-call-to-timer-check) (or nodisp (redisplay))) [...] The idea is to compensate for input-pending-p no longer calling timer_check so as sit-for will behave the same. --089e0158a92ec4fbee04e8cc76a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What I'm saying is that

=A0 [...]
=A0 ((inpu= t-pending-p)
=A0=A0 nil)
=A0 ((<=3D seconds 0)
=A0=A0 (or nodis= p (redisplay)))
=A0 [...]

would become

=A0 [...]
=A0 ((= input-pending-p)
=A0=A0 nil)
=A0 ((<=3D seconds 0)
=A0=A0 (to-be-determined-call-to-timer-check)=A0=A0 (or nodisp (redisplay)))
=A0 [...]

The idea is to compen= sate for input-pending-p no longer calling
timer_check so as sit-for wil= l behave the same.

--089e0158a92ec4fbee04e8cc76a8-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2013 02:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13818922579096 (code B ref 15045); Wed, 16 Oct 2013 02:58:01 +0000 Received: (at 15045) by debbugs.gnu.org; 16 Oct 2013 02:57:37 +0000 Received: from localhost ([127.0.0.1]:53320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWHIm-0002Me-Ay for submit@debbugs.gnu.org; Tue, 15 Oct 2013 22:57:36 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:53171) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWHIi-0002MU-Cj for 15045@debbugs.gnu.org; Tue, 15 Oct 2013 22:57:32 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r9G2vTFf020043; Tue, 15 Oct 2013 22:57:30 -0400 Received: by pastel.home (Postfix, from userid 20848) id A2AF362EBC; Tue, 15 Oct 2013 22:57:29 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Tue, 15 Oct 2013 22:57:29 -0400 In-Reply-To: (Barry OReilly's message of "Tue, 15 Oct 2013 13:08:58 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4732=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4732> : inlines <150> : streams <1056599> : uri <1566595> X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) > of (sit-for 0) doesn't change. It would no longer run timers if only > input-pending-p changes as described. Currently: > (defun sit-for (seconds &optional nodisp obsolete) > [...] > (cond > [...] > ((input-pending-p) > nil) > ((<= seconds 0) > (or nodisp (redisplay))) > [...] Indeed, the Elisp version of sit-for is a mess. > I considered whether (<= seconds 0) could fall through to the t case > instead. The easiest solution is to add an optional argument `check-timers' to input-pending-p, so you can preserve the exact same behavior. In the long run, we should try and clean up sit-for, but you may not have the courage to dig into this right now. > Looking ahead to the concurrency branch, should (sit-for 0 t) and > (thread-yield) have different behaviors? Not really. > I don't see thread-yield checking for timers to run, should it? Yes, it should. > (And it didn't look like timers were split out into their own threads > on the concurrency branch.) The current state of the concurrency branch is not always representative of what it should ideally look like ;-) But even if timers are made to belong to a thread, thread-yield should probably check timers. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2013 14:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138193546117419 (code B ref 15045); Wed, 16 Oct 2013 14:58:02 +0000 Received: (at 15045) by debbugs.gnu.org; 16 Oct 2013 14:57:41 +0000 Received: from localhost ([127.0.0.1]:54388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWSXc-0004Ws-G1 for submit@debbugs.gnu.org; Wed, 16 Oct 2013 10:57:41 -0400 Received: from mail-oa0-f49.google.com ([209.85.219.49]:57564) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWSXZ-0004We-Uv for 15045@debbugs.gnu.org; Wed, 16 Oct 2013 10:57:38 -0400 Received: by mail-oa0-f49.google.com with SMTP id j10so593768oah.22 for <15045@debbugs.gnu.org>; Wed, 16 Oct 2013 07:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wZKYCjg1+cVhZkQSs4pZTpq0XC9R4JCY0qw3cvOYArI=; b=Mp3DZ8ZADors64ZT28mhPjwoV2srW/RqXS+Ohewu9+068WkOMAsHAHcIrOkGyjYOwS JoaSTdmYnsaCEFaNago+QGyhNiJsNBIc7dVksNGUVTLGOvv1Xss/2GfAXOp16nuRMtPS fSExe28XbmUcGR7OGKsfU0YsznAoNXBTlNpqlGfaQiYX2M6HAcWJbZ2qyKP4BYANJfGk pYzaaH9G4FUSXGdbH9xtkzsjPZZo3JuG1k/VAFLLNJSnoSvVlDSK6sTNDC/5Rcu/qts1 N7Ofzoo/gMc8d2b202rI5LKymFvF9AzYhue8usZ7wLZJH06kE0QMJngHoVgqwWGItNfE jiHg== MIME-Version: 1.0 X-Received: by 10.182.149.234 with SMTP id ud10mr674979obb.73.1381935452082; Wed, 16 Oct 2013 07:57:32 -0700 (PDT) Received: by 10.76.156.103 with HTTP; Wed, 16 Oct 2013 07:57:31 -0700 (PDT) In-Reply-To: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Wed, 16 Oct 2013 10:57:31 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=001a11348918b9571a04e8dceb3c X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11348918b9571a04e8dceb3c Content-Type: text/plain; charset=ISO-8859-1 > The easiest solution is to add an optional argument `check-timers' > to input-pending-p, so you can preserve the exact same behavior. I assume you mean no-check-timers, nil being default. > In the long run, we should try and clean up sit-for, but you may not > have the courage to dig into this right now. I'm arguing I don't need to dig into sit-for's complexity to maintain its current behavior. If (sit-for 0 ...) calls something like thread-yield which in turn calls timer_check, then all ways of calling sit-for would have unchanged behavior. Even so, because of other calls to input-pending-p not through sit-for, there could conceivably be regressions in the latencies of timers, due to background tasks not yielding when they used to. If we discovered such cases, the solution is straight forward: replace (input-pending-p) with (sit-for 0 t) in the offending background task. But I understand the objection. If the no-check-timers arg solution is what you want, I'll prepare a patch to add it and have Semantic and NXML use it. Also, what do you think are the merits of putting in the specpdl-walking check discussed earlier, enabled with --enable-checking? I can't see a legit case where check_timers is called when point is on an excursion. Such code should not make any assumptions about the other timers the user is running which might call redisplay. > The current state of the concurrency branch is not always > representative of what it should ideally look like ;-) But even if > timers are made to belong to a thread, thread-yield should probably > check timers. The timer behavior on the concurrency branch seems reasonable. Moving them to their own threads might be complex, not least because of concerns that the global lock will be yielded often enough to not regress timer latencies. --001a11348918b9571a04e8dceb3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> The easiest solution is to add an optional argument `= check-timers'
> to input-pending-p, so you can preserve the exact= same behavior.

I assume you mean no-check-timers, nil being default= .

> In the long run, we should try and clean up sit-for, but you may n= ot
> have the courage to dig into this right now.

I'm argu= ing I don't need to dig into sit-for's complexity to maintain
its current behavior. If (sit-for 0 ...) calls something like
thread-yie= ld which in turn calls timer_check, then all ways of calling
sit-for wou= ld have unchanged behavior.

Even so, because of other calls to input= -pending-p not through
sit-for, there could conceivably be regressions in the latencies of
time= rs, due to background tasks not yielding when they used to. If we
discov= ered such cases, the solution is straight forward: replace
(input-pendin= g-p) with (sit-for 0 t) in the offending background task.
But I understand the objection.

If the no-check-timers arg solution = is what you want, I'll prepare a
patch to add it and have Semantic a= nd NXML use it.

Also, what do you think are the merits of putting in= the
specpdl-walking check discussed earlier, enabled with
--enable-checking?= I can't see a legit case where check_timers is
called when point is= on an excursion. Such code should not make any
assumptions about the ot= her timers the user is running which might
call redisplay.

> The current state of the concurrency branch is = not always
> representative of what it should ideally look like ;-) B= ut even if
> timers are made to belong to a thread, thread-yield shou= ld probably
> check timers.

The timer behavior on the concurrency branch seem= s reasonable. Moving
them to their own threads might be complex, not lea= st because of
concerns that the global lock will be yielded often enough= to not
regress timer latencies.

--001a11348918b9571a04e8dceb3c-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2013 17:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13819458551400 (code B ref 15045); Wed, 16 Oct 2013 17:51:02 +0000 Received: (at 15045) by debbugs.gnu.org; 16 Oct 2013 17:50:55 +0000 Received: from localhost ([127.0.0.1]:54557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWVFG-0000MV-FK for submit@debbugs.gnu.org; Wed, 16 Oct 2013 13:50:54 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:60637) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWVFE-0000MJ-2X for 15045@debbugs.gnu.org; Wed, 16 Oct 2013 13:50:52 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r9GHoocY027631; Wed, 16 Oct 2013 13:50:50 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id A0955B4162; Wed, 16 Oct 2013 13:50:50 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Wed, 16 Oct 2013 13:50:50 -0400 In-Reply-To: (Barry OReilly's message of "Wed, 16 Oct 2013 10:57:31 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4733=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4733> : inlines <151> : streams <1056976> : uri <1567214> X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) >> The easiest solution is to add an optional argument `check-timers' >> to input-pending-p, so you can preserve the exact same behavior. > I assume you mean no-check-timers, nil being default. No, I meant `check-timers', so the default behavior is modified, but you can recover the previous behavior by passing an extra argument. >> In the long run, we should try and clean up sit-for, but you may not >> have the courage to dig into this right now. > I'm arguing I don't need to dig into sit-for's complexity to maintain > its current behavior. If (sit-for 0 ...) calls something like > thread-yield which in turn calls timer_check, then all ways of calling > sit-for would have unchanged behavior. That's theory: there is no thread-yield right now, nor any timer-check. > Also, what do you think are the merits of putting in the > specpdl-walking check discussed earlier, enabled with > --enable-checking? I like the idea, tho I'd have to see the code first to know whether it should depend on --enable-checking or something else. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2013 18:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13819483439459 (code B ref 15045); Wed, 16 Oct 2013 18:33:02 +0000 Received: (at 15045) by debbugs.gnu.org; 16 Oct 2013 18:32:23 +0000 Received: from localhost ([127.0.0.1]:54593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWVtP-0002SV-0z for submit@debbugs.gnu.org; Wed, 16 Oct 2013 14:32:23 -0400 Received: from mail-ob0-f180.google.com ([209.85.214.180]:54161) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWVtN-0002SJ-2r for 15045@debbugs.gnu.org; Wed, 16 Oct 2013 14:32:21 -0400 Received: by mail-ob0-f180.google.com with SMTP id wo20so773231obc.25 for <15045@debbugs.gnu.org>; Wed, 16 Oct 2013 11:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mr4l+r036E8pVJFPZGMOYPvMxuY0w4b/xwl4NVcAuNc=; b=kr66j66JdslQwOsBaoRW1Jb07CS7xDDCreELEy/LuOzuyeqiKJgBc/7cQ51ZFgHAIC JUJ5RJwIcO2qQ6HZxjLkoOnmqmu/ZwIugOFfCqD5iJ2xDkWoxueniWkdwbDcFreEhLBl EXDv+UGfvyjDqJicf+vz+pPfe5sDQ6RySk0rFSz/VhxRqWJUsmBUGGtCP75pvFDy2ySz FcTfwYnB7Q+Ha98mLw2RZenjDVesb9Mrc0BGLjLYzYmdyySY2ttZSY3EwHRSdIW8kb3D fSYyn/Yd0ukSOMRWLjRt9HAiA3zqI/t0OsyTimGjliePeZ190a/hogVZrUh9m4qtT5wi 9GVA== MIME-Version: 1.0 X-Received: by 10.182.96.100 with SMTP id dr4mr7075846obb.22.1381948335409; Wed, 16 Oct 2013 11:32:15 -0700 (PDT) Received: by 10.76.156.103 with HTTP; Wed, 16 Oct 2013 11:32:15 -0700 (PDT) In-Reply-To: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Wed, 16 Oct 2013 14:32:15 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=001a11c33560a150a204e8dfeb94 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c33560a150a204e8dfeb94 Content-Type: text/plain; charset=ISO-8859-1 > That's theory: there is no thread-yield right now, nor any > timer-check. Why not add either? We could implement thread-yield on trunk to call the timer_check C function and nothing else for now. Or call it "yield" and rename "thread-yield" to "yield" on the concurrency branch. --001a11c33560a150a204e8dfeb94 Content-Type: text/html; charset=ISO-8859-1
> That's theory: there is no thread-yield right now, nor any
> timer-check.

Why not add either? We could implement thread-yield on trunk to call
the timer_check C function and nothing else for now. Or call it
"yield" and rename "thread-yield" to "yield" on the concurrency
branch.

--001a11c33560a150a204e8dfeb94-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2013 15:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138202220231246 (code B ref 15045); Thu, 17 Oct 2013 15:04:01 +0000 Received: (at 15045) by debbugs.gnu.org; 17 Oct 2013 15:03:22 +0000 Received: from localhost ([127.0.0.1]:55644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWp6f-00087s-I2 for submit@debbugs.gnu.org; Thu, 17 Oct 2013 11:03:22 -0400 Received: from mail-ob0-f180.google.com ([209.85.214.180]:47620) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWp6c-00087b-05 for 15045@debbugs.gnu.org; Thu, 17 Oct 2013 11:03:19 -0400 Received: by mail-ob0-f180.google.com with SMTP id wo20so1605455obc.25 for <15045@debbugs.gnu.org>; Thu, 17 Oct 2013 08:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8Kl12+HvA1QMq+8hYnuXAzW7mXWvv7ZX735pGiVd854=; b=cCO0QEau48iXmY3XMLelL0NlQ3lTgw+U9zvpE0+DICTAfKHHxA+6R9gNmLdmwCLfSM TXWtO2ptwjomUw01UTf8jJwaZVarOBS5Msbk+UUi5Z+HgLHJe0TnaRWiGrFsq51SsVlx Pf0Q4wx1aq3cC8PwBU4Or3CgtwYm62/JJV/2kEMoMqeg3ykyvkWzuvU5lCfOfKEdPEEb SodGCXPAlQtLz9vWLsm0D62izFzDGI5Q+hMMdL7iMxeW8o+zWTTuRCvHNP7YrEnbJloH SuTg2a8F5YMCWMmrmGfn0af5NQwcyPni4Lrjjyb+gr/zRiBsw4ksQO7Z+ZBoEWnSSfhm FRTA== MIME-Version: 1.0 X-Received: by 10.182.96.100 with SMTP id dr4mr14575884obb.22.1382022191387; Thu, 17 Oct 2013 08:03:11 -0700 (PDT) Received: by 10.76.156.103 with HTTP; Thu, 17 Oct 2013 08:03:11 -0700 (PDT) In-Reply-To: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Thu, 17 Oct 2013 11:03:11 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=001a11c33560ca1aa404e8f11d55 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c33560ca1aa404e8f11d55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here's the solution you requested. Let me know that it's good to install. diff --git a/ChangeLog b/ChangeLog index a755b5c..8b58ebc 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,15 @@ +2013-10-17 Barry O'Reilly + + Change how input-pending-p checks for timers to run. Its default + changes from checking to not checking. Its new check-timers param + allows for prior behavior. (Bug#15045). + * src/keyboard.c (Finput_pending_p): Accept optional check-timers + param. + * lisp/subr.el (sit-for): Call (input-pending-p t) so as to behave + as before. + * test/automated/timer-tests.el: New file. Tests that (sit-for 0) + allows another timer to run. + 2013-10-13 Glenn Morris * configure.ac [alpha]: Explicit error in non-ELF case. (Bug#15601= ) diff --git a/etc/NEWS b/etc/NEWS index ddb9a9f..06372f9 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -611,6 +611,9 @@ low-level libraries gfilenotify.c, inotify.c or w32notify.c. ^L * Incompatible Lisp Changes in Emacs 24.4 +** `(input-pending-p)' no longer runs other timers which are ready to +run. The new optional CHECK-TIMERS param allows for the prior behavior. + ** `defvar' and `defcustom' in a let-binding affect the "external" default= . ** The syntax of ?=BB and ?=AB is now punctuation instead of matched paren= s. diff --git a/lisp/subr.el b/lisp/subr.el index 0d03e9a..952b9b6 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -2222,7 +2222,7 @@ floating point support." (noninteractive (sleep-for seconds) t) - ((input-pending-p) + ((input-pending-p t) nil) ((<=3D seconds 0) (or nodisp (redisplay))) diff --git a/src/keyboard.c b/src/keyboard.c index e0cd4d4..7f8692a 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -9947,12 +9947,13 @@ requeued_events_pending_p (void) return (!NILP (Vunread_command_events)); } - -DEFUN ("input-pending-p", Finput_pending_p, Sinput_pending_p, 0, 0, 0, +DEFUN ("input-pending-p", Finput_pending_p, Sinput_pending_p, 0, 1, 0, doc: /* Return t if command input is currently available with no wait. Actually, the value is nil only if we can be sure that no input is available; -if there is a doubt, the value is t. */) - (void) +if there is a doubt, the value is t. + +If CHECK-TIMERS is non-nil, timers that are ready to run will do so. */) + (Lisp_Object check_timers) { if (!NILP (Vunread_command_events) || !NILP (Vunread_post_input_method_events) @@ -9962,8 +9963,9 @@ if there is a doubt, the value is t. */) /* Process non-user-visible events (Bug#10195). */ process_special_events (); - return (get_input_pending (READABLE_EVENTS_DO_TIMERS_NOW - | READABLE_EVENTS_FILTER_EVENTS) + return (get_input_pending ((EQ (check_timers, Qnil) + ? 0 : READABLE_EVENTS_DO_TIMERS_NOW) + | READABLE_EVENTS_FILTER_EVENTS) ? Qt : Qnil); } diff --git a/test/automated/timer-tests.el b/test/automated/timer-tests.el new file mode 100644 index 0000000..b4cb1e6 --- /dev/null +++ b/test/automated/timer-tests.el @@ -0,0 +1,42 @@ +;;; timer-tests.el --- tests for timers -*- coding: utf-8; lexical-binding:t -*- + +;; Copyright (C) 2013 Free Software Foundation, Inc. + +;; This file is part of GNU Emacs. + +;; This program is free software: you can redistribute it and/or +;; modify it under the terms of the GNU General Public License as +;; published by the Free Software Foundation, either version 3 of the +;; License, or (at your option) any later version. +;; +;; This program is distributed in the hope that it will be useful, but +;; WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +;; General Public License for more details. +;; +;; You should have received a copy of the GNU General Public License +;; along with this program. If not, see `http://www.gnu.org/licenses/'. + +;;; Commentary: + +;;; Code: + +(require 'ert) + +(ert-deftest timer-tests-sit-for () + (let ((timer-ran nil) + (timeout (time-add (current-time) + '(0 10 0 0))) + ;; Want sit-for behavior when interactive + (noninteractive nil)) + (run-at-time '(0 1 0 0) + nil + (lambda () + (setq timer-ran t))) + (while (not timer-ran) + (should (time-less-p (current-time) + timeout)) + (sit-for 0 t)))) + +;;; timer-tests.el ends here + --001a11c33560ca1aa404e8f11d55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Here's the solution you requested. Let me know that it= 's good to
install.

diff --git a/ChangeLog b/ChangeLog
ind= ex a755b5c..8b58ebc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3= +1,15 @@
+2013-10-17=A0 Barry O'Reilly=A0 <gundaetiapo@gmail.com>
+
+=A0=A0=A0=A0=A0=A0 Change how= input-pending-p checks for timers to run. Its default
+=A0=A0=A0=A0=A0= =A0 changes from checking to not checking. Its new check-timers param
+=A0=A0=A0=A0=A0=A0 allows for prior behavior. (Bug#15045).
+=A0=A0=A0= =A0=A0=A0 * src/keyboard.c (Finput_pending_p): Accept optional check-timers=
+=A0=A0=A0=A0=A0=A0 param.
+=A0=A0=A0=A0=A0=A0 * lisp/subr.el (sit-f= or): Call (input-pending-p t) so as to behave
+=A0=A0=A0=A0=A0=A0 as before.
+=A0=A0=A0=A0=A0=A0 * test/automated/time= r-tests.el: New file. Tests that (sit-for 0)
+=A0=A0=A0=A0=A0=A0 allows = another timer to run.
+
=A02013-10-13=A0 Glenn Morris=A0 <rgm@gnu.org>
=A0
=A0=A0=A0=A0=A0=A0=A0 * configure.ac= [alpha]: Explicit error in non-ELF case.=A0 (Bug#15601)
diff --git = a/etc/NEWS b/etc/NEWS
index ddb9a9f..06372f9 100644
--- a/etc/NEWS+++ b/etc/NEWS
@@ -611,6 +611,9 @@ low-level libraries gfilenotify.c, inotify.c or w32noti= fy.c.
=A0^L
=A0* Incompatible Lisp Changes in Emacs 24.4
=A0
+*= * `(input-pending-p)' no longer runs other timers which are ready to+run. The new optional CHECK-TIMERS param allows for the prior behavior. +
=A0** `defvar' and `defcustom' in a let-binding affect the &qu= ot;external" default.
=A0
=A0** The syntax of ?=BB and ?=AB is n= ow punctuation instead of matched parens.
diff --git a/lisp/subr.el b/li= sp/subr.el
index 0d03e9a..952b9b6 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el@@ -2222,7 +2222,7 @@ floating point support."
=A0=A0=A0 (noninte= ractive
=A0=A0=A0=A0 (sleep-for seconds)
=A0=A0=A0=A0 t)
-=A0=A0 (= (input-pending-p)
+=A0=A0 ((input-pending-p t)
=A0=A0=A0=A0 nil)
=A0=A0=A0 ((<=3D seconds 0)
=A0=A0=A0=A0 (or nod= isp (redisplay)))
diff --git a/src/keyboard.c b/src/keyboard.c
index = e0cd4d4..7f8692a 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
= @@ -9947,12 +9947,13 @@ requeued_events_pending_p (void)
=A0=A0 return (!NILP (Vunread_command_events));
=A0}
=A0
-
-DEF= UN ("input-pending-p", Finput_pending_p, Sinput_pending_p, 0, 0, = 0,
+DEFUN ("input-pending-p", Finput_pending_p, Sinput_pending= _p, 0, 1, 0,
=A0=A0=A0=A0=A0=A0=A0 doc: /* Return t if command input is currently availa= ble with no wait.
=A0Actually, the value is nil only if we can be sure t= hat no input is available;
-if there is a doubt, the value is t.=A0 */)<= br>-=A0 (void)
+if there is a doubt, the value is t.
+
+If CHECK-TIMERS is non-nil, = timers that are ready to run will do so.=A0 */)
+=A0 (Lisp_Object check_= timers)
=A0{
=A0=A0 if (!NILP (Vunread_command_events)
=A0=A0=A0= =A0=A0=A0 || !NILP (Vunread_post_input_method_events)
@@ -9962,8 +9963,9 @@ if there is a doubt, the value is t.=A0 */)
=A0=A0= /* Process non-user-visible events (Bug#10195).=A0 */
=A0=A0 process_sp= ecial_events ();
=A0
-=A0 return (get_input_pending (READABLE_EVENTS_= DO_TIMERS_NOW
-=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0 | READABLE_EVENTS_FILTER_EVENTS= )
+=A0 return (get_input_pending ((EQ (check_timers, Qnil)
+=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ? 0 : READABLE_EVENTS_DO_TIMERS_NOW)
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | READABLE_EVENTS_FI= LTER_EVENTS)
=A0=A0=A0=A0 =A0 ? Qt : Qnil);
=A0}
=A0
diff --git a/test/automate= d/timer-tests.el b/test/automated/timer-tests.el
new file mode 100644index 0000000..b4cb1e6
--- /dev/null
+++ b/test/automated/timer-test= s.el
@@ -0,0 +1,42 @@
+;;; timer-tests.el --- tests for timers -*- coding: utf-8; lexical-binding= :t -*-
+
+;; Copyright (C) 2013 Free Software Foundation, Inc.
++;; This file is part of GNU Emacs.
+
+;; This program is free soft= ware: you can redistribute it and/or
+;; modify it under the terms of the GNU General Public License as
+;; p= ublished by the Free Software Foundation, either version 3 of the
+;; Li= cense, or (at your option) any later version.
+;;
+;; This program is= distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCH= ANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.=A0 See the GNU
+;; Gener= al Public License for more details.
+;;
+;; You should have received = a copy of the GNU General Public License
+;; along with this program.=A0 If not, see `http://www.gnu.org/licenses/'.
+
+;;; Commentary:<= br>+
+;;; Code:
+
+(require 'ert)
+
+(ert-deftest timer-= tests-sit-for ()
+=A0 (let ((timer-ran nil)
+=A0=A0=A0=A0=A0=A0=A0 (timeout (time-add (cu= rrent-time)
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 '(0 10 0 0)))
+=A0=A0=A0=A0=A0=A0=A0 ;; Want s= it-for behavior when interactive
+=A0=A0=A0=A0=A0=A0=A0 (noninteractive = nil))
+=A0=A0=A0 (run-at-time '(0 1 0 0)
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 nil
+=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (lambda ()
+=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (setq timer-ran t)))
+=A0=A0=A0 (while (n= ot timer-ran)
+=A0=A0=A0=A0=A0=A0=A0 (should (time-less-p (current-time)=
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 timeout))
+=A0=A0=A0=A0=A0=A0=A0 (sit-for 0 t))))
+
+;;; timer-tests.el ends he= re
+

--001a11c33560ca1aa404e8f11d55-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2013 18:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138203394621140 (code B ref 15045); Thu, 17 Oct 2013 18:20:02 +0000 Received: (at 15045) by debbugs.gnu.org; 17 Oct 2013 18:19:06 +0000 Received: from localhost ([127.0.0.1]:55784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWsA5-0005Us-4x for submit@debbugs.gnu.org; Thu, 17 Oct 2013 14:19:05 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:4382) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWsA3-0005UO-Ae for 15045@debbugs.gnu.org; Thu, 17 Oct 2013 14:19:03 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCo0c/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kLodwBsEtkQoDpHqBXoMT X-IPAS-Result: Av4EABK/CFFMCo0c/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kLodwBsEtkQoDpHqBXoMT X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="35746751" Received: from 76-10-141-28.dsl.teksavvy.com (HELO pastel.home) ([76.10.141.28]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 17 Oct 2013 14:18:57 -0400 Received: by pastel.home (Postfix, from userid 20848) id F2F3E630FD; Thu, 17 Oct 2013 14:18:56 -0400 (EDT) From: Stefan Monnier Message-ID: References: <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Thu, 17 Oct 2013 14:18:56 -0400 In-Reply-To: (Barry OReilly's message of "Thu, 17 Oct 2013 11:03:11 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Here's the solution you requested. Let me know that it's good to > install. Looks fine. See comments below. > + Change how input-pending-p checks for timers to run. Its default > + changes from checking to not checking. Its new check-timers param > + allows for prior behavior. Good. "Don't run timers in input-pending-p" would have sufficed. > +** `(input-pending-p)' no longer runs other timers which are ready to > +run. The new optional CHECK-TIMERS param allows for the prior behavior. Please use 2 spaces after a full-stop (see sentence-end-double-space). > + return (get_input_pending ((EQ (check_timers, Qnil) EQ (check_timers, Qnil) => NILP (check_timers) > +;;; timer-tests.el --- tests for timers -*- coding: utf-8; > lexical-binding:t -*- The "coding:utf-8" is redundant nowadays. > +(require 'ert) IIUC this `require' is also redundant. > +(ert-deftest timer-tests-sit-for () > + (let ((timer-ran nil) > + (timeout (time-add (current-time) > + '(0 10 0 0))) > + ;; Want sit-for behavior when interactive > + (noninteractive nil)) > + (run-at-time '(0 1 0 0) > + nil > + (lambda () > + (setq timer-ran t))) > + (while (not timer-ran) > + (should (time-less-p (current-time) > + timeout)) > + (sit-for 0 t)))) I think there's a race-condition, here: - let's say we're at time < timeout. - we run sit-for, which does not run the timer since we're still timeout. - we check (should (time-less-p (current-time) timeout)) - we complain unjustly. I.e. we should test, after running sit-for, that the "current time before running sit-for" was < timeout. Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2013 20:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138204012030697 (code B ref 15045); Thu, 17 Oct 2013 20:02:02 +0000 Received: (at 15045) by debbugs.gnu.org; 17 Oct 2013 20:02:00 +0000 Received: from localhost ([127.0.0.1]:55866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWtlf-0007z2-2I for submit@debbugs.gnu.org; Thu, 17 Oct 2013 16:01:59 -0400 Received: from mail-oa0-f51.google.com ([209.85.219.51]:47336) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWtlc-0007yj-Le for 15045@debbugs.gnu.org; Thu, 17 Oct 2013 16:01:57 -0400 Received: by mail-oa0-f51.google.com with SMTP id h1so1030733oag.10 for <15045@debbugs.gnu.org>; Thu, 17 Oct 2013 13:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UpCRf9yYdWHmr3OXQxjUOl5SoV3ZFByHbM4sEfPrUjs=; b=z5YoTDNyjzsc2Xk86N5jEaG5P4nVct/pnSG1F83Z1V+Lsg69HRxdf0YrQ+0aO3Ozk+ e3QbG5z02dO0+gFg2Y2UVlWfuj7pwGIo1Hed8AwIKp6JBs0wkFJS5Ol6U89I4Fm9razw qe15C134hzswqBg+Fie1ezVghdXeNDCxDuUIYbffTdbYY0IxjByWLDLseYWdlR7EKKNw 0fiP7Sphn6vQRroJ0WcI9VD7N3CRKTfaeUpsYF7db0oqe9ZYU8nglHOazXaH2C4E5TLE RgYzcYNjD4ahUq+ZpiOUX9D0rlPkWW+2Zez5hU8t/5cbd+TRbREs8NOu3kykxAN0zi8c c3/Q== MIME-Version: 1.0 X-Received: by 10.182.39.161 with SMTP id q1mr5117696obk.54.1382040110508; Thu, 17 Oct 2013 13:01:50 -0700 (PDT) Received: by 10.76.156.103 with HTTP; Thu, 17 Oct 2013 13:01:50 -0700 (PDT) In-Reply-To: References: <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Thu, 17 Oct 2013 16:01:50 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=001a11c2de60da307d04e8f549e8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c2de60da307d04e8f549e8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I think there's a race-condition, here: > - let's say we're at time < timeout. > - we run sit-for, which does not run the timer since we're still - time advances to > timeout. > - we check (should (time-less-p (current-time) timeout)) > - we complain unjustly. This statement isn't right: > - we run sit-for, which does not run the timer since we're still + + Don't run timers in input-pending-p. Its new check-timers param + provides the prior behavior. (Bug#15045). + * src/keyboard.c (Finput_pending_p): Accept optional check-timers + param. + * lisp/subr.el (sit-for): Call (input-pending-p t) so as to behave + as before. + * test/automated/timer-tests.el: New file. Tests that (sit-for 0) + allows another timer to run. + 2013-10-13 Glenn Morris * configure.ac [alpha]: Explicit error in non-ELF case. (Bug#15601) diff --git a/etc/NEWS b/etc/NEWS index ddb9a9f..963c372 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -611,6 +611,9 @@ low-level libraries gfilenotify.c, inotify.c or w32notify.c. * Incompatible Lisp Changes in Emacs 24.4 +** `(input-pending-p)' no longer runs other timers which are ready to +run. The new optional CHECK-TIMERS param allows for the prior behavior. + ** `defvar' and `defcustom' in a let-binding affect the "external" default= . ** The syntax of ?=BB and ?=AB is now punctuation instead of matched paren= s. diff --git a/lisp/subr.el b/lisp/subr.el index 0d03e9a..952b9b6 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -2222,7 +2222,7 @@ floating point support." (noninteractive (sleep-for seconds) t) - ((input-pending-p) + ((input-pending-p t) nil) ((<=3D seconds 0) (or nodisp (redisplay))) diff --git a/src/keyboard.c b/src/keyboard.c index bb8fefa..85a1ce7 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -9947,12 +9947,13 @@ requeued_events_pending_p (void) return (!NILP (Vunread_command_events)); } - -DEFUN ("input-pending-p", Finput_pending_p, Sinput_pending_p, 0, 0, 0, +DEFUN ("input-pending-p", Finput_pending_p, Sinput_pending_p, 0, 1, 0, doc: /* Return t if command input is currently available with no wait. Actually, the value is nil only if we can be sure that no input is available; -if there is a doubt, the value is t. */) - (void) +if there is a doubt, the value is t. + +If CHECK-TIMERS is non-nil, timers that are ready to run will do so. */) + (Lisp_Object check_timers) { if (!NILP (Vunread_command_events) || !NILP (Vunread_post_input_method_events) @@ -9962,8 +9963,9 @@ if there is a doubt, the value is t. */) /* Process non-user-visible events (Bug#10195). */ process_special_events (); - return (get_input_pending (READABLE_EVENTS_DO_TIMERS_NOW - | READABLE_EVENTS_FILTER_EVENTS) + return (get_input_pending ((NILP (check_timers) + ? 0 : READABLE_EVENTS_DO_TIMERS_NOW) + | READABLE_EVENTS_FILTER_EVENTS) ? Qt : Qnil); } diff --git a/test/automated/timer-tests.el b/test/automated/timer-tests.el new file mode 100644 index 0000000..71a9b96 --- /dev/null +++ b/test/automated/timer-tests.el @@ -0,0 +1,38 @@ +;;; timer-tests.el --- tests for timers -*- lexical-binding:t -*- + +;; Copyright (C) 2013 Free Software Foundation, Inc. + +;; This file is part of GNU Emacs. + +;; This program is free software: you can redistribute it and/or +;; modify it under the terms of the GNU General Public License as +;; published by the Free Software Foundation, either version 3 of the +;; License, or (at your option) any later version. +;; +;; This program is distributed in the hope that it will be useful, but +;; WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +;; General Public License for more details. +;; +;; You should have received a copy of the GNU General Public License +;; along with this program. If not, see `http://www.gnu.org/licenses/'. + +;;; Commentary: + +;;; Code: + +(ert-deftest timer-tests-sit-for () + (let ((timer-ran nil) + ;; Want sit-for behavior when interactive + (noninteractive nil)) + (run-at-time '(0 0 0 0) + nil + (lambda () (setq timer-ran t))) + ;; The test assumes run-at-time didn't take the liberty of firing + ;; the timer, so assert the test's assumption + (should (not timer-ran)) + (sit-for 0 t) + (should timer-ran))) + +;;; timer-tests.el ends here + --001a11c2de60da307d04e8f549e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I think there's a race-condition, here:
> -= let's say we're at time < timeout.
> - we run sit-for, wh= ich does not run the timer since we're still <timeout.
> - tim= e advances to > timeout.
> - we check (should (time-less-p (current-time) timeout))
> - we = complain unjustly.

This statement isn't right:

> - we = run sit-for, which does not run the timer since we're still <timeout= .

If sit-for doesn't run the timer at any time in T+1s to T+10s, then=
it's supposed to fail.

However, reconsidering the test, I do= n't think the timing is
necessary, so I've simplified it.

diff --git a/ChangeLog b/ChangeLog
index a755b5c..553abe2 100644
= --- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2013-10-17=A0 Ba= rry O'Reilly=A0 <gundaetiap= o@gmail.com>
+
+=A0=A0=A0 Don't run timers in input-pending-p.=A0 Its new check-t= imers param
+=A0=A0=A0 provides the prior behavior. (Bug#15045).
+=A0= =A0=A0 * src/keyboard.c (Finput_pending_p): Accept optional check-timers+=A0=A0=A0 param.
+=A0=A0=A0 * lisp/subr.el (sit-for): Call (input-pending-p t) so as to beha= ve
+=A0=A0=A0 as before.
+=A0=A0=A0 * test/automated/timer-tests.el: = New file.=A0 Tests that (sit-for 0)
+=A0=A0=A0 allows another timer to r= un.
+
=A02013-10-13=A0 Glenn Morris=A0 <rgm@gnu.org>
=A0
=A0=A0=A0=A0 * configure.ac [alp= ha]: Explicit error in non-ELF case.=A0 (Bug#15601)
diff --git a/etc/NEW= S b/etc/NEWS
index ddb9a9f..963c372 100644
--- a/etc/NEWS
+++ b/et= c/NEWS
@@ -611,6 +611,9 @@ low-level libraries gfilenotify.c, inotify.c or w32noti= fy.c.
=A0=0C
=A0* Incompatible Lisp Changes in Emacs 24.4
=A0
+= ** `(input-pending-p)' no longer runs other timers which are ready to+run.=A0 The new optional CHECK-TIMERS param allows for the prior behavio= r.
+
=A0** `defvar' and `defcustom' in a let-binding affect the &qu= ot;external" default.
=A0
=A0** The syntax of ?=BB and ?=AB is n= ow punctuation instead of matched parens.
diff --git a/lisp/subr.el b/li= sp/subr.el
index 0d03e9a..952b9b6 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el@@ -2222,7 +2222,7 @@ floating point support."
=A0=A0=A0 (noninte= ractive
=A0=A0=A0=A0 (sleep-for seconds)
=A0=A0=A0=A0 t)
-=A0=A0 (= (input-pending-p)
+=A0=A0 ((input-pending-p t)
=A0=A0=A0=A0 nil)
=A0=A0=A0 ((<=3D seconds 0)
=A0=A0=A0=A0 (or nod= isp (redisplay)))
diff --git a/src/keyboard.c b/src/keyboard.c
index = bb8fefa..85a1ce7 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
= @@ -9947,12 +9947,13 @@ requeued_events_pending_p (void)
=A0=A0 return (!NILP (Vunread_command_events));
=A0}
=A0
-
-DEF= UN ("input-pending-p", Finput_pending_p, Sinput_pending_p, 0, 0, = 0,
+DEFUN ("input-pending-p", Finput_pending_p, Sinput_pending= _p, 0, 1, 0,
=A0=A0=A0=A0=A0=A0=A0 doc: /* Return t if command input is currently availa= ble with no wait.
=A0Actually, the value is nil only if we can be sure t= hat no input is available;
-if there is a doubt, the value is t.=A0 */)<= br>-=A0 (void)
+if there is a doubt, the value is t.
+
+If CHECK-TIMERS is non-nil, = timers that are ready to run will do so.=A0 */)
+=A0 (Lisp_Object check_= timers)
=A0{
=A0=A0 if (!NILP (Vunread_command_events)
=A0=A0=A0= =A0=A0=A0 || !NILP (Vunread_post_input_method_events)
@@ -9962,8 +9963,9 @@ if there is a doubt, the value is t.=A0 */)
=A0=A0= /* Process non-user-visible events (Bug#10195).=A0 */
=A0=A0 process_sp= ecial_events ();
=A0
-=A0 return (get_input_pending (READABLE_EVENTS_= DO_TIMERS_NOW
-=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0 | READABLE_EVENTS_FILTER_EVENTS= )
+=A0 return (get_input_pending ((NILP (check_timers)
+=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= ? 0 : READABLE_EVENTS_DO_TIMERS_NOW)
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | READABLE_EVENTS_FILTE= R_EVENTS)
=A0=A0=A0=A0 =A0 ? Qt : Qnil);
=A0}
=A0
diff --git a/test/automate= d/timer-tests.el b/test/automated/timer-tests.el
new file mode 100644index 0000000..71a9b96
--- /dev/null
+++ b/test/automated/timer-test= s.el
@@ -0,0 +1,38 @@
+;;; timer-tests.el --- tests for timers -*- lexical-binding:t -*-
+
= +;; Copyright (C) 2013 Free Software Foundation, Inc.
+
+;; This file= is part of GNU Emacs.
+
+;; This program is free software: you can r= edistribute it and/or
+;; modify it under the terms of the GNU General Public License as
+;; p= ublished by the Free Software Foundation, either version 3 of the
+;; Li= cense, or (at your option) any later version.
+;;
+;; This program is= distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCH= ANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.=A0 See the GNU
+;; Gener= al Public License for more details.
+;;
+;; You should have received = a copy of the GNU General Public License
+;; along with this program.=A0 If not, see `http://www.gnu.org/licenses/'.
+
+;;; Commentary:<= br>+
+;;; Code:
+
+(ert-deftest timer-tests-sit-for ()
+=A0 (le= t ((timer-ran nil)
+=A0=A0=A0=A0=A0=A0=A0 ;; Want sit-for behavior when interactive
+=A0=A0= =A0=A0=A0=A0=A0 (noninteractive nil))
+=A0=A0=A0 (run-at-time '(0 0 = 0 0)
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 nil
+=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (lambda () (setq timer-ran t)))
= +=A0=A0=A0 ;; The test assumes run-at-time didn't take the liberty of f= iring
+=A0=A0=A0 ;; the timer, so assert the test's assumption
+=A0=A0=A0 = (should (not timer-ran))
+=A0=A0=A0 (sit-for 0 t)
+=A0=A0=A0 (should = timer-ran)))
+
+;;; timer-tests.el ends here
+

--001a11c2de60da307d04e8f549e8-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Oct 2013 00:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138205605023398 (code B ref 15045); Fri, 18 Oct 2013 00:28:01 +0000 Received: (at 15045) by debbugs.gnu.org; 18 Oct 2013 00:27:30 +0000 Received: from localhost ([127.0.0.1]:56159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWxuc-00065J-2h for submit@debbugs.gnu.org; Thu, 17 Oct 2013 20:27:30 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:4725) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWxuZ-000656-Uw for 15045@debbugs.gnu.org; Thu, 17 Oct 2013 20:27:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCqev/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFFMCqev/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="35771116" Received: from 76-10-167-175.dsl.teksavvy.com (HELO pastel.home) ([76.10.167.175]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 17 Oct 2013 20:27:21 -0400 Received: by pastel.home (Postfix, from userid 20848) id 56EF46311B; Thu, 17 Oct 2013 20:27:21 -0400 (EDT) From: Stefan Monnier Message-ID: References: <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Thu, 17 Oct 2013 20:27:21 -0400 In-Reply-To: (Barry OReilly's message of "Thu, 17 Oct 2013 16:01:50 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > However, reconsidering the test, I don't think the timing is > necessary, so I've simplified it. Looks good, please install, Stefan From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Oct 2013 14:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138210499721763 (code B ref 15045); Fri, 18 Oct 2013 14:04:02 +0000 Received: (at 15045) by debbugs.gnu.org; 18 Oct 2013 14:03:17 +0000 Received: from localhost ([127.0.0.1]:57030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VXAe4-0005ex-LK for submit@debbugs.gnu.org; Fri, 18 Oct 2013 10:03:16 -0400 Received: from mail-oa0-f47.google.com ([209.85.219.47]:33251) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VXAe2-0005ei-Bv for 15045@debbugs.gnu.org; Fri, 18 Oct 2013 10:03:15 -0400 Received: by mail-oa0-f47.google.com with SMTP id i1so3408592oag.34 for <15045@debbugs.gnu.org>; Fri, 18 Oct 2013 07:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SeY3hjZSpXmguyq6g+CpxzogKUhrGPCRqI9cSH2Xsfs=; b=Y+W86pjNG+18AmjjEHOL2JAhLexivSOzO+Fgbr/BDg++aDLjWW+qi273ozyLXB6YDp NDUJuB3MRVQtwQLDdvxf9vkiIZUXPmmYLcXlOIGgfcrLLloxZOh1oC4KUgvWKhJHOxTH ZV8NsyGCf3yw7v20X5gaaCFHuA0s+AFN3lz9wp2eTzXqKETYrVabbr6nsaw5qP+2rofZ R7Hp7eqrR+xhqih7GkZJryJYjJLUtq1+B/3zr85GclKZ4djKBQ+pFhn7/obk/jUbW1hD dXtUh8WqLoYaIpsO30P+6n7t2+JCvQyFOMbOFrcMcrV1GoryCRFlxWAYdqaaD9ReX+JE PsfA== MIME-Version: 1.0 X-Received: by 10.182.131.196 with SMTP id oo4mr3091837obb.50.1382104988391; Fri, 18 Oct 2013 07:03:08 -0700 (PDT) Received: by 10.76.156.103 with HTTP; Fri, 18 Oct 2013 07:03:08 -0700 (PDT) In-Reply-To: References: <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Fri, 18 Oct 2013 10:03:08 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=001a11c1f6d6e0215d04e904646d X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c1f6d6e0215d04e904646d Content-Type: text/plain; charset=ISO-8859-1 Rev 114704. Leaving this open because of Semantic use of accept-process-output during an excursion. --001a11c1f6d6e0215d04e904646d Content-Type: text/html; charset=ISO-8859-1
Rev 114704. Leaving this open because of Semantic use of
accept-process-output during an excursion.

--001a11c1f6d6e0215d04e904646d-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Oct 2013 19:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138272855832712 (code B ref 15045); Fri, 25 Oct 2013 19:16:01 +0000 Received: (at 15045) by debbugs.gnu.org; 25 Oct 2013 19:15:58 +0000 Received: from localhost ([127.0.0.1]:43953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZmrU-0008VX-OK for submit@debbugs.gnu.org; Fri, 25 Oct 2013 15:15:57 -0400 Received: from mail-ob0-f180.google.com ([209.85.214.180]:47713) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZmrS-0008VI-E1 for 15045@debbugs.gnu.org; Fri, 25 Oct 2013 15:15:55 -0400 Received: by mail-ob0-f180.google.com with SMTP id wo20so1359315obc.39 for <15045@debbugs.gnu.org>; Fri, 25 Oct 2013 12:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ELcHijWg6H0NpBW1uOI1hT+LQ/dymDIEQptM4M33Lko=; b=phG0pr1A/cHJPA4pifzTbzgCeEdQXe2ogJR+dWnGqYB2MF0Mzyy05i4BU1Nomq9btY 6Rb23qwzcLtXXgwi7SWKEzY8YvuYba6JPkf/kO4OwqXRrPLkpY9O9JY8Oj3m8dyB0VYc uBDdutA9UbLCYqC9Cfj81Rtv28idoW0r6mV3i/DZs9l0WzjwM+C+OuKmgGw40hfErh5V 8xA2J/5CCRD3ebk0Xk/SZq7+LFk+plBnb7QVeLZF67ZcdDfypiDnA3snNs6fE5GXMjaA +iMOK4YJu1Mp09GazvEeK6xz1m5hnXrGpNGyG5MBYkCY8XCRD3YhFEEv0im4JvRzAGJ5 O9ZQ== MIME-Version: 1.0 X-Received: by 10.60.93.67 with SMTP id cs3mr4311829oeb.12.1382728548760; Fri, 25 Oct 2013 12:15:48 -0700 (PDT) Received: by 10.76.156.103 with HTTP; Fri, 25 Oct 2013 12:15:48 -0700 (PDT) In-Reply-To: References: <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Fri, 25 Oct 2013 15:15:48 -0400 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=047d7b33d176f847dd04e995937f X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b33d176f847dd04e995937f Content-Type: text/plain; charset=ISO-8859-1 In terms of solving the issue of how Semantic calls accept-process-output, here are two proposals: 1: Per David Engster: > If you look in the `define-lex' macro, you see that it calls > `semantic-throw-on-input' after each identified token. The problem is > that it does not restore the cursor position before that, so I guess the > fix is simply to change this call to > > (save-excursion > (goto-char starting-position) > (semantic-throw-on-input 'lex)) Here's a patch to implement the basic idea. My debugging indicates accept-process-output can be called when lexing other buffers, so I saved off the marker rather than just position. That said, I have never personally witnessed point unexpectedly redisplayed in another buffer -- only within the same buffer. That could be a consequence of how it interacts with the jit-lock-deferred-fontify idle timer. (I have confirmed with my debug statements that Semantic is the outer timer and jit-lock-deferred-fontify is the inner timer which redisplays.) Please let me know if this fix is suitable. diff --git a/lisp/cedet/semantic/fw.el b/lisp/cedet/semantic/fw.el index 825cdc9..869d183 100644 --- a/lisp/cedet/semantic/fw.el +++ b/lisp/cedet/semantic/fw.el @@ -369,6 +369,8 @@ later installation should be done in MODE hook." ;; (defvar semantic-current-input-throw-symbol nil "The current throw symbol for `semantic-exit-on-input'.") +(defvar semantic--on-input-start-marker nil + "The marker when starting a semantic-exit-on-input form.") (defmacro semantic-exit-on-input (symbol &rest forms) "Using SYMBOL as an argument to `throw', execute FORMS. @@ -376,7 +378,8 @@ If FORMS includes a call to `semantic-throw-on-input', then if a user presses any key during execution, this form macro will exit with the value passed to `semantic-throw-on-input'. If FORMS completes, then the return value is the same as `progn'." - `(let ((semantic-current-input-throw-symbol ,symbol)) + `(let ((semantic-current-input-throw-symbol ,symbol) + (semantic--on-input-start-marker (point-marker))) (catch ,symbol ,@forms))) (put 'semantic-exit-on-input 'lisp-indent-function 1) @@ -387,7 +390,16 @@ FROM is an indication of where this function is called from as a value to pass to `throw'. It is recommended to use the name of the function calling this one." `(when (and semantic-current-input-throw-symbol - (or (input-pending-p) (accept-process-output))) + (or (input-pending-p) + (save-excursion + ;; Timers might run during accept-process-output. + ;; If they redisplay, point must be where the user + ;; expects. (Bug#15045) + (set-buffer (marker-buffer + semantic--on-input-start-marker)) + (goto-char (marker-position + semantic--on-input-start-marker)) + (accept-process-output)))) (throw semantic-current-input-throw-symbol ,from))) ^L 2: Extend accept-process-output to allow suppressing timer_check. Actually, there's an input arg already for that, but only applicable if the PROCESS arg is non nil. --047d7b33d176f847dd04e995937f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In terms of solving the issue of how Semantic calls
acc= ept-process-output, here are two proposals:

1: Per David Engster:
> If you look in the `define-lex' macro, you see that it calls<= br> > `semantic-throw-on-input' after each identified token. The problem= is
> that it does not restore the cursor position before that, so I = guess the
> fix is simply to change this call to
>
> =A0= =A0=A0 =A0=A0 (save-excursion
> =A0=A0=A0 =A0=A0=A0=A0 (goto-char starting-position)
> =A0=A0=A0= =A0=A0=A0=A0 (semantic-throw-on-input 'lex))

Here's a patch= to implement the basic idea. My debugging indicates
accept-process-outp= ut can be called when lexing other buffers, so I
saved off the marker rather than just position.

That said, I have ne= ver personally witnessed point unexpectedly
redisplayed in another buffe= r -- only within the same buffer. That
could be a consequence of how it = interacts with the
jit-lock-deferred-fontify idle timer. (I have confirmed with my debug
st= atements that Semantic is the outer timer and
jit-lock-deferred-fontify = is the inner timer which redisplays.)

Please let me know if this fix= is suitable.

diff --git a/lisp/cedet/semantic/fw.el b/lisp/cedet/semantic/fw.el
i= ndex 825cdc9..869d183 100644
--- a/lisp/cedet/semantic/fw.el
+++ b/li= sp/cedet/semantic/fw.el
@@ -369,6 +369,8 @@ later installation should be= done in MODE hook."
=A0;;
=A0(defvar semantic-current-input-throw-symbol nil
=A0=A0 "= ;The current throw symbol for `semantic-exit-on-input'.")
+(def= var semantic--on-input-start-marker nil
+=A0 "The marker when start= ing a semantic-exit-on-input form.")
=A0
=A0(defmacro semantic-exit-on-input (symbol &rest forms)
=A0= =A0 "Using SYMBOL as an argument to `throw', execute FORMS.
@@ = -376,7 +378,8 @@ If FORMS includes a call to `semantic-throw-on-input',= then
=A0if a user presses any key during execution, this form macro
=A0will e= xit with the value passed to `semantic-throw-on-input'.
=A0If FORMS = completes, then the return value is the same as `progn'."
-=A0 = `(let ((semantic-current-input-throw-symbol ,symbol))
+=A0 `(let ((semantic-current-input-throw-symbol ,symbol)
+=A0=A0=A0=A0= =A0=A0=A0=A0 (semantic--on-input-start-marker (point-marker)))
=A0=A0=A0= =A0=A0 (catch ,symbol
=A0=A0=A0=A0=A0=A0=A0 ,@forms)))
=A0(put 's= emantic-exit-on-input 'lisp-indent-function 1)
@@ -387,7 +390,16 @@ FROM is an indication of where this function is called= from as a value
=A0to pass to `throw'.=A0 It is recommended to use = the name of the function
=A0calling this one."
=A0=A0 `(when (an= d semantic-current-input-throw-symbol
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (or (input-pending-p) (accept-proc= ess-output)))
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (or (input-pendin= g-p)
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (save-excursio= n
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ;; Timers m= ight run during accept-process-output.
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 ;; If they redisplay, point must be where the u= ser
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ;; expects. (Bug= #15045)
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (set-= buffer (marker-buffer
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 semantic--on-input-start-m= arker))
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (goto= -char (marker-position
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 semantic--on-input-start-marker))
+=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (accept-process-output))))
= =A0=A0=A0=A0=A0 (throw semantic-current-input-throw-symbol ,from)))
=A0<= br>=A0^L

2: Extend accept-process-output to allow suppressing timer_= check.
Actually, there's an input arg already for that, but only applicableif the PROCESS arg is non nil.

--047d7b33d176f847dd04e995937f-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Nov 2013 18:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Engster , Eric Ludlam Cc: 15045@debbugs.gnu.org, Stefan Monnier Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138445329620088 (code B ref 15045); Thu, 14 Nov 2013 18:22:02 +0000 Received: (at 15045) by debbugs.gnu.org; 14 Nov 2013 18:21:36 +0000 Received: from localhost ([127.0.0.1]:52495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vh1Xs-0005Dw-9a for submit@debbugs.gnu.org; Thu, 14 Nov 2013 13:21:36 -0500 Received: from mail-oa0-f53.google.com ([209.85.219.53]:35768) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vh1Xq-0005Df-HT for 15045@debbugs.gnu.org; Thu, 14 Nov 2013 13:21:34 -0500 Received: by mail-oa0-f53.google.com with SMTP id k1so2639512oag.40 for <15045@debbugs.gnu.org>; Thu, 14 Nov 2013 10:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=05sg9xZbyIJfYbWMTSQzQ7bJr9qhzFVn4+qYqWu4vZI=; b=yVPMoz0tPjoNB7jiBfX4kQ+X71eFJd2sE2a0urGlTWpWEP9Cn7/scmS/XR9HfcdHdi iqkHHd18xSharVjPZFZKgknqvtQwzy8rhYvo/sQW1/xlCbgyKLUeHKOSMT4S+1lTs7tv 5ql0uR8o3WMkiZwgVVDXXFds6djAgSJ1neQubF3bmZtuoC+Riw+BmQT+la38QXLgzqqp sq1/papE7YSQpDF7GUqQChX3a89D6YTQYeYRayNunn1vw4btVp20P+69F+qbzoxWMQm2 M2R4hzwr6qYig9005UaA6bzMjrv7OQKW8hxWxOKAkW43i2OTl3bBvgDCyVK2AfmG3cdw EZvw== MIME-Version: 1.0 X-Received: by 10.60.142.8 with SMTP id rs8mr2965281oeb.34.1384453288780; Thu, 14 Nov 2013 10:21:28 -0800 (PST) Received: by 10.76.156.103 with HTTP; Thu, 14 Nov 2013 10:21:28 -0800 (PST) In-Reply-To: References: <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Thu, 14 Nov 2013 13:21:28 -0500 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=047d7b33cd747cb47104eb2726d6 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b33cd747cb47104eb2726d6 Content-Type: text/plain; charset=ISO-8859-1 Eric, David, I would very much like to use Semantic without unwanted scrolling, so I'd appreciate your feedback. How is the patch I submitted? What else do I need to do or investigate? Patch: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15045#212 --047d7b33cd747cb47104eb2726d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Eric, David,

I would very much like to use Semantic= without unwanted scrolling, so I'd appreciate your feedback. How is th= e patch I submitted? What else do I need to do or investigate?

Patch= : http= ://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15045#212

--047d7b33cd747cb47104eb2726d6-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2013 04:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13845753042210 (code B ref 15045); Sat, 16 Nov 2013 04:16:02 +0000 Received: (at 15045) by debbugs.gnu.org; 16 Nov 2013 04:15:04 +0000 Received: from localhost ([127.0.0.1]:56483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhXHj-0000ZZ-8K for submit@debbugs.gnu.org; Fri, 15 Nov 2013 23:15:03 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:14429) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhXHf-0000Yn-G0 for 15045@debbugs.gnu.org; Fri, 15 Nov 2013 23:14:59 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCpLG/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kE4gLBgywVpBLjQ+DewOESoQXiV+EaY1RgV6DFYFR X-IPAS-Result: Av4EABK/CFFMCpLG/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kE4gLBgywVpBLjQ+DewOESoQXiV+EaY1RgV6DFYFR X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="38044516" Received: from 76-10-146-198.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([76.10.146.198]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 15 Nov 2013 23:14:53 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 87BF6AE21D; Fri, 15 Nov 2013 23:14:53 -0500 (EST) From: Stefan Monnier Message-ID: References: <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Fri, 15 Nov 2013 23:14:53 -0500 In-Reply-To: (Barry OReilly's message of "Thu, 14 Nov 2013 13:21:28 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > I would very much like to use Semantic without unwanted scrolling, so I'd > appreciate your feedback. How is the patch I submitted? What else do I need > to do or investigate? > Patch: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15045#212 The patch is a bit "ugly" (in the sense that it's a bit too ad-hoc), but it's probably what it takes (tho maybe semantic-exit-on-input could be replaced by while-no-input, which does not suffer from this problem, but it's not a simple replacement). But the main problem I see is that you already have a few "trivial" patches installed, so this is summing up to something non-trivial which requires copyright paperwork. If that's OK with you, then, please fill the form below and send it to the FSF as instructed, so they can send you the relevant paperwork. Stefan Please email the following information to assign@gnu.org, and we will send you the assignment form for your past and future changes. Please use your full legal name (in ASCII characters) as the subject line of the message. ---------------------------------------------------------------------- REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES [What is the name of the program or package you're contributing to?] Emacs [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] [For the copyright registration, what country are you a citizen of?] [What year were you born?] [Please write your email address here.] [Please write your postal address here.] [Which files have you changed so far, and which new files have you written so far?] From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2013 04:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13845777105945 (code B ref 15045); Sat, 16 Nov 2013 04:56:02 +0000 Received: (at 15045) by debbugs.gnu.org; 16 Nov 2013 04:55:10 +0000 Received: from localhost ([127.0.0.1]:56492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhXuX-0001Xo-8v for submit@debbugs.gnu.org; Fri, 15 Nov 2013 23:55:09 -0500 Received: from mail-oa0-f52.google.com ([209.85.219.52]:45513) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhXuT-0001XH-W0 for 15045@debbugs.gnu.org; Fri, 15 Nov 2013 23:55:06 -0500 Received: by mail-oa0-f52.google.com with SMTP id o6so4887505oag.39 for <15045@debbugs.gnu.org>; Fri, 15 Nov 2013 20:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G4oh/iVwuCS9PN6BaZNctU8/l/xZ1fMwUmBTYyydu38=; b=fjTiDdjAPS0RTaHy9uBorEFARVvvOsauf+iwA/fE33QOICtZ9D3oEehgMKOvzhQagK LBuTDCmFbg08Aa31fPpHQTvfxUQKEuuSQwx3eA5vpjvzKUSAoWtK1bkIT9CMgcF3XGlX H5wHVXt2I24PqOOtcb+m/jMNjx30TAqzAhk/wCSWTFf8krLOPjVVSokkZOrMU89MBpCq DX5FcLr7LDCwS2RPg3f02qOgtQoHc7rpVE8iow0WUT4M/r0nT+ysMDzIBtzlVhqIOPLg 1dxZS426ZUeeab6QbDpz/oubayNx6bxKmonfiQOg68wtPq8faZV14lwo3IqyGUSpz/8E uwYA== MIME-Version: 1.0 X-Received: by 10.182.118.199 with SMTP id ko7mr41980obb.91.1384577700037; Fri, 15 Nov 2013 20:55:00 -0800 (PST) Received: by 10.76.156.103 with HTTP; Fri, 15 Nov 2013 20:54:59 -0800 (PST) In-Reply-To: References: <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Fri, 15 Nov 2013 23:54:59 -0500 Message-ID: From: Barry OReilly Content-Type: multipart/alternative; boundary=089e013a2ac8f9884304eb441d0a X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e013a2ac8f9884304eb441d0a Content-Type: text/plain; charset=ISO-8859-1 > The patch is a bit "ugly" (in the sense that it's a bit too ad-hoc) Yes, I feel the same way. What seems more appropriate is if there was something like process-output-p which would indicate to Semantic that process output is ready to accept, and thus that Semantic needs to unwind out of its save-excursion form before allowing accept-process-output. Does the while-no-input you mentioned exit in that circumstance? > But the main problem I see is that you already have a few "trivial" > patches installed, so this is summing up to something non-trivial > which requires copyright paperwork. That's already done and you granted me commit privs to Emacs and ELPA. Let me know if you want me to forward the docs again confirming the processing is complete. --089e013a2ac8f9884304eb441d0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> The patch is a bit "ugly" (in the sense tha= t it's a bit too ad-hoc)

Yes, I feel the same way. What seems mo= re appropriate is if there was
something like process-output-p which wou= ld indicate to Semantic that
process output is ready to accept, and thus that Semantic needs to
unwin= d out of its save-excursion form before allowing
accept-process-output. = Does the while-no-input you mentioned exit in
that circumstance?

> But the main problem I see is that you already have a few "tr= ivial"
> patches installed, so this is summing up to something n= on-trivial
> which requires copyright paperwork.

That's al= ready done and you granted me commit privs to Emacs and
ELPA. Let me know if you want me to forward the docs again confirming
th= e processing is complete.

--089e013a2ac8f9884304eb441d0a-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2013 17:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.138462347220548 (code B ref 15045); Sat, 16 Nov 2013 17:38:02 +0000 Received: (at 15045) by debbugs.gnu.org; 16 Nov 2013 17:37:52 +0000 Received: from localhost ([127.0.0.1]:57384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhjod-0005LM-V9 for submit@debbugs.gnu.org; Sat, 16 Nov 2013 12:37:52 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:13678) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhjoY-0005L2-Gq for 15045@debbugs.gnu.org; Sat, 16 Nov 2013 12:37:47 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+J5Y/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av4EABK/CFHO+J5Y/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="38068444" Received: from 206-248-158-88.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([206.248.158.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 16 Nov 2013 12:37:40 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 4F273AE1D0; Sat, 16 Nov 2013 12:37:40 -0500 (EST) From: Stefan Monnier Message-ID: References: <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Sat, 16 Nov 2013 12:37:40 -0500 In-Reply-To: (Barry OReilly's message of "Fri, 15 Nov 2013 23:54:59 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > accept-process-output. Does the while-no-input you mentioned exit in > that circumstance? Inside a while-no-input, if the user hits a key (or clicks), then a `throw' is executed that exits the while-no-input. >> But the main problem I see is that you already have a few "trivial" >> patches installed, so this is summing up to something non-trivial >> which requires copyright paperwork. > That's already done and you granted me commit privs to Emacs and > ELPA. Let me know if you want me to forward the docs again confirming > the processing is complete. Oh, sorry, I didn't look up the copyright.list properly. Then please go ahead and install your change. Stefan From unknown Mon Jun 23 11:27:15 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Barry OReilly Subject: bug#15045: closed (Re: bug#15045: Point jumps inappropriately around time of Semantic lexing) Message-ID: References: X-Gnu-PR-Message: they-closed 15045 X-Gnu-PR-Package: emacs Reply-To: 15045@debbugs.gnu.org Date: Sat, 16 Nov 2013 20:34:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1384634042-9390-1" This is a multi-part message in MIME format... ------------=_1384634042-9390-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #15045: Point jumps inappropriately around time of Semantic lexing which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 15045@debbugs.gnu.org. --=20 15045: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15045 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1384634042-9390-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 15045-done) by debbugs.gnu.org; 16 Nov 2013 20:33:15 +0000 Received: from localhost ([127.0.0.1]:57506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhmYM-0002QK-L1 for submit@debbugs.gnu.org; Sat, 16 Nov 2013 15:33:14 -0500 Received: from mail-oa0-f45.google.com ([209.85.219.45]:64217) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhmYK-0002Q5-HH for 15045-done@debbugs.gnu.org; Sat, 16 Nov 2013 15:33:13 -0500 Received: by mail-oa0-f45.google.com with SMTP id m1so5539995oag.32 for <15045-done@debbugs.gnu.org>; Sat, 16 Nov 2013 12:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hsajYV/5yKzOWCTkLknS2EE40tnLJgWf44McNrhM6fk=; b=mHCZq5Ljn5JzHQYT6upDhdNQuDUW9dyx5Z3AfY6CMqH6M3iavVmUnMVjRmRYH0H3Mw igoivcUmAa+tf8MtGIPV/h9J/DoPnfAIUmtvTpPCV92tt8rvuF4bYKQHicXP9I6iu5K+ 9pCTsndHf8BbpwxtmJq0WrLyQrCi8GFXSfQ4ocsvIkxOsLb9TKTl7dguXf6CxhFkyZN0 tAccGy8iqkdByBKfESFtoX9h1ChmYfCALLJxEgBuQfhhBdrhbJmdKFglvpfjPD7Kg7qn BuHO3woj6X2zOSsk8PzhTWGf1/JK/VDnG9SqSrgQNefxrS7Tzw8+nvFHGZLpZ3cw3X0y yBkw== MIME-Version: 1.0 X-Received: by 10.60.44.239 with SMTP id h15mr12919353oem.22.1384633986435; Sat, 16 Nov 2013 12:33:06 -0800 (PST) Received: by 10.76.156.103 with HTTP; Sat, 16 Nov 2013 12:33:06 -0800 (PST) In-Reply-To: References: <83haexrgjn.fsf@gnu.org> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Sat, 16 Nov 2013 15:33:06 -0500 Message-ID: Subject: Re: bug#15045: Point jumps inappropriately around time of Semantic lexing From: Barry OReilly To: Stefan Monnier Content-Type: multipart/alternative; boundary=001a11331e1ae7cfe104eb513821 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 15045-done Cc: 15045-done@debbugs.gnu.org, David Engster , Eric Ludlam X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11331e1ae7cfe104eb513821 Content-Type: text/plain; charset=ISO-8859-1 > Inside a while-no-input, if the user hits a key (or clicks), then a > `throw' is executed that exits the while-no-input. I thought input-pending-p covers that base. If we use while-no-input, don't we still need to use accept-process-output, thus not solving the problem? > Then please go ahead and install your change. Thanks, rev 115123. Closing. --001a11331e1ae7cfe104eb513821 Content-Type: text/html; charset=ISO-8859-1
> Inside a while-no-input, if the user hits a key (or clicks), then a
> `throw' is executed that exits the while-no-input.

I thought input-pending-p covers that base. If we use while-no-input,
don't we still need to use accept-process-output, thus not solving the
problem?

> Then please go ahead and install your change.

Thanks, rev 115123. Closing.

--001a11331e1ae7cfe104eb513821-- ------------=_1384634042-9390-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 7 Aug 2013 17:59:22 +0000 Received: from localhost ([127.0.0.1]:45995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7813-0004eF-Gc for submit@debbugs.gnu.org; Wed, 07 Aug 2013 13:59:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34749) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7811-0004dy-0O for submit@debbugs.gnu.org; Wed, 07 Aug 2013 13:59:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V780t-0001Wz-Km for submit@debbugs.gnu.org; Wed, 07 Aug 2013 13:59:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-99.2 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID,USER_IN_WHITELIST autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V780t-0001Wi-Ha for submit@debbugs.gnu.org; Wed, 07 Aug 2013 13:59:11 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V780q-0003TD-P9 for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2013 13:59:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V780m-0001Lp-Ud for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2013 13:59:08 -0400 Received: from mail-ob0-x244.google.com ([2607:f8b0:4003:c01::244]:47598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V780m-0001Lb-NH for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2013 13:59:04 -0400 Received: by mail-ob0-f196.google.com with SMTP id wc20so790642obb.7 for ; Wed, 07 Aug 2013 10:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bvt43c+9kCsdS/Qca7hPUaCJ3RxVqKuHHcQ+CPdS4T0=; b=ZINr0HfTF24/ZIqAGC1UwbpFwF3ovX2BviI9OX01ld0Uxug1XiGXmFDnILEg9hrcfp no3vopAQEHKtnwnfWMzI8RKgnwuwag08+FadCwJLicby4VGlJUe7LW2+ALntjQ+lLTXv gplY76MSkP/DukdcWs//SgTz3sFfqkuoXLzAOMpL+DPfqABDUytNpxDzUm2kfyXcdsQy Ac/DFNCJiQ8bfaHXsNCaaJEJ1P7krU30Rb075V1GJyWEv4SXlIhkhqjhc6fWf2W7yBJl 2P3ypHTZqFoiyVS4LOFKnBNPIiNPuKaNxs9enYKsQv0jpWwe5EMFYq+Wu2TBBnGJzzUO kjvw== MIME-Version: 1.0 X-Received: by 10.182.76.38 with SMTP id h6mr3443896obw.74.1375898343107; Wed, 07 Aug 2013 10:59:03 -0700 (PDT) Received: by 10.76.89.194 with HTTP; Wed, 7 Aug 2013 10:59:03 -0700 (PDT) Date: Wed, 7 Aug 2013 13:59:03 -0400 Message-ID: Subject: Point jumps inappropriately around time of Semantic lexing From: Barry OReilly To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) See this thread for the original description: http://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00328.html The short of it is that I occasionally witness point jump to elsewhere in the buffer while I'm editing and then back again. The change of point is visually apparent in the display. This has consequences such as causing undesired scrolling while editing. To debug it, I used a change like this: diff --git a/src/editfns.c b/src/editfns.c index 50bde90..039e13f 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -234,6 +234,8 @@ The return value is POSITION. */) (register Lisp_Object position) { ptrdiff_t pos; + bool noninteractive_old =3D noninteractive; + noninteractive =3D true; if (MARKERP (position) && current_buffer =3D=3D XMARKER (position)->buffer) @@ -245,7 +247,19 @@ The return value is POSITION. */) SET_PT_BOTH (ZV, ZV_BYTE); else SET_PT_BOTH (pos, marker_byte_position (position)); - + int btI =3D 0; + Lisp_Object theBacktrace; + do + { + theBacktrace =3D Fbacktrace_frame( make_number(btI) ); + ++btI; + Fprin1(theBacktrace, Qnil); + printf("\017\n"); + } while( ! EQ(theBacktrace, Qnil) ); + { struct timespec debug_ts; char debug_dateStr[20]; { clock_gettime(CLOCK_REALTIME, &debug_ts); struct tm mytm; localtime_r(&debug_ts.tv_sec, &mytm); strftime(debug_dateStr, 20, "%Y-%m-%dT%H:%M:%S", &mytm); } + printf( "%s.%09ld|pid:%d|tid:%ld|%s|%d| DEBUG: goto-char marker pos=3D%ld\n", // TODO: debugging + debug_dateStr, debug_ts.tv_nsec, getpid(), pthread_self(), __FILE__, __LINE__, pos ); fflush(stdout); } + noninteractive =3D noninteractive_old; return position; } @@ -253,6 +267,19 @@ The return value is POSITION. */) pos =3D clip_to_bounds (BEGV, XINT (position), ZV); SET_PT (pos); + int btI =3D 0; + Lisp_Object theBacktrace; + do + { + theBacktrace =3D Fbacktrace_frame( make_number(btI) ); + ++btI; + Fprin1(theBacktrace, Qnil); + printf("\017\n"); + } while( ! EQ(theBacktrace, Qnil) ); + { struct timespec debug_ts; char debug_dateStr[20]; { clock_gettime(CLOCK_REALTIME, &debug_ts); struct tm mytm; localtime_r(&debug_ts.tv_sec, &mytm); strftime(debug_dateStr, 20, "%Y-%m-%dT%H:%M:%S", &mytm); } + printf( "%s.%09ld|pid:%d|tid:%ld|%s|%d| DEBUG: goto-char position pos=3D%ld\n", // TODO: debugging + debug_dateStr, debug_ts.tv_nsec, getpid(), pthread_self(), __FILE__, __LINE__, pos ); fflush(stdout); } + noninteractive =3D noninteractive_old; return position; } I got a reproduction with these debug statements. I was editing a Makefile in comments at about buffer position 3396 and observed point temporarily jump to the beginning of the comment block at position 3084. I filtered the output for calls to go to position 3084 around the time I witnessed this: [backtrace A] 2013-08-01T10:37:28.119778000|pid:10485|tid:2342111488|editfns.c|281| DEBUG: goto-char position pos=3D3084 [backtrace B] 2013-08-01T10:37:28.412962000|pid:10485|tid:2342111488|editfns.c|261| DEBUG: goto-char marker pos=3D3084 [backtrace C] 2013-08-01T10:37:29.715413000|pid:10485|tid:2342111488|editfns.c|281| DEBUG: goto-char position pos=3D3084 Strangly, the backtrace A and B are 35 and 45 empty (except my Ctrl-O chars) stack frames respectively. Backtrace C is: (t semantic-make-lexer 3083 3257 nil nil)^O (t semantic-lex 3083 3257 nil)^O (t semantic-parse-region-default 3083 3257 nil nil nil)^O (t semantic-parse-region 3083 3257 nil)^O (t semantic-edits-incremental-parser-1)^O parser error: %S" error-message-string t] 4)))] 3)^O (t semantic-parse-changes-default)^O (t semantic-parse-changes)^O (t semantic-fetch-tags)^O (t byte-code "=C0 *=C1" [semantic-fetch-tags nil] 1)^O (t semantic-idle-scheduler-refresh-tags)^O (t byte-code "=C6^X=C7p=C7=C6=C8=C9=CA \"\"\"^Y=C6^ZESC=C6^\^M;^\^@=CB^M!^^#^N$^^@=CC=CD!<= U+0085>+^@^N^M?^^@^N%?^^@^N#E^@^M;E^@=CE^M!= R^@^N#^^@=CB^M=C6=CF#^^@^N&=D0X^ ^M;=AD^@=CB^M!^^#^N$=EF^@=CC=CD!=BC^@^N^M?= =EF^@^N%?=EF^@^N#=D6^@^M;=D6^@=CE^M!=E3^@^N= #=EF^@=CB^M=C6=CF#=EF^@^N&=D0X=EF^@=D1 ^N&W) ^A^N(=FE^@=D2 ^A=D3=DA=DB ^Ap^KB^S)^N*A^V*^?^@*^K^Q)^N,=C6^^-^^*o^A^N= *@^V-^N+>^A=D6 8^A=D7 >^A=D8^N+=DC\"^N.I^A=DD=DE^N-\"^N(U^A^N- Z^A=D3=DF=E0 e-scheduler-queue service semantic-idle-scheduler-verbose-flag] 8)^O (t semantic-idle-core-handler)^O (t semantic-idle-scheduler-function)^O (t apply semantic-idle-scheduler-function nil)^O (t byte-code "r=C2=C3H\")=C1" [timer apply 5 6] 4)^O (t timer-event-handler [t 0 1 0 t semantic-idle-scheduler-function nil idle 0])^O nil^O I can see the call to goto-char in define-lex (the macro which creates semantic-make-lexer). However, there is a save-excursion in effect at the semantic-idle-core-handler frame, so this goto-char wouldn't seem to be the same goto-char I observe in the display. I'm not sure about the empty backtraces. Is the code I used to print backtraces valid? In my many runs, empty backtraces are very rare. I have since started using Fbacktrace() instead of the more long winded code above. Unfortunately I'm having a reproduction drought in the past week. One additional observation not previously noted is that I see this bug much more often when editing comments or strings. However, I'm fairly sure I've seen it when editing straight code too. In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.4) of 2013-06-18 on psd15 Windowing system distributor `The X.Org Foundation', version 11.0.70101000 System Description: Red Hat Enterprise Linux Client release 5.4 (Tikanga) Configured using: `configure --prefix=3D/redacted/user/boreilly/sw/emacs-install-trunk-20899d085afe6252= 0113b5acbfe3dbba57823dc9 --with-gif=3Dno' Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=3Dnone locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: outline-minor-mode: t global-whitespace-mode: t global-ede-mode: t global-semanticdb-minor-mode: t global-semantic-idle-scheduler-mode: t semantic-mode: t evil-mode: t evil-local-mode: t global-undo-tree-mode: t undo-tree-mode: t show-paren-mode: t delete-selection-mode: t global-auto-revert-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e p o r t - Recent messages: Loading redacted Loading redacted Loading whitespace...done 2013-08-07T13:47:52.565183 Loading tags file: redacted Starting a new list of tags tables 2013-08-07T13:47:52.716876 Finished loading init file. 2013-08-07T13:47:52.723671 Inside my-prog-mode-hook 2013-08-07T13:47:52.732424 Inside my-emacs-lisp-mode-hook for buffer *scrat= ch* For information about GNU Emacs and the GNU system, type C-h C-a. 2013-08-07T13:47:52.748012 ---------------- Finished with my-emacs-startup-hook. ---------------- Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils noutline outline easy-mmode my-config warnings semantic/lex-spp etags package cl-macs whitespace cus-start cus-load my-proj ede/cpp-root ede/speedbar ede/files ede ede/base ede/auto ede/source eieio-speedbar speedbar sb-image dframe eieio-custom wid-edit semantic/db-mode semantic/idle semantic/bovine/gcc semantic/dep semantic/ia semantic/analyze/refs semantic/db-find semantic/db-ref semantic/senator semantic/decorate pulse semantic/analyze semantic/sort semantic/scope semantic/analyze/fcn semantic/db gv eieio-base semantic/ctxt semantic/format ezimage semantic/tag-ls semantic/find semantic/util-modes easymenu semantic/util semantic semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp byte-compile cconv eieio-core mode-local cedet evil evil-integration evil-maps evil-commands evil-types evil-search evil-ex evil-macros evil-repeat evil-states evil-core evil-common windmove rect evil-digraphs evil-vars ring edmacro kmacro undo-tree diff goto-chg rainbow-delimiters my-util advice help-fns electric paren delsel autorevert cl nadvice cl-lib time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) ------------=_1384634042-9390-1-- From unknown Mon Jun 23 11:27:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2013 21:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Barry OReilly Cc: 15045-done@debbugs.gnu.org, David Engster , Eric Ludlam Received: via spool by 15045-done@debbugs.gnu.org id=D15045.138463734214642 (code D ref 15045); Sat, 16 Nov 2013 21:30:02 +0000 Received: (at 15045-done) by debbugs.gnu.org; 16 Nov 2013 21:29:02 +0000 Received: from localhost ([127.0.0.1]:57532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhnQM-0003o6-DL for submit@debbugs.gnu.org; Sat, 16 Nov 2013 16:29:02 -0500 Received: from relais.videotron.ca ([24.201.245.36]:14626) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhnQJ-0003ng-CK for 15045-done@debbugs.gnu.org; Sat, 16 Nov 2013 16:28:59 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ceviche.home ([173.179.11.28]) by VL-VM-MR003.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MWD00CTTL0AV410@VL-VM-MR003.ip.videotron.ca> for 15045-done@debbugs.gnu.org; Sat, 16 Nov 2013 16:28:58 -0500 (EST) Received: by ceviche.home (Postfix, from userid 20848) id 76FF1660A5; Sat, 16 Nov 2013 16:29:09 -0500 (EST) From: Stefan Monnier Message-id: References: <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> Date: Sat, 16 Nov 2013 16:29:09 -0500 In-reply-to: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) >> Inside a while-no-input, if the user hits a key (or clicks), then a >> `throw' is executed that exits the while-no-input. > I thought input-pending-p covers that base. The difference is that input-pending-p does polling (you have to keep calling input-pending-p), whereas while-no-input is interrupt based (it will stop whatever you're doing when the key comes in). > If we use while-no-input, don't we still need to use > accept-process-output, thus not solving the problem? Might very well be: while-no-input does not by-itself let processes run. I don't know what the CEDET code does, so I just mentioned while-no-input as something related, but indeed it might not solve our problem. >> Then please go ahead and install your change. > Thanks, rev 115123. Closing. Great, thank you, Stefan