Rambling About Vim

Well, long-time a Vim user like everyone else in the wild. This is just a recollection of good and not-so-good stuff about this editor. Day-to-day activity performed on this editor. Especially the system config file editing. It is getting into the act without much ado, every time. The downside is that I need to remember a few strokes to operate on it effectively. Okay, muscle memory sometimes overflowed and things skip off it. Although that can be fixed in a whisk with little dabble, still that is not natively built or done.

So, users have to spend some time figuring out which fits their memory muscle. It is a lean editor with an extremely powerful capability to do almost everything you can dream of. But, at a cost of bringing complexity (like every other software) to get it extended or enhanced.

Plugins do solve a lot of owes. But, they bring baggage too, and as a result, the parsing (the config file) takes time to react, which gets into nerve sometimes. As you grow along with it and comes to know the nuts and bolts of it, you started to throw away the external thing i.e plugins, and look for an option to do thing natively, which means finding a way to replicate that functionality provided by the plugins to writing some own script by manipulating vim own language.

Engaging in some sort of daily activity like coding or writing plain text files are blazing-fast activity. Of late, certain stuff allows writing markdown files as well. In fact, with some effort and tools, you can write almost anything stuff on it.

Some people are also crazy enough to try it convert as IDE because their workflow involves doing various activities and they wanted to live inside the editor to accomplish every little piece inside it.

Minimalist nature depends on the person’s needs. My requirements are very minimal because I don’t do rocket science and hover on some predicted place or do very deterministic stuff most of the time.

Vim allows you to write your own plugins and macros like another editor (i.e Emacs) to extend convenience and efficiency. Macros save a hell lot of time to do repetitive tasks with smooth incorporation of macros. And with little digging you can save those macros with name , so you can call them by name rather remembering the process.

Okay, every “Vim Experts” tell people to look into the help text ,but is the help text always helpful? I doubt it. But, know how to look for it good thing to learn. Looking at the help page is one thing and interpreting the instruction is other thing. Ofentimes people misinterpret what has been there in the help text. Other times there missing the concrete example about the stuff. Well, it is easy to complain and whine, but to make things easy for others. So, when the built-in stuff failed you, do something which made your life with this editor. Write some of your own understanding in words that conveys to your brain to grasp something you are looking at. Bring them out whenever you need a theme. I have made some of my own just for the sake of my understanding, eliminating the big padded words and instruction(basically esoteric and arcane stuff).

I do make keybinding as memory friendly as possible. So, with little effort, you can easily bring that to work.

Over the years I do accumulate lots of stuff in my vimrc , but I do need them. But, I am in the process of eliminating all the less required stuff from it. I have already incorporated a few themes in a different way. The overly crowded file might affect the runtime as well as performance.

I am getting rid of plugins once by once. Because I have seen a lot of work can be done with whatever built-in stuff shipped with the editor. Plus, it allows me to write small vim scripts to accomplish things I want. This is purely an excuse to learn and know more about the editor of choice. So, in essence, I am trying to give myself chance to catch up with the inherent facilities provided by the tool. But, with the effort I put in, the outcome is not always pleasant, going down the rabbit hole is the norm. Sometimes I do enjoy it, but you know, it pisses me off other times.

Every passing day brings something new to discover and implement, it is a vicious cycle, that takes some taking to stop doing anything.

But, sooner you discover that it is better to stop that mad pursuit. Because it is taking a toll on you and the performance of your tool. Tweaking the existing thing is fine for enhancement, but adding stuff every now and then is often less desirable.

🙂 To nullify whatever I said here is my convoluted and overly large Vimrc_At_GitHub .

How do I send patches to Linux Kernel Mailing list

Well, during this pandemic, I started to look deeply into the Linux kernel and due to some tenacity, I have sent some patches to the Linux kernel mailing list. Some of them get accepted, a few get ignored and a few get some comments.

Sending a patch to Linux kernel mailing is a daunting task. The preparation and environment set needs some time and careful decision.

Send a single patch or series of patches needs a different kind of approach. So, after a while bugged by my stupidity, I decided to automate stuff to get it done with minimum fuss.

Here is the code for sending a single patch to the mailing list :

How to send a single patch

send_patch() {

        printf "\n Acquire those mail address attached with this file.....\n\n"

        get_email_addresses

        printf "\n\n THE PATCH FILE IS BELOW \n\n"

        git format-patch -1
        patchfile=$(basename *.patch)
        to="--to=$(cat email_list)"
        cc="--cc=linux-kernel@vger.kernel.org"
        an="--annotate"

              printf "\n Checking values before sending the patch ....\n"
              printf "\n ${patchfile}  ${to}  ${cc}\n"

              printf "Is it look alright?? [Y/N] : %s"
              read consent

         if [[ "$consent" == "N" ]];then
              printf "\n\n  Patchfile and TO fields must be filled, it seems values are missing..so,aborting.\n"
         else
              git send-email $patchfile ${to} ${cc} ${an}

              printf "\nGetting rid of temp files....\n"
              rm -f email_list
              mv -v *.patch  ~/patches_sent/

          fi.
  }

Well, if the code looks complicated, it is because of my fat head and stupidity. I couldn’t figure it out, how could I do it better way. So, stick with it and it provides the stuff I needed.

Okay, one thing that might confuse you, is **get_email_addresses”,. Which is look like this :

get_email_addresses() {

        filename=$(git log -1 --name-only --oneline | grep /)
        scripts/get_maintainer.pl  $filename | tee $filename.$(date +'%T') 1> /dev/null
        extract_email_address $filename.* | paste -s -d, - > email_list
        rm -f $filename.*
}

Well, it is also not so straightforward, took me way more time than needed to figure this out.

How to send patch series

Here is what I have used :

patch_series() {

        patch_dir="/home/bhaskar/git-linux/linux/batch"

        printf "\n\t Creating a patch series.....pls get the relevant email from MAINTAINERS file\n\n"

               printf "\n Mention comma separated maintainers email .... : %s"
               read man_email

               to="--to=$(echo ${man_email} | paste -s -d, -)"
               cc="--cc=linux-kernel@vger.kernel.org"
               an="--annotate"

        printf "\n Pick the starting and ending commit for patch series range..\n"

                  git log --pretty=oneline --abbrev=committed | head -20


         printf "\n Select the first commit of the series : %s"
         read start_commit

         printf "\n Now Select the end commit for the range : %s"
         read end_commit

         if [[ ! -d ${patch_dir} ]];then
                 mkdir -p ${patch_dir}
         fi

        git format-patch -o ${patch_dir} --cover-letter -n --thread=shallow ${to} ${cc} ${start_commit}^..${end_commit}

        printf "\n\n Check the patch has been created properly or not....\n"

             find $patch_dir -type f -ls

             printf "\n Is it looks alright?[Y/N]: %s"
             read res

             if [[ $res == "N" ]];then

                     printf "\n Nope, it doesn't look good..aborting\n"
             else

                    printf "\n Actually sending the patches ....\n\n"

                   git send-email --to-cover --cc-cover $patch_dir/*.patch ${an}
             fi
}

Okay, it is hell, I have tried my best to strip out as much complexity as possible. Couldn’t dilute more, my lacuna.

All the pieces are in my .bashrc and available on Github_Dot_Bashrc

Hope this will help someone.

How do I send patches to Linux Kernel Mailing list

Well during this pandemic ,I started to look deeply into the Linux kernel and due to some tenacity , I have sent some patches to the Linux kernel mailing list . Some of them get accepted,few get ignored and few get some comments.

Sending a patch to Linux kernel mailing is a daunting task. The preparation and environment set needs some time and careful decision.

Send a single patch or series of patch needs different kind of approach. So, after a while bugged by my stupidity,I have decided to automate stuff to get it done with minimum fuss.

Here is the code for send a single patch to the mailing list :

How to send single patch

send_patch() {

        printf "\n Acquire those mail address attached with this file.....\n\n"

        get_email_addresses

        printf "\n\n THE PATCH FILE IS BELOW \n\n"

        git format-patch -1
        patchfile=$(basename *.patch)
        to="--to=$(cat email_list)"
        cc="--cc=linux-kernel@vger.kernel.org"
        an="--annotate"

              printf "\n Checking values before sending the patch ....\n"
              printf "\n ${patchfile}  ${to}  ${cc}\n"

              printf "Is it look alright?? [Y/N] : %s"
              read consent

         if [[ "$consent" == "N" ]];then
              printf "\n\n  Patchfile and TO fields must be filled, it seems values are missing..so,aborting.\n"
         else
              git send-email $patchfile ${to} ${cc} ${an}

              printf "\nGetting rid of temp files....\n"
              rm -f email_list
              mv -v *.patch  ~/patches_sent/

          fi.
  }

Well, if the code looks complicated, it is becasue of my fat head and stupidity.I couldn’t figure it out, how could I do it better way. So, stick with it and it provide the stuff I needed.

Okay, one thing might confuse you ,that is **get­email­address**(the forward slash to escape this org buffer markdown syntax). Which is look like this :

get_email_addresses() {

        filename=$(git log -1 --name-only --oneline | grep /)
        scripts/get_maintainer.pl  $filename | tee $filename.$(date +'%T') 1> /dev/null
        extract_email_address $filename.* | paste -s -d, - > email_list
        rm -f $filename.*
}

Well, it is also not so straight forward, took me way more time then needed to figure this out.

How to send patch series

Here is what I have used :

patch_series() {

        patch_dir="/home/bhaskar/git-linux/linux/batch"

        printf "\n\t Creating a patch series.....pls get the relevant email from MAINTAINERS file\n\n"

               printf "\n Mention comma separated maintainers email .... : %s"
               read man_email

               to="--to=$(echo ${man_email} | paste -s -d, -)"
               cc="--cc=linux-kernel@vger.kernel.org"
               an="--annotate"

        printf "\n Pick the starting and ending commit for patch series range..\n"

                  git log --pretty=oneline --abbrev=committed | head -20


         printf "\n Select the first commit of the series : %s"
         read start_commit

         printf "\n Now Select the end commit for the range : %s"
         read end_commit

         if [[ ! -d ${patch_dir} ]];then
                 mkdir -p ${patch_dir}
         fi

        git format-patch -o ${patch_dir} --cover-letter -n --thread=shallow ${to} ${cc} ${start_commit}^..${end_commit}

        printf "\n\n Check the patch has been created properly or not....\n"

             find $patch_dir -type f -ls

             printf "\n Is it looks alright?[Y/N]: %s"
             read res

             if [[ $res == "N" ]];then

                     printf "\n Nope, it doesn't look good..aborting\n"
             else

                    printf "\n Actually sending the patches ....\n\n"

                   git send-email --to-cover --cc-cover $patch_dir/*.patch ${an}
             fi
}

Okay, it is hell , I have tried my best to strip out as much complexity as possible. Couldn’t dilute more, my lacuna.

All the pieces are in my .bashrc and available on Github_Dot_Bashrc

Hope this will help someone.

Rambling about Emacs

Well, it looks to me that people are grossly is-comparing with another editor (i.e vim). First of all, they are not comparing running vim on tty and running Emacs on tty. They are/were comparing vim running in tty to Emacs’s GUI environment, which is absolutely wrong.

There is some fundamental stuff that I have noticed, although I started using Emacs much late, in spite of knowing its existence for a long long time. Well, I was and still use vim as my main configuration editor. The reason is that I am so accustomed to it from the very beginning.

Now, during this pandemic, I decided to take a peek at Emacs, and boy! it is a bloody huge and powerful environment(mind you I am referring to Emacs GUI). It has so many nuts and bolts, and importantly you do not need all of them. Likewise, Vim has so many things, we are happy to ignore because those parts are not required day-to-day work. But having said that, knowing bits and pieces along the way is building your arsenal with more tools, just like as we grow old we gather more phrases to communicate.

But, trying to learn all at once is a pretty common mistake almost all ordinary mortals do, a rush to get over things that take more time than the rushes offer.

I am pleasantly surprised by the plethora of tools offered or already built into it the environment. As always, there is a number of third-party packages to provide more utility to harp on. But, there is a caution of tell, that you need to be very careful about the stuff you are bringing into your system. In general rule, the cleaner the system is, the better the system runs. But opting for it to cut out so many goodies and eye candy stuff, it is a nature built into human beings explore more, so we look for it and get it. Moreover, if you are connected to the internet, chances are high that you get more stuff than required all the time.

A vanilla Emacs has so many things, as a modern peasant’s desire should meet almost 75% if not all. For the extra mile, there are always goodies available on the internet. In fact, people are developing stuff(sometimes very redundant) for their needs and keep some specific target users in mind.

I, personally use my conscience to decide, what actually I need to accomplish the work. It happened in the past when I used a tool, once the specific job was done with that tool and I realized those tools are not needed anymore, so I threw it away. Keeping the system in a minimal state is my utmost goal of mine.

Presently, I am having almost 190 packages on top of vanilla GNU/Emacs, which is quite a bit I think. And I am in the process of getting rid of redundant stuff plus unused ones.

But, a few things are still missing in that GUI environment and everyone knows about those. People have gone this far, as to use Emacs as their Window Manager(i.e EXWM), that kinda bold step, but lacking the required basic stuff probably hinders people to opt for it full time. Well, EAF is good but heavily relied on Python and QT and people are there who despise and refrain from both of them for some other reasons. There is also emacs-webkit which tries to port WebKit as the back end to provide facilities within the Emacs environment. That is kinda bleeding-edge stuff and it requires Emacs version 28 and up. If you decided to give it a shot, you have to compile Emacs from the source to get it going. At least on any GNU/Linux the standard shipment is 27.2.

I would specifically like Emacs to be yet another software and important one in my system rather than completely running the system on it. YMMV

So far I have enjoyed the facilities offered by it to some extent and continually looking for streamlined it. Getting help from unknown people on the internet is plus of having been connected to the internet.

Learning the intricacies of system operation, like the importance of keyboard macros is useful in several ways. I have made a few for my convenience. And editing those macros in the future is even more invigorating, which means you can add and subtract to the macro you defined previously cool.

I have made some shortcuts for frequently used applications, and those shortcuts help to open the application quick way. Also knowing some specific in-built shortcut keys will help you go the distance. For that specific purpose, which-key is wonderful. This package will help you find the command as well as keys related to it in pop, so you don’t have to remember all.

Org-mode is good but overblown by the fanatics. You can accomplish so many things with text and other facilities provided by it like markdown kinda thing and hyperlinking. Plus you can easily convert those textually written stuff with org syntax into HTML, latex, and many other forms too. So, it is a handy thing to know, how to manipulate stuff with minimal fuss. This model is specifically highlighted to do GTD and literate programming, which is kinda cool.

Are you fond of music? It has a bloody good thing called EMMS , which is the Emacs Multimedia System. But alas! it missed the video player, which you can easily achieve by selecting the video file in Dired buffer, selecting it pres ampersand and it will play stuff system default video player.

A textual browser will be at your disposal, called Eww and there are others. Unfortunately, a full-blown browser inside Emacs is still a WIP (I meant to say natively). It is okay for me, I do use VIMB and I kinda like it for its minimalist nature and overhead. But with that emacs-WebKit with that, I might be able to run it inside Emacs once upgraded to 28.

Okay, pdf-viewer natively works with a software called ImageMagick, the pdf-viewer tool converts pdf to png and then rendered it as pdf inside Emacs. Which is kinda okay for me, but might not be for you.

Like with other every software, it takes time to get accustomed to it by doing daily use, otherwise, the time might increase to get a grasp of it.

I do like Emacs as “One of the software” in my system and do use it in tandem with other stuff every single day.