# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 23
# self = https://watcher.sour.is/conv/wr6nxoa
Now. Next mystery. grep --color=always ... | less -R is broken. grep spits out a lot of \e[K which means: “Erase in Line (EL), VT100, Erase to Right”. less used to ignore that sequence, now it doesn’t anymore (since 580). Now I’ve got to read grep’s source code to debug this …
Now. Next mystery. grep --color=always ... | less -R is broken. grep spits out a lot of \e[K which means: “Erase in Line (EL), VT100, Erase to Right”. less used to ignore that sequence, now it doesn’t anymore (since 580). Now I’ve got to read grep’s source code to debug this …
Now. Next mystery. grep --color=always ... | less -R is broken. grep spits out a lot of \e[K which means: “Erase in Line (EL), VT100, Erase to Right”. less used to ignore that sequence, now it doesn’t anymore (since 580). Now I’ve got to read grep’s source code to debug this …
@movq There's no place for --color=always on grep imo. I was considering building a generic syntax highlighter for the CLI with various lexers, for ls, diff, grep, find, etc...
@movq There's no place for --color=always on grep imo. I was considering building a generic syntax highlighter for the CLI with various lexers, for ls, diff, grep, find, etc...
@adi Hm, yes and no. Passing the ANSI color sequences through the pipes is not that great, agreed. But grep knows best which parts of the output should be colored. Doing the coloring in a second step using a second program feels like a hack to me as well. (Maybe we just shouldn’t be passing flat plain text, but structured objects …)
@adi Hm, yes and no. Passing the ANSI color sequences through the pipes is not that great, agreed. But grep knows best which parts of the output should be colored. Doing the coloring in a second step using a second program feels like a hack to me as well. (Maybe we just shouldn’t be passing flat plain text, but structured objects …)
@adi Hm, yes and no. Passing the ANSI color sequences through the pipes is not that great, agreed. But grep knows best which parts of the output should be colored. Doing the coloring in a second step using a second program feels like a hack to me as well. (Maybe we just shouldn’t be passing flat plain text, but structured objects …)
@movq I disagree with _should_ or _shouldn't_.
@movq I disagree with _should_ or _shouldn't_.
@adi @movq \n\n> Doing the coloring in a second step using a second program feels like a hack to me as well.\n\nI don't believe it's hack a all, but true to the unix philosophy of a program that does just the highlighting for other programs.\n\n> (Maybe we just shouldn’t be passing flat plain text, but structured objects …)\n\nJust whip out a parser, it's not that hard, just saying. 😋
@adi @movq
> Doing the coloring in a second step using a second program feels like a hack to me as well.
I don't believe it's hack a all, but true to the unix philosophy of a program that does just the highlighting for other programs.
> (Maybe we just shouldn’t be passing flat plain text, but structured objects …)
Just whip out a parser, it's not that hard, just saying. 😋
@adi @movq \n\n> Doing the coloring in a second step using a second program feels like a hack to me as well.\n\nI don't believe it's hack a all, but true to the unix philosophy of a program that does just the highlighting for other programs.\n\n> (Maybe we just shouldn’t be passing flat plain text, but structured objects …)\n\nJust whip out a parser, it's not that hard, just saying. 😋
@adi It would be more UNIX-y, that’s true. How would you implement it? Or rather, how would it work in a pipeline? grep ... | colorize | less? That would potentially expose the same problem. Or replace less with something else? 🤔 > > > >
@adi It would be more UNIX-y, that’s true. How would you implement it? Or rather, how would it work in a pipeline? grep ... | colorize | less? That would potentially expose the same problem. Or replace less with something else? 🤔 > > > >
@adi It would be more UNIX-y, that’s true. How would you implement it? Or rather, how would it work in a pipeline? grep ... | colorize | less? That would potentially expose the same problem. Or replace less with something else? 🤔 > > > >
@movq
> But grep knows best which parts of the output should be colored.
I would go with a _good enough_ coloring.
> grep ... | colorize | less
Exactly!
> That would potentially expose the same problem.
It's only a problem for _you_ I guess, it seems they agree on that solution with advantages and disadvantages listed in the comments? Yeah, maybe go with another pager?
@movq\n\n> But grep knows best which parts of the output should be colored.\n\nI would go with a _good enough_ coloring.\n\n> grep ... | colorize | less\n\nExactly!\n\n> That would potentially expose the same problem.\n\nIt's only a problem for _you_ I guess, it seems they agree on that solution with advantages and disadvantages listed in the comments? Yeah, maybe go with another pager?
@movq\n\n> But grep knows best which parts of the output should be colored.\n\nI would go with a _good enough_ coloring.\n\n> grep ... | colorize | less\n\nExactly!\n\n> That would potentially expose the same problem.\n\nIt's only a problem for _you_ I guess, it seems they agree on that solution with advantages and disadvantages listed in the comments? Yeah, maybe go with another pager?
@movq @adi Every now and then I use grep --color=always … | grep … and then I'm super glad, that there is --color=always.