From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: Framework extending window functions for Follow Mode (etc.). Date: Tue, 10 Nov 2015 14:29:18 -0800 Message-ID: References: <20151105192905.GA7986@acm.fritz.box> <20151107130748.GB1770@acm.fritz.box> <20151110131306.GD2626@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447194628 26680 80.91.229.3 (10 Nov 2015 22:30:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Nov 2015 22:30:28 +0000 (UTC) Cc: Emacs developers To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 10 23:30:20 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 1ZwHQh-0006fV-GN for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 23:30:19 +0100 Original-Received: from localhost ([::1]:35871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwHQh-0000Be-5k for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 17:30:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwHPr-0007ct-9W for emacs-devel@gnu.org; Tue, 10 Nov 2015 17:29:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwHPp-0005VA-1U for emacs-devel@gnu.org; Tue, 10 Nov 2015 17:29:27 -0500 Original-Received: from mail-pa0-x230.google.com ([2607:f8b0:400e:c03::230]:33166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwHPo-0005Ux-Sc for emacs-devel@gnu.org; Tue, 10 Nov 2015 17:29:24 -0500 Original-Received: by pabfh17 with SMTP id fh17so9954788pab.0 for ; Tue, 10 Nov 2015 14:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mail-followup-to:mime-version:content-type; bh=0APL8+elWJzTVuT0Z+JhN6aZSOGJA2Y51BzA+R0Jpz8=; b=qCjsO4LuIBYX1LIabwylBGc0yBSOH2WOCGyPYotRWgur6ADQ0o+Bde4KdhYujJcMb9 iYZ8ie1nUOcWZr32yxpWerWWBRNYN2KenCeHpu3rRabVxZYeBU/SLWagV1Z+PrVOtEKD ELqkolf3js/nflh6GASpvyEMkuohvVgsD15iyLyMH6GGnJEOoiJ99uhHTDdz1kqebSWs 7lcfoc/d4K3wUAo1MfeAeLpbQPJ9FwpHpXSOgPJ39rBVeBFSydJIJWAw6V229zQbWq0e 3WHustloZzsyV76Gt2NuAfSHiv2L3OZSGx87xIufegSlZ5s2DrtT6cjlDQ3zjzHuW64t aJ/A== X-Received: by 10.68.142.37 with SMTP id rt5mr9399767pbb.64.1447194564455; Tue, 10 Nov 2015 14:29:24 -0800 (PST) Original-Received: from Vulcan.attlocal.net (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id zk3sm6015291pbb.41.2015.11.10.14.29.22 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 10 Nov 2015 14:29:23 -0800 (PST) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.attlocal.net (Postfix, from userid 501) id 9326C1054036A; Tue, 10 Nov 2015 14:29:21 -0800 (PST) In-Reply-To: <20151110131306.GD2626@acm.fritz.box> (Alan Mackenzie's message of "Tue, 10 Nov 2015 13:13:06 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: Alan Mackenzie , Emacs developers X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::230 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:193983 Archived-At: >>>>> Alan Mackenzie writes: >> Adding your proposal to the Emacs Wiki Proposals page >> (http://www.emacswiki.org/emacs/Proposals) would be a good way to liberate the >> current state of your work from this lengthy discussion, so I can look at it >> again with fresh eyes. > Done. Great proposal. I have an idea about this functionality I'd like to suggest. Right now we have a set of functions with well-defined behavior. Under certain conditions of use, those functions are too specific. You'd like to change the functions' API so that some packages (follow-mode) can change what they mean, and requiring other packages (isearch) to explicitly allow the override. Maybe the problem is that we've turned object-orientation inside out. What we really care about is not the set of functions, but the notion of what "current window" means. It needs to be broader in scope when follow-mode is active, to address the notion that multiple windows are being knit together, visually. It has nothing to do with isearch, so ideally the change shouldn't affect it. What if we just had `window-start-function', receiving the window as its argument -- effectively having getter and setters on window objects. Could follow-mode determine from the argument whether the window was involved in its "group", and act accordingly? That would avoid API changes, is cheaper to do, and no modes would have to change. That is: window-start WIND calls (funcall window-start-function WIND) calls window-object-start WIND So the current window-start is renamed to window-object-start (or some internal sounding name), which is reached by indirecting through the variable window-start-function. I wonder, though, if such extensibility is worth the extra layer of indirection. It feels a bit... special-cased and not very elegant, maybe? Do we care enough about follow-mode to make a core change like this? It could also be that we're looking too much at a specific solution, by needing window-start to change its meaning in order to support correct behavior by isearch. Is there a screencast anywhere, so I could see what follow-mode with isearch looks like using your patch, and what it looks like without the patch? Is anyone else using this code? John