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:47:29 +0000 Message-ID: <877cmg4pxa.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="1336"; 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:45:33 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 1r3wLs-000062-Ha for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Nov 2023 11:45:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3wLD-0002TW-Gj; Fri, 17 Nov 2023 05:44:51 -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 1r3wLC-0002TH-AW for emacs-devel@gnu.org; Fri, 17 Nov 2023 05:44:50 -0500 Original-Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r3wLA-00023X-Js; Fri, 17 Nov 2023 05:44:50 -0500 Original-Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2c6ed1b9a1cso22661641fa.3; Fri, 17 Nov 2023 02:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700217886; x=1700822686; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7f9FbeOlySlmIXosSYM/i0dNqOKzEGCokcA/MiXL97g=; b=ZRodFLXKE5GLV/3NvyBMckFNUvOQzdAiOlPDkPCGgCYodjzIhiMu+gyzwGbG0n5u4S xBAdUM/xTJ9IKXsAT7Likx4Z9pmURGBD59vI7AXJVQf+wG28CKDicu6yzv4BRmNrdzl9 qnFMXFc02ZXL0HPEDntkhykgMRtVuj1qTG9gw9XxwQOriGqdzbaq+XTMqefqDme0LXGI ClOzSNL6MchopaQnB4rqoTjewfltDOrIsCCRn6YzVlFK3idcIXPwQ7hb23C/6b43RfMO z7H2s4tlS6Q1cLvWqM1UQAocDL8+HR1KNvveZQ9DLzXgUtUNT/wsxcg25tYtQZCr6HS5 fXvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700217886; x=1700822686; h=content-transfer-encoding:mime-version:message-id:date:user-agent :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=j1KXA/8X+rhucDAPTOZAMSCzwEdnx+SUrTk8rZmaad4VdUkE9k6GTqH2wUdJNqoF3N KVo55NP0w+YlsNEiU05OJb4c7Z4SDG4794Hs7ad8K3DusBVDGTaiQ8NmNKXWarf+Y+7H NL1/+z5g2hxZFU+zm3z0aFsUqoQL+avyz8Los7PXjCbqr4STIH+ZjaO8pX0fTyAgp+/l 9pY6Cr7Z+0o67lq6QJZJ5LKot4cc+ZPJgFXr80OCKFKkVXxp4K0/e1WyTP0bY/cA9oQm 6YrbkQZxZVjX1EHUeo3mozsE8LI2FWbWphpclcG2MLDlIs/sAJbzTw7tcVpY3vlxgz9b rVhA== X-Gm-Message-State: AOJu0Yy58HsNqFC0WA0SCu/js8D1Kd6vH8FOOY+155vyVVI0CoNuAUzN +4ELlifOBEg45E1DMcy3aPMeSJ+TOPMI6Q== X-Google-Smtp-Source: AGHT+IF2wV4X820vqtxaHwXZm/tB0pcFIC0lBPx7EYlNdpgVRqQQEt7Y4YymOreFZmIq5ZZ+6w+waQ== X-Received: by 2002:a2e:88da:0:b0:2bd:102c:4161 with SMTP id a26-20020a2e88da000000b002bd102c4161mr9160504ljk.43.1700217885849; Fri, 17 Nov 2023 02:44:45 -0800 (PST) Original-Received: from krug (87-196-72-132.net.novis.pt. [87.196.72.132]) by smtp.gmail.com with ESMTPSA id k42-20020a05600c1caa00b003feae747ff2sm6838328wms.35.2023.11.17.02.44.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Nov 2023 02:44:35 -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::233; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x233.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:312863 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