Wed Apr 21 2004
The tiny tools site assures you that if you're "experienced" you'll have no trouble installing the code, so pay no attention to that odd feeling you have that it's a hassle. Once you do have it installed, you can expect to find all sorts of odd little changes in your emacs behavior -- just the sort of thing to annoy the hell out of an emacs user that really is experienced. The benefits you get from dealing with these problems appear to be "tiny", and don't seem to be worth the annoyance factor.
I've just done a websearch on the phrase "tinytools sucks", and for some strange reason I didn't turn up anything. This page is intended to rectify this problem.
If you haven't heard, the "Tiny Tools" purport to be a grab bag of emacs lisp utilities. I was interested in "tinyperl.el" myself, which appears to be a very badly named perl pod browser.
Down below (The Joys of Installing Tiny Tools), I go into some detail on the Tiny Tools experience. Here's a summary of what I found after installing the Tiny Tools package:
If all of that isn't bad enough, something weird is going on with my elisp mode:
When I try and look at the code for tinyperl.el I don't see anything much. The blocks of actual code are hidden from sight by some sort of collapsible outline feature I've never seen before. Messing and munging around, I find that everything between lines like these:
;;{{{
is hidden
;;}}}
I have no clue as to how I'm supposed to unhide it. Emacs narrowing features (e.g. widen) have no effect.
If I switch to text-mode I can see some of it, but it's formatted horribly, it appears to be using ^M as line terminators (macinstosh style text?). I have to swap them out and replace them with ^Js
Searching around a bit (every try doing a web-search on ";;{{{"?)
I get the feeling that this may be "folding.el" at work.
Ah, I guess that that's an xemacs package that the tiny
guys have snagged for their project, which may explain
that "other" directory that puzzled me a bit: other/folding.el
Code-reuse is the first thing all programmers learn, but the second thing they should learn is to avoid gratuitous dependencies. This attitude (if you want some of my code, you gotta have all of it) is incredibly egocentric.
Similarly, while it's all well and good to write code that you personally would want to use, it doesn't mean you should be assuming that everyone else is going to want to use it in the same way. When you install something new, you don't want to see old stuff break, and from the point of view of an experienced user, any unasked for change is breakage.
"Tiny Tools" isn't just a collection of utilities, it's probably better thought of as an emacs fork.
In summary, my first impression is: "Tiny Tools sucks". Let's try that again, for all you search engines in the audience: "tinytools sucks", that is to say "tiny-tools sucks". Tiny Tools are not recommended. Stay away from Tiny Tools. Beware Tiny Tools. "Tiny Tools" are "Big Waste of Time". Tiny Tools considered harmful. Got it?
It occurs to me that it might be possible to just run tinyperl.el without doing too much of that tinysetup shit... and it seems like others have gone down this path also. See this thread from help-emacs-windows
The whole thing seems needlessly confusing in my opinion!
--- Chris Lott
Out of the mouths of Windows NT users...
So, I tried this in my .emacs:
(require 'tiny-setup) (tiny-setup nil) (require 'tinyperl) (autoload 'turn-on-tinyperl-mode "tinyperl" "" t) (add-hook 'perl-mode-hook 'turn-on-tinyperl-mode) (add-hook 'cperl-mode-hook 'turn-on-tinyperl-mode) (tinyperl-install t nil)
Now it *appears* that I can do things like:
M-x tinyperl-pod-by-module
But there seems to be something screwy about the default
keymap, and it seems very inconsistent about whether
it thinks that module names end with a ".pm"... and I don't
see what this gains you over just using the man to
view the man pages installed by all CPAN packages.
Screw it. I don't care that much.
Unpacking the tinytools tarball, this is what I was greeted with:
/home/doom/End/Slot/Emacs/emacs-tiny-tools-2002.0805: total 3 free 7704204 drwxrwxr-x 2 doom doom 768 Apr 16 15:15 bin drwxrwxr-x 4 doom doom 160 Apr 16 15:00 doc drwxrwxr-x 4 doom doom 128 Apr 16 15:00 lisp drwxrwxr-x 2 doom doom 296 Apr 16 15:00 rc
This should've been my first warning. Never trust a tarball from people who don't know enough to put a README on the top level (preferably with an INSTALL right next to it.)
Perhaps down in "doc"? Hm, first choose a format,
"html" or "txt". So two levels down, we find this:
emacs-tiny-tools-2002.0805/doc/txt/README.txt
There are two things I want to know from this README, I want a listing of the stuff that's here, and I want to know if there are any installation quirks. But this README is about 4K long. I find the installation instructions bewildering, covering multiple different possible cases, but somehow not explaining what I want to know.
I try and focus on these two options:
2.2 Quick install -- personal
2.3 Quick install -- site wide
But even the "quick install" instructions have abstruse things like this in them this:
The installation function `tiny-setup' logs actions made to Emacs
into *Messages* or XEmacs *Message-Log* buffer. The output looks
something like this with the default setting _all_. For more finer
control for each individual feature, refer to `C-h' `f'
`tiny-setup'. Messages that read "No options to configure" means
that there is no default installation (yet) and you have to
manually take the package into use by reading its documentation.
The setup is very conservative: anything serious in existing emacs
will _not_ _be_ _overridden_.
I quote this for two reasons: (1) That last line will seem really funny in retrospect. (2) This is another warning sign I should've heeded. "tiny-setup"? Isn't this kind of elaborate for a bunch of "tiny" tools?
So, for whatever reason, I'm having trouble following these installation docs. (Defenders of Tiny Tools take note: this is the point where you should accuse me of being an obvious fool, the sort of idiot who should have known better than to touch your marvelously perfect software project.)
I go back to looking at the overall layout of files. It's difficult to believe that it can be all that hard to install. Installing emacs lisp is usually a matter of copying some *.el files over, adding a location to your load-path, and maybe adding another setting or two to your .emacs file. If there's something more complex going on here, well they'll probably just use the usual GNU tools. Doing a "./configure" a "make" and a "make install" should be all I need to do, right? Heh.
I see that the "bin" directory is a mess of "pl" files with some "sh" and so on thrown in for good measure. But there is some sort of Makefile apparatus down in there, and after some screwing around I get a "make" to work... but it doesn't seem to do anything except compile the elisp in place:
make install There is no automatic install. Please copy whole tiny-tools/ tree to suitable hierarchy e.g. to /usr/share/emacs/site-lisp/packages Refer to doc/README.txt for site wide and personal setup.
Why did these guys bother with a Makefile?
So screw it, I'm doing a manual install. I create a few locations for the elisp, copy it over, add these spots to the load-path, and add to my .emacs a few lines of their recommended setup stuff:
(setq load-path
(append load-path
'("/usr/lib/emacs/site-lisp/tinytools/tiny")))
(setq load-path
(append load-path
'("/usr/lib/emacs/site-lisp/tinytools/other")))
(load "tinypath")
;; Next, auto configure most of the packages with defaults
;; See M-x tiny-setup-display and C-h f tiny-setup
(require 'tiny-setup)
(tiny-setup 'all)
By the way, about adding things to the load-path... Somehow, it doesn't seem to be particularly difficult to me to do this in my .emacs:
(setq load-path
(append load-path
'("/usr/lib/emacs/site-lisp/tinytools/tiny")))
I mention this because one of the tinytools (tinypath.el, I think) is supposed to do something automagical that lets you avoid doing this. This strikes me as symptomatic of the tiny tools in general: some nice clever little hacks that don't do anything you really need and cause more problems than they solve. After all, you need to know how to add tinypath to your load-path before tinypath can do you any good...
One of the first things I notice is that starting up tinypath, it complains about this:
TinyPath: [ERROR] Please create $HOME/elisp
I have no idea if this means I really need this location, or if I need to do something to convince it that I've put the "tiny" code somewhere else, but just to get it to shut up about it, I create it.
Another oddity is that tinyperl keeps bitching about a dead location in my perl's @INC. I don't know why it cares -- certainly perl doesn't -- but I go into my .bash_profile and delete it from my PERL5LIB environment variable. It is however, not all that hard to think of reasons you might want to keep a non-existent location in your @INC, e.g. what if I liked to port this .bash_profile around to different machines with different library locations?
I see that the help for tiny-setup ( C-h f tiny-setup )
is is full of all sorts of exciting information. But
why I would want to understand this for the sake of using
these cheesy little packages remains beyond me.
You know, I write a lot of insanely verbose docs myself -- often on even more minor pieces of code -- but I hope that I at least manage to "make easy things easy". Most people will not look at the docs. If you need to think about it for more than ten minutes to understand a feature, you've immediately screened out 99% of the potential users.
All of a sudden, I can't just type in one double-quote.
For example, if I hit the double-quote key just once,
I get this: ""
...with the cursor positioned inbetween the pair of quotes.
This is disconcerting, but you might argue that it could be
useful once you got used to it.
But now suppose you've typed a line like:
People will tell you with a straight face that the tiny tools package is easy to install if you're experienced.
And you decide that you want to put some phrases in quotes, like "easy to install". So you cursor over to the beginning of the word "easy" and type one double-quote character. This is what happens:
People will tell you with a straight face that the tiny tools package is "easy" to install if you're experienced.
Note: it inserts a second double-quote, helpfully assuming that you wanted to quote that word, and only that word. If you're like me, you expect that when you type a single character, you're going to get a single character, so you quickly cursor ahead to the other location and type one in:
People will tell you with a straight face that the tiny tools package is "easy" to install" if you're experienced.
Interestingly enough, it only adds one double-quote (I might've expected a pair of them, but this is a very "smart"" feature. Oops.) Anyway, now I get to cursor back, delete the excess one, skip forward to the other word I want to quote, "experienced", and type in another single-quote, and I get:
People will tell you with a straight face that the tiny tools package is "easy to install" if you're "experienced."
Now, this is closer to what I want, but unfortunately being a computer geek I'm fussy about what goes inside my quoted strings, and I don't like having that period inside there. On the other hand, that probably is standard english (if that's not too oxymoronic for you), so maybe that's the Right Thing? Hm... what if it was a different kind of punctuation mark? What if that wasn't quite the end of the sentence? I see this case behaves the same way:
People will tell you with a straight face that the tiny tools package is "easy to install" if you're "experienced," huh?
You get the double-quote positioned after the comma... This just looks like lazy programming to me, sticking the double-quote in front of the next bit of whitespace.
So, I really hate this kind of feature, but what the hell, maybe you like it. If I don't like it, why not just turn it off?
The problem is that I NEVER ASKED TO TURN IT ON. "Tiny Tools" volunteered to do this for me.
For more whining, see the rest of The Whinery