patchmerge: use string_list_split() in add_strategies()

>  static void add_strategies(const char *string, unsigned attr)
>  {
> -	struct strategy *list = NULL;
> -	int list_alloc = 0, list_nr = 0, i;
> -
> -	memset(&list, 0, sizeof(list));
> -	split_merge_strategies(string, &list, &list_nr, &list_alloc);
> -	if (list) {
> -		for (i = 0; i < list_nr; i++)
> -			append_strategy(get_strategy(list[i].name));
> +	int i;
> +
> +	if (string) {
> +		struct string_list list = STRING_LIST_INIT_DUP;
> +		struct string_list_item *item;
> +		string_list_split(&list, string, ' ', -1);
> +		for_each_string_list_item(item, &list)
> +			append_strategy(get_strategy(item->string));
> +		string_list_clear(&list, 0);
>  		return;
>  	}

> I wonder, however, if we could somhow turn things around by introducing
> something like
>
> 	split_and_do_for_each(item_p, length, string, delimiter)
> 		... <do something with item_p and length> ...
>
> that both string_list_split() *and* add_strategies() could use? We would
> then be able to avoid allocating the list and duplicating the items in the
> latter case.

> delimiters into one without introducing an "empty" element, allowing
> more than one delimiter characters like SP and HT, and ignoring
> leading or trailing runs of delimiter characters).
>
> If the input is generated internally, perhaps we should rethink the
> interface between the function that wants to do the for-each-word
> and its caller; if the caller wants to pass multiple things to the
> callee, it should be able to do so without first having to stuff
> these multiple things into a single string, only to force the callee
> to use this helper to split them out into individual pieces.

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > I wonder, however, if we could somhow turn things around by
> > introducing something like
> >
> > 	split_and_do_for_each(item_p, length, string, delimiter)
> > 		... <do something with item_p and length> ...
> >
> > that both string_list_split() *and* add_strategies() could use? We
> > would then be able to avoid allocating the list and duplicating the
> > items in the latter case.
> 
> I do think such a feature may be useful if we often work on pieces of a
> string delimited by a delimiter, but if the caller does not see the
> split result, then the function with "split" is probably misnamed.
> 
> I however suspect the variant of this where "delimiter" can just be a
> single byte would not be so useful.
> 
> If the input comes from the end user, we certainly would want to allow
> "word1  word2\tword3 " as input (i.e. squishing repeated delimiters into
> one without introducing an "empty" element, allowing more than one
> delimiter characters like SP and HT, and ignoring leading or trailing
> runs of delimiter characters).
> 
> If the input is generated internally, perhaps we should rethink the
> interface between the function that wants to do the for-each-word and
> its caller; if the caller wants to pass multiple things to the callee,
> it should be able to do so without first having to stuff these multiple
> things into a single string, only to force the callee to use this helper
> to split them out into individual pieces.