From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Fri, 17 May 2019 12:01:54 +0300 Message-ID: <83mujlbgjh.fsf@gnu.org> References: <878sv7sp3r.fsf@telefonica.net> <83r28z8zl9.fsf@gnu.org> <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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="97151"; mail-complaints-to="usenet@blaine.gmane.org" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri May 17 11:02:24 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 1hRYky-000P3j-OM for geh-help-gnu-emacs@m.gmane.org; Fri, 17 May 2019 11:02:24 +0200 Original-Received: from localhost ([127.0.0.1]:44844 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRYkx-0002Pl-PL for geh-help-gnu-emacs@m.gmane.org; Fri, 17 May 2019 05:02:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRYkc-0002Ly-8o for help-gnu-emacs@gnu.org; Fri, 17 May 2019 05:02:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39021) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRYkc-0000eB-5d for help-gnu-emacs@gnu.org; Fri, 17 May 2019 05:02:02 -0400 Original-Received: from [176.228.60.248] (port=2065 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hRYkb-00019d-6d for help-gnu-emacs@gnu.org; Fri, 17 May 2019 05:02:01 -0400 In-reply-to: <20190517055202.ted62gt6hqcip7xt@Ergus> (message from Ergus on Fri, 17 May 2019 07:52:02 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:120462 Archived-At: > 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. > 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. > 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. > 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. > 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". > 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"?? 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! > 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. > 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. > 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. > 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 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. > >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.