Re: PATCH: print -v with an array

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 21,  9:51pm, Oliver Kiddle wrote:
} Subject: Re: PATCH: print -v with an array
}
} Bart wrote:
} > useful to have every reuse of the format add a separate entry to
} > the buffer stack.  Similarly for "print -s -f" and the history.
} 
} I doubt that anyone would notice a change of behaviour. Is multiple
} entries definitely more useful?

I don't know of a specific use-case.  It just seemed to make sense
that if you deliberately designed the format to consume only part
of the input on each pass, you might be expecting it to make separate
entries for each chunk so consumed.

Multiple buffer-stack entries might be less useful than multiple history
entries just because the buffer stack is LIFO.

} > (Currently -S is silently ignored if -f is given.  Hmm.  Not sure
} > how that ought to work anyway.)
} 
} -S is also missing from the completion function so I've missed that.
} The only way it could work is for the parsing and splitting to be done
} last. It doesn't even take more than one argument at the moment.

Yes, I'm wondering if print -S -f ... should just be an error.

} > It's probably a mistake/oversight with -c.  The *embedded* newlines
} > always get included.  The question is whether
} >
} >     print -l one two three four
} > and
} >     print -l -v stuff one two three four
} >     print "$stuff"
} >
} > should produce identical output, rather than the latter having two
} > consecutive newlines at the end.  Whichever way we decide, the same
} > really should also apply to -c.
} 
} I'd vote for the two consecutive newlines in the case of both -l and -c.

Feel free to fix this when you make whatever other tweaks emerge from
the foregoing conversation.