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 23:12:39 +0300 Message-ID: <83pnogalhk.fsf@gnu.org> 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> <20190517192429.maibexmwcr56mlky@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="249414"; 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 22:13:07 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 1hRjE1-0012fp-J5 for geh-help-gnu-emacs@m.gmane.org; Fri, 17 May 2019 22:13:05 +0200 Original-Received: from localhost ([127.0.0.1]:53277 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRjE0-0000EA-1v for geh-help-gnu-emacs@m.gmane.org; Fri, 17 May 2019 16:13:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRjDo-0000Dl-A8 for help-gnu-emacs@gnu.org; Fri, 17 May 2019 16:12:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33288) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRjDo-0003KT-7r for help-gnu-emacs@gnu.org; Fri, 17 May 2019 16:12:52 -0400 Original-Received: from [176.228.60.248] (port=4353 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hRjDi-0001P8-Md for help-gnu-emacs@gnu.org; Fri, 17 May 2019 16:12:48 -0400 In-reply-to: <20190517192429.maibexmwcr56mlky@Ergus> (message from Ergus on Fri, 17 May 2019 21:24:29 +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:120512 Archived-At: > Date: Fri, 17 May 2019 21:24:29 +0200 > From: Ergus > Cc: help-gnu-emacs@gnu.org This discussion is going nowhere useful. So I'm going to respond just to a couple of minor issues, and let's just stop and agree to disagree about the rest, okay? (Personally, I'm amazed you use Emacs with such ideas in your head, excuse my being blunt.) > >> 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. I didn't mean "undo" literally, I meant "do-SOMETHING" and "UN-do-SOMETHING". Every editor I've met has different commands for action and counter-action, while you say we should have a single command that does both. Of course the fact that undo and redo have different keys only confirms my point, and refutes yours. > >> 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 This is a tangent: you said "reserve one prefix", and I pointed out that we already did. > >> 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 ... That just means we need to extend our support for those other languages. > 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. I disagree with this, I see no reason not to extend our support to more languages as needed. We are doing that constantly. > >> 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. And you go there by line numbers? Meaning that you remember by heart the line numbers of those places? Me, I use M-. instead, and occasionally M-C-s and M-> (a.k.a. C-END). I don't really care on which line number these variables and functions live. > 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. No, the alternative is to improve the features that fail to find what they are supposed to. > >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. I see at least one more: make the developer team larger. Which is actually happening, albeit slowly. > Unix principles imposes here, do one thing and do it right That's not applicable to Emacs, since Emacs is not a tool, it's a programming and text-editing environment.