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: Tue, 14 May 2019 19:21:04 +0300 Message-ID: <83ef519fdb.fsf@gnu.org> References: <20190502214006.4fdsinp7u5xuqvdv@Ergus> <20190503004416.xfuzzucflp6bxpuz@Ergus> <8736lm30lz.fsf@web.de> <864l61j04d.fsf@zoho.eu> <20190511073254.GB29829@tuxteam.de> <04187AB9-AD7D-492D-A890-BCB01848370C@icloud.com> <20190511075712.GD29829@tuxteam.de> <86a7fsfv1m.fsf@zoho.eu> <20190512075448.GA11650@tuxteam.de> <346107E9-590D-4A18-9152-ECFF36FC4EDC@icloud.com> <83r293bvok.fsf@gnu.org> <87ef53vihw.fsf@telefonica.net> <83mujrbsk7.fsf@gnu.org> <867eavywh1.fsf@zoho.eu> <837eaubesw.fsf@gnu.org> <86lfzawgb2.fsf@zoho.eu> <83y33a9y10.fsf@gnu.org> <868sv9w8t4.fsf@zoho.eu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="148410"; 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 Tue May 14 18:21:51 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 1hQaBY-000cIF-P6 for geh-help-gnu-emacs@m.gmane.org; Tue, 14 May 2019 18:21:48 +0200 Original-Received: from localhost ([127.0.0.1]:50848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQaBX-0003Fx-Km for geh-help-gnu-emacs@m.gmane.org; Tue, 14 May 2019 12:21:47 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQaB5-0003E3-7i for help-gnu-emacs@gnu.org; Tue, 14 May 2019 12:21:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38863) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQaB5-0005ue-5X for help-gnu-emacs@gnu.org; Tue, 14 May 2019 12:21:19 -0400 Original-Received: from [176.228.60.248] (port=2769 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hQaB3-0002P4-NJ for help-gnu-emacs@gnu.org; Tue, 14 May 2019 12:21:18 -0400 In-reply-to: <868sv9w8t4.fsf@zoho.eu> (message from Emanuel Berg on Tue, 14 May 2019 13:54:15 +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:120370 Archived-At: > From: Emanuel Berg > Date: Tue, 14 May 2019 13:54:15 +0200 > > _also_ I certainly don't feel there is > _anything wrong at all_ to "to go to the shell > and invoke pdb as a console program." Modern debugging front-ends show multiple windows every time the debuggee stops: a window with the source, another with local variables, yet another with callstack (a.k.a. "backtrace"), one more with program input/output, optionally threads and registers, etc. Displaying that on the console requires the user to type separate commands for each display, which is time consuming, and also pushes the other stuff off the visible portion of the console window (so you need to retype the same commands, or scroll the window with the mouse, to see that again). So using a debugger from a console is much less convenient, when you deal with a complex program, and users nowadays expect much more from an IDE. > >> And we want more language-specific features > >> like I guess Java has with Eclipse or C# > >> with .NET/Mono? > > > > They are not language-specific features, they > > are in general features needed in any language. > > OK, FTR "needed" isn't a word to my liking... > But what I mean is they are language-specific > in terms of how one would go about and > implement them. font-lock and `forward-char' > and much of Emacs isn't. Actually, font-lock needs to be customized for each language, and there are commands that move by functions, blocks, and other lexical units, which also need to understand the language to some extent. IOW, someone must write the code to support each language with the infrastructure provided by Emacs; if we didn't write that, we cannot claim we support the language "because the tools are there". > Because I can't imagine you want all the same > little helpers for every single language > there is? Not sure what you mean by "all the same little helpers", but in general every language needs its own variety of the same "helpers", yes. > > No, we don't disregard anything. But having > > Dired or the other niceties is little comfort > > if what you need is to refactor your code or > > debug it. > > Right, but when we compare our editor to the > supposedly superior ones [1], I mean. They are > perhaps better IDEs in terms of > _a single language_, but we are the better > (the best?) "IDE" in terms of the > whole computer! This argument doesn't fly with users, because newcomers usually need just one language, but they need a good support for it. They will go away if we don't have it, and telling them we support a dozen others will not make them change their minds. To keep Emacs alive and kicking for the observable future, we need to be sure we will have enough developers and contributors. And since developers and contributors start as users, we want to attract new users. If we fail to attract them, we will quite literally lose our future. > I never used those tools so I don't know what > I'm missing. Programming in Emacs I've done in > some 20ish languages with no problems - not > form Emacs, at least :) > > Sure, I didn't do it with a deadline, a 40+h > a work week, a deadline, and a I don't know how > many digit salary. And this is probably part of > the difference. I think a more important factor is the size of the project you work on.