Re: Why isn't ert-buffer.el part of Emacs?

[Emanuel Berg]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> I recently discovered 'ert-buffer.el' and find it
> very useful. It is introduced and discussed here
> ... I wonder why such a generally useful library
> isn't included in Emacs (I don't even find it in the
> package repos)?

I stopped reading here, because I don't have any
comments on that specific software.

But, in general, I have found tons of useful stuff that
isn't included, and I have written tons of stuff that I
think should be included, perhaps not my implementation
specifically, but rather the functionality.

And often when I miss something I think - "can it
really be that no one got this idea before me?" - and I
always answer "no, that can't be" because what I want
isn't any eccentric stuff anyway. But what happens is I
still write it myself because I don't know how to find
it. I enjoy writing Elisp, but I don't enjoy browsing
the Emacs Wiki, or Googling for that matter. When I
write Elisp I know what has to be done - when I Google,
it is all so frustrating - how do I phrase that? can
that be that page? no? why not? etc. - I usually phrase
the problem as exact as I can, Google once, try the
first hit, and if no luck, then I write it. It is more
important not to be frustrated than to be
efficient. Besides, do it often enough, your Elisp
skills will "catch up" and for quick fixes Google will
eventually even loose time-wise. Still, if I could just
get it, I would.

I suppose the reason why not more stuff is included in
general is that there is so much stuff around, and it
is so easy to "install" it yourself if you just have
the code. If everything was included, Emacs would just
be all over the place. Remember that Emacs isn't
"modular" in the sense that there is one namespace
(which explains the elaborate use of prefixes in
function names: gnus-group-whatever-what-have-you).

Still, one has to wonder by which standards things are
included? I suppose the maintainers and otherwise
developers of Emacs simply have very keen eyes for
this, and include what they know to be
good. Intuitively that sounds like the most sensible
method as well. (But if I'm wrong, and there is some
formal process, it would be interesting to know.)

The other side to it - how to find stuff if you
strongly suspects it is out there - remember the old AI
"expert systems"? They could do anything from
diagnosing health problems to play "20 questions" (and
they would always beat you). I suppose those were a
state machine (a tree) with annotated questions that
would drive the machine to a leaf based on
probability. Wouldn't that be a cool project for some
CS students?

Here is one example of very basic functionality which I
use a lot, and wouldn't have written if it were there
(obviously) or if I could have found it somewhere,
quick and pleasant: it echos the value of a variable,
i.e., compared to describe-variable, it doesn't require
any new pane (so all the documentation etc. isn't
displayed) - it is just very useful (and basic). (I
have it bound to M-m - without a shortcut it isn't as
fast, as always.)

(defun describe-variable-short (var)
  (interactive
   (let*((v            (variable-at-point))
         (var-at-point (not (eq v 0)))
         (v-name       (if var-at-point (symbol-name v)))
         (v-final
          (completing-read
           (format " variable%s: " (if var-at-point
                                       (format " (default %s)" v)
                                       ""))
           obarray
           (lambda (vv)
             (or (get vv 'variable-documentation)
                 (boundp vv) ))
           t    ; require match
           nil  ; no insert to minibuffer (?)
           nil  ; no history
           v-name
          )))
   `(,(intern v-final)) ))
  (message (format " %s: %s" (symbol-name var) (symbol-value var))) )

-- 
underground experts united:
http://user.it.uu.se/~embe8573