From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id a7ab763d for ; Wed, 31 Jul 2019 13:35:13 +0000 (UTC) Received: (qmail 2423 invoked by alias); 31 Jul 2019 13:35:06 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44624 Received: (qmail 1224 invoked by uid 1010); 31 Jul 2019 13:35:06 -0000 X-Qmail-Scanner-Diagnostics: from mail-io1-f42.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25524. spamassassin: 3.4.2. Clear:RC:0(209.85.166.42):SA:0(-2.0/5.0):. Processed in 1.645573 secs); 31 Jul 2019 13:35:06 -0000 X-Envelope-From: roman.perepelitsa@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.166.42 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yFV81HANlHIVPc9ajM3AuqIKtKXD6wc/nZEG1A0WNYA=; b=cgWVVYGJt5Gza6q1jhWlBvMHeKITaNY24pix/Y97ASgGRyDJUAgBsY6XUtQx8lqKTC tmMrpQTYT9EpvqHnbQDmfDfpvkgDXF2/zo0aKpPY39fRDP/xlDfD3LZqwuCkp2ifjzpb WN93U0JPvZb1OAT8dsxIzcjILT5zcSC1jxvTO3XcFUfByK0Ki8MWfsOXPck20r9IiqZE OhCZoATb82G4v/xwxrfQSHa8zAwYC17LEeQyds5Nv03LrIc/Hc6m8b8UDKnu2p73kT/4 nA2uz2Po/iOLff3Zunrfzh7bCqBOCGzYEWtUe/0p+k4PRaBm+tKeKlTeewUlXlmm2OCU SiDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yFV81HANlHIVPc9ajM3AuqIKtKXD6wc/nZEG1A0WNYA=; b=g091M8dxaod1Uqb2JVALA23Od6y2wf6hF2ExgV4yBbMfgiOgqs0CT2bRXhcycctiaG NPsnTx+ESrJiYAZcLuFeBQHBvAVLuGIW1kfB+jFHRLsU3SaMMuiF6Vm0X6+xN4G5/UTs 2LSWzqN8zzT/l9BSUFBaCZG6MKfIRovq8rKn4l3itdQxhAaIcpDhk5D9FmIPm0VrGrU1 6FoGtksepAfsFr4MiakzKofcDyDeA3vQ1beYSwLk9hsU0y7EjpWunKiT7k0vM/lvDk6V YHMb4J4UzwOR9eJ/sIticoX2c0k7zHEWGjXAZceTTzSulFxUUY49O6RlNIfIH5F8L+AL S29g== X-Gm-Message-State: APjAAAWfw1GH6e8mrJ7VUZtC7qwgDUk+izGr2vnASJdMlavlNVfHi2oO NZzqCQcIQAuN3yM17dztv3uWFpGQUcu5waU8vq84C31OKBhPGg== X-Google-Smtp-Source: APXvYqxElpsLk31eWozXyvkyiTBwiivXmOiMB+tfQJEfuuchsyAwslx0f3hTAibztka3jurJQP6Z6u/NoK2pb/0JwEE= X-Received: by 2002:a05:6638:cf:: with SMTP id w15mr47885795jao.136.1564580071870; Wed, 31 Jul 2019 06:34:31 -0700 (PDT) MIME-Version: 1.0 References: <49013421-774e-4389-a25d-680f1d97a8ef@www.fastmail.com> In-Reply-To: From: Roman Perepelitsa Date: Wed, 31 Jul 2019 15:34:20 +0200 Message-ID: Subject: =?UTF-8?Q?Re=3A_A_serious_bug_in_execution_=E2=80=93_where_to_debug=3F?= To: Sebastian Gniazdowski Cc: Daniel Shahaf , Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Wed, Jul 31, 2019 at 3:10 PM Sebastian Gniazdowski wrote: > This particular case will be solved if the plugin will use > add-zle-hook-widget instead of wrapping (support for this isn't yet in > zplugin, but it'll be there soon). Unfortunately, using add-zle-hook-widget is no-no. If you use it while other plugins are still wrapping widgets old-school, you can cause infinite loops. All plugins have to be switched to add-zle-hook-widget at the same time, which is pretty much impossible. Hopefully someone will care enough to fix add-zle-hook-widget but the benefits are difficult to see. Wrapping widgets works fine. It breaks zplugin's unloading code but the same can be said about pretty much everything. > To sum up, your opinion is a mathematical-like proof that: > > * You cannot implement an unloading that just works as expected. > > While my opinion is a practical-view -like point that: > > * You can often get good results with unloading, just try & test it > first with the plugin that you need to unload. Both statements are true. What I don't like is the implication of offering a maybe-works-maybe-doesn't unloading mechanism. It creates an expectation that plugins must be unloadable not via their public APIs but through brutal and unceremonious deletion of their internal parameters, widgets and so on. If something breaks during unloading, users may not even realize they've grown to rely on hacks and that their shell configuration is unsupported. They can reasonably reach out to the "malfunctioning" plugin's developers and ask them to fix the "issue". It's like selling rocks as a tool to turn off TV sets. Just throw a rock at the TV and it'll turn off! If it breaks your TV, please don't complain to your TV manufacturer. I also have intense emotional reaction to this kind of unloading. It just feels rude to modify internal implementation details of software. It's one thing to do it with code that only you yourself use, or to apply this sort of dirty patching to a product you are intimately familiar with, but it's quite another to distribute this crude tool as a feature. It's disrespectful to the developers whose code is brutalized, and it causes extra strain on them due to bug reports by the affected users. Roman.