From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ken Manheimer" Newsgroups: gmane.emacs.devel Subject: blink-cursor-end sometimes fails and disrupts pre-command-hook Date: Fri, 18 Aug 2006 18:30:29 -0400 Message-ID: <2cd46e7f0608181530l1c1a18f7k1923f610edf73f59@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1155940276 5670 80.91.229.2 (18 Aug 2006 22:31:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 18 Aug 2006 22:31:16 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 19 00:31:14 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GECrn-0006ES-Uw for ged-emacs-devel@m.gmane.org; Sat, 19 Aug 2006 00:31:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GECrn-0002Ox-9n for ged-emacs-devel@m.gmane.org; Fri, 18 Aug 2006 18:31:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GECrL-00022u-AB for emacs-devel@gnu.org; Fri, 18 Aug 2006 18:30:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GECrJ-00020M-77 for emacs-devel@gnu.org; Fri, 18 Aug 2006 18:30:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GECrI-0001zp-RF for emacs-devel@gnu.org; Fri, 18 Aug 2006 18:30:32 -0400 Original-Received: from [64.233.182.190] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GECy6-0000zI-FE for emacs-devel@gnu.org; Fri, 18 Aug 2006 18:37:34 -0400 Original-Received: by nf-out-0910.google.com with SMTP id q29so1639624nfc for ; Fri, 18 Aug 2006 15:30:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=GAjDKv1fZT3Siy9CAX6g1BhS9TzR8JFSUTcC5OZjL85H+BUeH7uEmPzFN8q5lFQcSw+mtjocZq4fvm+BpjRrmsR7t1x7ea0mc1Mq+XpSwUtmMCoKdBccPifUREOysE2zBhqbYpoW+yxcWEtbXziRV2txkKKo5ysIns2RCUBFhbU= Original-Received: by 10.49.90.4 with SMTP id s4mr4612624nfl; Fri, 18 Aug 2006 15:30:31 -0700 (PDT) Original-Received: by 10.78.144.19 with HTTP; Fri, 18 Aug 2006 15:30:29 -0700 (PDT) Original-To: Emacs-Devel Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58496 Archived-At: i've been having a hell of a time tracking down a user-configuration-sensitive blink-cursor error, and can't even report a case to reproduce it. i do have a simple change which prevents the problem and which i think is proper, though i couldn't swear to that. i'm attaching the patch below. after my first keystroke in an emacs session, i find the error message in the *Messages* buffer: Error in pre-command-hook: (error Invalid timer) deactivation of the pre-command-hook disrupts my editor session, of course, disabling all activity on the pre-command-hook. after a bunch of searching, i determined the problem was happening in blink-cursor-end running off of the pre-command-hook. i was unable to determine the combination of packages and settings from my emacs rc file necessary to trigger it (and i spent a few hours adding things in and out, aaargh). it started happening about a week ago, with upgrade to a recent version of emacs 22. one incidental point. i would really, really, *really* have liked to backtraces to help track this down, but emacs backtraces are useless for that by design. you have to know where to put them to get the backtrace from an error at that point. that is terrible - more than half the usefulness of a backtrace is in pinpointing where an error occurred. i can understand not wanting to produce a backtrace on every error, if it's an expensive operation. however, i can't understand not having a mode - eg, with a `debug-on-error' style variable, eg `retain-backtrace-on-error' - for retaining backtraces on any error, to be replaced when the next error happens. i have no C chops, so can't implement this, but would love it if someone were interested in doing so. (if this kind of thing is already possible, please someone clue me in, and my apologies for my rant.) here's the change which prevents the blink-cursor problem. the condition is similar to that used in blink-cursor-mode, and i'm pretty sure is not harmful. it may be covering over some kind of timing sensitivity in changes to pre-command-hook, but i've been unable to track that down. -- ken ken.manheimer@gmail.com http://myriadicity.net --- frame.el 21 Jul 2006 03:42:52 -0400 1.237 +++ frame.el 18 Aug 2006 17:58:18 -0400 @@ -1308,7 +1308,8 @@ itself as a pre-command hook." (remove-hook 'pre-command-hook 'blink-cursor-end) (internal-show-cursor nil t) - (cancel-timer blink-cursor-timer) + (if blink-cursor-timer + (cancel-timer blink-cursor-timer)) (setq blink-cursor-timer nil))