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 09:24:05 +0300 Message-ID: <83y335bnui.fsf@gnu.org> 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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="193962"; 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 08:24:29 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 1hRWI6-000oHX-HB for geh-help-gnu-emacs@m.gmane.org; Fri, 17 May 2019 08:24:26 +0200 Original-Received: from localhost ([127.0.0.1]:43094 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRWI4-00086v-V9 for geh-help-gnu-emacs@m.gmane.org; Fri, 17 May 2019 02:24:24 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42038) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRWHt-00086n-IY for help-gnu-emacs@gnu.org; Fri, 17 May 2019 02:24:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRWHt-0000EJ-Fz for help-gnu-emacs@gnu.org; Fri, 17 May 2019 02:24:13 -0400 Original-Received: from [176.228.60.248] (port=4157 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hRWHs-0000Tt-Qd for help-gnu-emacs@gnu.org; Fri, 17 May 2019 02:24:13 -0400 In-reply-to: <20190516202327.5cgy2s4kppy3ahxa@Ergus> (message from Ergus on Thu, 16 May 2019 22:23:27 +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:120457 Archived-At: > Date: Thu, 16 May 2019 22:23:27 +0200 > From: Ergus > Cc: help-gnu-emacs@gnu.org > > My point of view since the beginning of my first email ever in the > mailing list was based in 3 things: > > 1) Some design choices and limitations in the actual emacs were imposed > due to technology 40 years ago. (keyboard bindings, coding system, > screen resolutions, memory available and CPU, network latency, storage > capacity) but most of them are not issues anymore (at least not in the > emacs scales) so we are limiting the potential of emacs due to issues > that disappeared long time ago. > > 2) Many new features and functionalities (pure editing oriented) have > been introduced/proved/improved in other editors, and they have proven > to be useful (move line, initial configuration, associative bindings, > specific key combinations like in cua-mode, undo/redo and many > others). > > An important part of those functionalities are can be implemented with > Elisp in one afternoon probably because they are just details and some > are already available as external packages, but the changes never arrive > because there are not available (practical) keybindings or because of > backward compatibility. 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. I can assure you that if the _only_ reason for having a default is that alternatives don't work well on obsolete systems, there's no chance in the world someone will be reasonably against changing them. IME, usually there are other significant reasons, such as incompatibility with Emacs conventions, disruption of keyboard-only workflows, etc. 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. So if you want to have a useful discussion about these matters, I suggest to come up with specific contemporary examples of features that illustrate your POV. Otherwise, these just empty slogans for me, sorry. > 3) The development is not focused in the first thing that a user needs > when she opens emacs: provide the most comfortable and useful TEXT > EDITOR. 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. If you are saying that these basic features are not enough, then a useful start would be to come up with a list of additional features that new users are looking for (but please don't try to make your point by deliberately making a list of features we don't have; this list should be the result of either polling users or some kind of survey of popular text editors). We could then discuss their introduction into Emacs in an intelligent way. > If emacs as TEXT EDITOR does not convince them (just the first try, > without config, without reading the manual/tutorial/documentation), then > they will not even try any other functionality. I think that you are one > of the few in this list who sees the importance if attracting new > users/developers. 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. One of those niches should IMO be multi-language IDEs, but there are others. > For example, many people use nano just because the basic actions are in > a button bar, so they don't get stocked and they can do the basic stuff > quick and fast, no installation no config needed. Emacs has the same. > Look at the spacemacs community and how many members are there wrapping > emacs functionalities to behave like in vim... Doesn't prove anything to me, sorry. People who like spacemacs should be free to use spacemacs, but it tells nothing about those who don't, of whom there's quite a large number, AFAIU. > >Personally, I wish people would invest much more time and efforts in > >adding new features, and would stop futzing with existing features. > >For starters, the former is much more useful for our users than the > >latter. Also, I see many times how a change in existing code to make > >some minor improvement introduces bugs, which sometimes are more > >significant than the "fixed" problem -- this is expected in a complex > >stable program, and is a clear sign that changes of existing code long > >since entered the area which engineers call "the limit cycle" -- > >oscillations that don't converge, i.e. the overall code quality is > >quasi-constant. IOW, we are wasting our own resources for little or > >no gain. > > > I would support that the functionalities go in elpa (I say elpa because > it won't need an initial configuration to be used, just list-packages > and install). Before we decide where the functionality will go, we should have it in the first place. It currently doesn't exist anywhere. That's the main problem; the location of the packages is secondary. > Also improve the modules API and support to create packages with C as > with elisp. 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. 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. > >> Just give a look how many good packages are in melpa, but not in elpa > > > >If you are saying that those packages are in MELPA because they were > >rejected to be included in Emacs or ELPA, then I'd be very surprised > >to learn that this is true. I think the vast majority of those > >packages started up with MELPA and their developers never tried to > >submit the packages to be included in Emacs. > > > No, I am saying that there is a reason why they made their work, and > they maintain it, but they don't spend time to put it in the official > repository. People are welcome to scan MELPA packages and suggest to their developers to submit them to Emacs. If indeed the reason is what you say (and I sincerely doubt that), we will have many of them in Emacs/ELPA in no time.