From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: how to speed up Lisp devel time Date: Fri, 09 Aug 2024 15:54:40 +0200 Message-ID: <87a5hl4x9b.fsf@dataswamp.org> References: <87y156413v.fsf@dataswamp.org> <86sevekvjy.fsf@gnu.org> <87v80a402y.fsf@dataswamp.org> <86ikwakmdg.fsf@gnu.org> <87frre3pxa.fsf@dataswamp.org> <86ed6xlx9r.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9095"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:MI9kJ1bNQj1j1aryslKaF6z3o14= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 09 16:52:36 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1scQyq-00027n-Ci for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Aug 2024 16:52:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1scQyA-0004pb-Tu; Fri, 09 Aug 2024 10:51:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1scQ59-0003ce-QM for emacs-devel@gnu.org; Fri, 09 Aug 2024 09:55:03 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1scQ57-0004mr-PM for emacs-devel@gnu.org; Fri, 09 Aug 2024 09:55:03 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1scQ55-0001Fy-Uf for emacs-devel@gnu.org; Fri, 09 Aug 2024 15:54:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 09 Aug 2024 10:51:53 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322574 Archived-At: Eli Zaretskii wrote: >>> This is rather unusual, and you should expect to have some >>> more-than-normally complicate code in that case. >> >> What do you mean? It is the same for `forward-line' >> >> C-u M-x forward-line RET >> C-u 4 M-x forward-line RET > > No, it isn't. forward-line accepts a numeric argument, and > that's all. All you need to do to support that is use the > corresponding 'interactive' code. Okay, bad example. What about this one, then? C-u C-u a aaaaaaaaaaaaaaaa C-u 17 a aaaaaaaaaaaaaaaaa >>> Also, someone pointed out that you could write this in >>> just 83 characters. >> >> Really? Well, well, let's see the code then! > > It was posted, I just counted the characters. Here is the original code [last], I said it was 402 chars but excluding the initial whitespace every line it is 376 chars. One can make it shorter here and there, but to write that in 83 chars of Elisp - well, let's see it. BTW that interface isn't complete/optimal I see now, there are more stuff, also uncontroversial as you will see, that I can add. Maybe later. Right now - conceptually, not thinking about the details - it supports * Interactive use with M-x, including C-u M-x and C-u x M-x. * Default values, for the _function_, not the interfaces. * Verification of all args, again for the _function_ and not for any particular interface. >>> That usually makes little sense in Emacs. Interactive and >>> non-interactive uses have different semantics. >> >> Same default for any kind of call makes little >> sense. Usually! >> >> I OTOH thinks that is the first policy I can think of. > > Then your code is unlikely to be accepted into Emacs. The default values I speak of here isn't the default of any particular _interface_, it is values for which _the function_ - regardless of interface - can fall back upon if the value is unset. I know that isn't at all any kind of radical or original thought, it is a very basic idea and I don't care if you - based on how it is done in Emacs - disagree. >>> That happens, but very rarely. Well-designed clean code >>> should avoid that. >> >> It is better if everyone, well-designers or not, could use >> a clean interface to do that. Then one could simply use it >> and not having to rely on people writing great Elisp >> for everything. > > Code doesn't write itself. Good design is always needed for > elegant code. The Emacs design in this case isn't good. In fact it is a mess. The interactive and non-interactive stuff are both tangled up sometimes and parallel sometimes. The functions should not be branching mid-way based on that and there shouldn't be a separate set of functions for this or the other interface. "This is for interactive use" and all. Interactive/non-interactive should _only_ matter in setting up and executing _the interface_, after that the functions should run the same based on the present data, regardless of how that data is obtained. Just imagine if we were to add a third interface? Would be branch on that mid-way into functions as well, and have a third set of functions, just for that interface? But be that as it may, the way you do it with the `interactive' format string still isn't good - not powerful enough, which is way so often people have to use Lisp instead. And, too cryptic in that tiny string which makes it error-prone to write, and difficult to read. [code] (interactive (if (numberp current-prefix-arg) (list current-prefix-arg) current-prefix-arg)) (unless end (setq end 73)) (unless step (setq step (min 10 (max 2 (/ end 10))))) (unless i (setq i 0)) (unless (and (numberp i) (<= 0 i) (numberp end) (< 0 end) (numberp step) (< 0 step)) (error "Bogus indata")) -- underground experts united https://dataswamp.org/~incal