From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Wed, 15 May 2019 13:57:36 +0200 Message-ID: <86r290szf3.fsf@zoho.eu> References: <20190514235412.kncazq45szlum2gr@Ergus> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="235191"; 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 Wed May 15 13:58:05 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 1hQsXs-000z2L-Lp for geh-help-gnu-emacs@m.gmane.org; Wed, 15 May 2019 13:58:04 +0200 Original-Received: from localhost ([127.0.0.1]:35745 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQsXr-0004rQ-N8 for geh-help-gnu-emacs@m.gmane.org; Wed, 15 May 2019 07:58:03 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQsXb-0004r7-8z for help-gnu-emacs@gnu.org; Wed, 15 May 2019 07:57:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQsXZ-0000yY-R3 for help-gnu-emacs@gnu.org; Wed, 15 May 2019 07:57:47 -0400 Original-Received: from [195.159.176.226] (port=42864 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hQsXZ-0000xP-Ip for help-gnu-emacs@gnu.org; Wed, 15 May 2019 07:57:45 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hQsXX-000yaX-A1 for help-gnu-emacs@gnu.org; Wed, 15 May 2019 13:57:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Cancel-Lock: sha1:ey++MoxyECz6ujXbYGoM+mDVOEE= 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:120376 Archived-At: Ergus wrote: > I go every time to the same topic here, but > all the time I only receive complains and > strong answers with strong feelings from the > older users. Well, if you ever feel you get an unpleasant answer from me, tell me immediately, thru an off-list mail if necessary. > We NEED to update the interface (unify the > bindings for all the languages, unify > packages with similar functionalities, delete > unused functionalities.) It is not a should, > it is a must. Hey, man, relax. We don't need to do anything and we certainly must not. We need food and clothes and shelter. If you feel that what you mention is so important, start working on it today! It is much more rewarding and less frustrating that trying to convince others you are right. But as/if you do, please do continue to tell us all about it, of course. > To mention just one example: It does not make > sense that C-c C-c comments the current lines > in C-mode, but sends the current sexep to > terminal in other modes, or send the messages > in others. So emacs somehow behaves as > a different tool/editor for 3 different > modes, so the "unified bindings/behavior" is > not an advantage anymore. Well, Emacs isn't consistent in that sense. I think it never will be. I don't see a huge advantage having it consistent either, if that is even possible, actually I see many disadvantages to it. If the `C-c C-c', which is a short and close (i.e. fast and good) shortcut, if that is always to do the same thing, many modes that do not do that _at all_ will be one short, close, and fast shortcut, eh, "short" (... :)). Besides, people are used to the shortcut! Changing them to have potential future generation of Emacs users have a more consistent interface will just make tons of people, who already use Emacs every second day, unhappy. > Or that we provide several options (or > packages) to add parents with 300 > customizable variables but a very bad default > behavior. The existence of spacemacs > ergoemacs and other similar customization is > a user's scream for better defaults (I am not > telling to ennable all what spacemacs does, > but we have functionalities that the users > will never discover if they don't go in the > ddeep parts of the manual). Find a spot and start working, is again my piece of advice! Start small and post on gmane.emacs.devel and see what happens. Keep posting here as well tho. It is much appreciated if you ever got the impression it isn't. > Usually the old users (who deserve the legacy > behaviors), are also the most skilled ones, > so it is easier for them to add some lines to > their config, than for new users that we > don't want to scare the first day with Lisp. Not all new users are that afraid! Some think Lisp is awesome and that is a big reason they came to and stayed with Emacs. What one can do with Lisp, in terms of Emacs, but also in terms of Lisp itself, and actually even the very language, Lisp, itself! Emacs user's contribution to the Lisp world is huge. > Sometimes new users also mix languages, but > the worst supported ones are the newer > languages (Lua, Julia, Ruby, Python, C++ 11+, > Rust) Which are also what they need > more often. Again, pick your favorite of the ones you mention and start working on what you think is lacking! > But also there is the fact that we are > spending a lot of effort/work/manpower in > specific use cases and fancy functionalities > (web browsing, pdf reader, image shower) > instead of looking and prioritizing the > general and basic editor functionalities OK, let me tell you straight off without being unpleasant, I hope, this is a complete dead end for you. Don't go there. Because we *want* Dired, Emacs-w3m, Gnus, ERC, and everything else! Just as much as we want the programming modes. There is no contradiction. On the ... contrary :) > What happens now is that if a user wants > a simple editor with indentation support and > syntax highlight for multiple languages I'm not following? We have that. > The program grow an grow and grow and the > unused/old/substituted/unsuccess > functionalities weren't deleted. IMO things that work should _never_ be deleted. If it isn't used, like ever, perhaps move it to ELPA. But don't delete it. > And as a plus the Elisp language and > interpreter, two more things to maintain > and update. Again, it is there because we _want_ it! > So, in spite of our product is better [...] Is it? The way you talk of it one would think you wouldn't think so? But I agree, of course :) -- underground experts united http://user.it.uu.se/~embe8573