From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniele Nicolodi Newsgroups: gmane.emacs.devel Subject: Implicit assumptions in the latest discussions Date: Thu, 17 Sep 2020 15:30:48 +0200 Message-ID: <1bc3251a-7b36-f151-7fc6-9ecf2639bb9f@grinta.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15929"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 17 15:32:55 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 1kIu1u-00040W-5K for ged-emacs-devel@m.gmane-mx.org; Thu, 17 Sep 2020 15:32:54 +0200 Original-Received: from localhost ([::1]:39380 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kIu1s-0004wZ-Sb for ged-emacs-devel@m.gmane-mx.org; Thu, 17 Sep 2020 09:32:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55058) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kItzz-0003AO-Sw for emacs-devel@gnu.org; Thu, 17 Sep 2020 09:30:55 -0400 Original-Received: from grinta.net ([109.74.203.128]:57554) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kItzw-0004bX-2K for emacs-devel@gnu.org; Thu, 17 Sep 2020 09:30:55 -0400 Original-Received: from black.local (unknown [37.120.217.164]) (Authenticated sender: daniele) by grinta.net (Postfix) with ESMTPSA id 5A6DDEB70D for ; Thu, 17 Sep 2020 13:30:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=grinta.net; s=2020; t=1600349450; bh=xVTH2ZXQjqgFqA3GVVCQJ2LIdemB8vCohBJMDdeLnUs=; h=To:From:Subject:Date:From; b=TKjcaRBy/vRySZ2F91XGWH2MZv+E2IV8Z9QSs5H0b4rVXxvNz4nvHyoxqABqyoKjG Hm//3ftW2dRWXXWRxSNNDtnOje/NV5wXYGixLjIBDj7DXI1nt+feEh/IaiUIHpz0vQ KII57v12o3ClwaIAsEqYdUXhQayZ8OeOm5UqudRXm67cMkxju29CZMLtqmMh2HaYxq 8mgFN2bfEvZw7FwxXLqroOkX3Y26P4b+3VRSqv0uV/S3C2z3S4sN90S3C+eP4wbyrl 7dm0gXFFvHf3lyLTCp3Ml87hBHonC9uHs+z33mEXXVmk5Wj1gmmqChqIz7S9dIQ7u1 3tNBUx4sV/O2Q== Content-Language: en-US Received-SPF: pass client-ip=109.74.203.128; envelope-from=daniele@grinta.net; helo=grinta.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/17 07:08:52 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no 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:255991 Archived-At: Hello, I admit I just read a minimal part of the posts in the current threads about making Emacs simpler, or friendlier, or more "modern" (for a definition of modern very different to mine). However, I would like to express my doubts about the assumptions implicit in these discussions. These assumptions seem to be: 1. Emacs would be better if it had a larger user base or the Emacs users would be better served by an Emacs that appeals to a larger user base. I think that this can be true only as far as another assumption hold, namely that with a larger user base there would be more manpower to work on Emacs itself, thus Emacs will become better because more people is hacking on it. I don't think there can be any correlation between the number of users of Emacs and the number of hackers interesting in working on it. If the end goal is to make Emacs development more sustainable, an easier way to get there would be to modernize the development practices used to work on Emacs itself. However, this is a much harder (social) problem to solve. 2. Users are not drawn to try Emacs because what Emacs is and for his reputation, but because they expect Emacs to be like other editors. I think that who chooses Emacs, does so because of what Emacs is and what it has been in its long history, not because they expect something different. If they expect something different, Emacs has an enormous technical disadvantage compared to younger editors that are based on different technologies and that do not want (need?) to keep compatibility if an incredibly long history. Probably there are better thing that can be done to make the experience of these users better than providing "simplified" Emacs environments, because the users that choose Emacs don't want a simplified Emacs, they want better ways to access the power of Emacs. Having "simplified" modes also poses the problem of allowing the users to "graduate" from the simplified environment to the full blown one. I haven't see this discussed. 3. Emacs is perfect as it is, but the users do not understand it. I feel that a lot of the discussions are centered toward having ways to simplify Emacs to make it more appealing to new users or to some very specific classes of prospective users. Wouldn't it be more productive and wouldn't it be better for who already has invested in Emacs (namely the current users) to discuss ways to make Emacs better for everyone? For example, GNU/Linux is the platform where Emacs should run best, however, as far as I know, there is currently no way to run Emacs on a Wayland compositor, and Wayland is the future of graphical interfaces on GNU/Linux. Also, some of the complexity of hacking on Emacs, comes from supporting a wide range of graphical toolkits. Wouldn't it be a worthwhile goal to support a graphical toolkit that works on Wayland, and then make it the only one supported (at least on GNU/Linux) and redirect some hacking energy into making this solution a good solution for everyone (hacking on the toolkit itself if necessary)? This would be much more important to keep Emacs relevant in a few years from now than a Emacs-simplified-mode. While the use of a specific graphical toolkit may seems a technical issue far from the current discussions, I would like to point out that also this is mostly a "social" issue: removing support for other toolkits will affect those that for one reason or another prefer to use Motif Emacs. Cheers, Dan