From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8836 invoked by alias); 6 Jul 2015 14:17:32 -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: X-Seq: 35702 Received: (qmail 23977 invoked from network); 6 Jul 2015 14:17:31 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SEz7afXKOx6FaORzJ84CiqOFvkb9BmW6bVg64LfGVBw=; b=OyNjwCjf8ABnua6X3xMamBjFcjH+fD7haASotj1cPzYCOH6jqbjAGfUxdsh7n0NRwI v6f6ZAczNdnv3sajNub8CXNgnO3QG9JC24PXFtu9zmf1cHPN2+sSkyCEPLz/+av5tHqk w6+rQP+4AV7X/kb1YQq5VMnHFMXKYGMDlkoCKwqoa8eRXmtwKal4+0jLbUbWFwjBIezO 7lMuBAiMV0I8EP+BrQUyMdERlFEndx8ztToe3Ac6IfXHdMO9CH5P6H627x7t9hAFPIe1 6h1msxTGAJMdJmAbKQIm5XDAd15U+FsLnD3OJf7CLVcVVioAhEPXlydRc8AVVwlDt9Mf EJTw== MIME-Version: 1.0 X-Received: by 10.107.136.89 with SMTP id k86mr4039081iod.53.1436192246757; Mon, 06 Jul 2015 07:17:26 -0700 (PDT) In-Reply-To: <4740.1436181110@thecus.kiddle.eu> References: <1436143012-9243-1-git-send-email-mikachu@gmail.com> <4740.1436181110@thecus.kiddle.eu> Date: Mon, 6 Jul 2015 16:17:26 +0200 Message-ID: Subject: Re: PATCH: _ps1234, _date_formats: Complete strftime formats for %D{} From: Mikael Magnusson To: Oliver Kiddle Cc: zsh workers Content-Type: text/plain; charset=UTF-8 On Mon, Jul 6, 2015 at 1:11 PM, Oliver Kiddle wrote: > Mikael Magnusson wrote: >> >> PS, my strftime(3) says it handles %E and %O, and it does work with date +%Ey, >> but zsh just prints the literal %Ey. Is it handled wrong by us or not >> by the libc like the manpage claims? > > Looking at the source, it seems only - is treated as a modifier. > It'd be nice for it to be updated if it can remain portable. > >> Completion/Unix/Type/_ps1234 | 14 +++++-- > > Shouldn't this be in Completion/Zsh/Type? Possibly, but I figured we could use it for _date too? >> +else >> + _default "$@" > > I really don't think _default is applicable there. The function is only > for completing date formats. If the calling function needs that, it > should do it itself. If _default is somehow needed, the return status > should be considered. For this I just copied what I did in _ps1234, which before these two patches did the compset before calling _default, so it would complete filenames anywhere... but of course you couldn't complete in subdirectories since it compset -P away what you just typed :). I guess it's unlikely to be useful here yeah. >> + compset -P "*" >> + _describe -t date-format-specifier 'date format specifier' '(%)' -S '' > > Using _describe to complete just % seems rather overkill. An _wanted > would do. However, it'd be better to use a prefix for the % and use > compset -P to cut off complete format specifiers or unrelated > characters. The patch below does that and adds a case statement to > select some OS specific additions. > > It'd perhaps be nice to complete format specifiers and modifiers with a > different tag and description. I don't know how most of the things you did work, but as far as I can tell it only breaks one thing; pressing tab after %5 now completes all modifiers instead of just putting in a . since %. is the only one that takes a numeric argument. %- is also handled internally by zsh for some modifiers, so it'll work on any OSTYPE as long as $1 is zsh. I'll commit my patches as they were and then you can modify them. -- Mikael Magnusson