From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Proposal to change cursor appearance to indicate region activation Date: Fri, 30 Jan 2015 10:19:50 +0100 Message-ID: <87iofobp6x.fsf@fencepost.gnu.org> References: <87r3udomzc.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1422609629 14232 80.91.229.3 (30 Jan 2015 09:20:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Jan 2015 09:20:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kelly Dean Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 30 10:20:23 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YH7kS-0003MC-89 for ged-emacs-devel@m.gmane.org; Fri, 30 Jan 2015 10:20:20 +0100 Original-Received: from localhost ([::1]:35652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH7kR-0002MB-1X for ged-emacs-devel@m.gmane.org; Fri, 30 Jan 2015 04:20:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH7kC-0002Jq-L3 for emacs-devel@gnu.org; Fri, 30 Jan 2015 04:20:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YH7kB-00067c-Oo for emacs-devel@gnu.org; Fri, 30 Jan 2015 04:20:04 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH7kB-000678-Ec for emacs-devel@gnu.org; Fri, 30 Jan 2015 04:20:03 -0500 Original-Received: from localhost ([127.0.0.1]:57730 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH7kA-0000AJ-Ri; Fri, 30 Jan 2015 04:20:03 -0500 Original-Received: by lola (Postfix, from userid 1000) id BB4BBDF2DD; Fri, 30 Jan 2015 10:19:50 +0100 (CET) In-Reply-To: (Kelly Dean's message of "Fri, 30 Jan 2015 07:20:10 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182033 Archived-At: Kelly Dean writes: > David Kastrup wrote: >> Multiple independent use cases. add-hook/remove-hook is a mechanism for >> organizing independent use cases for one feature, but there is no such >> mechanism for organizing independent use cases for the varhook feature >> in your implementation even though you actually use add-hook. But it >> requires first individually allocating, naming, and using a hook for any >> variable you might want to varhook into. > > IIUC, you mean independent uses of varhook might choose different > symbols for the hook. It seems that would be solved by the convention > of using the symbol =E2=8C=9Cfoo-varhook=E2=8C=9D as the hook for =E2=8C= =9Cfoo=E2=8C=9D; all > independent uses would add/remove their functions on that same hook. A convention is not an interface. > I guess another solution would be to put the car of the list of > functions directly in a dedicated varhook slot for the target symbol, > rather than indirecting through a regular hook. That would increase > the size of each symbol from 24 to 28 bytes (on 32-bit platforms). But > even in my main Emacs session, which has been up for 54 days (with > 300MB reserved memory), I only have 10k symbols, so an extra 40kB of > memory usage isn't much overhead. I have 40k right now, and this session has been up for few minutes (admittedly, using desktop-load). But at any rate, this does not appear like a feature that should be a central part of the data/operation in a production Emacs, and consequently it should not be a required part of the implementation of a production Emacs feature either. I also have to warn you that there is little point in trying to convince or coax me since I more or less have the authority of a court jester. So it is pointless to argue away problems with me since it does not help getting the code accepted. --=20 David Kastrup