please tell me the sofware for testing
Blinking Commits
31–40 of 105 posts
Re: Blinking Commits
#32Haha, what a coincidence. Just the other day we discussed string special cases[0][1], to which I contributed ansi escapes. Unicode "fonts" 𝓵𝓲𝓴𝓮 𝖙𝖍𝖎𝖘 seem to work in commit messages as well. I think this is quite harmful, especially the character movement ansi escapes could be used for nefarious purposes. [0] https://news.ycombinator.com/item?id=10035008 [1] https://github.com/minimaxir/big-list-of-naughty-str…
I think this is quite harmful, especially the character movement ansi escapes could be used for nefarious purposes. Like what?
Hiding changes on previous lines.
Re: Blinking Commits
#33Haha, what a coincidence. Just the other day we discussed string special cases[0][1], to which I contributed ansi escapes. Unicode "fonts" 𝓵𝓲𝓴𝓮 𝖙𝖍𝖎𝖘 seem to work in commit messages as well. I think this is quite harmful, especially the character movement ansi escapes could be used for nefarious purposes. [0] https://news.ycombinator.com/item?id=10035008 [1] https://github.com/minimaxir/big-list-of-naughty-str…
I think this is quite harmful, especially the character movement ansi escapes could be used for nefarious purposes. Like what?
- Push malicious commit
- Rewrite the commit hash in git log with character movement
Actually I don't know if it's a practical attack in any way, could cause some confusion.
Re: Blinking Commits
#34Earlier quoted context omitted.
I think this is quite harmful, especially the character movement ansi escapes could be used for nefarious purposes. Like what?
Annoying your coworkers, for one
Just yesterday I ran across this example: "(っ˘▽˘)っ :cloud: ⊂(◕。◕⊂)" in the Parse SDK repo, which I found especially distracting, and in general, kind of turned me off from the project (even though I know Parse is awesome). I agree that UTF and special-chars should be permissable; I don't agree that if they don't actually communicate something, they should be used anyway. Maybe this cute 'moticon trend is trendy, but for my buck$, I'd rather things just be kept simple. My eyeballs see (っ˘▽˘)っ :cloud: ⊂(◕。◕⊂) as line-noise, mostly, and make me wonder if there are other such typo's to be found in the attached code-base.
Re: Blinking Commits
#35Re: Blinking Commits
#36Earlier quoted context omitted.
Annoying your coworkers, for one
Just yesterday I ran across this example: "(っ˘▽˘)っ :cloud: ⊂(◕。◕⊂)" in the Parse SDK repo, which I found especially distracting, and in general, kind of turned me off from the project (even though I know Parse is awesome). I agree that UTF and special-chars should be permissable; I don't agree that if they don't actually communicate something, they should be used anyway. Maybe this cute 'moticon trend is trendy, but…
I personally just find the committer to be immature, nothing else.
Re: Blinking Commits
#37This works for me in OS X's built-in Terminal app, but not iTerm. Both report xterm-256color as $TERM, so I'm not sure what about iTerm is configured differently to prevent it from working there.
Re: Blinking Commits
#38[deleted]
Re: Blinking Commits
#39Regrettably (?), you can't use this to implement marquee. But you can make your text black with a black background. Or re-order lines, which I suspect to be "fun" for git logs.
ANSI control characters include cursor positioning, so in theory you could implement marquee messages. The problem would be introducing delay. I don't recall if you can do that using ANSI. You can emulate it by doing repeated cursor repositioning, but that would be rendered so quickly that the commit message would have to be enormous to include any appreciable delay.
Re: Blinking Commits
#40I wonder if GitHub do/will support this and parse it to HTML
Killer feature :D