zsh-workers
 help / color / mirror / code / Atom feed
From: Frank Terbeck <ft@bewatermyfriend.org>
To: Oliver Kiddle <okiddle@yahoo.co.uk>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCHv3] Refactor baud rate completion
Date: Tue, 03 May 2016 23:01:32 +0200	[thread overview]
Message-ID: <87a8k6hn4j.fsf@ft.bewatermyfriend.org> (raw)
In-Reply-To: <27858.1462193719@thecus.kiddle.eu> (Oliver Kiddle's message of "Mon, 02 May 2016 14:55:19 +0200")

Hi Oliver,

thanks for taking your time to look over the code. I'll address these as
soon as I can, though on weekdays my spare time is severely limited at
the moment.


Oliver Kiddle wrote:
> Frank Terbeck wrote:
>> This adds a new helper function _baudrate and uses it in place of
>> private solutions in various existing completions.
>
> Some comments on this: the normal convention is for helper functions
> to have plural names. The logic being that all baud rates are added
> as matches. So this should be named _baudrates or _baud_rates.

Sure that's simple enough.

> Secondly, the convention for completion functions is two spaces for
> indentation. See Etc/completion-style-guide. Annoyingly, there's quite a
> few functions that don't follow this but it'd be nice if we could avoid
> adding more.

Huh. I wasn't aware of this one at all. But it's easy enough to fix.

>> +#     -t TAG       Use TAG as the tag value in _wanted call.
>> +#
>> +#     -d DESC      Use DESC as the description value in _wanted call.
>
> It is usually more flexible to just accept normal compadd options for
> descriptions and tags and pass them on to compadd fairly directly. It
> then will work in conjunction with other helpers like _alternative.
> _pdf is a good example. Using _wanted here isn't entirely necessary:
> _description would be sufficient and avoids nesting tag loops.

I'll take a look at _pdf and the possibility to use _description. I kind
of expected there to be a way to propagate stuff to compadd, but was too
lazy to find out. :)

>> +# It is also possible to override the arguments to -f, -u and -l via styles in
>> +# a similar fashion:
>> +#
>> +#   zstyle ':completion:*:*:screen:*' max-baud-rate 9600
>> +#   zstyle ':completion:*:*:screen:*' min-baud-rate 1200
>> +#   zstyle ':completion:*:*:screen:*' baud-filter some_function_name
>
> The original concept with styles was that style's could have fairly
> generic names because the context allows you to select the detailed
> context. So perhaps consider allowing this to work as, for example:
>   zstyle ':completion:*:*:screen:*:baud-rates' max-value 9600

Sounds reasonable. I'll take a look at this as well.


Regards, Frank


  reply	other threads:[~2016-05-03 21:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-01  1:12 [PATCH] Add completion for picocom utility Frank Terbeck
2016-05-01  3:27 ` Ryan Wilson
2016-05-01 10:57   ` Frank Terbeck
2016-05-01 12:47     ` [PATCH] Refactor baud rate completion Frank Terbeck
2016-05-01 13:14     ` [PATCHv2] " Frank Terbeck
2016-05-01 13:27     ` [PATCHv3] " Frank Terbeck
2016-05-01 22:21       ` Frank Terbeck
2016-05-02 12:55       ` Oliver Kiddle
2016-05-03 21:01         ` Frank Terbeck [this message]
2016-05-07 21:53         ` Frank Terbeck
2016-05-11 15:08           ` Oliver Kiddle
2016-05-07 22:09         ` [PATCH 0/6] Update baud rate completion with Oliver's comments in mind Frank Terbeck
2016-05-07 22:09           ` [PATCH 1/6] _baudrate → _baudrates Frank Terbeck
2016-05-07 22:09           ` [PATCH 2/6] _baudrates: Use 2 space indentation Frank Terbeck
2016-05-07 22:53             ` Frank Terbeck
2016-05-07 22:09           ` [PATCH 3/6] Use _baudrates helper instead of _baudrate Frank Terbeck
2016-05-07 22:09           ` [PATCH 4/6] _baudrates: Fit better into the general completion framework Frank Terbeck
2016-05-07 22:09           ` [PATCH 5/6] _cu: Remove old -d option of _baudrates Frank Terbeck
2016-05-07 22:09           ` [PATCH 6/6] _baudrates: Make style lookups fit better with the rest of compsys Frank Terbeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a8k6hn4j.fsf@ft.bewatermyfriend.org \
    --to=ft@bewatermyfriend.org \
    --cc=okiddle@yahoo.co.uk \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).