From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: questions about blink-cursor-mode Date: Thu, 19 Nov 2009 09:17:31 -0800 Message-ID: <61362E665F83401885B1D0C233C75F40@us.oracle.com> References: <59E57B2EDA3D465DA20C720A327090CC@us.oracle.com><5F1590E419004FC3988A3EB1CDFF52EB@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1258651851 12720 80.91.229.12 (19 Nov 2009 17:30:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2009 17:30:51 +0000 (UTC) Cc: 'Juanma Barranquero' , emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 19 18:30:44 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NBAq8-0006Zz-3p for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2009 18:30:40 +0100 Original-Received: from localhost ([127.0.0.1]:55450 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBAq7-0008Qm-Hy for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2009 12:30:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NBAdi-0005gU-5y for emacs-devel@gnu.org; Thu, 19 Nov 2009 12:17:50 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NBAdd-0005aI-6K for emacs-devel@gnu.org; Thu, 19 Nov 2009 12:17:49 -0500 Original-Received: from [199.232.76.173] (port=47453 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBAdc-0005a5-VH for emacs-devel@gnu.org; Thu, 19 Nov 2009 12:17:45 -0500 Original-Received: from rcsinet12.oracle.com ([148.87.113.124]:17628 helo=rgminet12.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NBAdc-00012k-Gm for emacs-devel@gnu.org; Thu, 19 Nov 2009 12:17:44 -0500 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nAJHHbIP016779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Nov 2009 17:17:38 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nAJHHgT3008293; Thu, 19 Nov 2009 17:17:42 GMT Original-Received: from abhmt016.oracle.com by acsmt358.oracle.com with ESMTP id 468035001258651052; Thu, 19 Nov 2009 11:17:32 -0600 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Nov 2009 09:17:31 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpotIUa6MCHexS1RHe009h1dXAb2AAgH7TQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4B057DB3.0010:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:117267 Archived-At: > > Thanks, Juanma. Now that I see that explanation, I recall > > that I knew this at one time - but I guess I forgot it. > > Note that not only is it not declared (e.g. defvar), it > > is also not bound, which is why `C-h v' doesn't recognize it. > > The first problem is in the docstring: > "It finishes by running the mode hook variable `MODE-hook'." > this repeats a very widespread misconception, which is that > those hooks are variables. They're not: a hook is a symbol, > not a variable. That's why it can work even if the variable > by that name is not bound. 1. Yes, fine, correct the doc string if you like. Similarly, the Emacs manual and Elisp manual need to be corrected, if you deem this important. The Emacs manual, node Hooks, defined "hook" in its very first sentence this way: "Hooks" are an important mechanism for customizing Emacs. A hook is a Lisp variable which holds a list of functions, to be called on some well-defined occasion. And the Elisp manual, node Hooks, repeats the same thing (why such repetition, BTW?): A "hook" is a variable where you can store a function or functions to be called on a particular occasion by an existing program. The entire Hooks node in each manual then explains more about such "variables" ("symbol" is never used). If the distinction is truly important here, then we shouldn't be defining hooks in a way that loses the distinction. However, for a hook to actually be _used_, `add-hook' or similar must have been called, so the symbol must have a value. (And even if you then use `remove-hook', the symbol is not unbound.) IOW, for any discussion or explanation of the real use of a hook symbol, which pretty much means for all practical purposes, the symbol is a variable (it has a value - it must have a value to be useful). The nuanced explanation helps users like me who forget or are unaware of the fact that hooks are not bound initially, but I don't know what purpose it serves otherwise. So what is the reason that hook symbols are not initialized to nil? Is it simply to save a little memory? If they were initialized (e.g. by such as `define-minor-mode'), then they would show up for things like `C-h v', which helps user discovery. IOW, what is the benefit of not initializing them? 2. My main questions are still out there - the discussion about hooks being possibly unbound symbols is ancillary. The questions are about `blink-cursor-mode'. It is a global minor mode. Is there a way (how?) to turn it on only locally - e.g. for a particular buffer or mode? (`make-local-variable' won't help.) If not, what's a good way to get something like that effect? Currently, I just turn it on when my particular major mode is turned on, and then turn it off when that mode is exited (or, via `blink-cursor-mode-hook', when the user turns it off). This is an ugly, approximative hack - I'd love to learn a better approach.