From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Sun, 19 May 2019 15:38:19 +0200 Message-ID: <20190519133819.6ymsyl4x37zy7fyd@Ergus> References: <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> <83pnogalhk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="268479"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun May 19 15:38:53 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 1hSM1d-0017lp-BG for geh-help-gnu-emacs@m.gmane.org; Sun, 19 May 2019 15:38:53 +0200 Original-Received: from localhost ([127.0.0.1]:48957 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hSM1c-00083z-Az for geh-help-gnu-emacs@m.gmane.org; Sun, 19 May 2019 09:38:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hSM1J-00082u-Hg for help-gnu-emacs@gnu.org; Sun, 19 May 2019 09:38:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hSM1I-0005ov-5a for help-gnu-emacs@gnu.org; Sun, 19 May 2019 09:38:33 -0400 Original-Received: from sonic304-22.consmr.mail.ir2.yahoo.com ([77.238.179.147]:35996) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hSM1F-0005m2-Da for help-gnu-emacs@gnu.org; Sun, 19 May 2019 09:38:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1558273105; bh=tv/Z6nbFchWINajDf0plWeX5gWaCSPmTlte0swILqSk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=m+D3o7uxAmkTyrKycCdE3SgoTu0R3mUT7eVyAhr5d2PKkfK00DD1tpfUUZOLW+Bxf/ytK1EEjwckY/2R4ma9oLbffEMgieBBgn0e8hg1c0SVjMcMKiCIN1A03Zfu2wtwulzyTwpPGBYPBakX+KeI/pXL0V9EaBMKWtKQqxtZHzEVLh6TzsqFXEzxheJwvzKBJUFz81xShskyyFfw1/YKGIyJnUCBBnOpuvTpzuVl9qgu/O3QFDbRSfvil7QXNtUOVYOi5/mWH/H2uz/a6+udQaJ1DMiVFNcbsMxtKB9ccQp9UlW/6Vt6OBBU34uSwskNEnG0P578bBdeYKWu+4H/PQ== X-YMail-OSG: DeqiNQYVM1nRhpKW.rMAfiP8CsSjec8aHndnEPAmGnMgLeJK1xp06TTLzXeth9L grnMSxYz_Vhv8QAGacX3pSgpqT6I7jT3LfWoUy4QObYL3hbaVWjjOvN83qQCWuLEdkzh7GxlzwfT .Sb5lV9aAUfuaIF10risAFtEh4TcBRiPdVkNNGhxAevGrC.fy6y3e.LkjgRo_k_uwO7a.kty8PGj jxdKvx.dY6yWLw6Bk7eIn_qJth5OtTBl_M2iwZ9BCj2GTWSR_msEVVNKOmnPweKQ4uJc3yO2ODba 8iieIY9kVLSTmlBj53Px5y.NMUug238F9CZ2QbHXZLzXhl21PlF2Hdn7Xlt5pQsQYyPzPLXGAlf3 JQFY_WBM6NYMfFq.lyyUOgOzeS0O5BRuwhI2zzZ_qGaW4R31eO7DoXzckMnHqHufkdFpZUDRbYzD lD80p_WwAxytyvx_3QWlP5Iag1r4oJ7iq4XMlYp3ez9_uOfecJqgUDt_NJDrP_d4nd3onhf3i8cR rYUaaglWWvmUeLN5oPFxkXqHTBO9PvYruHd68gSilVLpuM.Tzybgb0orcYI4iCAALc8xU1Dtinp5 Jh_Dg5mfFXygTYwSXLBRoxlgyJLKHnwbXAFr.LFqmXYZLTB9vJxR94hzsScnTAJpPxQEU_M_kCe0 X27vzkQiLcIqAi6XRW10FFm9J9deSAnNGboQqOZCaTFq23IYksH9ThwIVpumBryc9iayUhLF0roM sV2N_5Kdh._O.8cuP6X4hznEUwA_in1KrUA_QGwo7Vq.7bt5K2EzmNjecIoCIaEs0XhFKwJ2qdA2 9O99gRW50.mtuavldjF2X5iZypAeXxcfsPhz0fprUh Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ir2.yahoo.com with HTTP; Sun, 19 May 2019 13:38:25 +0000 Original-Received: from 2.152.205.184.dyn.user.ono.com (EHLO Ergus) ([2.152.205.184]) by smtp423.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 703dc7073033318023dd184a343f6cd6; Sun, 19 May 2019 13:38:22 +0000 (UTC) Content-Disposition: inline In-Reply-To: <83pnogalhk.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.179.147 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:120544 Archived-At: On Fri, May 17, 2019 at 11:12:39PM +0300, Eli Zaretskii wrote: >> 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. > Actually my proposal in this point was just to find a way to release some bindings. It was not even a real proposal at all, just an attempt. What is clear is that all the bindings are set and we talk about new features without binding (or a plan to bind them). Y made all the possible questions, case sensitive bindings, release some of them, make a C-a go to indent and then to beginning of line... anything to have some more place without create longer bindings. >> >> 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. > So why C-mode, message modes and others bind commands there. Then the user does not have a reserved place confident to no create collisions. >> >> 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. > That's the perfect choice (utopic), with the actual number of maintainers, ignoring whats already in melpa (that is a lot of community work and time improving) I think I am pessimist about the materialization. > >> 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. > The new methods standards and systems complexity grows faster and in many directions that what we can maintain updated enough in the core. It is not a theoretical problem, it is a practical limitation. > >> >> 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. > OK, different workflows. >> 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 true, but in the mean time that's what we have and some bugs need years to be solved. This in fact is a consequence of the C++ support limitations we were mentioning before in this threads. > >> >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. >