From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32564 invoked from network); 26 Feb 2023 00:47:40 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 26 Feb 2023 00:47:40 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1677372460; b=gPk749gZ+GUCu+n7pqupFFigsnzkklZFmzOPZ2/sionNxLRr6zql1sDitLB6rhoICnGcER/cC2 Dg80ZsXbd0GwB8xkJe2x7bsxcdd6LIkeptpgHO3Q8DcffJOunLzXiwpmQqG4v3spEYwOVxyIeM +JG8MXja6zL2QP/deWuLLHK7/4e9zlgL6HjZeShGlcoKHaEKeQOJK7Ht3CqS2cSsL1Efmdwvg6 hPRbbwSCxnin4FZxZzSillpbwTyhCMlc5UnUJ/yEcSuqUsUMms/PG0f/+qK3JH/QuoqgHlMvjr tQ2QhKQsGVvLMYpmW7fZd/n1rkrlHXrlpdJDpxv4gTWbkA==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ed1-f48.google.com) smtp.remote-ip=209.85.208.48; dkim=pass header.d=brasslantern-com.20210112.gappssmtp.com header.s=20210112 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1677372460; bh=j6QuQQM+M20jVwAyFAoRTMFjoHMl0hpXbdJcZ9tacrg=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:To:Subject:Message-ID:Date:From:MIME-Version: DKIM-Signature:DKIM-Signature; b=ayLRMXwnhoFFUXcgF59LAZvmCSA/Lu73tp5Tu2PLPyYGXaBlFeoEPdMxuzbhP6ZbKcpHYdGWiv ecJK0klNrveJDvcpVmhV/ZlKCIadd21zWKzrIXIaLwFu3ThenmJfoOd74YiZgv3VFg1lrrrsiF 5fWvxq3LKtFWAI5t+6YOEz8RFpRJNOka878oozQMbpoqcCbRyZMxviP4QYEJDePDo7hNr55rFO 7gfHkVeR/3pPkiGlfZVnpqzzJ7VLQLh7AGZl4Ve7cZqF/58avU7gPEEExdoP/0tX5SdaTdfgm2 fVk+iQeNZHaHSEwsW2fBq19T6sJ75Zk+hXZnakqRlp14vw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:To:Subject:Message-ID: Date:From:MIME-Version:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References; bh=waSNzpF3W4AVgxqbagtO6VtGCJ/hGs4HRL/9D8JTYCo=; b=ULYcFEDF+PD5Agdd6K7QDySky/ v78R5s8Ki3YJfBrLPYXyx2Jg9xgOzWoAYqDhOQf59+pbJcZUsqAuWDGXllR8aYlDV3A6EZtEZzjZr qeTIZ5w+lz0rYFIzqgv6xZQ3Vuh5kFQqWVmyEsUcmeRzOEAs2dXvugSkxc4XTHi7AOF6dd15zPu+1 0YCPgdErwnkEUpRuUZrK26G9eIshouP2voShilbM55MlN1SzL8qCW7irHF+tzOEKa+bVvo6xw6YUh RYhtiCgeqOIr+x4RJ4P/0JgqPWqtJMpev5aqTzuRcMsQML09QoukyDVo/0iaOif4STDQApUXJcnPQ 8ew1vA9A==; Received: by zero.zsh.org with local id 1pW5CV-000Hdx-AE; Sun, 26 Feb 2023 00:47:39 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ed1-f48.google.com) smtp.remote-ip=209.85.208.48; dkim=pass header.d=brasslantern-com.20210112.gappssmtp.com header.s=20210112 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-ed1-f48.google.com ([209.85.208.48]:34537) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1pW5C9-000HNN-JH; Sun, 26 Feb 2023 00:47:18 +0000 Received: by mail-ed1-f48.google.com with SMTP id cq23so12117784edb.1 for ; Sat, 25 Feb 2023 16:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=waSNzpF3W4AVgxqbagtO6VtGCJ/hGs4HRL/9D8JTYCo=; b=ft7xEfSvWKyDUQUEgVgn41wIPQgVrwh1OddFTu7Yry/XR7FmWbsrEYW4LwaLwTKdDH mNRPYgRqu8LWkGlE+iUZfx0UXMcNTHKArXPNQlg934fvZdyM3fL4tCt5fj+ZxSO1IJ8K TBE4HDNDi5/1hEuCqsskSROpgKeWFLHmDFPUGc5QDPVAFi66khjPE6k8u3YT/0xu4cMr rOv1pJomnGXDwzkHDiNYBX39O14uYAg+A4b+771A+OqMRWkkjnObv/ZuS8iEyncbIIjT h+XSZXmRXiikBlqwX1UQEnXyidd8a+Q+5m/zOj4+Mw9vk7dKufHVdL9En0hzkWxZoiVr zxBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=waSNzpF3W4AVgxqbagtO6VtGCJ/hGs4HRL/9D8JTYCo=; b=Mwi7xGfcFv8WUqs35+K2sDQ+xrzQYnffJN0LvLL0qrBKWzrjg0FhCdxbVRTZ5fO8Qu VZxT11y2MxamXcm1P5HuwHKm/M7vfP2p7xY406YnGpuMrAXd+vuBuzlRV4cyvKuQhlY5 cqbRRPb39P4eNmr8Etie60vNlFXXsne4MzN5sdgKS4YTtZhhMEjF69uLIB77hv141n/F TzrHmFgjJdl+udJHTtBr0rLLE9ieDB4ptIJr7iYOJp8vH8Uplw1WiLIz8bX9cFjCeYF8 NK/O6y/da52PSz/ggagB/bRFqtxXjAYgFk8SMdViw58aadK5xotBY1CVLV5D264+6ddD 4fDA== X-Gm-Message-State: AO0yUKX4syxgDwZP8ELx+PRxQihaTP3/AeL1KQDO5hZVNnS0QvB2HtWC aQjSfjYSiLckFqodgGhJs+mWuVN2wjAv5+DNq4zKV44SnSWt069i X-Google-Smtp-Source: AK7set+e3/FZHnAgm5TEGYhrEn7Y8HzPcR80iiWipL9BNJqGBqBW1Ta3xwHhQ/aiAGPLmK8yox4NTnQZBW9g7BEX67k= X-Received: by 2002:a17:906:ce59:b0:8b1:7e1b:5ec1 with SMTP id se25-20020a170906ce5900b008b17e1b5ec1mr13959825ejb.6.1677372436595; Sat, 25 Feb 2023 16:47:16 -0800 (PST) MIME-Version: 1.0 From: Bart Schaefer Date: Sat, 25 Feb 2023 16:47:05 -0800 Message-ID: Subject: Misc. module stuff To: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 51481 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: It has been a while since I worked on a module and the last one had only one autoloaded builtin. This is stuff I've noticed while working on a more complicated case. The .mdd file provides two ways to declare autoloads: autofeatures autofeatures_emu The former are loaded in zsh native mode, but the latter are loaded in every other emulation mode. This means jumping through some complicated hoops to, for example, autoload something only in "ksh" emulation and not in "sh" emulation. Further, it's implied by zsh-development-guide that it's not possible to have a .mdd where autofeatures is empty but autofeatures_emu is not empty. Is this intentional? It seems necessary to duplicate autofeatures in autofeatures_emu if there are any items that should be autoloaded in both cases. Speaking of zsh-development-guide, it says: - PARAMDEF() gets as arguments: ... - optionally a pointer to a variable holding the value of the parameter - a GSU pointer to the three functions that will be used to get the value of the parameter, store a value in the parameter, and unset the parameter The part about a pointer to a variable holding the value is only correct if the GSU pointer is NULL or the setfn is explicitly expecting a pointer-to-object (which the default one does). This can be fixed by editing the document. In zsh.h there is a comment * ... Parameters used in a module that don't * have special behaviour shouldn't be declared in a table but * should just be added with the standard parameter functions. This can also be added to zsh-development-guide. However, parameters mentioned in autofeatures must be declared in the tables, or an error message results at module load time: zsh: module `zsh/example' has no such feature: `p:exref': autoload cancelled Is there no correct way to declare a feature that is enabled only via the setup_ function? Curiously even after that "cancelled" message, referencing a different autoloaded feature might reload the module again, successfully. Quoting dev guide again: The function named `boot_' should register function wrappers, hooks and anything that will be visible to the user that is not handled by features_ and enables_ (so features should not be turned on here). It will be called after the `setup_'-function, and also after the initial set of features have been set by calls to `features_' and `enables_'. As far as I can tell this is false: boot_ is not called after setup_, only once after the initial call to features_ and enables_, and is not called if features_ "fails". The admonition that features_ and enables_ might be called multiple times is correct. One of the things I think it is useful for a function wrapper to do, is to create local parameters in the function scope. It took me quite a bit of experimentation to figure out how to do this, because startparamscope() is not called until after control has passed out of the wrapper. The trick is: * Increment locallevel * Call pm = createparam(name, PM_LOCAL) to get a Param pointer * Assign pm->level = locallevel (this, I was not expecting to need) * Set the value of the parameter * Decrement locallevel again. This is all best done inside queue_signals/unqueue_signals. Don't forget to decrement before calling either runshfunc(...) or return 1; A drawback to doing the above is that if the user writes a function containing "local foo" for some wrapper-created local "foo", typeset will print out the value of that variable.