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: face-remap.el patch to resize window Date: Mon, 10 Aug 2009 14:41:02 -0700 Message-ID: <1D8E4D2CC1104D828FC388424038651F@us.oracle.com> References: <7D6750DD60204DB082A761ECEE706CEA@us.oracle.com><91793771320945CAA5CA2B600D0E9B67@us.oracle.com> <8763cvbme4.fsf@catnip.gol.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 1249940560 5938 80.91.229.12 (10 Aug 2009 21:42:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Aug 2009 21:42:40 +0000 (UTC) Cc: 'Stefan Monnier' , emacs-devel@gnu.org To: "'Miles Bader'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 10 23:42:33 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 1MacdV-0008Bh-44 for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2009 23:42:33 +0200 Original-Received: from localhost ([127.0.0.1]:33454 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MacdT-0004ga-7K for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2009 17:42:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MaccL-0003s6-5Q for emacs-devel@gnu.org; Mon, 10 Aug 2009 17:41:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MaccF-0003in-Im for emacs-devel@gnu.org; Mon, 10 Aug 2009 17:41:20 -0400 Original-Received: from [199.232.76.173] (port=51182 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaccE-0003id-W8 for emacs-devel@gnu.org; Mon, 10 Aug 2009 17:41:15 -0400 Original-Received: from rcsinet12.oracle.com ([148.87.113.124]:31075 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 1MaccA-0002E8-2s; Mon, 10 Aug 2009 17:41:11 -0400 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 n7ALexDE021108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Aug 2009 21:41:04 GMT Original-Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n7ALf3w7022479; Mon, 10 Aug 2009 21:41:03 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Aug 2009 14:41:00 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoZ4Uk0KevqLL/UTHm10XgzpBOHewAAqf3g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <8763cvbme4.fsf@catnip.gol.com> X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010206.4A8093EE.001F:SCFSTAT5015188,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:114002 Archived-At: > > (No reason given.) Why? > > Well the obvious reason is that it avoids hard-wiring > behavior which we believe to be to inflexible, and is > a smaller change. There is no inflexible, hard-wired behavior in the patch I sent. If the option value is nil, nothing is done. If it is non-nil, then the window is resized. Completely soft control, via a variable. User control, in fact -nothing is softer. No hard-wiring, and nothing inflexible. And my patch has 17% fewer lines than yours, if that's what you meant by smaller. ;-) > [The hook, after all, already exists; my patch mainly just > records a bit more information for it to use.] These are each tiny patches. One adds a user variable and calls `enlarge-window*' if the option value is non-nil. The other adds two internal variables that record state and three alternative functions that call `enlarge-window*'. One makes text-scaling look at the option value and maybe change the window size. The other provides window-sizing functions that you can add to the text-scale hook. That's the only real difference, I think you'll agree. I don't see either approach as unclean, inflexible, or hard-wired. I see one approach that is user-friendly, with well-defined behavior that is advertised to users clearly via a user option. I see another approach that does nothing for users, unless they happen to read the code, discover the potential hook functions, and add one of them to the hook. And if a user wants to change the behavior, s?he needs to mess with `add-hook' and `remove-hook' all over again. > > I mentioned some disadvantages to using a hook. > > Hmm, the only real disadvantage I can see > is that hooks aren't well-supported by customize. Not just Customize. Hooks also do not facilitate on-the-fly addition/removal by users. A user cannot get the equivalent of `set-variable' using hooks - s?he needs to fiddle with some Lisp code (e.g. via `M-:'). And that includes making the behavior buffer-specific or updating a buffer-local setting. With `set-variable', you just use a prefix arg to do that. With hooks, you need to first use `remove-hook', then `add-hook', specifying the LOCAL flag as appropriate. The question is whether we really intend this for users. Using hooks instead is somewhat of a copout IMO - making it seem like we did something. (E.g. to get Drew off our backs. ;-) ) > [As for "buffer localness", hooks, after > all, can also be buffer-local, or can examine a buffer-local > variable to determine their behavior.] Sure, a user can always code something up. But _why_ make users do that, when using an option is so much simpler for them? You seem to suggests that your patch is easier for those working with the code (though it's not). What about the users? > > No one has mentioned any advantages. > > See above: Smaller; more flexible. > Hooks (like other indirection mechanisms) are generally more flexible, How is it smaller? More flexible for whom? Users? > at some cost in user-friendliness and clarity. So if there's very > commonly desired behavior, sometimes it's good to hard-wire it Apparently, code that examines a user option and reacts to it constitutes "hard-wired" behavior, for you. That's a misleading designation. Yes, you can add any behavior you want with a hook, so in that sense nothing beats its flexibility - it does nothing, anything, and everything. The behavior is undefined. Yes, predefined behavior that reflects a user's intention through an option value is, well, predetermined. IOW, it is well-defined. As you said, it has the advantages of "user-friendliness and clarity". > instead of telling people to use a hook or whatever (even if an > appropriate hook already exists). However as I've mentioned, > it's not clear to me that the described behavior in this case > is generally useful/universal enough to hard-wire. The point really seems to be that you're not convinced users should be offered this behavior. ;-) But you're willing to provide the hook functions for it. Sounds like that's as good as we're going to get. It's still an improvement for users to have this possibility, no matter what they need to do to use it. Please add the feature, one way or the other.