From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Fri, 17 Nov 2023 10:44:29 +0000 Message-ID: <878r6wlkvm.fsf@gmail.com> References: <83wmuowwp3.fsf@gnu.org> <8334xcwank.fsf@gnu.org> <320999cc-6c83-2315-0044-cc0403400af3@gutov.dev> <9ab5d2bd-a648-cae0-a4a7-ae86be10af0f@gutov.dev> <87r0kuqxbf.fsf@gmail.com> <54e115a2-fc36-3056-a030-0dbf32416ddb@gutov.dev> <43f290b0-4119-597b-c89a-0fb4c7db1665@gutov.dev> <87bkbtn79k.fsf@web.de> <87wmuhpxxv.fsf@gmail.com> <87v8a1lodp.fsf@web.de> <83msvdps4k.fsf@gnu.org> <83cyw8q35d.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29566"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: michael_heerdegen@web.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 17 11:43:07 2023 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 1r3wJW-0007Sz-RA for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Nov 2023 11:43:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3wIb-0000pb-Gg; Fri, 17 Nov 2023 05:42:09 -0500 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 1r3wIZ-0000pD-Q6 for emacs-devel@gnu.org; Fri, 17 Nov 2023 05:42:07 -0500 Original-Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r3wIY-0001kM-2p; Fri, 17 Nov 2023 05:42:07 -0500 Original-Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-509c61e0cf4so2598029e87.2; Fri, 17 Nov 2023 02:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700217722; x=1700822522; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7f9FbeOlySlmIXosSYM/i0dNqOKzEGCokcA/MiXL97g=; b=MmMTTaJajkIJ5uuxY6vIyGly4lRZQYYGBkMPNjIzKjpRutWiwfVFTNoFc/Y4M0o/nC ZOenDbu/jVKLEXhnFwbszfjjntdIh9rNecnU80bcKu11YaHnkKC1+nINd+LoAoogoOIl R4diYrd8K+5T9l045/evIMxSuylx2lsoyV4+op8ZjLR4memn+g/HbSftKK2IWGo04n/Q hQOhopUFihU+qPdcQrtdBzxIUJSTiq6mtufuxUFIop+uaZ5byq1DQVdYDAyusoi51Kue zK4Q1O6zjv0fjL+EyZVJzCWRTXCCeRl5LdryxJSTfvgWaZdEFJ6KACJthMUqceZra9SP 9QEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700217722; x=1700822522; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7f9FbeOlySlmIXosSYM/i0dNqOKzEGCokcA/MiXL97g=; b=YejORGd4mLOcogZhcemUnloQ0PwgEt1EQxqzAIvjXjYUXwMd3+lNRhdMVu8gP3w2Z6 xk405bamLnEe10+s3Uhn4FcPtBR9n25WVmdP2Y4q27X3MM5knjlugRyR/mhY2xExwGkW aC4uY3tU972DcSUmoieWnV8U6iuoY6sKhOENMmasd41PozKXsnndKf+2TSrbQNZ8D1rz 7vIrMfSc2z/mO58cv+MiV1T7hQcaRwBxY5JNPCIbJWzaadBEIn2sBDfWEw0MsSLtg6f+ izrnq+uIYXJfn/hSjnvHrSkvDJeOmSyz+ZWRGO0qHvlWRyIJ8cYAJlCCi31dRulAfZwB yzxA== X-Gm-Message-State: AOJu0YxB9VX91hiXgyAub4xHfzc2CWP65a6xI6AoDAOEnxm7Olix82Yl e7mrXURNhMc1bfGh2ptSxlWCAawMw4TxzQ== X-Google-Smtp-Source: AGHT+IEZ3SAVq4glld1F2NE71C1o5mGSVFQyjGijGP2rqqUDdkymS/iOkjKDO8ncVxuq4U8yqrB08Q== X-Received: by 2002:a19:6705:0:b0:501:c779:b3bb with SMTP id b5-20020a196705000000b00501c779b3bbmr11912919lfc.60.1700217721673; Fri, 17 Nov 2023 02:42:01 -0800 (PST) Original-Received: from krug (87-196-72-132.net.novis.pt. [87.196.72.132]) by smtp.gmail.com with ESMTPSA id r12-20020adfda4c000000b003232380ffd7sm1876108wrl.102.2023.11.17.02.41.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Nov 2023 02:41:32 -0800 (PST) In-Reply-To: <83cyw8q35d.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 17 Nov 2023 08:56:14 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::12e; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:312862 Archived-At: Eli Zaretskii writes: > Such improvements are always welcome here. I just answered your > original question, viz.: > >> > seq.el's documentation is where? I don't see it. > > which seemed to imply that you didn't know at all that we have seq.el > functions described in the manual. Sorry, I should have been clearer. I was talking for some while in this thread about API implementor's documentation, a description on how to _extend_ seq.el to define new sequence types, not how to _use_ it in programs to process sequences. > Feel free to suggest improvements and additions to what we have. I've been doing that. But it still feels like some people are not convinced that that documentation is essential at all (you seem to be one of them, reading further). And before this manual is written down, we have to come to an agreement of exactly what guarantees seq.el gives the user who wants to extend it for new sequence types. > Do you see something like that in other Lisp-related manuals we have? Yes, for my part see Flymake, Eglot and JSONrpc manuals. They're not great, but they each have a section on how to extend the library to provide new diagnostic backends, new request handlers and new JSONRPC transports, respectively. > Does cl.info has this information regarding cl-lib? I think the answer > is NO Of course, and that's obvious. cl-lib is not extensible. >, because we generally don't say such things in our manuals, Of course we do. See 21.6.7 * Programmed Completion:: Writing your own completion function. It tells you how to _write_ a completion backend. The instructions on how to _use_ completion functions to complete things are elsewhere. I use this part of the manual all the time, and so does everyone else writing a backend. We've been upholding that contract very well for a number of Emacs releases so, we don't break backends willy-nilly. I recently added an optimization (completion-lazy-hilit) that doesn't break anything (AFAI and other reviewers could tell). > except in rare exceptional cases Huh, is Flymake rare and exceptional? I see a lot of backends popping up that (correctly) take inspiration from the manual describing how to extend Flymake. > (which the seq.el one isn't, IMNSHO). As far as I could gather from this discussion, seq.el is to be recommended to users as the preferred way to process sequences in their Lisp programs, most any program, including basic facilities in the core. I have shown that performance aspects of this library, even when applied to primitive data types such as lists and vectors, vary in accordance with the presence or absence of other custom sequences, because of the GF-based nature of seq.el. The nature of these custom sequences changes the magnitude of the impact. So IMO it is wise to explain to users exactly what custom sequences are and aren't supported/recommended. Jo=C3=A3o