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 21:24:29 +0200 Message-ID: <20190517192429.maibexmwcr56mlky@Ergus> References: <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> <20190517123551.vumasyoyr5bv5voq@Ergus> <835zq9b4vi.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="98888"; 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 21:39:46 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 1hRihj-000PV2-Pw for geh-help-gnu-emacs@m.gmane.org; Fri, 17 May 2019 21:39:44 +0200 Original-Received: from localhost ([127.0.0.1]:52948 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRihi-0000vt-RA for geh-help-gnu-emacs@m.gmane.org; Fri, 17 May 2019 15:39:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRigS-0008Tg-42 for help-gnu-emacs@gnu.org; Fri, 17 May 2019 15:38:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hRiTB-00061c-I9 for help-gnu-emacs@gnu.org; Fri, 17 May 2019 15:24:43 -0400 Original-Received: from sonic310-14.consmr.mail.bf2.yahoo.com ([74.6.135.124]:44045) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hRiTB-0005yp-78 for help-gnu-emacs@gnu.org; Fri, 17 May 2019 15:24:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1558121079; bh=NHczWmYA2jBlM+R1l6TMs4ZVBYqJjztAD2q0zCoYRVk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=bl3ksZsJop9rOSUNvpUdkQh29P/WASYXR4V2SyXdG9ZDZ4PqQwIgdLcX6Hodx4RrO8BgjhuU2EdEqAA52BVg+Ro57dHUYYWpHxCY4qsE6nE3eCT4/YPMOJTnVLZj5pN44oqrJnWfwxpYlzhj8Nzhy/llkACYziOLpHAsBDqtHtnb9aAl69JHYBLUsz39Esvtw982Sb8fNsQkuZv7L64Eeq/LWXlzshtQWI59HE1LxwS6ieJv1cO4NT41YfogdyNgg1+MQcQy5KDbB3tokk6mZolMw8g+XoPvW6pnOOwoajwfj5lhNjKCe4Ps9IN1Bg4glsvA/w1nNy45nyrcxT2IPA== X-YMail-OSG: nRuP1uIVM1mhwZSjYtDscS8uTgZSZy.abDxhfVpkAC3.0HvI1i.DOIrJTkDv.VY GJzWFxiYjM2L3QRSmpgKsy1iGa3maMuSU0u_l813Btep17b.tRgF.Gg1_418jQDX1a8ZQ7BwtDER U5odQFKimmmi_3UDlsVVgzP9fCOqZYzxXE_5dYPm1I1u2FurtRN_0XD3OIKqlzBggX3JrwX1oZap beKXYuhSd4xcbzNVqiQEKop6TRbvxj7ceM.FkVVdgODhaqgvNevXOjf4pLRY05dASENiG2dwEVWP GyKZ2E38LCNGGL9VwVWHSU2ch1H9F2B3_mgKNWzTnFWaxAwuxKXDjMnHuYEnVMyBDLraVMaytRKN seYXJc9Y1GFpXvVIpwcxPcmGa59KEd_Om5VhFpTnng9Seg48qBpx.ze7Ni3W50SHGCkOVKi9sabv jDjNNH5JSVhhI_vcGgOoKY3jIwXUPak2JLeDRtXJEIZ2l44cnH2lwqK6z5DwUZ1sR.zWRuL1MRpB PKmhkTOS9Y5fKa4ASMmdOkHQzelNuWrmXztop1b5rRaF52ToJaPI8oSZYikq34Aqx.vgj8mtZKxg b8LLT12fQwZmVyGPBarpY2JLY8mmWigiXkoItM8rzWQiupU5Hp13ivA7HS8HFGiEZYk6TzEgs_pN eJYxmrXgBeU5DAxsKDVGaDFV6Xil1kqFRZerb8dQIGxrIhD4_fk2z8QkaCzjLycaSYjWpLL.VWTO o5PuLGAziubE5b_CSgv_Dw.jAZFTKLulIVAF53ZXnfxUaJ7SReZXozFr6jFroYyI_EbBG0.Jz86y h1zwQYavp3l2ap0BTExdRt_e0opT68qAWjSUv1bRzl Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Fri, 17 May 2019 19:24:39 +0000 Original-Received: from 84.88.50.33 (EHLO Ergus) ([84.88.50.33]) by smtp417.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e59dc14db602bbb3f4641dfe04f96d5d; Fri, 17 May 2019 19:24:35 +0000 (UTC) Content-Disposition: inline In-Reply-To: <835zq9b4vi.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.135.124 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:120510 Archived-At: On Fri, May 17, 2019 at 04:13:53PM +0300, Eli Zaretskii wrote: > > >Is an Emacs installation really significantly larger than a Vim >installation nowadays? > In arch Linux: 39M /var/cache/pacman/pkg/emacs-26.1-2-x86_64.pkg.tar.xz 1.5M /var/cache/pacman/pkg/vim-8.1.1186-1-x86_64.pkg.tar.xz 5.6M /var/cache/pacman/pkg/vim-runtime-8.1.1186-1-x86_64.pkg.tar.xz >> 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. > >Then I guess you are in a minority. Certainly among newcomers. > Most Linux users are very terminal lovers. Actually many mac users like mac because there is a bash shell, and even MS added the BashOnWindows for a reason. > > >In that case, I don't even understand why you brought that up. Not >having modes comes with a price, and IMO it is not too high. Once we >all are on the same page about this basic fact, we should stop wasting >time discussing it. Arguing for a change in basic bindings like C-f, >"C-x C-f", etc. is a non-starter, the community will never agree to >something like that. > I know, but still those they are uncomfortable distributed on the keyboard. Now that the TKL keyboards are becoming popular again is not a good idea to rely on the arrow keys too much. >> 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). > >This is not going to fly, no way. > I know that's why the "(if any, which is not actually)" was added. >> Delete redundant bindings like ESC = Alt for prefixes, M-4 = C-u, or >> the numerical prefixes with alt and C and keep only one. > >This will cause more keystrokes in some cases. E.g., if the binding >is Meta-something, the M-digit binding is very handy, and the same >with commands that are Control-something. > I still don't know any user that uses the numeric arguments for common commands. But I know this won't change either. > >> Join similar "opposite" commands like C-o and C-j, or comment >> uncomment to exploit negative prefix for one of them > >This is not ergonomic for frequent commands (witness how you exempt >DEL from this scheme), because typing the prefix too frequently is >painful. > > >Anyway, which other editor does that? They all have different >commands to DO and to un-DO. > They use C-z and C-S-z for undo-redo. That's why I asked in other email about case sensitive bindings. Same for many others. >> Reserve one prefix only for user specific functions and recommend >> the packages not to use that. > >That's C-c, which we already have. > But some modes sets commands there like message mode, so the user needs to care not reassign any in all the modes he uses. And sometimes there are collapses (personal experience) >> 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) > >What is which-key. > https://github.com/justbur/emacs-which-key >The idea to be more verbose is an interesting one, but I don't yet see >what kind of implementation do you envision. For starters, where will >the extra text come from, and where and under what conditions will it >be displayed? > https://github.com/justbur/emacs-which-key https://github.com/abo-abo/hydra These are good starter points. Abo-abo actually holds a copyright already. And all his packages modernize emacs a lot. >> Actually all vim users are terminal users > >Then I don't think we should be too interested in those, when we >describe modernization of Emacs. > I disagree, specially considering that the GNU/Linux OS is our main destination. Else we need to center more in MSW (no coherent with free software promotion, but also, in that case, the cua-mode must be default, because C-x C-c C-v C-z are the standard there for everything. And we won't convince any average MSW user to change that. > > >> The gui support is a good move, but most of our potential >> (short-medium time) users are terminal dependents. > >That should be backed up by some statistics. I don't think it's true, >but even if it is, it just is one result of us lagging behind in the >IDE department. > We just need to consider the statistics of the users who use emacs (including spacemacs) and what OS they use. Linux for desktop is sadly a fail in the short medium time, but the number of GNU/Linux users keeps growing (very slowly, but growing). And the most popular distributions are not the most fancy-desktop-oriented ones. At the moment we can't compite as an IDE for comercial software, so the probabilities that a 20 yo MS user chose emacs over VS or androidStudio are very low compared to a Linux user that is developing backend, embedded systems or HPC. And also the door for windows is opening with Azure and BashForLinux. > >> >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. > >I disagree. > This is a deadlock ;p > >> Compilation errors and warnings are much simple to find that way. > >Our compilation-related features make that entirely unneeded. > If we use only C, yes, but in PHP (where an interpreter server produces a log), Python mode (that the script is sent to an external terminal) or Latex projects (built in latexmk), or fancy compilers like Rust... in general we end up opening a terminal (in or outside emacs) an building by hand. CMake project are difficult to set up as they use out of sources compilation for everything and in tramp mode the remote compilation usually needs to set up environment or lmod modules dynamically ... The compilation engine can't be optimized/configured for all those cases. If we do for 300 use cases there will be 300 more at the moment. > >> 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) > >Why would one need to go to a line by its number, when you have >fast-movement commands like "C-u C-u C-n"? > This is a joke right? ;) xdisp.c is a good example: long file, long functions, lisp variables in the button and macros on the top. Another example is how imenu fails in C++ mode when there are classes and namespaces in a long file. So for going to a function isearch or line numbers are the only alternatives. > >> >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. > >That's the price, yes. But removing valuable features to make the >maintenance easier is IMO the wrong way of solving this problem. > It is the only really scalable solution I can see in the medium-long term. And it is not applicable to everything of course. But maintain everything, add new complex features to compete with specialized applications already available that has been corrected and upgraded among years I don't think will never work (Unix principles imposes here, do one thing and do it right). We will not create a better Lisp compiler that specialized projects that center all their effort on that. Or gtags or a shell. It is impossible and unneeded. > >> >We don't _want_ success of the vim type. That's the wrong type of >> >success for Emacs. >> > >> Why? > >Because we are a different kind of beast, see above. >