From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ishikawa Newsgroups: gmane.emacs.devel Subject: Re: "Use font-lock-support-mode rather than calling lazy-lock-mode" Date: Fri, 01 Dec 2006 15:29:40 +0900 Message-ID: <456FCBD4.7090703@ubin.jp> References: <456152B2.6040307@ubin.jp> <45641140.5050502@ubin.jp> <4566A16F.2030605@ubin.jp> <456A95B3.2020200@ubin.jp> 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 1164967043 26130 80.91.229.2 (1 Dec 2006 09:57:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2006 09:57:23 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 01 10:57:17 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 1Gq58s-00030c-4b for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2006 10:57:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gq58r-0008FE-Dn for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2006 04:57:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gq1u9-00077X-Qw for emacs-devel@gnu.org; Fri, 01 Dec 2006 01:29:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gq1u8-00073P-85 for emacs-devel@gnu.org; Fri, 01 Dec 2006 01:29:49 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gq1u8-00073A-5k for emacs-devel@gnu.org; Fri, 01 Dec 2006 01:29:48 -0500 Original-Received: from [202.32.0.84] (helo=post.ubin.jp) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gq1u4-0000xI-6J; Fri, 01 Dec 2006 01:29:44 -0500 Original-Received: from post.ubin.jp (post [127.0.0.1]) by localhost.ubin.jp (Postfix) with ESMTP id 8BA4629AC40; Fri, 1 Dec 2006 15:29:41 +0900 (JST) Original-Received: from [10.254.248.233] (dell-w2k-note.ddns.member.ubin.jp [10.254.248.233]) by post.ubin.jp (Postfix) with ESMTP id 52A6F29AC3F; Fri, 1 Dec 2006 15:29:41 +0900 (JST) User-Agent: Thunderbird 1.5.0.8 (X11/20061025) Original-To: Stefan Monnier In-Reply-To: X-Mailman-Approved-At: Fri, 01 Dec 2006 04:54:59 -0500 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:63182 Archived-At: Stefan Monnier wrote: >> They'd think "Damn, Richard! What got into you?". >> Seriously, I think we're wasting our time here: this problem does not >> impact functionality. > >> I am skeptical of these statements. >> Could you present reasons for them? > > IIRC the "problem" was that Emacs warned the user that lazy-lock is obsolete > and that she can fix that via font-lock-support-mode. That's no loss of > functionality: lazy-lock works just as well as ever, AFAIK. > Hi, The original reporter The problem here was that I got a warning about lazy-lock being deprecated and the code that printed the warning contained "(sit-for 2)" and the resulting behavior was not quite friendly since I could not figure out initially where lazy-lock was invoked until I traced the code to figure out where. I am not sure if lazy-lock mode (supplied with 22.0.90) works without showing this warning every now and then (electric-buffer mode certainly was not usable due to this warning message obscuring the intermediate output/input all the time.). Basic functionality works maybe, but it was hardly usable to a testing luser. Just my observation. As for NOT putting the information into the info page, I concur given that there is a NEWS entry and/or other pointers available on-line so that the package mainteners have ample hints to fix his/her codes. By the time, the release to the general public occurs, the kind of problems that I faced (in relation to somewhat obscure initialize code for VM) would disapper, hopefully. Chiaki Ishikawa