Live data from Hacker News

Show HN: Grep with colours written in Go

github.com

61–70 of 90 posts

Re: Show HN: Grep with colours written in Go

#61
post #58
post #46

Earlier quoted context omitted.

That is correct. The project is at its early stages. I want to see what the community need the most and shape the project towards that goal. On the other hand I tried to avoid optimisations until most of functionalities are implemented.

It's a very nice idea and you should be proud of what you've built, but my personal opinion is that speed is a core feature of `grep`. A good place to start would be this: why GNU grep is fast[1] - Starting with the Boyer-Moore string search algorithm and reading through the optimizations done in GNU grep. p.s. there's an implementation of Boyer-Moore hiding in Go's standard library. [1] https://lists.freebsd.org/pip…

Thanks mate, I will definitely have a read.

Re: Show HN: Grep with colours written in Go

#62
post #26

Earlier quoted context omitted.

What if someone needs colors, but not colors that util maker used? What if two or more tools make different use of colors? With terminal aware of that problem you can remap or erase specific colors, but maybe it’s wiser to not create a problem at all, since just making text bold may be enough for practical needs. Edit: missing not

Sounds like a better standard is being able to define color schemas for CLI utilities. Would be pretty awesome if this were possible, though many utilities vary in what type of output is colored a certain way sadly. Another workaround is to merely pipe the output to a file in certain cases.

> Another workaround is to merely pipe the output to a file in certain cases.

If that works for a certain tool, it's author really has no excuse to not implement NO_COLOR env as well.

Re: Show HN: Grep with colours written in Go

#63
post #61
post #58

Earlier quoted context omitted.

It's a very nice idea and you should be proud of what you've built, but my personal opinion is that speed is a core feature of `grep`. A good place to start would be this: why GNU grep is fast[1] - Starting with the Boyer-Moore string search algorithm and reading through the optimizations done in GNU grep. p.s. there's an implementation of Boyer-Moore hiding in Go's standard library. [1] https://lists.freebsd.org/pip…

Thanks mate, I will definitely have a read.

Note that you don't need Boyer Moore for the common case. ripgrep for example will very rarely use Boyer Moore. Its work horse is much simpler and typically faster: https://github.com/rust-lang/regex/blob/master/src/literal/m...

In Go-land, you should be able to replace uses of memchr with IndexByte[1], which should be implemented in Assembly on most platforms.

Of course, for any of this to have a big impact, you'll want to take Mike Haertel's advice on avoiding line breaking and stop using bufio.Scanner. :-)

[1] - https://golang.org/pkg/bytes/#IndexByte

Re: Show HN: Grep with colours written in Go

#64
post #22

Earlier quoted context omitted.

I don't understand why this is a standard. First: It requires that every command line tool add support for this environment variable. It may not be much effort for each project, but it adds up to a ton of developer time. Even if this standard gains traction, some apps will slip through the cracks. So in the success case, many users will still be annoyed that one or two of their tools print colors when they shouldn't.…

I'll speak for my case specifically: a lot of programs I use have varying levels of colour-by-default, but I don't want that. What I want is to have them all off, except the ones that actually add value. I think it's apparent that this isn't something you're really keen to support in ag in the few times I've seen you talk about it, so feel free to close the PR I have open there rather than leave it hanging without an…

> a lot of programs I use have varying levels of colour-by-default, but I don't want that. What I want is to have them all off, except the ones that actually add value.

Your use case seems perfectly valid to me, but how would NO_COLOR help you? Wouldn't it suppress all color in all programs when it's set? Assuming everyone gets on board, of course.

Re: Show HN: Grep with colours written in Go

#65
post #64

Earlier quoted context omitted.

I'll speak for my case specifically: a lot of programs I use have varying levels of colour-by-default, but I don't want that. What I want is to have them all off, except the ones that actually add value. I think it's apparent that this isn't something you're really keen to support in ag in the few times I've seen you talk about it, so feel free to close the PR I have open there rather than leave it hanging without an…

> a lot of programs I use have varying levels of colour-by-default, but I don't want that. What I want is to have them all off, except the ones that actually add value. Your use case seems perfectly valid to me, but how would NO_COLOR help you? Wouldn't it suppress all color in all programs when it's set? Assuming everyone gets on board, of course.

Yeah that seems to be what he wants!

He can then selectively enable color on the programs he wants by simply unsettling the NO_COLOR variable before execution of the program.

Re: Show HN: Grep with colours written in Go

#66

Do be sure to at least consider supporting no colour! http://no-color.org

I'm confused, with a tagline like "grep with colors!", wouldn't you just use grep if you don't want colors?

This feels like complaining that Spotify doesn't have a silent mode for people who dislike sound. /shrug

Re: Show HN: Grep with colours written in Go

#68
post #33

Earlier quoted context omitted.

I turned most colors off many years ago. For me it was because several tools (especially ls) used colors that were very hard to distinguish with my terminal background. I found myself spending too much time trying to figure out what was on my screen. Another bonus is that I don't feel cheated when I log into systems that don't support colors (*BSD, Solaris, etc). Everything just looks normal to me. Even non-syntax hi…

The tools don't exactly choose the color. They choose a color name from a palette. Your terminal's theme defines that palette. If your terminal has a background very close to one of the colors on that palette, that is a theme problem, not an app problem.

This was a long time ago before terminal emulators had themes and I also did a lot of work on actual terminals (monochrome hardware) and the console (black background with gray text). Even my current emulator doesn't support "themes". I have to set each color register individually in the .Xresources file. On modern hardware this works fine, but years ago the quality of CRTs was such that you couldn't guarantee brightness and color levels across devices.

Do you remember the days of X Modelines? I still have the nightmares.

Re: Show HN: Grep with colours written in Go

#69
post #62

Earlier quoted context omitted.

Sounds like a better standard is being able to define color schemas for CLI utilities. Would be pretty awesome if this were possible, though many utilities vary in what type of output is colored a certain way sadly. Another workaround is to merely pipe the output to a file in certain cases.

> Another workaround is to merely pipe the output to a file in certain cases. If that works for a certain tool, it's author really has no excuse to not implement NO_COLOR env as well.

Piping the output does not guarantee the removal of the color codes. This is yet another standard some programs have chosen to implement.

The program checks if the output is a tty, if it is not a tty it will drop color information as it is either a pipe or a file. The escape codes would look ugly in a file and could get in your way with some text processing programs.

Even if the program did drop color when not sending output to a tty it still is a crappy way to remove color as the pipe would need another program as a receiver such as pager.

Re: Show HN: Grep with colours written in Go

#70
post #17

Earlier quoted context omitted.

Genuinely curious, why do some developers prefer not having colors for ls, grep, etc.? no-color.org mentions that many users prefer having colors disabled, but didn't list any reasons why.

I don't find that they add anything. I feel like they make it harder for me to do a coherent read of the screen, to suck in all the text & process it. I have my own mental algorithms to pick out relevant things, and having a bunch of glaringly contrasting blocks of color glaring out of the terminal at me just makes it harder to slurp in the screen. I don't want that segmentation. It's awful. And the color themes for…

That makes sense. In a way, it's like they're mental "speed bumps" that disrupt reading the text. I can certainly see why those "bumps" would be aggravating, thanks for the insight!
Post reply on HN