Control: tags -1 +pending On 2018-02-25 22:17:36, Adam Borowski wrote: > On Sun, Feb 25, 2018 at 01:06:15PM -0500, Antoine Beaupré wrote: >> On 2018-02-25 02:29:28, Adam Borowski wrote: >> >> undertime prints terminal escape sequences to pipes and files. >> > >> > There are two types of escape sequences here: >> > >> > • SGR. These make sense, as undertime uses color to convey its output. >> > A plain text interface would be a reasonable request but is probably a >> > feature >> > (anarcat: you can detect non-terminals by !isatty(1) ). >> >> What's SGR? Do you mean: >> >> https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters > > Yeah -- "\e[…m", in your case bold and colors. > >> If so, could you expand on what you would expect this would look like? >> keep in mind that undertime doesn't generate those escape sequences on >> its own: it passes a list of rows to the terminaltables library and lets >> it handle that on its own. > > I guess that skipping colors would work then.
Skipping colors doesn't fix the problem described by pabs in the original bug report: [1014]anarcat@curie:undertime$ ./undertime --no-colors | less qqqqqqqk EST qqqqqqqu 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 08:51 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 └───────┘ [1015]▒┼▒⎼␌▒├@␌┤⎼␋␊:┤┼␍␊⎼├␋└␊$ >> undertime is written in python, so: >> >> no Python documentation found for 'isatty' >> >> There is, of course, os.isatty(): >> >> https://docs.python.org/3/library/os.html#os.isatty > > Yeah, using Python is merely a penance rather than a crime (unlike, say, > node.js), so usual POSIX interfaces are obvious to find. Your faith in POSIX is impressive. ;) >> ..and sys.stdout.isatty(). But isn't this something that should be >> handled by the underlying terminaltables library? > > I think most low- and mid-level libraries assume that the program does such > logic rather than relying on the library. In your case, I'd recommend > defaulting to --colors/--no-colors based on isatty(1) -- this is what the > vast majority of programs that use colors for highlighting do. > > The difference in doing this yourself is, if you decide to convey > information that you currently give via colors by some other means (such as > a '*') in plain-text output, you don't need to rely on an interface the > library might or might not provide. > > And, it takes a single line of code to default --colors/--no-colors to > isatty. Which is less than what we already spent on this discussion. :) It's actually more than one line, because of a small bug in NegateAction, which forcibly overrides the default: diff --git a/undertime b/undertime index f28c691..c12b6b8 100755 --- a/undertime +++ b/undertime @@ -33,6 +33,7 @@ along with this program. If not, see <http://www.gnu.org/licenses/>. import argparse import datetime import logging +import sys # also considered colorama and crayons # 1. colorama requires to send reset codes. annoying. @@ -71,9 +72,9 @@ class NegateAction(argparse.Action): def __init__(self, option_strings, *args, **kwargs): '''set default depending on the first argument''' - default = not option_strings[0].startswith(self.negative) + kwargs['default'] = kwargs.get('default', not option_strings[0].startswith(self.negative)) super(NegateAction, self).__init__(option_strings, *args, - default=default, nargs=0, **kwargs) + nargs=0, **kwargs) def __call__(self, parser, ns, values, option): '''set the truth value depending on whether @@ -92,7 +93,7 @@ def arg_parser(): help='end of working day, in hours [default: %(default)s]') parser.add_argument('--date', '-d', default=None, help='target date for the meeting, supports arbitrary dates like "in two weeks" [default: now]') - parser.add_argument('--colors', '--no-colors', action=NegateAction, + parser.add_argument('--colors', '--no-colors', action=NegateAction, default=sys.stdout.isatty(), help='show colors [default: %(default)s]') parser.add_argument('--default-zone', '--no-default-zone', action=NegateAction, help='show current timezone first [default: %(default)s]') But even then: this doesn't work, as --no-colors still shows the bug. What *does* fix the issue is using unicode, as you mentioned and as I suggested in the upstream bug report: https://github.com/Robpol86/terminaltables/issues/59 What's interesting is that there *is* a style that outputs unicode already: the "DoubleTable" style: https://robpol86.github.io/terminaltables/doubletable.html >> > • VT100 line drawing. These codes shouldn't be used these days: there's a >> > debate whether they're allowed within an UTF-8 locale, as the relevant >> > standard seems to say no. >> > >> > Also, tools like "less -R", which support colors well, don't handle such >> > line drawing. This includes my ansi2txt and ansi2html > >> So this sounds like a total nightmare that makes timezones and GUI >> toolkits look like an awesome time at the beach. In fact, this makes me >> want to rewrite the whole thing to *not* output on the terminal and >> instead use Kivy or some other gaming engine to output a beautiful >> interface like http://worldchatclock.com/ instead. > > That's nowhere near the worst quirk of Unix terminals -- we're talking about > something that has evolved with direct ancestry of 19th century design. I know. > On the other hand, a terminal interface is massively more useful for our > kind of folks than some pretty but fragile web stuff. I wasn't suggesting writing a web interface for undertime (yet). And if I would, it would be optional: just something that reuses the code... What I was suggesting is simply a native GUI... maybe you heard of those? (And no, I don't mean Electron.) >> Again: I didn't write those escape sequences, I just use terminaltables >> blindly because it supports colors neatly. I have found other >> alternatives, documented in the source here: > >> Let me know when you're done. :p More seriously, underline is >> (deliberately) a small program: 200 lines, and half of that is usage >> instructions, comments and metadata. > >> I forwarded this upstream, and, for what it's worth, there are *three* >> pull requests to implement unicode tables in terminaltables >> already. Someone(tm) needs to review those and patch terminaltables in >> Debian to include the right fix. > > Yeah, it's reasonable to punt this logic there. Unlike colors/no-colors, > such implementation details have no place in a program like yours, it's the > library what's supposed to know such things. Yep, the upstream issue is still open. >> I'm tempted to just reassign this bug and #891378 to the >> python-terminaltables project, because it's not really a bug in >> undertime itself... > > Exactly. We have two issues here, though, so I'd recommend doing the > --no-colors part yourself (resulting in no SGR), and reassign line drawing > (VT100/Unicode). So I looked into that and I have improved --no-colors to still somewhat outline the relevant lines with "_" or "*" when we don't use colors. But considering that `less -r`, `more` and many other pages can display colors without problems, I am not sure i see the point of defaulting to "no colors" for !isatty. In fact, I surmise that tools like git *do* pass escape sequences to pagers freely, and it works fine. Of course, git calls the pager itself, which could explain why it's doing the right thing, but I wouldn't want to keep colors from working completely for users that have their pager configured correctly. So this will be "fixed" in the next upload, in that we'll switch to the DoubleTable style and have an improved "--no-color" output. We will, however, retain the colors on pagers, assuming those can be told to do the right thing (or, in worse case, the users need to learn about --no-colors). Thanks for the bug report and instructive discussion... A. -- The survival of humans and other species on planet Earth in my view can only be guaranteed via a timely transition towards a stationary state, a world economy without growth. - Peter Custers
