Monday, October 14, 2019

Emacs - Day 1

Day 1 of giving Emacs a try.  After 20+ years of using vim, I wanted to improve my development environment and general workflow at the office.  I found Emacs OrgMode and thought it sounded interesting. The last time I used Emacs was in the mid 90s or so and I couldn't figure out how to exit and got frustrated.  Everyone I knew used a form of vi, so those were the questions they could answer.  And here I am all these years later in vim.  Would I actually like Emacs if I gave it a fair try?  Time to try it out.

DAY ONE

I started by installing the emacs package on my workstation:
dnf install -y emacs
OK, that was easy.  Now run 'emacs' from the terminal and...it launches a graphical program.  I wanted it to run in the console. Searching around, I find the way to do this is to run 'emacs -nw'. You can also install the emacs-nox package, but I might want the graphical one so I will just use the command line option for now.  I added an alias to ~/.zshrc:
alias emacs='emacs -nw'
Easy.  Now to get down to business.  My .vimrc file is not particularly large and I have never really been comfortable with VimScript.  Without getting in to that now, I decided to just use the default Emacs configuration to edit and save some source files.  This also has the advantage of making me learn the Emacs defaults.

I opened a C source file and made changes.  I did have to go and look up how to exit.  I used Ctrl+x Ctrl+c and it asked me to save, so I said yes.  I hope I get better at this.

So, some success.  I will admit I had a lot of unexpected "i" characters appearing throughout the files I edited, but I would expect that right now.  I want to go through my .vimrc and figure out what I want ported over to the Emacs configuration.

Wednesday, October 9, 2019

What? You're using Emacs?

I have been a vim user for a long time, but I'm also lumping in various varieties of 'vi' in with that.  For most of the time I have used vim, but there were times where I used nvi or elvis or the vi that came with some variant of a commercial Unix operating systems.  But why?

Mostly because it was the first editor someone showed me how to use and then it just sort of went from there.  I maintain that the vi vs. emacs argument is flawed because both programs require training yourself over a long period of time.  There is nothing inherently intuitive about either of them.

I'm going to say that I've been a vim user for 20 years.  I started using it before that, but those years were a mix of nvi, elvis, and vim.  And I'm going to subtract some years from that because I didn't make effective use of my .vimrc until later.

I have never given Emacs a real shot.  Mostly because I didn't want to invest all the time in to learning another program that was still going to leave me with just another editor.  And for a long time I didn't care.  But recently I have found myself wanting more out of my development environment.  I have tried many vimscript plugins and external tools and they are nice, but I still have about a zillion vim sessions open and it never quite feels well integrated.  Internet tells me that people have nice Emacs setups for development, so maybe I should try that.

OK, I'll do it.

About a month ago I looked in to doing this and then about 3 weeks ago I decided to make it happen for real.  On my workstation at the office.  I installed emacs and removed vim.  When I type 'vim' now, I get command not found.  I forced myself to use emacs as-is without modifying the configuration file for the first week.  I made notes on paper and focused on the basic commands and training myself out of vim muscle memory.

I have also been writing up blog posts to post later as I have moved over to Emacs.  I am still using it and I like it.  I will post my Emacs entries later, but for now I will post a link to my now growing .emacs file.

Tuesday, October 8, 2019

rpminspect-0.7 released, bug fixes and a new integration test suite

rpminspect-0.7 has been released.  The main things in this release are a new integration test suite and many bug fixes.  There is one new user feature and that's the -t or --threshold option.

The -t option lets you control the result code that triggers a non-zero exit code from rpminspect.  By default, this is set to VERIFY.  But you could set it to BAD or INFO or any other valid result code in the program.  The result code specified by this option means that any result in rpminspect at that code or higher will trigger a non-zero return code.  Combined with the -T option, this can be a useful tool for some types of CI system integration.

As always, thank you for the bug reports and pull requests!  The next release will likely take the same amount of time and will continue to focus on stabilization with the test suite.

This release is available in my Copr rpminspect repo as well as for rawhide and F31.  Please let me know if you have any questions.