fszf

I see a few people sharing incorrect details in the comments so I figured I'd echo some details.

'hyprctl output create headless'

This creates a headless monitor. You can verify this with:

'hyprctl monitors'

rockorager

Private Mode for In-Band Window Resize Notifications

Terminal emulators typically receive window resize events by installing a signal handler for the SIGWINCH signal. Handling of these signals can create challenges due to their inherently racy properties. Resize events must be synchronized with other application state in a safe manner.

Standard control sequences exist to query the current terminal size from the terminal and receive an in-band control sequence with the window size. However, this system requires polling - which is not ideal. Usually, SIGWINCH handling

lisawolderiksen

Adding co-authors to Git commits

How do you share credit for a new or altered piece of code when one person commits the change in a pair programming or mob programming session? And when you have questions about a particular change, how can you see in Git who has been working on that change, besides the committer? You add co-autors to your commits. This gist contains information on how to do that, so that the Git commit message contains a list of co-authors, and all co-autors for a commit are automatically listed in GitHubs web UI.

GitHub has some info on specifying co-authors here. This is good info, pretty straightforward. The gist of it (pun intended) is to include at least one blank line and then a line for each co-author like so Co-authored-by: name <name@example.com> at the very end of your commit message.

GitHub's recipe tells you [how to find the right e-mail address to use](https:

lisawolderiksen

Using Git Commit Message Templates to Write Better Commit Messages

The always enthusiastic and knowledgeable mr. @jasaltvik shared with our team an article on writing (good) Git commit messages: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the

nifl

Answer by Jim Dennis on Stack Overflow question http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118

Your problem with Vim is that you don't grok vi.

You mention cutting with yy and complain that you almost never want to cut whole lines. In fact programmers, editing source code, very often want to work on whole lines, ranges of lines and blocks of code. However, yy is only one of many way to yank text into the anonymous copy buffer (or "register" as it's called in vi).

The "Zen" of vi is that you're speaking a language. The initial y is a verb. The statement yy is a simple statement which is, essentially, an abbreviation for 0 y$:

0 go to the beginning of this line. y yank from here (up to where?)