From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: hw Newsgroups: gmane.emacs.devel Subject: Re: Some developement questions Date: Wed, 22 Aug 2018 18:37:54 +0200 Organization: my virtual residence Message-ID: <8736v6icgt.fsf@himinbjorg.adminart.net> References: <444779489.8504194.1534538988289.ref@mail.yahoo.com> <444779489.8504194.1534538988289@mail.yahoo.com> <83sh3cfb3t.fsf@gnu.org> <87sh36inql.fsf@himinbjorg.adminart.net> <8336v6cvem.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1534956158 17771 195.159.176.226 (22 Aug 2018 16:42:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 22 Aug 2018 16:42:38 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cc: spacibba@aol.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 22 18:42:33 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsWDJ-0004Vk-8M for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2018 18:42:33 +0200 Original-Received: from localhost ([::1]:59983 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsWFP-0007B0-Py for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2018 12:44:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsWFG-00079j-Cj for emacs-devel@gnu.org; Wed, 22 Aug 2018 12:44:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsWFF-0004nF-AX for emacs-devel@gnu.org; Wed, 22 Aug 2018 12:44:34 -0400 Original-Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::6]:27919) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fsWFB-0004jg-BN; Wed, 22 Aug 2018 12:44:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1534956267; s=strato-dkim-0002; d=adminart.net; h=Sender:References:Message-ID:Date:In-Reply-To:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=b91ACPvwqnDC8KROV5BJdckzZJCdhLdvEaNuw+of88A=; b=sUaPZ4IDaxVXBSW3j85u6fnvdUR1gAHJTWvP2LoNZV4E8qVo6jaSztFbSITZqPV/nj TJsyjfqqGTysowWiUiink1ffBChErOt/ijtw0xGRX87TmcR3DCmg661AugOoj/OuCIbD RCoBgaQ49uCxGQ6+22mbi4SI+YP8wier8/7oDZ7Eox8nWkdr6tgyhDg6grq0/sOPEflB vurBvzprYWG8dcOaVO1xhBP4qhVsZLohNEZf8aphm4CR8+IPpFXUUX265zW0qhf8yhAM IVRgjCM5i5UuHn6OQzrutSpNBT+I8RNed1PBfme4BKb2pGYX/IMpdBTYGX7r7vHM5Bqd vWTw== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from lee by himinbjorg.adminart.net with local (Exim 4.90_1) (envelope-from ) id 1fsWF6-0000Yg-0R; Wed, 22 Aug 2018 18:44:24 +0200 In-Reply-To: <8336v6cvem.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 Aug 2018 17:45:21 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5300::6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:228820 Archived-At: Eli Zaretskii writes: >> From: hw >> Cc: Ergus , emacs-devel@gnu.org >> Date: Wed, 22 Aug 2018 14:34:26 +0200 >>=20 >> > Exactly my point: you have just enumerated at least 3 different >> > classes of users, and the solution is different for every one of them. >> > Finding a way of being friendly to each class is the problem to solve. >> > One possible solution could be groups of Custom options that are >> > likely to be relevant to each class of users, and writing >> > customization commands that target each class. Patches are welcome. >>=20 >> How about including a number of ~/.emacs files, containing options >> supposed to make things easier for a class of users --- or include >> groups of ~/.emacs files so that for any given class, there can be many >> configurations to pick from within a group? > > IMO, that would be too radical, because in an init file each option > already has a value. So we will have to decide for the users whether > or not they want certain options to have certain values. That might > work for boolean options, but many options in Emacs are non-boolean. > As just one example, consider display-line-numbers-mode -- it has > between 3 and 4 different styles, so which one would you put in the > .emacs? Use the values you would you put for the particular use case the file is designed for. I didn=C2=B4t know that there=C2=B4s a mode displaying line numbers that has styles; I=C2=B4ve only used linum-mode so far. It would be interesting to learn about this from a file. > By contrast, by creating a group of options, we don't need to decide > for the users what values of which options they like; we just make the > options we think are relevant for them more easily discoverable. But then, the users can be overwhelmed by a multitude of options and may have trouble figuring out which ones to change and which values to set. When customize was introduced, I tried it out and got totally lost in it. I got taken from one buffer to another and figured this isn=C2=B4t useful at all unless you already exactly know what you=C2=B4re looking for. Even then, it=C2=B4s difficult to find. The only thing I sometimes use customize for is setting the default font, and that is /very/ difficult to find because I never think of "face" when trying to pick a font. (Only yesterday I found out that setting the default font is now easy because there=C2=B4s an entry in the menu which works great. A long time ago, I disabled the menu bar, and I usually don=C2=B4t run 'emacs -q' ...) How do you customize key bindings and add your own elisp? > I also think that browsing through a Custom buffer is more > user-friendly than telling the users to find their way through several > files. They don=C2=B4t need to do that. You offer them to use one of the configurations in the LaTeX group for working with LaTeX and to use one of the configurations in the C++ group when writing C++ source code, and so on. Users may be happy when they can try some different configurations, pick one they like and go from there --- rather than having to figure it out all at once all by themselves. Configuring Emacs is kinda like configuring fvwm, and it was fvwm-crystal that brought me back to fvwm after using enlightenment for a long time. Fvwm-crystal is like a pre-defined configuration for fvwm, with a few customization options to choose from. It didn=C2=B4t take long before I wanted to create my own configuration, so I did, learning from the docs and other configurations. I ended up with a window manager that *finally* manages the windows for me rather than forcing me to manage the windows --- and any time I want to change something, I can just do that. Why would I put up with anything less? So what I suggest is more like giving users a choice between fvwms default configuration, fvwm-nightshade, fvwm-crystal and others for Emacs, rather than forcing users to try to find their way through configuration files or options. They may discover Emacs over time, starting from something useful they like, and it probably won=C2=B4t take long before they aren=C2=B4t willing to put up with anything less than Emacs (unless they like vi maybe).