Firefox extentions

30.05.2018 02:00

Firefox finally did something they should have done a long time ago. They re-wrote their engine, and the result is that they are faster than Chrome. I’m not going into the Safari discussion here, because the Safari team have other priorities over pure speed, like for example battery life.

The result is that Firefox broke a lot of stuff as a result of it. What I’m wondering is how long it will take before plugins are updated – and how many that aren’t. And what Mozilla should do about it? Starting to hide all the stuff that aren’t compatible with the recent versions?


29.05.2018 02:00

My favourite thing about my “post DayOne” life is being able to journal with Org-Journal by hitting ESC SPC ojj in emacs. To journal in my text editor makes it far more likely that I do it, than when it is a separate app.


29.05.2018 02:00

One of the problems with digital photography is that it is so easy to end up with 30 000 pictures shot over 4 four years; and that is after you have deleted a lot of them. I have spent a lot of time the last 8 months or so trying to get rid of as much of the “noise” in that collection as possible. It will probably take a while before I get there. You get rid of 75%, then you give it some time, and repeat it until you can’t remove anything more without loosing something you really care about.

Some people think that machine learning or what ever will solve this problem. It might, for some or to some degree. But I still think we have to do the manual work of deciding what to keep or not. It requires a lot of work, like everything else worth doing.

Moving to Doom Emacs have made it simpler

29.05.2018 02:00

One of the awesome bonuses of moving my Emacs config system of choice from Spacemacs to Doom is that how I sync my configuration between systems are much simpler. Because of the difference in where your additions or modifications live in relation to the rest of the code.

In Spacemacs you have a config file: .spacemacs and then you have all the Spacemacs code in .emacs.d and a folder called “private” in the layer folder in .emacs.d where you add your stuff. Doom on the other hand (on the develop branch) has all its code in .emacs.d and all your stuff in .doom.d. What makes the doom.d folder interesting is that in its init file is where you control what modules to load, but it is also a module of itself. Which menas that you can treat it as your private modules that adds all the extra packages you want and all your configuration.

The great thing about this is that when you want to update or re-install your emacs setup on a machine, all you have to do is to is to clone Doom Emacs and clone / copy your doom.d folder. Instead of how you had to do it with spacemacs

Doom Emacs

28.05.2018 02:00

So I found something called Doom Emacs a few days ago. It is kind of like Spacemacs, a Emacs configuration system / setup with VIM keybindings.

The big selling point of doom over Spacemacs is that it loads much faster. For example on my MacBook Pro it loads in 25% of the time with similar setups.

There are multiple reasons for Doom being faster:

  • It is in general much less code, than in Spacemacs.
  • All the code in Doom uses modern methods to load Elisp code.
  • Doom uses a Makefile to install / uninstall and update packages instead of during startup
  • And you can pre-compile most modules with “make compile”.

Now. Spacemacs is much more “complete” all the built in keyboard shortcuts and command have been set up to be very intuitive and it almost always work exactly how you expect. This means that I think Spacemacs is a better place to start, than Doom. But Doom is awesome if you are afraid of configuring yourself.

Doom features a similar module system to the Spacemacs layer system. But I found it much more intuitive to use myself. Doom itself is also much more like standard emacs than Spacemacs when it comes to configuration. You can use much more code exactly how it would be using plain Emacs.

My favourite thing on the develop branch is that you have the doom code in .emacs.d and then you have your “private” module (exactly the same as other modules) located in .doom.d. This is awesome and makes it much easier to keep your settings in sync on multiple branches than with the Spacemacs structure where you have your stuff inside the Spacemacs repo.


26.05.2018 02:00

I might be very cynical, but I love how Billions portraits everyone as the bad guys.


26.05.2018 02:00

Hello World

The ArchLinux Wiki

25.05.2018 02:00

There are a few Linux resources out there that is beyond awesome, and shows that there are good parts of the world. Where a community come together and make something amazing. The Arch Linux Wiki is one of them. When I want to find out to do something on Linux, the Arch Wiki always come to the rescue. I use it even when I’m trying to do it on other distros or operating systems.

How to fix C# Auto complete in VS Code and Emacs.

24.05.2018 02:00

There are times when the auto complete for C# and .NET Core stops working in editors that use the OmniServer auto complete engine. For me it is Emacs and Visual Studio Code.

Visual Studio Code will give you a hint when it starts, while Emacs will just fail. The problem is that they can’t locate the “dotnet” command. The place you need to start is that you start a Terminal with your shell of choice and make sure that it works there. If it does type “which dotnet” and copy the output.

Then you type sh and enter. Test it there, this is the place where it should fail. There are two ways you can fix it, either by adding the folder where the dotnet binary is located in to the path, or if you are lazy like me by doing something like “ln -s /usr/local/share/dotnet/dotnet /usr/local/bin/dotnet”.

And that should do the trick. As long as you can run the command “dotnet” in sh it should be available anywhere.


23.05.2018 02:00

New camera bag