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.help Subject: RE: How can i enable webmode? Date: Mon, 11 May 2020 08:02:27 -0700 (PDT) Message-ID: References: <008d9cd4-8d24-f19b-82ad-d5c1bf7a435f@posteo.net> <86d07b6a4w.fsf@duenenhof-wilhelm.de> <864ksm4rf9.fsf@duenenhof-wilhelm.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="57258"; mail-complaints-to="usenet@ciao.gmane.io" Cc: aprekates , help-gnu-emacs@gnu.org To: dieter@duenenhof-wilhelm.de Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 11 17:03:22 2020 Return-path: Envelope-to: geh-help-gnu-emacs@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 1jY9xh-000El3-A7 for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 17:03:21 +0200 Original-Received: from localhost ([::1]:43582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jY9xg-000478-AR for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 11:03:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35832) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jY9x4-0003vR-9t for help-gnu-emacs@gnu.org; Mon, 11 May 2020 11:02:42 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:42934) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jY9x2-0002Sr-DC for help-gnu-emacs@gnu.org; Mon, 11 May 2020 11:02:41 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04BF2CR4043253; Mon, 11 May 2020 15:02:34 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=Sha9AtvGYJniXdUJwUnB4ISP7f8n1DaTdmy4lqPETXA=; b=ZZVdTUYILiHGPIt9zGAqMk4fTJpGvcPXo4goY2L+9HfvrBcX+JpWAkKfVuFRYk9mKG4Z mrPkPZuuY2jx72jqYt+C8pwxfpNIRdJ8ZXYWYOwc/RDl2pPDZ837VbCIggBPPIQchm0W mVjalUzZ4/n+B5iSCHlQBjALeOwbvFZlcVB1+8jwvt0tg1Lx7hgB8tY6QLsYHuQyacwA kU9XAZgHKUzsMnDdgTxaXywNDTxsRwOH2khy+jlVy0KceCuaALn4zDoKzJcfWk7KBVom ADmyN5pyA5I5qDcUsBzwt2rdmv8UTT+HA0VddvOV00YOOYLAAKh6JjtCkxqHjk496lfv gQ== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 30x3gmdmkt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 11 May 2020 15:02:34 +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 04BEhZF9059469; Mon, 11 May 2020 15:02:33 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 30x63mvfba-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 May 2020 15:02:32 +0000 Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 04BF2T71009284; Mon, 11 May 2020 15:02:29 GMT In-Reply-To: <864ksm4rf9.fsf@duenenhof-wilhelm.de> 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=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 suspectscore=1 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-2005110117 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 clxscore=1015 spamscore=0 lowpriorityscore=0 phishscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 suspectscore=1 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110118 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/11 11:02:38 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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:123072 Archived-At: > >> For example the Melpa package `inform' is activating itsel during > >> installation (and maybe by restarting Emacs in some situations). > The > >> motivation is: If you are interested you'll have it without much ado > >> and > >> if you don't like it any more just uninstall the small package. > >> > >> Does it make sense or do you regard this behaviour as impolite? > > > > It's generally considered impolite, and is > > contrary to convention. >=20 > Thank you for showing the Lisp coding convention. >=20 > And I accept these reasonable rules. But I think there are also > borderline cases where (small?) packages don't change editing behaviour > and do not change existing code in any way. And the its feature(s) can > be completely removed by uninstalling the package. >=20 > Why would I download a package if I do not want to activate an > advertised feature? So this uncommon way can save unnecessary hassle, > I hope. First, a user may well want to download something just to try it out, without wanting, say, changes made to a local setup. Or even just want to take a look at the source code. There's good logic, and consideration of users, behind such guidelines. But second, I personally agree that they should be only guidelines (for 3rd-party coders), and such guidelines have exceptions. I think that what's really important/helpful is for the Commentary in a library (source file), or some other associated doc, to make clear what happens, what the behavior is. If a user uses a command, or loads a file, or turns something on, s?he should know just what will happen. If s?he then does that, knowing what will happen, that's a user choice. An example: GNU Emacs policy/recommendation is that code should not bind or set a user-option value. The idea behind that (good, reasonable) guideline is that it's a _user_ setting, and a user preference should be respected. But what about a command or other user-choosable construct whose very purpose is to change an option value? Does it make sense to outlaw providing such things to users? No, IMO. For example, there are Isearch options, and there are Isearch keys that temporarily have the effect of toggling the behavior controlled by some such options. They actually toggle an internal variable, without affecting the option value. But what if the point of a particular key/command is precisely to change (e.g. toggle) an option, so that the change affects not only the current Isearch but also subsequent ones? In such cases my own opinion differs from GNU Emacs policy. I don't feel constrained, in providing 3rd-party code, to never bind or even set option values. I do feel compelled to document behavior. It's then up to users to choose whether to take advantage of it. Same thing applies to commands that might change colors or whatever interactively. IMO, there's no reason that Customize should be the only way for users to alter such state. It's good, not bad, to provide ways for users to incrementally change appearance or behavior interactively. But it's important that users be in control, that they choose whether to do this or that, knowing what behavior will result. Just one opinion. Understand that those guidelines came about because there were too many Lisp files that did change too many things just by loading them. It was hard for users to work around that, undo it, or sometimes even be aware that it was happening. It's understandable that this happens, because the typical road to the creation of a 3rd-party library often starts with someone's personal customizations (with Lisp code). Such a file of code that changes behavior can evolve into a library that others pick up. And it's all too easy for that evolution to skip steps of making sure every behavior change becomes something optional and undoable. There are degrees. And it's not always easy to make everything optional and undoable. A minor mode is a good way to provide for optional behavior, in general: key bindings, whatever. But some changes of Emacs state are not so easily reversed. The most important thing, IMO, is to be clear (document) what happens.