@href First of all, welcome to Elvish!

For reference, there is already a git.elv module written by @muesli, which is used already by several prompt themes, including my own chain theme. This module uses git instead of gitstatus, but I think it would be nice to make the APIs compatible if possible so we can use them exchangeably :)

To answer your question, I don't think character-based reading can be done at the moment in Elvish, so your bash-based workaround seems reasonable for now. Maybe @xiaq can provide some other ideas.

(sidenote: I find the 0x30/31-based separation used by gitstatusd a bit awkward in general. I think a line-based interface would be much easier to use).

Cheers!

I think it's reasonable to at least provide a translation layer compatible with the existing git.elv module. Though I'll probably only go as far as implementing git:status by translating the results of gitstatus:query: href/elvish-gitstatus#2

I'm a bit hesitant to implement functions which throw away results of the status, as the whole point of gitstatus is performance and I think it makes sense to nudge people towards getting the data as a variable. If I include things like git:branch_name, then people might be encouraged to use these functions and lose out on the performance.

I also need to keep a separate set of return values in any case, as gitstatus is still in development and new values get added at times which might not be part of git:status. So I certainly want to stay true to gitstatus there.

And I do agree that 0x30/31 is a bit awkward, but that's not my call to make and from what I can tell this API is pretty much going to be in-flux.

Makes sense. I didn't know about gitstatus before, looks interesting for performance-sensitive applications such as shell prompts. Even with the existing git package, which is quite optimized, and with Elvish background handling of prompt commands, I still sometimes notices a lag in large repositories. I might give a try to using your gitstatus module for my chain prompt, see how it behaves 😄

Try splitting the string and getting the first element?

splits , a,b,c | take 1

The problem is not the splitting of the string, but getting it in the first place. The string has to be read from a long-running pipe. The record has a variable length, delimited with a special character (not a newline).

So I need a way to read characters from a pipe until I find a certain character.

You can see the problem if you run the following go program:

package main

import "os"

func main() {
	for {
		os.Stdout.WriteString("foo,bar,baz")
	}
}

I'd like to get 'foo' out of this program with elvish. How do I do it? When I run go run main.go | head, the command runs forever, because head waits for a newline. Same goes for go run main.go | splits , (all).

I am considering introducing a read-upto command:

read-upto $last

The command reads from the bytes input, one byte at a time. The argument $last may be one of:

• A string with a single byte, in which case it specifies the byte to stop reading after;
• A function, in which case read-upto passes each byte as a string to the predicate, and stops after the predicate outputs a false value.

There is something subtle about read-upto: its output will include the first byte that is equal to $last (if $last is a string) or fails the $last predicate (if $last is a function). This is a consequence of how pipelines work.

The first variant is now implemented and satisfies the need of this issue. Enjoy!

I have filed #885 to track the implementation of the predicate variant.

@xiaq thanks!

@href I have submitted href/elvish-gitstatus#4 to use read-upto in your elvish-gitstatusd package.