[Top][All Lists]

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

Re: Perhaps rearrange *Help* buffer a bit?

From: Basil L. Contovounesios
Subject: Re: Perhaps rearrange *Help* buffer a bit?
Date: Mon, 08 Jul 2019 22:24:35 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Lars Ingebrigtsen <address@hidden> writes:

> I think Drew (or somebody?) mentioned this in a bug report the other
> day: The way the automated stuff is arranged in the *Help* buffer is
> perhaps not optimal.
> Consider:
> ----
> cadr is a compiled Lisp function in ‘subr.el’.
> (cadr X)
>   This function has a compiler macro ‘internal--compiler-macro-cXXr’.
>   Probably introduced at or before Emacs version 20.
> Return the car of the cdr of X.
> ----
> car is a built-in function in ‘C source code’.
> (car LIST)
>   Probably introduced at or before Emacs version 1.2.
>   This function does not change global state, including the match data.
> Return the car of LIST.  If arg is nil, return nil.
> Error if arg is not nil and not a cons cell.  See also ‘car-safe’.
> See Info node ‘(elisp)Cons Cells’ for a discussion of related basic
> Lisp concepts such as car, cdr, cons cell and list.
> ----
> So the thought here is that those indented lines isn't what's most
> interesting to the user.  The compiler macro stuff is interesting to
> about two people in the world, and the "introduced at or before" to
> seven.

Don't forget me!

> What people want to know is the calling convention (line 3) and
> the stuff a human has lovingly written (starting in line 8 in both these
> examples).

And in the case of variables, the trailing "You can _customize_ this
variable" which indicates a user option.

And maybe also the indication of the presence of some advice on a named
function: ":around advice: `some-function@my-advice'"

And maybe some other usual suspects I'm forgetting about.

> The first line is perhaps not vital for people to know either, but since
> that's what I use to jump to function definitions, it's useful.  (But
> perhaps a command that's just take us there is even better.)

The first line also indicates whether a function is interactive,
so I think it is useful for the average user.

> Anyway, what about rearranging this a bit so that the stuff the users
> are interested in comes first?

No objections here.



reply via email to

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