From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: "Emacs Lisp Packages" chapter in the Emacs manual Date: Tue, 12 May 2020 08:46:42 -0700 (PDT) Message-ID: <10b99f72-5700-4563-9dac-beae0d5b78a7@default> References: <11437E00-8970-4908-A900-0438A248428D@traduction-libre.org> <75254771-9303-4982-AB60-F92AF7AC6454@traduction-libre.org> <11AC1ECE-C120-4CBE-93C7-6FD82AF12299@traduction-libre.org> <18BA1545-091A-454E-B459-DEB96071D048@traduction-libre.org> <4f5da1c3-1311-44ca-80f7-942d9a0537b4@default> <0BBC80E8-7A74-4DB4-8C13-AF2AAFF04B4B@traduction-libre.org> <920E43F8-B65B-4802-97D3-F64BEBF5E8B8@traduction-libre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="97014"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Jean-Christophe Helary , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 12 17:48:07 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYX8Y-000Oze-PR for ged-emacs-devel@m.gmane-mx.org; Tue, 12 May 2020 17:48:06 +0200 Original-Received: from localhost ([::1]:56660 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYX8X-0005QZ-Px for ged-emacs-devel@m.gmane-mx.org; Tue, 12 May 2020 11:48:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYX7O-0004Nw-QY for emacs-devel@gnu.org; Tue, 12 May 2020 11:46:54 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:46428) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYX7N-0007Ha-PU for emacs-devel@gnu.org; Tue, 12 May 2020 11:46:54 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04CFh3dB195470; Tue, 12 May 2020 15:46:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=ExGUgZCBHha78b6rzAeiweQ1QOsX0yDLh3hVtUw+glI=; b=xZHj6N36ifGVVBiEV5UOj+uujHS1bsoCvHcTqqrR7C2DGAiHm9DttJqlnhPijEn4N1+g ybe+TFLzH1L8/77rRhjAA41qy+MZFIdZWHs3knZtplK2HcMgucOXfglSSroNwpdFTGPG AjJV009CGTcWN4Ut/8CoNfGP02Vo3m7U7YsFMNEWhSNXcl5fQIrzevaJwTllpXf9vU0P 6a3Hff31+XsbPJDR+svVevS9CL/A83fKHoqyE6Pni3esC6At979e8lHxGemUDmDF2e/2 8XPMoFTaX0N0Teb1EpOR7MDPbRvz/KBxfmd5eX90wXEy+MiiZl8hptLDzIHmMEszQI8l /Q== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 30x3gskthc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 12 May 2020 15:46:49 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04CFhlTM056458; Tue, 12 May 2020 15:46:49 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 30x63q1pqd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 May 2020 15:46:48 +0000 Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 04CFkh0P011342; Tue, 12 May 2020 15:46:45 GMT In-Reply-To: <920E43F8-B65B-4802-97D3-F64BEBF5E8B8@traduction-libre.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9619 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005120118 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9619 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 clxscore=1015 bulkscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005120118 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/12 11:46:50 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:249982 Archived-At: > > If the file is needed simply because the user decided to split their > > `.emacs` file into several separate files, then `load` (or `require`) > > is probably fine. That is the case where the file is a configuration > > file, i.e. loading it changes Emacs's behavior. > > > > If OTOH that other file is a package/library which provides a > > particular feature (in which case, loading the file *should not* > > change Emacs's behavior), then usually what should be done is add a > > few autoload`s to load the file on-demand. >=20 > Well, actually all this started because I wanted to install > Drew's help-fns+.el and it happens that Drew uses "require". Here's a half-hearted excuse/explanation. Loading help-fns+.el is a user (or other-library) choice. And yes, loading it does change behavior - that's the aim. It's not a normal library, in that sense. Conventionally, loading a library should not change behavior. Mea culpa. No, the changes are not optional (e.g., the different behavior is not provided by a minor mode). It's meant to, in effect, _replace_ some of what help-fns.el does, without replacing all of its code. Think patch, if you like. After loading it, you have, in a way, patched some of help-fns.el. Two of the `require's are soft requires: no error if not found. Again, a user choice: if those libraries are not present in `load-path' then nothing happens. They're not really required. Two of the `require's are hard: help-fns.el, wid-edit.el. Yes, this way of doing things doesn't perfectly respect the coding guidelines. But hopefully the Commentary makes clear that the library changes some behavior. For example, it points out `describe-*' commands that it redefines. > So, in case I want to add a similar feature set, would > 'require be too much ? Would (autoload 'help-fns+) be > sufficient ? >=20 > When I have the information about this, I think I can > make a satisfactory patch to the manual :) >=20 > Keep in mind that this addition is for users who know > a minimal subset of emacs lisp (enough to play with > their init file), not for authors.