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.0 required=5.0 tests=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 540c7b88 for ; Sat, 4 Jan 2020 16:28:46 +0000 (UTC) Received: (qmail 24073 invoked by alias); 4 Jan 2020 16:28:40 -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: 45233 Received: (qmail 20361 invoked by uid 1010); 4 Jan 2020 16:28:40 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25677. spamassassin: 3.4.2. Clear:RC:0(66.111.4.25):SA:0(-2.6/5.0):. Processed in 4.516037 secs); 04 Jan 2020 16:28:40 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeghedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfffgrnhhivghlucfuhhgrhhgrfhdfuceougdrshesuggr nhhivghlrdhshhgrhhgrfhdrnhgrmhgvqeenucfrrghrrghmpehmrghilhhfrhhomhepug drshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <63663202-4b1d-428a-b16b-5be1425e84ef@www.fastmail.com> <0C0C9775-59EE-4FBB-AB84-3E7FEF6E5024@dana.is> <186D63AE-2F2A-41C3-9E09-CEE0714E2B7F@dana.is> <12F64C78-BFA2-460C-80D4-921F22C72F78@dana.is> <1578063609.4581.6.camel@samsung.com> <20200103204856.bv6f3dkqhtrjm6vm@tarpaulin.shahaf.local2> <54205248-124e-4e9a-942f-7ff0626791a6@www.fastmail.com> Date: Sat, 04 Jan 2020 16:27:34 +0000 From: "Daniel Shahaf" To: "Zsh hackers list" Subject: Re: Official plugin manager? Content-Type: text/plain Roman Perepelitsa wrote on Sat, 04 Jan 2020 15:46 +00:00: > zle -N zle-line-init my-zle-line-init > > This works. Until we source a plugin after setting up bindings and the > plugin happens to hook zle-line-init without calling our hook. This > time it's the plugin breaking our code rather than vise versa. That plugin is broken. Plugins shouldn't overwrite whatever had been hooked to zle-line-init before they were sourced. That's no more acceptable than for a plugin to rm(1) files that it didn't create. I know of two solutions. One, plugins can wrap my-zle-line-init (using ${widgets} to discover it). Two, add-zle-hook-widget may be used. > The alternative to this rather complex and brittle approach is to bind > beginning-of-line to several escape sequences. "Hard cases make bad law." Don't design the system to DTRT even when plugins remove random files; just fix those plugins, or don't use them. > > Obviously we shouldn't go crazy with it, but i don't see any reason to > > specifically limit the use of styles. The style system is an important aspect > > of configuring zsh. There are very useful settings that can only be changed > > that way, and it's important for users to know about it if they want to make > > their own changes. > > Oh yeah, I've nothing against styles. I wanted (but failed) to make a > point that the basic config shouldn't attempt to provide the best > possible shell experience at the expense of config complexity. If 12 > completion style lines give you only slightly better completion that 2 > lines, it may be preferable to go with 2 lines. When the user's > complexity threshold is exceeded by the config, the whole thing > becomes opaque. A slightly worse but simpler config may result in > better long term user experience as the user will be able to customize > it. Well, yes and no. You're right that new users shouldn't be overwhelmed with complexity right off the bat, but that doesn't mean we can't have any complexity at all; we just have to label it appropriately so new users won't try to dive into it on their first day. For example, in zsh-sensible we could, say, create a "zshrc.history_options" file that walks the reader through the 25 (!) history-related options, and have zshrc point to it as a "further reading" resource. [It may very well be that few readers will ever open that file. That'll be an indication that it's working as designed. :)] I've done this sort of thing before in presentations (put the table of contents in the margin of each slide, with chapter titles being hyperlinks, and click them to skip past entire chapters). It's even been done in print: for example, The TeXbook called this "dangerous bends". Cheers, Daniel