stargrave's blog

At last I realized that zsh shell is really much more useful and better to use than either tcsh or far much than bash. Many shells provide different very cool features, that looks like a killing feature, but in most cases, for me, all of them are in seldom use. tcsh has plenty history substitution options, as bash has large quantity of parameter expansion techniques. But I hardly use even a small piece of them. Of course they can greatly reduce overall character input count, but are too bloated to remember.

One of the most often mentioned zsh‘s feature is it’s commands completion. It is convenient possibility to use fancy menus to either select process you are going to kill, or git’s subcommand to execute. Or maybe just to choose corresponding directory or filename. Well, sometimes, in my opinion, this can be pretty useful, but character count during those menus exploration in most cases, visual analyzing of all those entries leads to too high interaction (human with computer) delay and I will enter two more characters of filename and complete it with Tab faster. Entering filename’s part and hitting Tab is one context, but looking for necessary entry is uncomparable another one. Context switching is an expensive operation.

Moreover all those completions can be very relaxating: you will forget your files hierarchy, forget what options does command have, forget what targets exist in your Makefile, forget how to easily automate PID saving and killing by it, forget how to either make cool shell aliases or write yet another extra useful small Perl-script. Of course there is no distinct border of those unskilled relaxation: if there is file “foo” and “bar”, then obviously there is no need to force hacker typing it’s fullname. Remote SSH directories transparent observation and completion is another undoubtedly useful feature. But all of those completions exist in other shells except zsh.

Anyway there are some killer features that made me zsh hard fan and currently no word about switching back to either tcsh or bash. Here they are:

• multiline editing capabilities are extremely useful without creating many temporary one-time separate shell-scripts. And of course you can easily edit them inside external text editor.
• **/*-like various path expansion that saved me from huge quantity of find occurrences and together with *(.)-like things your will forget about it in most cases at all. I had several aliases and external shell-scripts, all calling find, but now throw them out.
• command spellchecking — tcsh already had this feature, but bash did not. With high speed typing, error rate is pretty high too and this feature can save much time and nerves.
• autopushd possibility — each cd to directory acts like pushd and you can easily travel back like in your browser. This feature is particularly useful together with Z plugin.
• autocd option is also presented in bash. It is under a big questions of usefulness, as ambiguity may appear too often with it. With this option you can suppress cd before directory name and shell automatically understands that you are going to change it.
• filename extension related aliases that saves a lot of time from entering zathura to view PDF files, sxiv for images and so on.
• it is much faster than bash. Without turned off unused extensions it starts faster, runs faster, completes faster. Each dozen of milliseconds are nice to spend not awaiting for many-bogomips powerful computer.

And there is separate killer must have plugin that I met firstly when using bash (it also works with zsh of course): Z directory jumper. It tracks each time you change directory and offers quick jumping to previously visited place identified by regular expression and directory visiting frequencies. And it works perfectly with autocd and autopushd.

zmv feature looks very promising and seems that it will replace another bunch of Perl/shell-scripts from my computer. However it requires some learning curve of course.

There are plenty of reasons why I still do not understand why people like Gmail’s webmail so much and are ready to replace powerful desktop email clients.

Critical issues

No threaded conversation view

There is no threaded conversation view. What a hell!? Even simple mailx under every modern GNU/Linux distribution can display messages in threaded view. Email nature itself, it’s In-Reply-To, References and similar fields assume that any conversation can be a graph like, not linear. Of course you can create really linear thread, where every next message is In-Reply-To the very first threaded starting. But Gmail does not do that and In-Replying-To the message you are really currently answering.

I think that root of that “problem” lies only within huge quantity of cyberspace newcomers, that are not capable of serious long-term discussion with many new questions arising during it and that have to be separated from the main thread. Those people mostly have never met situation where technical discussion may lead to completely different and more important various subjects. Most of them tend to mix unrelated discussion subjects in single letter.

It is just simple lack of discussion experience. Of course either instant messaging or IRC chatrooms have nothing similar and they offer just a raw one huge heap of short messages. It is chatting, nothing more and that behaviour is acceptable there. But email was born as a powerful tool of convenient conversation without big piles of weakly referenced messages with low total overall signal-to-noise ratio. For over several dozens of years this email nature have never been seriously changed, because it is really cleaver and fine. So many hackers can not be wrong.

Google turned it to yet another instant messaging system. It does not use specific protocols like XMPP for that, but SMTP one. It destroys all graph-like structures by their linearization. Newcomers just can not learn how to deal with real serious discussions (like hackers do), because they do not have an instruments for that.

Ignoring of In-Reply-To header fields

Gmail does not look for In-Reply-To messages fields to determine if it is starting of a new thread. If you change message’s subject (just to clarification for example), then it will be recognized as a new thread, however you clearly tell in In-Reply-To field that this is reply to exactly that message of the same thread, not another one. Long-term discussion thread with several branches is divided to unrelated isolated linear conversations, however headers did not allow this behaviour.

Lack of headers control

Moreover you can not control your own message headers. You can not forcefully split thread (removing In-Reply-To and keeping subject same). You can not join mistakenly dismembered thread. You can not use some mailing list management software that is controlled through message headers fields. You can not add just simple informational fields, for example just to mention your your PGP public key’s availability.

Lack of any maillist related functionality

As mentioned above, there are no “thread split” and “threads join” actions. Also there is no “reply to list” buttons. Just only trivial “reply” and “reply to all”. This is the reason why people send messages twice to one recipient so often (duplicating it through already including maillist and by CCing him simultaneously). Gmail have no ability to show either are you subscribed to a maillist and there is no need in separate reply message intended for you, or you are not subscribed and should be CCed. It does not support Mail-Followup-To header. You can not add it, because you are not allowed to edit headers. You can not take it in action non manually, because there is no “list reply” functionality, again.

No scoring

There is no such powerful thing as message scoring. But many desktop email clients lack this feature too. You can specify various rules that alter message score. You could sort all correspondence by this score, leaving trivial notifications at the bottom and moving to thrash after reading. You could easily wipe unneeded messages, could easily find important things. Gmail’s mailboxes are just a huge heaps of equally scored letters.

Supporting obsolete RFC standards

Gmail encodes attachment’s filenames in obsolete RFC2047, instead of modern and everywhere supported RFC2231. I said everywhere? Of course with exceptions: Microsoft Outlook products will never be on a technologies bleeding edge. Gmail seems to be on the same way.

Attachments censorship

Gmail does not allow you to send Windows executable binaries of any kind in any form even when using it without webmail interface. Even if you will change attachment’s Content-Type, filename’s extension, put it in archive, compress that archive. They say that this is because of security. Why are they making decisions of that will be secure for me? Who the hell they are? It is my choice, my problems and my responsibility to send my own compiled binaries to someone awaiting for them.

Annoying things

• Unability to forward message as valid correct RFC822 email attachment, keeping all headers and attachments as is.
• You do not know how spam-filtering works and you can not adjust and control that blackbox.
• No regular expressions support or complex search queries (comparing for example with Mutt). But I agree that this is seldom actions for most of us.
• No way to either specify or override attachment’s MIME type.
• You can not send just single file/attachment. It always will consist of an empty text part and an attachment itself.
• No possibility to turn of line wrapping, for example either to insert patch/preformatted text contents as is or draw ASCII schemes.

And of course an obvious lack of PGP de-facto standard for privacy greatly reduces all potential usage possibilities of that webmail.