Howard Melman <
hme...@gmail.com> writes:
> In this case it's particularly egregious
> because sub-x.el isn't documented in the lisp
> manual or in any other manual.
>
> Perhaps a page in the lisp manual describing
> these 11 functions, saying these are
> potentially useful, would mean that someone
> would find them, use them and then we'd be
> able to deem them useful.
Well, *reading* manuals are great if they are
books intented for humans to read, for example
my favorite computer book, which is
@book{internet-book,
author = {Comer},
ISBN = 0138920923,
publisher = {Pearson},
title = {The Internet Book},
year = 1997
}
However when it comes to tech details like this
such books aren't much good, and reference
manuals are only good if there is a good method
of looking up things in it.
Otherwise it is only frustrating to browse tons
of material and often I dislike it so much
I prefer writing new stuff to do the same, just
so I don't have to browse all that unrelated
material before I get to what I want...
So, there should be an explicit algorithm which
can be anything from "use the index at the back
of the book" to "use the
`dynamic-built-in-function'...".
The criteria for if the method/reference is good
enough should be that you should find what you
look for if you know the correct term.
In this case, the result was very bad because
I knew the correct term (to "trim" a string)
but still didn't find the function; worse,
I found the ERC, Gnus, Google translate
trimmers, which is confusing at best and will
result in tangled-up software at worst.
But the method applied was `apropos' (search
string: "trim") and nothing else, so there is
no disqualification of any other method anyone
else may suggest - but it sure isn't a good
start...
Another advantage with explicit methods is
that after you have done it you can turn to
gnu.emacs.help or #emacs and nobody can tell
you anything, except for God willing the answer
you are looking for...