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,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26539 invoked from network); 28 Mar 2021 20:51:46 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 28 Mar 2021 20:51:46 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1616964706; b=Qt6oXRdLwn9vlpSgJYQdQGGXOXr3ADVG3MNiblJZuCgFKPzZcDmf6Gkct68dKFBrvdVYCrkZvY gb0ZIBnJyzrFgJjfXFgQPU/RhCcCP415kK+iM6Md1A8TL4+W9kkcxUbnhCCVhMNnNFjnS3vwiv pvm1SSsBCFsLx5aJXDDAesQC2wwrfqkkOovrm4Lg0MzJsyRBhLRbThIuwf37A1DGvAyYgkhkLM CGnoqLXG1MPTB5LVF6GcgqikTrT55wkGPcRjaFHriWDy5ovZpAb4aUnA98ZXLQ8sfONXCpYF0T P2nP96Mbzm8y2Nm4jlt6mshDfqKIYPPiAZqs3ACwJeQ+MQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-oi1-f173.google.com) smtp.remote-ip=209.85.167.173; dkim=pass header.d=brasslantern-com.20150623.gappssmtp.com header.s=20150623 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-20200801; t=1616964706; bh=ZzomjyNeusGgKYtE2nsSE4iKTtSgCXEeozeZdc+caik=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=KwcyWa2gEN8WSRHCPaK76oSkkLoM4E0D8L/t6L3A5ex2Su1uanQQ7CwaQ/R9PG4ku7wqUDopTi b7aI78FNkpXc8yf5zmmcfYDZ7/3hzDXA8LnuDWwpjvd4i+cwr0uuotF5Q9PWFXImH3mL4zoCsZ daMQV8H7NYfd8WfWUe4e9FpkrIFWuoFcuViMiX17R5rZr+kb3s5bZDGABqjRbrAUpwCuTmFb2u PcIjY6fq+pxA2eBwkO12W41170c7oelZtQIGW5QBGgtM0uBqhU+DGqgZ/B8I/ddLUQcbry/4Wh Ua0Q/80hiAQvz3Bw8s9vrNLvKXc5TkQHEeMJOjMChKPx5A==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=dSfmSfb9bltyLngoWH2Bpn81ytDENX/H53HFs867O+Q=; b=DdEr0MkWhRJs+4pqBedAjAgWhR 2EM+5hbVQ8lwrvaKWveB+sXwDEPDbHgjCjhsgw9q0XkKhJJt0b2rsFgmeZselCTbRo5rmwuU4d6sO YjSJXX8iQvQFZw7ERLtwpOD+MZuru+dxMapfCby6dbz0mPQO20jaWkBpI6KhDLIChbIAYZ0cJeK9x hQNMsTkx8hNhxuF6ypDaPXY071fT49A82ZBCPLFEoiozQ06r86x+cGctCUWFvgCSnlHoCMThCKWv3 iDksxj/v1f51gGvi/o/fZRtfou7L3yT+9Ly3veOdlTz32NfZlnelVeYWCGnlg2zgQ73+1FOriuzZU fN3JqSzQ==; Received: from authenticated user by zero.zsh.org with local id 1lQcNs-000MC8-BQ; Sun, 28 Mar 2021 20:51:44 +0000 Authentication-Results: zsh.org; iprev=pass (mail-oi1-f173.google.com) smtp.remote-ip=209.85.167.173; dkim=pass header.d=brasslantern-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-oi1-f173.google.com ([209.85.167.173]:43774) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1lQcNZ-000M2b-S9; Sun, 28 Mar 2021 20:51:27 +0000 Received: by mail-oi1-f173.google.com with SMTP id n8so11254403oie.10 for ; Sun, 28 Mar 2021 13:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dSfmSfb9bltyLngoWH2Bpn81ytDENX/H53HFs867O+Q=; b=OxeF8VUolFqc7s13irWEoaMhUA0R0scNJoBm4Rw/bp/2ouxtDVvWpvWveHapNCGsUM 1LyBewf+lN7l5Y4V1qUA/LEVxrgfCJlh8q6qe6DwhxZAnACoFJLHlQ398ByXN7VaKrcO 3sQ52+OD3EjcQd3L2jewkvF+8nXtlYO4GFD6wvONiyKue/N8GSiaXbtCs1euLlHy3i0I zAYpG3ZTGhm2FYQnHKXJevBLDCLhrgRxC3mykDoJ7qE99BbPG/CEu4B2sHNkZH8QCZRu 7PmKnnauQTY56VhiXwQWHbjVaQani8CFvJWai2nhpCaF8v5pUFd3mpyrrTj57gb4V3mR F+NA== 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=dSfmSfb9bltyLngoWH2Bpn81ytDENX/H53HFs867O+Q=; b=mRiRLy6tah779PooiizuI0RBQBV2Akpo8ROy2sYGwDN2lnwhzPyMc7Nubx1zcEk7dH OEeblvnpYyIo9ms+A5YxxyOVsI9uSRoZ3dFdeVi6yPuZs8BxnVwCvpdnuQJSvsbFAfMD 8Q5fTKo+1YbY2Y+2qmDNExGqDxkt6Dm6bfApo805DsVnejyDWbvVXqBeDMAkfMhLDZqC wBv8MZJShMk+A4XcXlVBCYAF19JVrZMmjglfvB4J6qsgWdTiIZBpz/h1vLuw+iURvcmJ sgpSll0EDytCvwTJEOC58xh76czCiK0XOQaZrD2lUVmVYY8rU3qCX0jl7Nxg7n/kG7U6 wBkg== X-Gm-Message-State: AOAM532rZqVJBnvrZfckg1hntMopbXLsUAoS6MQJHH3NX26k9AI+fFY9 3d0VSvfC1ml25LLtj0pNxzH+Wq1HjSm0r4lZY6rUpg== X-Google-Smtp-Source: ABdhPJy7mhfqRmQS/eKXMd0QvKx5NVcY53YztePxbX5c1pCUAU02ioBaVNW2yZcMNJcAkDP6/yv8cL5yaqQQjWGJY+4= X-Received: by 2002:aca:4d8f:: with SMTP id a137mr16400977oib.132.1616964683336; Sun, 28 Mar 2021 13:51:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bart Schaefer Date: Sun, 28 Mar 2021 13:51:12 -0700 Message-ID: Subject: Re: Why does _main_complete not try the next completer when $_comp_mesg is non-zero? To: Marlon Richert Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 48292 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: Archived-At: On Sun, Mar 28, 2021 at 11:07 AM Marlon Richert wrote: > > Would there be any drawback to removing this check? I think it would break the intended behavior of "_guard" when used in an _arguments action (which is how we're getting into _message in the first place). There is some divergence between the doc for _guard and the actual implementation. The doc says: _guard [ OPTIONS ] PATTERN DESCR This function displays DESCR if PATTERN matches the string to be completed. It is intended to be used in the ACTION for the specifications passed to _arguments and similar functions. The return status is zero if the message was displayed and the word to complete is not empty, and non-zero otherwise. In fact the return status only depends on the word being non-empty, not on the message at all. Another curiousity is that _message is supposed to take an optional tag _message -e [ TAG ] DESCR but _guard never passes it one, it just passes all it's non-option arguments as a string: _message -e "$*" This has the effect that anything looked up as a style down-stack from _message repeats the context as the tag, e.g. from _complete_debug: +_description:15> zstyle -s :completion::complete:grep:argument-1:argument-1 group-name gname So there may very well be something more needed here than just removing that check. > Convenient would be that I could specify through a zstyle that I don't > want that behavior. Though, why anyone would actually want the current > behavior is unclear to me. In this case the author of the _grep completion function determined that to be the desirable behavior, otherwise _guard would not have been used in that context. Whether an author should ever be able to "know better" than the user is an entirely different question. But there are tags generated for both _guard and _message that could be used to look up additional styles within those functions, if we as a group can agree on the semantics. Meanwhile, what about putting this in your completer style? _complete_or_history () { _complete "$@" local ret=$? _mesg=$_comp_mesg if [[ $ret -ne 0 || -n "$_comp_mesg" ]] then _comp_mesg='' _history "$@" && ret=0 fi (( $compstate[nmatches] )) || _comp_mesg=$mesg return ret }