Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: print -v with an array
- X-seq: zsh-workers 39409
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Zsh workers <zsh-workers@xxxxxxx>
- Subject: Re: PATCH: print -v with an array
- Date: Wed, 21 Sep 2016 14:24:20 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=IJcvVm17vn32vGJhRCapHp5bNFpzYBITu8XMDCOE180=; b=xT0thvFdhaK+SLszdIN8omKPADFqBqzOlKzjgClmWnnM528ptg78AUtj2KAZCrg8qg woAZAz5qnC1Ijk0mwdpqFgGpimhWx6nBr0xxhN33JALfDRwso+EWDhhiz3l2SyD3oB07 yNbBrwYU8MjfXoxljUdRbZ6tIUzU6zE0nAwF88zGOnhb3xJ/VN4utOTI7Rb/6h2BI2pm 2Rgy+DQSwNbHTHs707SY8dcKfILPDEEWFOTemxSUO5WzGa27VLujIytUM3WGsPrRDyjp sYQk0nYG8FdzxeSTGHbWK7vPOXSUmi1NkQh/Xeo90JxZQYfgydUz16YgTHtKgdc6jx4Z XMCg==
- In-reply-to: <email@example.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <firstname.lastname@example.org> <160919133047.ZM28795@torch.brasslantern.com> <email@example.com>
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.
Messages sorted by: