Blinking Commits • Hacker News Board

Re: Blinking Commits

#101

Post by yuubi » Sat, Aug 15, 2015, 6:28 AM UTC

LukeShu wrote: post #94

chrisfosterelli wrote: post #88

Earlier quoted context omitted.

Unfortunately most browsers don't have support anymore

Well, then it fits; many terminal emulators don't support \e[5m as blink anymore. Xterm, URxvt, and Konsole do, but the Linux terminal doesn't (gives it a grey background, not blinking), VTE-based terminals (gnome-terminal, lxterminal, ...) don't (ignored), Emacs term-mode doesn't (treats it as bold).

The "gray background" is really a "bright black" background. The old IBM CGA and successors had a flag for whether to interpret the top bit of the background color as intensity or blink[0]. It looks like Linux used to have it set to blink a few years back[1].

[0] http://webpages.charter.net/danrollins/techhelp/0087.HTM

[1] http://sourceforge.net/p/linux-fbdev/mailman/message/7849329...

Re: Blinking Commits

#102

Post by erikb » Sat, Aug 15, 2015, 10:14 AM UTC

daveloyall wrote: post #81

rquirk wrote: post #45

Earlier quoted context omitted.

Doesn't work on Xfce either. On a virtual terminal thingy (ctrl-alt-f1) it shows a grey background with white text. I suspect blink is only implemented on the Mac's terminal, not in Linux-land.

> I suspect blink is only implemented on the Mac's terminal, not in Linux-land. ...Lord, when did I get so old? :/ EDIT: https://en.wikipedia.org/wiki/VT100

I suspect it's really not a terminal issue but something about git. Or does a Terminal that doesn't interpret a command print it in clear text? I just get the string back, the same way I entered it.

Re: Blinking Commits

#103

Post by rurounijones » Sat, Aug 15, 2015, 12:06 PM UTC

rudolf0 wrote: post #97

rurounijones wrote: post #4

I actually quite like the idea of control codes in commit messages for internal teams where you can implement rules. It could be useful for highlighting risky commits in red or other visual markers. Would play merry hell with almost every other way of viewing commits though :D

>I actually quite like the idea of control codes in commit messages for internal teams where you can implement rules. >It could be useful for highlighting risky commits in red or other visual markers. Yeah... that is really not a good idea. You are not supposed to take this blog post seriously. Why not just agree on some terminology like CRITICAL/MINOR/SECURITY, which a visual interface can then highlight? SECURITY:…

> You are not supposed to take this blog post seriously.

And you were not supposed to take my comment seriously... I thought I made that obvious with the last sentence but oh well.

Re: Blinking Commits

#104

Post by alxndr » Sat, Aug 15, 2015, 3:00 PM UTC

madaxe_again wrote: post #66

Every time I use a control character, my mind strays back to CHR$141. Although I do wonder what havoc you could wreak on hosted git services with cunning sequences of control characters. Smacks of injection.

If anyone else is curious about CHR$141, it's how you can show doubly-tall letters on an Acorn BBC Micro's teletext display...

http://www.bbcbasic.co.uk/bbcwin/manual/bbcwinh.html

https://en.wikipedia.org/wiki/Teletext

Re: Blinking Commits

#105

Post by daveloyall » Tue, Aug 18, 2015, 5:01 PM UTC

erikb wrote: post #102

daveloyall wrote: post #81

Earlier quoted context omitted.

> I suspect blink is only implemented on the Mac's terminal, not in Linux-land. ...Lord, when did I get so old? :/ EDIT: https://en.wikipedia.org/wiki/VT100

I suspect it's really not a terminal issue but something about git. Or does a Terminal that doesn't interpret a command print it in clear text? I just get the string back, the same way I entered it.

What?

https://en.wikipedia.org/wiki/ANSI_escape_code

It's definitely a terminal thing. The "bug" in git is that it doesn't strip out the control characters or reject the commit if the commit message contains non-text data.