From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Pretest begins end-June Date: Wed, 01 Jun 2011 21:08:08 +0200 Message-ID: <4DE68E18.8070400@gmx.at> References: <87y61ojhp4.fsf@stupidchicken.com> <4DE60326.8040505@gmx.at> <4DE64788.5060304@gmx.at> <4DE661B2.20609@gmx.at> <0683A4086BE145C282DF052109336390@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1306955331 1870 80.91.229.12 (1 Jun 2011 19:08:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 1 Jun 2011 19:08:51 +0000 (UTC) Cc: 'Chong Yidong' , 'Stefan Monnier' , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 01 21:08:42 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QRqmY-0007qs-A4 for ged-emacs-devel@m.gmane.org; Wed, 01 Jun 2011 21:08:42 +0200 Original-Received: from localhost ([::1]:36423 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRqmX-0002Cl-0J for ged-emacs-devel@m.gmane.org; Wed, 01 Jun 2011 15:08:41 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRqm6-0002Bv-Ti for emacs-devel@gnu.org; Wed, 01 Jun 2011 15:08:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRqm5-0003P2-BZ for emacs-devel@gnu.org; Wed, 01 Jun 2011 15:08:14 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:34174) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QRqm4-0003Op-Lu for emacs-devel@gnu.org; Wed, 01 Jun 2011 15:08:13 -0400 Original-Received: (qmail invoked by alias); 01 Jun 2011 19:08:11 -0000 Original-Received: from 62-47-57-149.adsl.highway.telekom.at (EHLO [62.47.57.149]) [62.47.57.149] by mail.gmx.net (mp028) with SMTP; 01 Jun 2011 21:08:11 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+R+o9l9nSR7rbYADboK/VYB1nbs4jv9lbDjalWMw 2L68U689o5wBU2 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <0683A4086BE145C282DF052109336390@us.oracle.com> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 213.165.64.22 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:140032 Archived-At: > You said that binding the var would no longer work. > That is a removal/limit of that possibility. The application can bind the variable `display-buffer-alist' instead. > And you do not provide a suitable alternative. You are missing/ignoring the > general case, where the code that does the display is not necessarily available > to modify textually. I don't understand you here. > Your "suitable alternative" is workable only in the minority of cases where the > call to `pop-to-buffer' is directly available and can be edited. You propose > source-code editing as a replacement for the programmatic control of dynamic > binding. Actually I followed Stefan's advice which I repeat here once more: Rather than let-binding some Lisp-manipulated "config" var, I was thinking of passing special parameters to display-buffer (I'd rather avoid dynamic scoping whenever possible). So you can see that my first approach was to use conventional binding. >> IMHO an application may request (or better "suggest") >> specific behavior and set private variables. > > Your example substitute code does not "request" or "suggest" how to display, > IIUC. It imposes how to display, the same as the code it would replace. But not by manipulating a user option. Moreover, users can _always_ override the application, if they want to. > Or if not, then it is not at all a suitable alternative and we are not even > talking apples and oranges but rather apples and orangutans. > >> But it should not change or rebind any user option. > > Obviously I disagree. You're apparently OK with an application deciding whether > to pop up a frame, but not OK with doing that by binding a dynamic variable, > because in this case the var is a user option. Yes (if we replace the term "deciding" by the term "suggesting"). > That's hypocritical and silly. If an application controls the display, then it > has taken control for that away from the user, regardless of how it does so. No. A let-binding affects every `display-buffer' call nested in it. An argument affects only the associated call. > Bypassing `pop-up-frames' to do that is no more respectful of the user's general > preference as expressed by that var than is binding the var. What is important > are the resulting behavior and the user's preferences. > > Sometimes an application can be right to decide how something is displayed, in > spite of a user's general preference. Developers need to DTRT, thinking about > the user and her preferences to decide what TRT is in any given context. > Respecting users does not necessarily mean blindly applying their general > preferences in all contexts. Let's agree that developers and users may be both wrong, sometimes. > If your code violates a user's general preference as defined by her > `pop-up-frames' value, it is irrelevant how that violation was implemented. > > And this is more general than a question about user options. It is about > dynamic variables in general. Removing the ability to bind a dynamic var in > order to control behavior in code that is not directly modifiable is limiting > and, frankly, unlispy. (No flames about lexical-only Lisps, please.) We wouldn't agree anyway. martin