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: [PATCH] frame.c: focus hooks Date: Tue, 19 Nov 2013 10:53:55 -0800 (PST) Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="__138488723581996076abhmp0003.oracle.com" X-Trace: ger.gmane.org 1384887268 31764 80.91.229.3 (19 Nov 2013 18:54:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Nov 2013 18:54:28 +0000 (UTC) Cc: Bozhidar Batsov , emacs-devel To: Brian Jenkins , rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 19 19:54:32 2013 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 1ViqRQ-0005GE-8Z for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2013 19:54:28 +0100 Original-Received: from localhost ([::1]:51148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ViqRP-0001ga-UZ for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2013 13:54:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ViqRD-0001e5-UJ for emacs-devel@gnu.org; Tue, 19 Nov 2013 13:54:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ViqR5-0004fu-7X for emacs-devel@gnu.org; Tue, 19 Nov 2013 13:54:15 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:51974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ViqR4-0004fm-TY; Tue, 19 Nov 2013 13:54:07 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAJIrvoj032719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Nov 2013 18:53:58 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAJIruld005835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Nov 2013 18:53:57 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAJIruj1027258; Tue, 19 Nov 2013 18:53:56 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:165399 Archived-At: --__138488723581996076abhmp0003.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hm. I see nothing in either the Emacs manual or the Elisp manual that sugge= sts that Lisp code should not use `add-hook' or `remove-hook'. =20 Where do you find a convention saying that *polite* Lisp packages do not mo= dify hook values and that to do so in a package published for widespread us= e is "rude" and "ill-mannered"? Or that package authors who do not respect = such a presumed convention are impolite or do not act in good faith? =20 Where are the "Emacs etiquette" and "social norms" in this regard put forth= ? =20 Just wondering. =20 The only thing I see that is related to this is in (elisp) `Coding Conventi= ons', where it says: =20 If loading the file adds functions to hooks, define a function `FEATURE-unload-hook', where FEATURE is the name of the feature the package provides, and make it undo any such changes. Using `unload-feature' to unload the file will run this function. *Note Unloading::. =20 You say: =20 It's probably not a bad idea to document the intent of these hooks -- that = they are meant for the end user and that it is inappropriate to set them in= public packages, but I don't see that adding them opens a huge can of worm= s. =20 Then please do that. If it is inappropriate for Lisp code to use these hook= s, then document that, of course. And perhaps document the reason. I don't = think you can assume that people (users or package authors) are aware of th= e convention that you presume. =20 Are you assuming that these hooks won't be used by any Lisp packages? =20 Yes, I am expecting that they will be left for the user to specify in his or her local Emacs configuration. =20 That is, I expect that they won't be assigned by *polite* Lisp packages. It would be rude to set these hooks in a package published for widespread use. =20 Package authors aren't perfect, but they care enough about Emacs culture to learn Lisp and contribute work. We should assume good faith. When people write impolite packages, we should teach them Emacs etiquette and help them observe social norms. =20 Further, ill-mannered Lisp packages are not forced on the user. They are deliberately downloaded in source form and installed. If a package inappropriately assigns hooks, we are free to uninstall it, to clear the hooks after load, to modify the package for local use, to contact the authors and suggest that they not over-specify our environment, or even to distribute a better-behaved fork of the package. =20 Inappropriate hook assignment is also easier to detect than many possible package misbehaviors -- just evaluate the hook variables. =20 It's probably not a bad idea to document the intent of these hooks -- that they are meant for the end user and that it is inappropriate to set them in public packages, but I don't see that adding them opens a huge can of worms. =20 Best, Brian Jenkins=20 --__138488723581996076abhmp0003.oracle.com Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hm. = I see nothing in either the Emacs manual or the Elisp manual that suggests = that Lisp code should not use `add-hook' or `remove-hook'.

 

Where do you find a convention saying that *polite= * Lisp packages do not modify hook values and that to do so in a package pu= blished for widespread use is "rude" and "ill-mannered"= ? Or that package authors who do not respect such a presumed convention are= impolite or do not act in good faith?

 

Where are the "Emacs etiquette" and "social norms" = in this regard put forth?

 

Just wond= ering.

 

The only thing I see that is= related to this is in (elisp) `Coding Conventions', where it says:

 

=

    &nbs= p;If loading the file adds functio= ns to hooks, define a function

     `FEATURE-unload-hook', where FEATURE is = the name of the feature

     the package provides, and make it undo any such= changes.  Using

     `unload-feature' to unload the file will run this= function.  *Note

 

You say:

 

It's probably not a bad idea to document the intent of these hooks = -- that they are meant for the end user and that it is inappropriate to set= them in public packages, but I don't see that adding them opens a huge can= of worms.

 = ;

Then please do that. If = it is inappropriate for Lisp code to use these hooks, then do= cument that, of course. And perhaps document the reason. I don't think you = can assume that people (users or package authors) are aware of the conventi= on that you presume.

 

Are you assuming that thes= e hooks won't be used by any Lisp packages?

 

Yes, I am expecting that they wil= l be left for the user to specify in

his or her local Emacs configuration.

 

That = is, I expect that they won't be assigned by *= polite* Lisp packages.

It would be rude to set these hooks in a pac= kage published for

widespread use.

=

 

<= span style=3D'color:#943634'>Package authors aren't perfect, but they care = enough about Emacs culture

to learn Lisp and contribute work.  = ;We should assume good faith.  When

people write impolite pack= ages, we should teach them Emacs etiquette and

<= div>

help them observe so= cial norms.

 

Further, ill-mannered Lisp packages are not forced on the user.  They

are deliberately downloaded in source form and installed. &nbs= p;If a package

inappropriatel= y assigns hooks, we are free to uninstall it, to clear the

hooks after load, to modify the package for l= ocal use, to contact the

auth= ors and suggest that they not over-specify our environment, or even

to distribute a better-behaved fork = of the package.

 

Inappropriate hook assignment is al= so easier to detect than many

possible package misbehaviors -- just evaluate the hook variables.

 

It's probably not a bad idea to document the intent of the= se hooks -- that

they are mea= nt for the end user and that it is inappropriate to set them

=

in public packages, but I don't see that ad= ding them opens a huge can of

worms.

 

=

Best,

Brian Jenkins 

--__138488723581996076abhmp0003.oracle.com--