From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg via help-gnu-emacs Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Thu, 30 May 2019 19:58:16 +0200 Message-ID: <86muj33juv.fsf@zoho.eu> References: <20190514235412.kncazq45szlum2gr@Ergus> <83v9yb92c7.fsf@gnu.org> <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> <83y335bnui.fsf@gnu.org> Reply-To: Emanuel Berg Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="37336"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu May 30 19:58:52 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 1hWPKG-0009bK-A8 for geh-help-gnu-emacs@m.gmane.org; Thu, 30 May 2019 19:58:52 +0200 Original-Received: from localhost ([127.0.0.1]:57417 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hWPKF-0007Yk-9W for geh-help-gnu-emacs@m.gmane.org; Thu, 30 May 2019 13:58:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hWPJz-0007XS-7p for help-gnu-emacs@gnu.org; Thu, 30 May 2019 13:58:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hWPJw-0000vE-Am for help-gnu-emacs@gnu.org; Thu, 30 May 2019 13:58:35 -0400 Original-Received: from [195.159.176.226] (port=36360 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hWPJw-0000u1-3D for help-gnu-emacs@gnu.org; Thu, 30 May 2019 13:58:32 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hWPJs-00098G-Ug for help-gnu-emacs@gnu.org; Thu, 30 May 2019 19:58:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Cancel-Lock: sha1:V3O52c1wNtw2ye2L65RVa7a8as8= 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:120706 Archived-At: Eli Zaretskii wrote: > OTOH, many, if not all of the features you > say were proven in other editors we already > provide in Emacs. If you are saying it took > too long for Emacs to adopt them, then this > is an argument about the past, which is again > not useful IME. That's exactly right: the past is the past and nothing can be done about it. The future will come when it comes, no doubt. So only the present is up for grabs! So get as good and meaningful a grip as you can, I'd say. > We will not attract new users by providing > just a text editor. There are way too many of > them out there, and it's very hard, to say > the least, to be significantly better just in > that class. We must find our own niches, and > be one of the top players in those niches. But: we have already found our own niche, and that is to be *everything*. This explains why we aren't the best at every little programming language out there. That would mean to be superhuman - which (except for the X-Men) is impossible. > It is very hard to discuss this stuff in > a useful manner when your arguments are so > abstract. In general, the (alleged) reason > for the current defaults to be rooted in some > obsolete technology, if that indeed is the > case, doesn't necessarily mean those defaults > are invalid today. The discussion of the > defaults should be on a case by case basis. It is much easier that way, most definitely. > [...] disruption of keyboard-only > workflows, etc. And that in particular we never want to disrupt! :) > Since you didn't say what TEXT EDITOR should > entail, it is again very hard to discuss this > claim. From my POV, we do provide a text > editor OOB: you have the usual arrow keys, > PgUp/PgDn, copy/paste by mouse, a menu bar > and a tool bar with items most users will > expect, scroll bars, simple edit commands > like delete-char bound to keys users expect > them to be, F1 for Help, RET which indents > when appropriate, etc. ...? Is this the definition of a text editor? If so, perhaps we should come up with another category name for Emacs... > The main IDE features cannot be implemented > in modules. They can use some external > support functionality via the module > interface, but the features themselves must > be in Lisp. ...? Cannot there be Lisp modules? What "module interface" or type of module are we talking, exactly? > We don't even have a coherent framework for > such features at this time. CEDET was > supposed to be it, but judging by the fact > that no one is developing it, and, on the > contrary, what little development we have in > the IDE area is bypassing CEDET, I'm > beginning to think that maybe that decision > was a de-facto mistake. CEDET - ah, yes, I've heard of that (now). It means "Collection of Emacs Development Environment Tools" [1] > People are welcome to scan MELPA packages and > suggest to their developers to submit them to > Emacs. Shouldn't stuff from MELPA be moved to ELPA first before it is moved into Emacs? :) [1] http://cedet.sourceforge.net -- underground experts united http://user.it.uu.se/~embe8573 https://dataswamp.org/~incal