From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Uniformity (was: Is Elisp really that slow?) Date: Wed, 15 May 2019 11:07:50 -0400 Message-ID: References: <20190514235412.kncazq45szlum2gr@Ergus> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="17521"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed May 15 17:08:36 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hQvWF-0004Qk-9Z for geh-help-gnu-emacs@m.gmane.org; Wed, 15 May 2019 17:08:35 +0200 Original-Received: from localhost ([127.0.0.1]:38456 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQvWE-0000h5-8j for geh-help-gnu-emacs@m.gmane.org; Wed, 15 May 2019 11:08:34 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQvVn-0000bu-KY for help-gnu-emacs@gnu.org; Wed, 15 May 2019 11:08:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQvVm-0003fi-MQ for help-gnu-emacs@gnu.org; Wed, 15 May 2019 11:08:07 -0400 Original-Received: from [195.159.176.226] (port=50500 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hQvVm-0003dv-Fn for help-gnu-emacs@gnu.org; Wed, 15 May 2019 11:08:06 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hQvVf-0003il-D6 for help-gnu-emacs@gnu.org; Wed, 15 May 2019 17:07:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:H1fpt/CWZEOFzE30SmKVL291i6Y= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:120386 Archived-At: > To mention just one example: It does not make sense that C-c C-c > comments the current lines in C-mode, but sends the current sexep to > terminal in other modes, or send the messages in others. AFAIK C-c C-c should always mean some kind of "OK, I'm done with the edit, now do what needs to be done with it", I believe many modes already follow this, but some modes (such as C-mode) instead follow the old "convention" of binding C-c C-c to comment-region (this convention became redundant in Emacs-21 where M-; was extended to cover comment-region). I agree this is a bug/misfeature and I encourage you to report it as such. Unifying behavior between different major modes is something important, IMO, and it's been the focus of a lot of my work on Emacs, but since it requires changing existing packages (with no immediate benefit to those packages nor their users) it has to work against inertia. > Sometimes new users also mix languages, but the worst supported ones are > the newer languages (Lua, Julia, Ruby, Python, C++ 11+, Rust) Which are > also what they need more often. In which sense are Python and C++ among the worst supported ones (I don't have enough knowledge of the modes for the other languages you mention to include them here, but I'm also mildly surprised about them being in your list). IOW which languages do you consider have better support (in Emacs) than Lua, Julia, Ruby, Python, C++ 11+, or Rust? > But also there is the fact that we are spending a lot of > effort/work/manpower in specific use cases and fancy functionalities > (web browsing, pdf reader, image shower) instead of looking and [ FWIW, I don't think this is a zero-sum game here, so improvements in those areas don't necessarily impact improvement in other areas. ] > So, as usual in technology, other products filled the hole thinking in > the final user and not in the developers. So, in spite of our product is > better we don't find users for it because we don't know how to present > it to the new market. Right. I wouldn't invest money in Emacs, indeed. But we're not driven by money, luckily, so matters of "market" don't drive us. I have no hope/intention of making Emacs into the dominant editor "on the market". Instead, I try to improve Emacs as much as I can so as to make it as pleasant as possible *for Emacs users and hackers*. Emacs fills a particular niche nowadays and trying to make it compete against something like Sublime is not only unlikely to succeed but it's likely to make you lose your niche (because it'll be basically a different text editor). IOW, if I were starting from scratch, I'd implement my editor very differently. But I don't think we can realistically get there from where we are (other than starting from scratch, that is). Stefan