std::aelloc

Until you see this.

Me every morning:

#lobsters

Lobste.rs has a special tag(#ask) for posts that asks the opinion of the community on an arbitrary topic. Every week, there are at least two posts with this tag.

- What are you doing this weekend?
- What are you doing this week?

Other than that, people usually ask some other things, and today's #ask post is very beneficial to me.

- What is your favorite blog to read recently?

Whenever I read a post on Lobste.rs, I always check if the website has other interesting articles in Blog page. But today, people are listing their favorite blogs which might be useful for many people including me.

Also, other #ask posts in case you are interested:

https://lobste.rs/t/ask

Lobste.rs is lagging right now, please don't visit it, I can't read anything. /s

.gitignore isn't the only way to ignore files in Git.

Article: https://nelson.cloud/.gitignore-isnt-the-only-way-to-ignore-files-in-git/

Having more than one way to ignore files in Git would seem like an overkill, at least it did for me until I read the article above. This post is a TL;DR for it and actually, the article is not that long. It's 3 minutes read time and 443 words.

So basically, you have 3 options to ignore files in Git.

1. Project-wise, consequential.

Listing files you don't want to commit in .gitignore file is the first and the most popular way to achieve it and it will somewhat pollute the repository because you have to commit your changes, and it's an extra content in the diff. However, it still might be necessary depending on the file you are ignoring, the ones other people working on the project should NOT accidentally commit.

2. Project-wise, harmless.

You might have files that are only relevant to you but you wouldn't want to commit, your notes or anything, in this case you can list those inside .git/info/exclude to ignore them in the file tree. Since .git folder is not tracked by git, it's considered a harmless operation and will not pollute the repository history.

3. System-wise, harmless.

The last one mentioned in the article is to list the files in ~/.config/git/ignore file. This is like the second way but works for all projects and you will not have to do it for every single project so it depends on you to decide.

I have configured git using home-manager, and it has an option for the 3rd way, I have copied it from somewhere else and have been using it without even knowing about it. These are the lines from my nix config:

programs.git = {
  ignores = [
    ".idea"
    "node_modules"
    # where did this come from? I don't own Apple Device 🗿
    ".DS_Store"
    "*.swp"
  ];
};

It's an interesting article that I found from lobste.rs, I highly recommend to check both the article and lobste.rs, you might find some other things that are interesting to you, maybe. Lobste.rs deserves another article, where I will try to sell it to everyone who doesn't use it regularly.

Vim Macros are great. But I struggle with applying macros to multiple lines. However, there is one thing I have found related to it.

:g//norm! @a

It's used to apply the macro "a" to all results of the last search.

:g -> global command
// -> last search
norm! -> execute a command in default NORMAL mode(! for force)
@a -> apply the macro

In case you didn't know, Lazygit.

Lazygit is a TUI app for Git and it's very convenient. My brother recommended me Lazygit well before I have switched to Vim, so the navigation felt very strange in the beginning. But once I got used to the hjkl navigation, I liked it more, not just for the navigation but also for the shortcuts.

LG made it easier and so much faster to work with Git, and it visualized new concepts in Git that I struggled with or didn't even know before. For example, stashes. No matter how strange it is, but I have never used stashes before using Lazygit.

Moreover, LG is the reason how I realized that you can stage/unstage only some changes inside a file(hunks).

https://github.com/jesseduffield/lazygit

Splits

After purchasing this keyboard(silakka54), my life was split to two: before and after split keyboard. While it's very hard to give concrete conclusion on this keyboard, I will try to express my subjective feedbacks which I think are pretty much an advantage.

- Thumb keys

Thumbs are the least efficient keys in regular keyboards, because in most cases they are occupied with a single button - space - and BOTH OF THEM. However I can't say I have a maximum efficiency using them. My thumb keys are occupied with the following actions from left to right: Modifier 1, Super, Space, Space, Alt, Modifier 2. The thing is, one of the Space keys could've been used for Enter instead, that would increase my confidence while typing cause I usually have hard time finding Enter with my right pinky.

- Closer Corner Keys (2)

The left red arrow is Escape, the right one is Backspace. The left orange arrow is Control and the right one is Enter, you can compare it with your keys and measure how far they are.
Yes it's obvious because it has fewer buttons than regular keyboards.

- QMK(ZMK if wireless)

Thanks to QMK, it offers a lot of extra functionality that regular keyboards lack such as remapping, layers and macros.

- And Finally... Layers... (3,4)

As you can see Layer 1 has a lot of extra functionality such as Browser Back/Forward, Mouse Up/Down/Left/Right. Mouse 1/2 is for scrolling up and down. Not only that, it's pretty neat to have special keys for Media Play/Previous/Next which will control music or any currently playing media. ▽ key imitates the action of previous layer. Very helpful when used with Home Row Mods from another layer.

Layer 2 is just for home row mods. It's faster to place them in another layer than setting a hold time on your keyboard.

Moreover, ortholinear keyboard(vertically aligned) keys make it easier to locate buttons. But my key caps are a bit against it, so I’m planning to replace them soon(in Summer I hope).

Now, couple of words about disadvantages. My keyboard is wired. That's it.