help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: describe-mode "some-mode"?


From: Emanuel Berg
Subject: Re: describe-mode "some-mode"?
Date: Mon, 01 Sep 2014 00:27:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Drew Adams <drew.adams@oracle.com> writes:

>> Why isn't such a helpful feature itself vanilla?
>
> There are lots of helpful features that are not in
> vanilla Emacs.

Yes, which is good. But I believe many should be part
of vanilla Emacs, especially those that do things that
can be considered atomic or very general.

Best example I can think of, and one I have mentioned
many times on this list, is the describe-variable-short
here [1]. It echoes the variable's value in the echo
area. Simple as that.

But there are many, many examples I've come across that
are super simple, very atomic and general but
nevertheless seemingly nowhere to be found and Google
don't show any either. Probably so easy that most
people just write it. And after finding nothing, that
is what I do as well!

> The choice is up to the Emacs maintainers.

Yes, of course. 

> (And one person's helpful feature is can be another's
> PITA.)

Only if it gets in the way!

If it doesn't, you are free to use whatever features
you like.

And: Features are good. A bicycle repair shop has all
the tools of the trade. Tools that aren't used
frequently (but still, sometimes) are put on hooks on
the wall. They don't bother anyone but when they are
needed, they are right there.

> No, they don't - see my first message. (It has nothing
> to do with `message-mode'.)

That's what I used to test.

> The first one does not try to include minor-mode
> info. That's easily added if you want it.

I don't have an opinion if they should be included -
probably not, if this is to describe the major mode. I
just thought the functions were identical.

> The point was to show that all of this is already
> available, even if not in the form of a ready-made
> command. The function `documentation' that you were
> looking for, is used here, for instance.

Yeah, well, in a way everything is always available
with programming but now I talk in the sense
"instantly" available, i.e., the existence of such a
command.

> As is typically the case, the elements of what is
> needed to cobble together such a "feature" (command)
> are in the Emacs code. E.g., just look at the
> definition of `describe-mode'.

Yes, I know, I have myself done such thing hundreds of
times. Some of those times it has been called for, but
many times it is to my mind features that are not
specific to me but should be there for everyone. Next
time I come across such a situation, I'll report it to
this list and hopefully someone can tell me if such a
feature exists, if it exists somewhere else (if so, how
to look for it), and if no to both questions, where I
should publish my solution for the next guy around.
Right now, this discussion is a bit hollow because I
don't have such an example. [Read on, I remembered
several writing this.]

> It often happens that a given user wants a simple
> command to do XYZ, while other users don't feel such
> a need.

If a user wants XYZ, and there is already X, Y, and Z,
I don't think XYZ should be added, unless that's the
only use case for X, Y, and Z.

But if the user want W, and W isn't related to the
user's taste or personality - it is just a simple unit
of computation - then it should be added.

There is one `degrees-to-radians' in float-sup.el. But
it is a macro, not a function. I like it a function.
That is super-simple for me to do. But I still think
there should be such a function in vanilla Emacs. Is
it? If not, where should I look for it? If I don't find
it, where should I publish it if I write it?

Here is another example.

(defun yank-pop-back (&optional arg)
  (interactive "*p")
  (yank-pop (if arg (* arg -1) -1)) )

> And core Emacs features change over time too - usually
> for the better.

Yes, of course.

[1] http://user.it.uu.se/~embe8573/conf/emacs-init/help.el

-- 
underground experts united


reply via email to

[Prev in Thread] Current Thread [Next in Thread]