From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.devel Subject: Re: Lisp watchpoints Date: Sun, 29 Nov 2015 16:33:13 -0500 Message-ID: References: <83wpt922dn.fsf@gnu.org> <83egf8oiwt.fsf@gnu.org> <834mg4oa3l.fsf@gnu.org> <831tb8o7qa.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1448832810 31218 80.91.229.3 (29 Nov 2015 21:33:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Nov 2015 21:33:30 +0000 (UTC) Cc: John Wiegley , Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 29 22:33:27 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 1a39b3-0008C9-JP for ged-emacs-devel@m.gmane.org; Sun, 29 Nov 2015 22:33:25 +0100 Original-Received: from localhost ([::1]:37832 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a39b7-0005cV-C3 for ged-emacs-devel@m.gmane.org; Sun, 29 Nov 2015 16:33:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a39au-0005cF-6m for emacs-devel@gnu.org; Sun, 29 Nov 2015 16:33:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a39at-00078w-Dp for emacs-devel@gnu.org; Sun, 29 Nov 2015 16:33:16 -0500 Original-Received: from mail-io0-x22a.google.com ([2607:f8b0:4001:c06::22a]:35533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a39ar-00078a-Pu; Sun, 29 Nov 2015 16:33:13 -0500 Original-Received: by ioc74 with SMTP id 74so154026412ioc.2; Sun, 29 Nov 2015 13:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=o38C85HJmB3uVCRNUasp87c2HiyG4c6MnolxgbJSoZo=; b=OFbSeg5QHCPqXrasSbqL/NSySWJNoCdSvi5voxP1CiXbBYDReEoPQfCJLqvOGbijR6 OaWtnx7xukvs5/5PuzxW/Uxufjzs9B5q80X3DAEygK3LfEv9U43f0NKyTCKUrz7isvpU bWuSxyW+eGIjia4WKxXQ0jZd6C+f6hBFZvj5mqTPHznhSbZeGNKQb7PW1QdX/jePIxaH o8vRww4Q2jPDnOM8/5s2uAzJFFuin9NRGhFCEKk5dYLzqL9WrdPlqceF98BZAkS0WLz0 g0jrncC83Vqh9M6Iy5kvHZC6vQX97j3WjXxUDbAq5W8eOOTuWwFrG+IuW7rjP74on5IJ DcnA== X-Received: by 10.107.130.167 with SMTP id m39mr56355930ioi.18.1448832793458; Sun, 29 Nov 2015 13:33:13 -0800 (PST) Original-Received: by 10.79.119.2 with HTTP; Sun, 29 Nov 2015 13:33:13 -0800 (PST) In-Reply-To: <831tb8o7qa.fsf@gnu.org> X-Google-Sender-Auth: KZHkLBqbWFi1QlHvBwUTkcIWXaU X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c06::22a 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:195576 Archived-At: On Sun, Nov 29, 2015 at 3:45 PM, Eli Zaretskii wrote: >> Date: Sun, 29 Nov 2015 15:35:24 -0500 >> From: Noam Postavsky >> Cc: Stefan Monnier , John Wiegley , emacs-devel@gnu.org >> >> Would it help if I added a WATCHER_NUMBER_LIMIT to the enum after >> WATCHER_NUMBER_SET_REDISPLAY and used that instead? > > Yes, thanks. (WATCHER_NUMBER_LAST sounds a better name to me, but > that's nitpicking.) The thing I don't like about LAST (or MAX) is that it implies it's a valid number, when it isn't. > >> If window.c would be in charge of defining >> set-redisplay-internal-watcher-number, then it would need to know the >> right number, which would probably mean moving the >> WATCHER_NUMBER_SET_REDISPLAY definition to a header file away from the >> watcher_table definition > > Yes, that's what I had in mind. > >> which would be suboptimal, I think. > > But then data.c will forever be doomed to export all the other watcher > numbers, utterly unrelated to it. I think this would be worse. Code > should live where its natural home is, even if that means to have some > declarations in a header. Hmm, okay. Header it is then.