From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?7KGw7ISx67mI?= Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Sun, 19 May 2019 23:57:21 +0900 Message-ID: <63DACECC-2F87-44BB-8421-BD5582C7DB87@icloud.com> References: <20190514235412.kncazq45szlum2gr@Ergus> <83v9yb92c7.fsf@gnu.org> <878sv7sp3r.fsf@telefonica.net> <83r28z8zl9.fsf@gnu.org> <20190515210924.sijzy6mnpgzkt4gm@Ergus> <86a7fjnwdq.fsf@zoho.eu> <20190519130051.jhxjwa3yoba3yf4r@Ergus> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88995"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Van L , help-gnu-emacs@gnu.org To: Ergus Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun May 19 16:57:48 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 1hSNG0-000N2Q-9B for geh-help-gnu-emacs@m.gmane.org; Sun, 19 May 2019 16:57:48 +0200 Original-Received: from localhost ([127.0.0.1]:49769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hSNFz-00048S-9y for geh-help-gnu-emacs@m.gmane.org; Sun, 19 May 2019 10:57:47 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hSNFg-00048A-MI for help-gnu-emacs@gnu.org; Sun, 19 May 2019 10:57:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hSNFf-0000f4-73 for help-gnu-emacs@gnu.org; Sun, 19 May 2019 10:57:28 -0400 Original-Received: from pv50p00im-ztdg10022001.me.com ([17.58.6.58]:51463) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hSNFe-0000eH-UN for help-gnu-emacs@gnu.org; Sun, 19 May 2019 10:57:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1558277845; bh=ldt1i/JbXkWHlkclc2AzbrXILdJAbyEOn+j43lOL3R8=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=zLdvURlkUy9i3Cog5CecEd7cHX5agq+Kpvu43YssmJdEeLTcDQUSc3ydAmDKbsx0N toz85FKh6EQVh5+C33uZf/w7n+ap3ZozXWdfuAjsJeq2cZizj/1iz29nsOwBPfI1tN eAzkhGWuODANGkXqqFac5we0GZVEXcOWRfvPxNbrpd9ZFc59BMpf4x2YA8aFLnDKOl Br8lgAxAhC1o9Q2805u103rQFzMGgI93qsMsJ60Lv10mYq5BYc9xOKpMsTAEjCiPmZ 7OTn6YPV6W03OqpdHAJP23TLJ6vQ7uyAThGYqR4t6VcYDt8tVY3Rb5bbGaQiudPWR0 AiW+mDrcs0y7Q== Original-Received: from [192.168.0.11] (unknown [1.230.108.64]) by pv50p00im-ztdg10022001.me.com (Postfix) with ESMTPSA id 7775FA03DF; Sun, 19 May 2019 14:57:24 +0000 (UTC) In-Reply-To: <20190519130051.jhxjwa3yoba3yf4r@Ergus> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-19_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905190109 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.58 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:120550 Archived-At: > 2019. 5. 19. =EC=98=A4=ED=9B=84 10:00, Ergus = =EC=9E=91=EC=84=B1: >=20 > On Sun, May 19, 2019 at 07:35:58PM +0900, =EC=A1=B0=EC=84=B1=EB=B9=88 = wrote: >>=20 >> 2019. 5. 19. =EC=98=A4=ED=9B=84 5:16, Van L = =EC=9E=91=EC=84=B1: >>=20 >>> Emanuel Berg writes: >>>=20 >>>> Ergus wrote: >>>> I don't consider myself an Emacs expert - >>>> far from it. But I've been here for 10+ >>>> years, so I'm happy with my Emacs and my >>>> skill level. But this place still >>>> doesn't feel like home! That is strange. >>>=20 >>> Is it possible to have the best of all possible >>> worlds? >>>=20 >>> For conservatives, a winter release of old gold keybindings. >>> For the free radicals, a spring release with modernizations. >>=20 >> What if having a compatibility-mode that can be activated by = something like: >> ```elisp >> (classic-keybindings-mode 1) >> ``` >> and refine the default keybindings to be more consistent/mnemonic? = People who miss the old keybindings will be elisp-proficient; Adding 1 = s-exp to the init file won=E2=80=99t be a barrier. >> For the refined keybindings, Spacemacs can provide a good starting = point. >>=20 > This is interesting. (of course spacemacs not in evil mode). Yeah, of course evil=E2=80=99s keybindings can=E2=80=99t be a starting = point; I was saying that spacemacs classify most keybindings in a pretty = consistent way; we can be inspired by that. > I will just tell an idea I had (before knowing how things work in = emacs, > I actually thought it was implemented in that way) >=20 > If we create a single file with the full list of general bindings as > variables for all the main modes like >=20 > ;; Basics >=20 > C-a begin-line-binding > C-e end-line-binding C-b go-backward-line-binding C-d = delete-forward-binding > ... >=20 > ;; Prog mode > C-c C-c whatever-you-decide-binding >=20 > ;; Minibuffer mode > bla bla bla > ... >=20 > And so on. >=20 > All the derived modes can be changed to use the variables instead of > hard-code the bindings in multiple files. >=20 > this: > (define-key c-mode-base-map "\C-d" 'c-delete-forward) > will be: > (define-key c-mode-base-map delete-forward-binding 'c-delete-forward) >=20 > This is similar to use remap, but with some advantages: >=20 > 1) The bindings will be organized in a single file and the collisions > will be exposed easily. And fixed for all of them. >=20 > 2) In case a mode adds a new functionality and it needs a binding, it = t > in the global map, it will be clear if some others already have a > similar one and will bind to the same using the same criteria. If the > binding has never been used, it will be added to the list for future > modes that wants the same functionality. >=20 > 3) Old users will be minimally affected because the starting criteria > are the actual bindings. >=20 > 4) Implementation of test modes (like ergoemacs or evil-mode) and = future > modifications will require less effort and the final experience will = be > less hacky than now.. >=20 > 5) If a user personalize a binding (changing the value of one of these > variables) the changes will apply to all the packages and modes she > uses in his section. >=20 > 6) If the user wants to use remap or hard-code the binding (as now) = the > actual behavior will be unchanged. >=20 > 7) Packages like elpy, irony, or company will also use the = "binding-list", > so the user will only learn the most specific bindings (if any) so > external packages will be standardized with minimal effort. >=20 > 8) Future bindings changes that the community agree will not require > changes in the files of all the modes. With the potential side = effects. This, at least for me, feels like a fantastic idea :-) IMHO the point of this is that we can now have a list of functions that = are common between modes; which will help users having a coherent = experience and provides package authors a minimum start point to provide = a pretty-good experience. > I know that proposing this here is a crazy idea, but the intention is > not to start a crazy war again, If it is crazy (for technical reasons) > just ignore it. Actually I just mention it because it seems to me like > something extremely simple-advantageous and maintainable. With minimal > affections to the user space. >=20 > But remember that we have a limited number of bindings so managing = them > better is important if we want to find place for new functionalities. >=20 > In any case I will leave this threads as it is not going anywhere (as > usual with this topics) and what is obvious for me seems to be heretic > for the rest. But you are free to consider the idea if it has anything > useful for emacs.. >=20 >=20 >>=20 >>> When I use a long M-x sequence, a shortcut suggestion appears. It = disappears before I can catch it. Can it stay for 30 seconds? Can there = be an instant interactive override to set it whatever you like? >>=20 >> I would like a semi-AI that suggests interactive functions based on = key presses or actions the user performs... `You can use C-e = (goto-end-line) to perform 12 keystokes you performed.' >> Saying about discoverability, I would like a context-sensitive = right-click mouse menu, something like Microsoft Office. Most newcomers = are familiar with finding functionality with the mouse; and it isn=E2=80=99= t intuitive to find new keybindings/functions that Emacs provide to = boost productivity. (Actually, that=E2=80=99s one of my problems; how = should I find new functions...?) >>=20 >>> Evolutionary programming of popular custom keybindings collected at = upstream and put thru obstacle course competition is one way of = composing a spring release. >>>=20 >>> -- >>> =C2=A9 2019 Van L >>> gpg using EEF2 37E9 3840 0D5D 9183 251E 9830 384E 9683 B835 >>> "The interface is a nightmare." - Brendan = Schaub