Wednesday, October 23, 2019

Emacs part 3

I have removed vim from my system.  Not because I am completely sold on emacs, but because I keep typing vim out of habit and I want to train myself to remember to type emacs.

My ~/.emacs file is growing.  So far I have this in it:
(package-initialize)

(require 'package)

(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/"))
(package-initialize)


;;; Prevent tabs and use 4 space tab stop

(setq-default indent-tabs-mode nil)
(setq-default tab-width 4)
(setq-default indent-line-function 'insert-tab)

;;; Put backup files in one place

(setq-default backup-directory-alias '(("" . "~/.emacs.d/backup")))
I have not done much to my configuration and that continues to be deliberate.  I have learned some new commands based on things I would frequently do in vim:

  • Ctrl-x i
Like ":r FILENAME" in vim, inserts the named file at the current cursor position.
  • Meta-g Meta-g NUMBER
Like ":NUM" in vim to go to a specific line number.  You type the number after the keystrokes and press Enter.

The Meta key is mapped to Alt on my keyboard despite there being a perfectly suitable Meta key.  I may remap it later.

Things I am still trying to figure out in emacs:
  • How to disable automatic formatting.  In vim I only had this enabled for certain types of source code files.  I want to turn it off by default in emacs.
  • Something like "set bg=dark" in vim.
  • How to show trailing whitespace on lines as dark grey characters.  In vim, I displayed trailing spaces as dark grey periods and trailing tabs as dark grey |_ blocks.  This has to be possible in emacs.
And the day continues.

Friday, October 18, 2019

Emacs part 2

Well, it's not really day 2 but close enough.  I have been using emacs mostly for some days now and feel more comfortable with it.  In fact, I am writing this in emacs now.  The day 1 log was written in vim.

I am still making minimal configuration changes to emacs and am not using the vi helper mode.  I want to learn the emacs keystrokes rather than rely on my vim muscle memory.  This has been difficult, but is getting easier.  So what have I learned?

First, I found a one page emacs cheatsheet that I printed out and put on my desk.  It is easier than searching the web each time I want to remember a keystroke.  It does use emacs jargon for some things, which may be frustrating to some, but I am also trying to get used to that. For example, emacs use of the word buffer or kill.

I have successfully gotten used to opening files, saving files, and quitting the program.  Three things I consider essentially to using an editor.  I have also been using the forward and backwards search capabilities.  One thing I have not quite figured out how to do is delete an entire line similar to how vim did it, but there may not be a direct way.

In vim, I can type dd in command mode and it will delete the current line regardless of where the cursor position is on that line.  The line is removed and the entire file shifts up.  I have found Ctrl+k in emacs which has similar but slightly different behavior.  If I am in column 0, it deletes the entire line but leaves the newline in place. If I am in any other column, it deletes the line and brings the next one up to join where the newline was.  I may not be completely
understanding what's happening, but it's not a deal breaker.

I would like to make better use of emacs buffers, but that will come as I continue to use it day to day.  Until the next log entry... Ctrl+x Ctrl+c

rpminspect-0.8 released (and a new rpminspect-data-fedora)

Work on the test suite continues with rpminspect and it is finding a lot of corner-case type runtime scenarios.  Fixing those up in the code is nice.  I welcome contributions to the test suite.  You can look at the tests/test_*.py files to see what I'm doing and then work through one inspection and do the different types of checks.  Look in the lib/inspect_NAME.c file and for all of the add_result() calls to figure out what tests should exist in the test suite.  If this is confusing, feel free to reach out via email or another means and I can provide you with a list for an inspection.

Changes in rpminspect-0.8:

  • Integration test suite continues to grow and fix problems.

  • The javabytecode inspection will report the JAR relative path as well as the path to the embedded class file when a problem is found. (#56)

  • libmandoc 1.14.5 API support. rpminspect will continue to work with 1.14.4 and previous releases and will detect which one to use at build time. The mandoc API changed completely between the 1.14.4 and 1.14.5 release. This is not entirely their fault as we are using it built as a shared library and the upstream project does not officially do that.

  • rpminspect now exits with code 2 when there is a program error. Exit code 0 means inspections passed and exit code 1 means there was at least one inspection failure. (#57)

  • If there is a Python json module exception raised in the test suite, print the inspection name, captured stdout, and captured stderr. This is meant to help debug the integration test suite.

  • Fix the Icon file check in the desktop inspection. Look at all possible icon path trees (set in rpminspect.conf). Also honor the extensionless syntax in the desktop file.

  • Fix the Exec file check in the desktop inspection so it honors arguments specified after the program name.

  • Fix a SIGSEGV when the before and/or after arguments on the command line contain ".." in the pathspec.

  • [MAJOR] Fix fundamental problems with the peer detection code. The integration test suite caught this and was leading to false results.

  • Add the IPv6 function blacklist check. The configuration file can carry a list of forbidden IPv6 functions and raise a failure if it finds any of those used.

Changes in rpminspect-data-fedora-0.6:
  • Change bytecode version to be JDK 8
  • Add desktop_icon_paths to rpminspect.conf

Many thanks to the contributors, reporters, and testers.  I am continuing on with the test suite work and new inspections.  Keep the reports coming in.

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.