From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Fri, 17 May 2019 14:35:51 +0200 Message-ID: <20190517123551.vumasyoyr5bv5voq@Ergus> References: <20190515210924.sijzy6mnpgzkt4gm@Ergus> <83ftpecwu1.fsf@gnu.org> <20190516161408.4dov3dwk5h4yoizn@Ergus> <838sv6cmwt.fsf@gnu.org> <20190516202327.5cgy2s4kppy3ahxa@Ergus> <871s0yqg2i.fsf@telefonica.net> <3210C8E9-7A74-47D6-81A0-470948E6D09C@gmail.com> <87r28xq0j1.fsf@telefonica.net> <20190517055202.ted62gt6hqcip7xt@Ergus> <83mujlbgjh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="10671"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri May 17 14:37:40 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 1hRc7H-0002cC-G4 for geh-help-gnu-emacs@m.gmane.org; Fri, 17 May 2019 14:37:40 +0200 Original-Received: from localhost ([127.0.0.1]:48008 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRc7G-0001iK-0x for geh-help-gnu-emacs@m.gmane.org; Fri, 17 May 2019 08:37:38 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRc5i-0000qd-L8 for help-gnu-emacs@gnu.org; Fri, 17 May 2019 08:36:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hRc5g-000257-9T for help-gnu-emacs@gnu.org; Fri, 17 May 2019 08:36:02 -0400 Original-Received: from sonic305-2.consmr.mail.bf2.yahoo.com ([74.6.133.41]:36253) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hRc5f-00023X-Qv for help-gnu-emacs@gnu.org; Fri, 17 May 2019 08:36:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1558096558; bh=EbKl2FgLEPKAO4tvdygLMp9EhG3qAt3DL2uD9fMru08=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=fEaK0YZFBJl0omclf54+rLxo9RmyZu86l027GtJm8hAEK4kH6AZudF3RvmlrwZzDlfZqOiKNIDKBXeszzkx/KuTZ4POMYFhfXD6Y5dWQqXnnaDt4CDu/8CK2G9bhSl9JjMTqbWixPfyuAz29b4Dk34u69LYJRk8kGzu6a7VMYatdDd15z38oenPj2qmzTlgbLgTQY77GRPRJ2Id7CW06/TfmIDqUtxTgd+qzPHC92wNXUP4UoptnEiMNpfpmT1OA6DJfmIfb1srMB3RyY5z8yqYV7wsyDUEvetud2cuCLC3e5qqSBGBnMdQ/PxmVTdq1SdslOwAHYfkMBeZEV+B8CA== X-YMail-OSG: J2TPR5kVM1m8F93HKNG0Tu.zTFvH7mI1IXaptBta28wyLvJJTaxIGWJogxAhY3w T3UwIJ0ljWAD8e04z48oZnAFan97U0FUE2YgrIGhquFbIkMqgC.hhi3owHek6EXIAck4IM_WnW5J p1EzviTT_zw_wyqhPDUs4NVtTGjHB8VPDRlKjvM0diErR0j41.9fACLJ98fXmLUI9CpTR2qDJZ.G VSQJhsqvCRubffVMp8MM9ol6BlPYzOh5Zm1k.kS.oS1hkQ4e59jkAUJiam0P6UdlzBODJUoPPH.V wzf4LkJ9MqYsAxtVIeckTPydeW4.kjIjlTkz2GIPoISdzVAkqKmBG4MBgANIFuvKcbas4fSrtoAy RwPS65rQABbhrMWn3KTgkB.SgnW9Uu.eJaorOs2ehHPOEY2TGXwDnzz6ZGpukfQynVbbId4exZ9N g_RG3uPVmunPUgFzFSY7_ha_4ptPEiRxpXLCC2F0jNhJxsMBHo9df.AHxQQ6yKBa8_DVoU2q_LUE I8Qy9jHffzdDooXyNINOUcmnM6FGs..B6wRXZbM3coLxLeyWb77s1d4x3Yav8UwIH.InmxqyNMRu ajKU1fhGXoe1BXK9JoMVrnP_PKFTi9iUe.AR3fgdhJR2n4df7yW3ue7ngJioS9gQ965axxLDpo0V .nvmeX9aOQhdMB3VDWmlmqSk6GzNk0NWKErdXajoCB8TUFoAuRGW0F1WHdwAwau6gFfWgsvfyO0i tubscuzJynN4qwGC.SP3NiSf.5UbxPGhUeL4I48af_MO63ZeeW9pOLtb5cfltdoYOrC27yCdQfMw TW8bz.QXQDDkfMEt80P0iwRDvHQwDYzvyD4iV8E.0i Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Fri, 17 May 2019 12:35:58 +0000 Original-Received: from 84.88.50.33 (EHLO Ergus) ([84.88.50.33]) by smtp413.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 018563c241cfb90aa4f36e6a522c28e4; Fri, 17 May 2019 12:35:55 +0000 (UTC) Content-Disposition: inline In-Reply-To: <83mujlbgjh.fsf@gnu.org> X-Mailer: WebService/1.1.13634 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.133.41 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:120471 Archived-At: On Fri, May 17, 2019 at 12:01:54PM +0300, Eli Zaretskii wrote: >> Date: Fri, 17 May 2019 07:52:02 +0200 >> From: Ergus >> Cc: help-gnu-emacs@gnu.org >> >> The problem comes when people needs to configure everything because the >> defaults are terrible > >Please don't exaggerate like that, it makes the discussion more >emotional and less useful. Our defaults are not "terrible" by any >account, certainly not when expressed in such a general form. > Sorry then. But I am getting tired. > >> Vim [...] is the only editor that worth to compare with emacs. > >I think you are wrong here. There are VSCode, Atom, and a few others. > Yes, but they are very different and limited in many sense. VSCode extensibility is very limited. And they don't work in terminal, which is my base starting point (because some limitations comes from there) > >> It is easy to explain and I have refereed to this in many maaaaany other >> emails: >> >> 1) vim is there in all the GNU/Linux distros. > >Not much we can do about that. Feel free to lobby distros to include >Emacs. IMO, if something is related to 40-year old decision, it is >this one. > I did actually some time ago and some distributions just replied that the community was too small and the package too big compared to vim, but it could be easily installed from repositories bla bla bla. > >> 2) It works the same in all the systems, in all the languages, even the >> default color themes are better by default. > >Emacs also works the same on all systems. As for "better default >colors", that debatable at best. It's a matter of taste, and >psychologically we tend to favor our first experience: old habits die >hard. > The gui could look much modern with a couple of lines in the configuration. But the first impression now is like a program in windows 95. This is something that an emacs user changes in 10 minutes probably, but for a new user is not trivial. The gui interface is not important at all for me. This is one of the very simple changes that could take 5 minutes to do and 3 months arguing in the mailing list. > >> 3) The keybinds (apart from the insert-escape) are easier, more >> ergonomic and logically composable. >> >> 4) It is extremely responsive and fast to open-close workflows. No >> lagging, or delays, no server configuration needed. >> >> 5) The important editing commands are usually only 1 key far. We can >> make a simple comparison: >> >> Move forward: C-n -> j >> Move forward 3 lines: M-3 C-n -> 3j (look sparsity in the keyboard) >> Copy 3 lines and return to point position: >> C-SPC C-SPC C-a C-SPC M-3 M-w C-u C-SPC C-u C-SPC -> 3yy >> >> Plus: >> hjkl are way more ergonomic than what we have (you can type them >> with one hand, while the other types the prefix, but they are also >> together, so going 3 lines up 5 letters left is way faster and easier) > >If you want to argue that Emacs should be a dual-mode editor like the >vi family, and that this is your "future", then we will never agree. >One of the revolutions that Emacs brought to text editing was its lack >of modality, where you just type text to have it inserted. Dual-mode >editors are a thing of the past in my eyes, a remnant from the old >days when editors didn't have the real-time display, where you needed >to have commands like "move N lines from the current one, then delete >M lines" etc. Please don't even get me (and others) started on this >"feature". > I don't use vim due to the modes. I literally hate the modes. But on the other hand npbf are too sparse and between some keys that modify the buffer when Ctrl is hold (ojd). My real proposes (if any, which is not actually) would be to change those basic ones with jkli, or asdw (it is just an example). Delete redundant bindings like ESC = Alt for prefixes, M-4 = C-u, or the numerical prefixes with alt and C and keep only one. Join similar "opposite" commands like C-o and C-j, or comment uncomment to exploit negative prefix for one of them (so we free a bind and standardize somehow, except C-d and DEL). Reserve one prefix only for user specific functions and recommend the packages not to use that. Enable some extra verbose features when there is not any configuration file and not using -Q (because it is a hint that probably it is a new user or an old user in a foreign machine) (I mean which-key for example) >> Plus: >> In vim the user can enter complete lines/commands/functions: >> >> :e file >> :8,10 s/search/replace/g > >How is this different from Emacs's "C-x C-f" or M-% in the selected >region? Are you saying that it's easier to remember ":e" than "C-x >C-f"?? > Once we entered C-x C-f (which is actually longer and with no associative relation) it is not possible to change mind, go back and do the equivalent to C-x C-v or C-x 4 f (without C-g reenter the new bind and reenter the file). With a ":command argument" it is more familiar for terminal users and is possible to add modifiers to the commands (to easy standarization and reduce memorized bindings)... Add finally an undo and redo, even if it is optional. but have some binding for both. > >And you contradict yourself here: simple text editors all provide >operations on the selected portion of text. Emacs does that, while >vim tells the users to remember the cryptic "N,M s/foo/bar/g" stuff >that goes back to the 50-year old ed(1) and sed(1) editors! > I don't complain about our approach in replace (with transient-mark-mode of course, and there are suggestions there) it was just an example of a very complex command that vim users love for some reason but it is composed by many pieces that work independently with logic, no memory. > >> which is more intuitive and familiar for terminal users. > >"terminal users"? who are those? what's a "terminal"? Are we really >going to target 70-year old curmudgeons that still work on a >'terminal"? why? because vim does that? > >Forgive me, but this is all backwards! Modern users want first and >foremost GUI editors, because you can do in GUI display stuff that is >unimaginable for text-mode environments. > Actually all vim users are terminal users, so they are not quite a few these days, specially on GNU/Linux. Server management, remote access, embedded systems, and core hardware pieces with Linux kernels (routers) raspberry pi and single board computers, High performance clusters don't have GUI. The terminal emulators are still the most popular and important part for GNU/Linux users. And those systems actually are more used in servers than desktop. And looks like it will be like that for a long time. The gui support is a good move, but most of our potential (short-medium time) users are terminal dependents. Packages like i3wm, bash, zsh and low level GNU/Linux distributions (like arch) are very popular. > >> Plus: >> There are no conflicts with the modified inputs and the terminals, so >> they have more keybindings to use. > >Yesh, and you pay by having two modes. No, thanks. > I know, I am just pointing out one of their advantages over our design limitations. I really hate the modes. > >> 6) They do one thing and do it well. Editing functionalities have >> priority (for example column indicator or line numbers were added very >> long time ago.) > >Line numbers are a _must_ in vim, because so many commands _require_ >you to name the line numbers. See your example above. That Emacs >originally didn't have line numbers is because you don't actually >_need_ them so much. > For programming it is a must, actually. Compilation errors and warnings are much simple to find that way. Also, going to a line is the kind of command that must have only a 2 keys binding by default (and probably a behavior like goto-line-preview by default) > >> 7) I understand it is also much simpler than emacs in functionalities, >> but that is a benefit from the maintenance and update point of >> view. They don't need to maintain an interpreter, their own language, a >> graphical and a terminal interface, different modes for every >> programming language, wrapper functions for terminal commands like grep >> (or version control functionalities) a browser, file manager, a server >> interface and client, a network infrastructure... This also means that >> the number of programmers and expert fields they need to maintain all >> the code is also smaller. > >This also means that you can never have a MUA in vim, or an IDE, or a >debugger front-end or anything even remotely similar to Org. Let the >people who want simplicity at a price of a limited editor use vim. It >is not them that I think we should attract. > I mention this because there is too much code to maintain and of course we can't do the best in all those fields. There are external packages (compilers, text web browsers) that at some point we will need to trust them and rely functionalities on them. And other functionalities could be unified (like grep, rgrep and so on to a single general function to call all shell commands and produce the same outputs (we already have that, but still specialize to produce occur like buffers)) > >> I am NOT making apology of vim, I am just pointing how are they doing >> and why they success more with a "worst product" because it is not a >> mystery. > >We don't _want_ success of the vim type. That's the wrong type of >success for Emacs. > Why? > >> >Maybe, just maybe, having "kill & yank" instead "copy & paste" is not >> >the cause of Emacs' lack of appeal to the new generations. >> > >> >> It is one more. > >Excuse me, but this is nonsense. Our menu and tool bar say copy/paste >for at least 20 years, as do the manuals. I wonder when people will >stop beating this dead horse. > In reply to the other email... I proposed to do a survey and functionalities interest question a long time ago in the developers mailing list. I even proposed some initial questions to do. Sent the link of some pages to publish that and finally nobody cared.