finding stuff

finding stuff

[Tomas Hlavaty]

Hi,

is there a way to search "everything" which comes with Emacs?

Example: I do not remember Local Variables section syntax and have to
look it up.  I try various things, fail and end up using web browser.
That is far from ideal.

Today I invested a bit more time and found C-h d command so C-h d "local
variables" and then C-s "local variables:" finds something: one hit
only.  Now I discovered add-file-local-variable function.  But still not
the syntax of the Local Variables section.

Searching info is still a mystery to me.  Is there a way to search
across all info files?

Is there a way to search everything which comes with emacs,
e.g. function names, docstrings, info, NEWS etc?

Cheers,

Tomas

Re: finding stuff

[Bob Newell]

If I understand your needs correctly, 'apropos' will give you some of
what you want. However it won't search the info files, news, etc.

But actually for learning how to do something, web search really is
the best option.

Re: finding stuff

[Jean Louis]

* Bob Newell <bobnewell@bobnewell.net> [2021-01-24 08:34]:
> If I understand your needs correctly, 'apropos' will give you some of
> what you want. However it won't search the info files, news, etc.
> 
> But actually for learning how to do something, web search really is
> the best option.

For specific stuff the web search provides solutions.

For general stuff people shall start with:

1. TUTORIAL under Help - Emacs Tutorial or {C-h t}

2. The Emacs Editor manual: (info "(emacs) Top")

3. An Introduction to Programming in Emacs Lisp: (info "(eintr) Top")

4. Emacs Lisp manual: (info "(elisp) Top")

5. Using the menu item Help.

To search all info files use {M-x info-apropos RET} or click within 

If one wants to index various files on system then person can use
desktop indexing software. That will not nicely help with Emacs
variables and functions. But it could help by at least locating where
some information exists.

Beagle - Quickly find the stuff you care about.
http://beagle-project.org/

Recoll is a desktop full-text search tool.
https://www.lesbonscomptes.com/recoll/

Tracker is a filesystem indexer, metadata storage system and search tool
https://wiki.gnome.org/Projects/Tracker

Terrier is a highly flexible, efficient, and effective open source search engine
http://www.terrier.org/

NEPOMUK - The Social Semantic Desktop
https://nepomuk.semanticdesktop.org/


Jean

Re: finding stuff

[Tomas Nordin]

Jean Louis <bugs@gnu.support> writes:

> * Bob Newell <bobnewell@bobnewell.net> [2021-01-24 08:34]:
>> If I understand your needs correctly, 'apropos' will give you some of
>> what you want. However it won't search the info files, news, etc.
>> 
>> But actually for learning how to do something, web search really is
>> the best option.
>
> For specific stuff the web search provides solutions.

Maybe the stuff actually found typically is specific, but the search on
the web is so general it must be hard to compete with.

It has happened to me a number of times I search the web on some Emacs
question, find links to the Emacs manual wich provide the answer and
only by then understand I would have found it by a direct search in the
manual.

But there must be nothing wrong with this combination of searching the
web and searching Emacs. Sometimes even if something is described in
detail in the manual, it is faster or more convenient to see some
user-written example on the web.

Re: finding stuff

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2021-01-24 05:33]:
> Hi,
> 
> is there a way to search "everything" which comes with Emacs?

There are ways to search everything that comes with Emacs. There is
just no united way for everything.

> Example: I do not remember Local Variables section syntax and have to
> look it up.  I try various things, fail and end up using web browser.
> That is far from ideal.

The menu item HELP - DESCRIBE contains many pointers. Then you have
plethora of M-x apropos* and M-x describe* functions. Then you have
the manual with {C-h r} and {C-h i} for other manuals.

> Today I invested a bit more time and found C-h d command so C-h d "local
> variables" and then C-s "local variables:" finds something: one hit
> only.  Now I discovered add-file-local-variable function.  But still not
> the syntax of the Local Variables section.

Try here:

(info "(emacs) Specifying File Variables")
(info "(emacs) Safe File Variables")

> Searching info is still a mystery to me.  Is there a way to search
> across all info files?

M-x info-apropos searches through many info files.

> Is there a way to search everything which comes with emacs,
> e.g. function names, docstrings, info, NEWS etc?

Obviously yes, there are various methods. But I do not think there is
one unified method to search everything together. I also do not find
it necessary.

I also recommend using {M-x package-install RET hyperbole RET} as it
will help with quicker jumping from function to function. For example
when I am on some definition of a function such as (dolist (a b)) if I
press M-RET on "dolist" then it brings me quickly to function definition in other window where I can see:

(defmacro dolist (spec &rest body)
  "Loop over a list.
Evaluate BODY with VAR bound to each car from LIST, in turn.
...

Jean

Re: finding stuff

[John Yates]

On Sun, Jan 24, 2021 at 2:14 AM Jean Louis <bugs@gnu.support> wrote:
>
> M-x info-apropos searches through many info files.

I have been using emacs for decades and was unaware of this command.
Perhaps help-for-help-internal could be improved to make it more discoverable.
Today we have:

[..SNIP..]
i           Start the Info documentation reader: read included manuals.
I METHOD    Describe a specific input method, or RET for current.
k KEYS      Display the full documentation for the key sequence.
K KEYS      Show the Emacs manual’s section for the command bound to KEYS.
l           Show last 300 input keystrokes (lossage).
L LANG-ENV  Describes a specific language environment, or RET for current.
m           Display documentation of current minor modes and current major mode,
              including their special commands.
n           Display news of recent Emacs changes.
[..SNIP..]

A possible improvement might be:

[..SNIP..]
i           Start the Info documentation reader: read included manuals.
I STRING    Grovel indices of all known Info files on your system for STRING.
              Build a menu of the possible matches.
k KEYS      Display the full documentation for the key sequence.
K KEYS      Show the Emacs manual’s section for the command bound to KEYS.
l           Show last 300 input keystrokes (lossage).
L LANG-ENV  Describes a specific language environment, or RET for current.
m           Display documentation of current minor modes and current major mode,
              including their special commands.
M METHOD    Describe a specific input method, or RET for current.
n           Display news of recent Emacs changes.
[..SNIP..]

/john

RE: [External] : Re: finding stuff

[Drew Adams]

> > M-x info-apropos searches through many info files.
> 
> I have been using emacs for decades and was unaware of this command.
> Perhaps help-for-help-internal could be improved to make it more
> discoverable.

Menus are a good way to discover things.

`Help > Search Documentation' has these menu items:

 Emacs Terminology
 Look Up Subject in User Manual
 Look Up Subject in Elisp Manual
 Look Up Key in User Manual...           C-h K
 Look Up Command in User Manual...       C-h F
 _____________________________________________
 Find Commands By Name...                C-h a
 Find Options By Name...
 Find Options By Value...
 Find Any Object By Name...
 Search Documentation Strings...         C-h d

Notice the last one.

IMO it's too bad that many people have come to get
the idea that using menus is for sissies.

I think this is especially true of developers, and
of Emacs users generally.  It's misguided, IMHO.

Re: [External] : Re: finding stuff

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Mon, 25 Jan 2021 16:31:52 +0000
> 
> IMO it's too bad that many people have come to get
> the idea that using menus is for sissies.
> 
> I think this is especially true of developers

It isn't.

Re: [External] : Re: finding stuff

[Bob Newell]

>> IMO it's too bad that many people have come to get
>> the idea that using menus is for sissies.

Using menus is for anyone who wishes and/or likes to do so,
and as mentioned elsewhere, they do have the great advantage
of allowing for learning by discovery (this is especially true
if you use Gnus).

I don't use them myself, not because of a fear of being
labeled, and certainly not because I already know everything
(I prove daily that I'm forever learning). I don't use menus
because for me they get in the way by taking up screen space,
being distracting, and generally requiring reaching for the
mouse. But my use case is not necessarily anyone else's.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: [External] : Re: finding stuff

[John Yates]

On Mon, Jan 25, 2021 at 12:37 PM Bob Newell <bobnewell@bobnewell.net> wrote:
> I don't use menus
> because for me they get in the way by taking up screen space,
> being distracting, and generally requiring reaching for the
> mouse.

Is this not what all the work on completion / narrowing frameworks
is trying to address?

Re: [External] : Re: finding stuff

[Stefan Monnier]

> I don't use them myself, not because of a fear of being

I rarely use them as well, but I do find them handy every once in a while.

> labeled, and certainly not because I already know everything
> (I prove daily that I'm forever learning). I don't use menus
> because for me they get in the way by taking up screen space,

I use (menu-bar-mode -1) to solve this problem.
It's still available on `C-mouse-3` so nothing's lost.

> being distracting, and generally requiring reaching for the
> mouse. But my use case is not necessarily anyone else's.

Since I use them rarely, I usually don't mind using the mouse in those
rare cases.  But there's probably some way to make it pop up in response
to a keyboard event (and you can definitely navigate it with the mouse).


        Stefan

Re: [External] : Re: finding stuff

[Robert Pluim]

>>>>> On Mon, 25 Jan 2021 15:59:35 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

    Stefan> Since I use them rarely, I usually don't mind using the mouse in those
    Stefan> rare cases.  But there's probably some way to make it pop up in response
    Stefan> to a keyboard event (and you can definitely navigate it with the mouse).

f10 works in both gui and non-gui frames. It even works when you have
the menubar disabled :-)

Robert

RE: [External] : Re: finding stuff

[Drew Adams]

> f10 works in both gui and non-gui frames. It even
> works when you have the menubar disabled :-)

Yup.  I bind it to `lacarte-execute-menu-command'.

,----
| <f10> runs the command lacarte-execute-menu-command,
| which is an interactive compiled Lisp function in
| 'lacarte.el'.
| 
| It is bound to f10, M-`.
| 
| (lacarte-execute-menu-command MAPS)
| 
| Execute a menu-bar menu command.
| Type a menu item.  Completion is available.
| 
| A prefix argument controls which menus are available:
| 
| * None: current major mode, global, and minor-mode keymaps.
| * Positive (including plain `C-u'): current major mode keymap.
| * Zero (e.g., `C-0'): current global keymap.
| * Negative (e.g., `C--'): current minor mode keymaps.
`----

Re: [External] : Re: finding stuff

[moasenwood--- via Users list for the GNU Emacs text editor]

Bob Newell wrote:

> Using menus is for anyone who wishes and/or likes to do so,
> and as mentioned elsewhere, they do have the great advantage
> of allowing for learning by discovery (this is especially
> true if you use Gnus).
>
> I don't use them myself, not because of a fear of being
> labeled, and certainly not because I already know everything
> (I prove daily that I'm forever learning). I don't use menus
> because for me they get in the way by taking up screen
> space, being distracting, and generally requiring reaching
> for the mouse. But my use case is not necessarily
> anyone else's.

I don't ever use the mouse but other than that I agree 100% :)

But ... this is a mere interface issue/detail and shouldn't be
a dispute, TEHO.

Rather, what _are_ the best ways of "fining stuff", in general
I mean? Is there a unified function to look everywhere and to
give an output with hints/links where to look next, an output
that may point to emacs(1), tutorials, manuals, the Wiki,
maybe even sites like the Emacs SX, furthermore docstrings,
FAQs, all you can think of and all that exists? If so,
I didn't see it! (Well, if it exists, maybe I could use it to
find it, even!)

What I can think of ... what I use ... that doesn't do that
but are still very useful ... are

  `apropos'
  `apropos-command'
  `apropos-value'

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: [External] : Re: finding stuff

[Bob Newell]

> But ... this is a mere interface issue/detail and shouldn't be
> a dispute, TEHO.

Exactly what Emacs is all about (TEHO!).

-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

RE: [External] : Re: finding stuff

[Drew Adams]

> > I think this is especially true of developers
> 
> It isn't.

You sound sure of yourself.  Perhaps you thought
I meant the developers _of Emacs_?  I didn't.

I meant that I'm guessing that people who do a
lot of software development are maybe less likely
to use menus (and a mouse) - as opposed to your
average computer user.

Re: [External] : Re: finding stuff

[moasenwood--- via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> I meant that I'm guessing that people who do a lot of
> software development are maybe less likely to use menus (and
> a mouse) - as opposed to your average computer user.

This sounds like The Computer Chronicles in 1985...

Maybe back then "real programmers" didn't use menus but then
also came the whole desktop paradigm with Apple (Finder) and
Windows so by now there are many, many skilled programmers
that use menus all the time and they don't even know other
skilled programmers have the habit, and perhaps takes some
small pride in, not using menus!

It is just a matter of style ... doesn't say anything
about skill.

Like they say, you have to be a bit modest, because somewhere
on the planet there is a coder who is more skilled than
you. Ha.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

RE: [External] : Re: finding stuff

[Drew Adams]

> > I meant that I'm guessing that people who do a lot of
> > software development are maybe less likely to use menus (and
> > a mouse) - as opposed to your average computer user.
> 
> This sounds like The Computer Chronicles in 1985...

It's also the case in 2021, I'm afraid.

> Maybe back then "real programmers" didn't use menus but then
> also came the whole desktop paradigm with Apple (Finder) and
> Windows so by now there are many, many skilled programmers
> that use menus all the time and they don't even know other
> skilled programmers have the habit, and perhaps takes some
> small pride in, not using menus!
> 
> It is just a matter of style ... doesn't say anything
> about skill.
> 
> Like they say, you have to be a bit modest, because somewhere
> on the planet there is a coder who is more skilled than
> you. Ha.

One might hope that you are right.  My experience
suggests otherwise.

Anecdotally based on comments in Emacs mailing
lists, the proportion of Emacs users who turn off
the menu-bar seems quite large.  Likewise, those
who eschew use of a mouse (in Emacs at least).

Also based on comments I see in mailing lists, I
think that many/most Emacs users are programmers.
___

To be clear, _I_ do use the menus.  The point of
my post was to _recommend_ them, for discovery.

The Help command that OP found to be so helpful
in this thread, and that was thought to be so
hard to discover, is right there in the `Help'
menu, hiding in plain sight.  But you have to
have a reflex to look under `Help', to find it.

FWIW: Not only do I use menus, but I go to great
lengths to ensure my libraries have good menus.

And I wrote library La Carte, which lets you
navigate Emacs menus using the keyboard.

Especially if combined with powerful incremental
matching, you can easily discover and access
menu stuff at all levels, directly - no need to
drill down layer by layer (though that's possible
too, as well as going back up).

https://www.emacswiki.org/emacs/LaCarte

https://www.emacswiki.org/emacs/download/lacarte.el

https://www.emacswiki.org/emacs/LaCarte#IciclesEnhancesDining

Re: [External] : Re: finding stuff

[John Yates]

On Tue, Jan 26, 2021 at 4:09 PM Drew Adams <drew.adams@oracle.com> wrote:
>
> The Help command that OP found to be so helpful
> in this thread, and that was thought to be so
> hard to discover, is right there in the `Help'
> menu, hiding in plain sight.  But you have to
> have a reflex to look under `Help', to find it.

(OP here.)

Drew, Are you saying that the help menu contains
items that are not listed by C-h C-h?  That, to me,
would be very surprising.

I am not opposed to using the mouse.  I avoid
menus because they present such a jarring UI
discontinuity.  Your LaCarte sounds intriguing.
Does interface with completing-read (i.e. can I
use it in conjunction with Selectrum and friends)?

RE: [External] : Re: finding stuff

[Drew Adams]

> > The Help command that OP found to be so helpful
> > in this thread, and that was thought to be so
> > hard to discover, is right there in the `Help'
> > menu, hiding in plain sight.  But you have to
> > have a reflex to look under `Help', to find it.
> 
> (OP here.)

The thread OP is actually Tomas Hlavaty.  But yes,
you're the one I meant, by OP.  You mentioned that
you've been using Emacs for decades but you were
unaware of that command.  There's so much we aren't
aware of - all of us.  (That particular command is
about as old as Emacs, BTW.)

> Drew, Are you saying that the help menu contains
> items that are not listed by C-h C-h?  That, to me,
> would be very surprising.

No, I didn't say that or mean to suggest it.  Without
checking, I'd assume, like you, that the `Help' menu
covers all of what `C-h C-h' covers.

My point was only about discoverability.  `C-h C-h'
is a fine way to discover help commands.  So is the
`Help' menu'.  My contribution was to second that
last point, which was first stated in the thread by
Jean Louis.

Specifically, I wanted to point out how helpful the
`Help' menu is, and that the command in question is
there, with the name `Search Documentation Strings'.

And yes, it's also listed with `C-h C-h':

  MORE ADVANCED HELP
  ------------------
  d: Shows Emacs functions and variables whose
     doc matches a regexp.

One can argue about the most helpful words used
to describe this, in terms of discoverability.
Menu `Help' talks about "searching" doc strings.
`C-h C-h' talks about "matching" doc.  And the
command name has the components `apropos' and 
`documentation'.  For users who know about
apropos,  "apropos" helps; for others, it might
not help so much.

> I am not opposed to using the mouse.  I avoid
> menus because they present such a jarring UI
> discontinuity.

Menus are one way to access commands.  Like the
other ways, they have their plusses and minuses.

For help, at least, we have `C-h C-h', which
_groups help commands_.

We don't have much otherwise (e.g. to help
discoverability), when it comes to _grouping_
related commands.  We can have related keys
(e.g. same prefix key or similar key mnemonics).
We have related command names (with some degree
of naming convention).  And we have apropos
(`C-h a' etc.).

Those all help group commands somewhat, and so
help with discoverability.  But each has its
weaknesses in that regard.

If you have a good completion system then you can
also find commands, variables, etc. by their name components etc., or even by doc matches - similar
to `apropos-documentation.  (I do that all the
time, using Icicles progressive completion.)

But menus too can aid discoverability, using
hierarchy and grouping (with named groups).

> Your LaCarte sounds intriguing.
> Does interface with completing-read (i.e. can I
> use it in conjunction with Selectrum and friends)?

Yes, you should be able to use it with any
completion system.  Yes, it uses `completing-read'.
___

https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#ChippingAway

https://www.emacswiki.org/emacs/Icicles_-_Progressive_Completion

Re: [External] : Re: finding stuff

[moasenwood--- via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> To be clear, _I_ do use the menus. The point of my post was
> to _recommend_ them, for discovery.

Yeah, in a consumer-oriented, very limited piece of software,
it is always a good habit to first check out the settings
(and/or menus) to see what things are there.

But here - no fishing expeditions, thank you.

Well, except for real ones. Relaxing, fun, and you always
learn something new even from very modest tours.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: [External] : Re: finding stuff

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Tue, 26 Jan 2021 05:21:49 +0000
> 
> I meant that I'm guessing that people who do a
> lot of software development are maybe less likely
> to use menus (and a mouse) - as opposed to your
> average computer user.

There was no "maybe" and no "less likely" in your original assertion.
Quote:

> IMO it's too bad that many people have come to get
> the idea that using menus is for sissies.
> 
> I think this is especially true of developers

If that included any qualifications whatsoever, I probably wouldn't
have bothered responding.

RE: [External] : Re: finding stuff

[Drew Adams]

> > I meant that I'm guessing that people who do a
> > lot of software development are maybe less likely
> > to use menus (and a mouse) - as opposed to your
> > average computer user.
> 
> There was no "maybe" and no "less likely" in your
> original assertion. Quote:
> 
> > IMO it's too bad that many people have come to get
> > the idea that using menus is for sissies.  I think
> > this is especially true of developers, and of Emacs
> > users generally.  It's misguided, IMHO.
> 
> If that included any qualifications whatsoever,
> I probably wouldn't have bothered responding.

It included the qualification "I think".  And "IMO".
And "especially".  And "generally".  And "IMHO".

As usual, you want to quibble.  (Sue me.)

After your first remark I clarified what I meant.

And yes, it's my impression that "many people have
come to get" the idea that many menus aren't worth
bothering with - in particular, I think, many
programmers.  And perhaps many Emacs users.

And one reason for that might be that sometimes
3rd-party Emacs libraries don't put a lot of
emphasis on providing good menu support.  Menus,
like doc, can often take back seat.  Programmers
like to code. ;-)

Have I added enough "perhaps", "might", "maybe",
"I think", "often", "sometimes" etc. for you?
(If not...)

What I say is only what I think.  YMMV.  I don't
preface everything I say with "It's my impression
that...".  (Do you?)
___

Message: Menus have more to offer than (I think)
many people realize.  Good menus, especially.

Re: [External] : Re: finding stuff

[moasenwood--- via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> And yes, it's my impression that "many people have come to
> get" the idea that many menus aren't worth bothering with -
> in particular, I think, many programmers. And perhaps many
> Emacs users.

Maybe in the hard-core Unix and Emacs community there is
a tilt towards that but if you think you are alone think
again, just check out Eclipse, all the Microsoft IDEs ...
there, menus are a/the fundamental building block of
the interface.

And while it is possible to have menus in Emacs, here, the
corresponding building block is not menus but shortcuts.
So obviously people here tend to not use menus, or use them
much less...

I think shortcuts are better, faster, they don't involve
a mouse, they are less disruptive visually and imply less eye
strain as there is no alternative to spot and pick, so all in
all, they are much more ergonomic. (Especially good shortcuts! ;))

But I suppose you are right, for the purpose of, with your
word, discoverability, menus are better.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: [External] : Re: finding stuff

[moasenwood--- via Users list for the GNU Emacs text editor]

> But I suppose you are right, for the purpose of, with your
> word, discoverability, menus are better.

But can't you do the same discovery travel with shortcuts,
with `C-h m' or `describe-mode'?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

RE: [External] : Re: finding stuff

[Drew Adams]

> But can't you do the same discovery travel with shortcuts,
> with `C-h m' or `describe-mode'?

No, you can't.  (Whatever's not the same is
different - has relative (dis)advantages.)

1. `describe-mode' is limited.  It's limited to
whatever someone wrote for it for the given mode.

2. Menu items generally describe/name commands a
bit differently from their command names.  I cited
the example for the case in question (`C-h d').

And menus group related commands, in a hierachy.
The names of the ancestors and siblings in the
hierarchy also help with discovery.

3. Wrt matching against menu names (items and
their ancestor menus): If you use something like
La Carte together with completion that allows
substring or regexp matching, and progressive
completion, then you can directly match component
bits of a menu item looked at as an absolute name,
i.e., including its entire path from the root.

That lets you discover it based on any/all of its
ancestors, as well as the item name, AND go to it
directly, in one go.

4. All of these are helpful, including for
discovery, and each offers a difference access
approach or entry point:

* key sequence (e.g. mnemonic, similar to keys
  for related behavior)
* command name (e.g. name components that say
  different things about what it means/does
* menu item name
* full menu item name, i.e., including its "path"

Re: [External] : Re: finding stuff

[moasenwood--- via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> But can't you do the same discovery travel with shortcuts,
>> with `C-h m' or `describe-mode'?
>
> No, you can't. (Whatever's not the same is different - has
> relative (dis)advantages.)
>
> 1. `describe-mode' is limited. It's limited to whatever
> someone wrote for it for the given mode.
>
> 2. Menu items generally describe/name commands a bit
> differently from their command names. I cited the example
> for the case in question (`C-h d').
>
> And menus group related commands, in a hierachy. The names
> of the ancestors and siblings in the hierarchy also help
> with discovery.
>
> 3. Wrt matching against menu names (items and their ancestor
> menus): If you use something like La Carte together with
> completion that allows substring or regexp matching, and
> progressive completion, then you can directly match
> component bits of a menu item looked at as an absolute name,
> i.e., including its entire path from the root.
>
> That lets you discover it based on any/all of its ancestors,
> as well as the item name, AND go to it directly, in one go.
>
> 4. All of these are helpful, including for discovery, and
> each offers a difference access approach or entry point:
>
> * key sequence (e.g. mnemonic, similar to keys
>   for related behavior)
> * command name (e.g. name components that say
>   different things about what it means/does
> * menu item name
> * full menu item name, i.e., including its "path"

Regardless of whatever side-effects menus may have in this or
any other direction, their purpose is for the user to invoke
commands, and this happens in a certain way.

The problem remains that if one doesn't like that certain way,
the discoverability side-effect won't help. One will still not
like it and probably not use it.

Instead, if we were to go discover stuff, we should have
a dedicated `discovery-mode' with that and only that purpose,
so that everyone, menu lovers and haters alike (because that
has nothing to do with it), so that everyone can discover
Emacs and then invoke the newfound commands in... you guessed
it... any way they like!

menus vs shortcuts - fine discussion

menus vs shortcuts with respect to "discoverability" - DNC

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

RE: [External] : Re: finding stuff

[Drew Adams]

> I think shortcuts are better, faster, they don't involve
> a mouse, they are less disruptive visually and imply less eye
> strain as there is no alternative to spot and pick, so all in
> all, they are much more ergonomic. (Especially good shortcuts! ;))
> 
> But I suppose you are right, for the purpose of, with your
> word, discoverability, menus are better.

Yes, the point was about discovery.

It's not about using menus versus using keyboard keys to invoke commands regularly.

Re: [External] : Re: finding stuff

[moasenwood--- via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> I think shortcuts are better, faster, they don't involve
>> a mouse, they are less disruptive visually and imply less
>> eye strain as there is no alternative to spot and pick, so
>> all in all, they are much more ergonomic. (Especially good
>> shortcuts! ;))
>> 
>> But I suppose you are right, for the purpose of, with your
>> word, discoverability, menus are better.
>
> Yes, the point was about discovery.
>
> It's not about using menus versus using keyboard keys to
> invoke commands regularly.

Yeah, but still, if it is about discovery there should be
a solution that is focused on that and only that, that has
nothing to do with either menus or shortcuts or anything else
unrelated...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: finding stuff

[Robert Thorpe]

John Yates <john@yates-sheets.org> writes:

> On Sun, Jan 24, 2021 at 2:14 AM Jean Louis <bugs@gnu.support> wrote:
>>
>> M-x info-apropos searches through many info files.
>
> I have been using emacs for decades and was unaware of this command.
> Perhaps help-for-help-internal could be improved to make it more discoverable.
> Today we have:
>

I think John Yates makes a good suggestion.

Alternatively, info-apropos could be associated with C-h C-i by
default.  As far as I can tell there is nothing that uses that binding
in vanilla Emacs.

BR,
Robert Thorpe

Re: finding stuff

[John Yates]

On Mon, Jan 25, 2021 at 8:59 PM Robert Thorpe
<rt@robertthorpeconsulting.com> wrote:
>
> Alternatively, info-apropos could be associated with C-h C-i by
> default.  As far as I can tell there is nothing that uses that binding
> in vanilla Emacs.

My suggestion to repurpose 'C-h I' was to conform to the pattern
in that table of binding wherein an uppercase letter implements a
deeper, more verbose version of its lowercase counterpart.  Such
patterns facilitate (my) memorization.

Re: finding stuff

[doltes doltes]

If I would really need to search all Emacs files, I would do the
following: Download the source code repository and execute =grep=
there but in all this time I've been using Emacs, I've never felt the
need to do this.

Apparently, what you were trying to find was a section in the Emacs
info manual and you knew some keywords but wasn't able to find the
Info heading. What I would do is the following:

1. Visit the =Emacs= info file. That is, execute =info-emacs-manual=
   (or press =C-h r=)
2. Execute =Info-toc= (or press =T=)
3. Execute =occur= (or press =M-s o=) while being in the =Table of
   Contents=.
4. Search the keywords I want to know about. In this scenario, they
   would be: =local variables=.

If no occurrence were found, I would repeat the same process with the
=Elisp= info manual.

If you want to actually search a given regexp in all info manuals, you
can try the following command. I would call this the brute-force
method. If you haven't set the =$INFOPATH= environmental variable,
then just use =/usr/share/info= as your =$path_info=.

#+begin_src dash
path_info="$(printf "%s" "$INFOPATH" | tr ":" "\n")"

pattern="emacs"
flags="--color"

find $path_info \
  -type f \( \
    ! \( -name '*.png' -o -name '*.gz' \) -exec grep "$flags" -- "$pattern"
{} + \
    -o -name '*.gz' -exec zgrep "$flags" -- "$pattern" {} + \
  \)
#+end_src



On Tue, 26 Jan 2021 at 10:09, John Yates <john@yates-sheets.org> wrote:

> On Mon, Jan 25, 2021 at 8:59 PM Robert Thorpe
> <rt@robertthorpeconsulting.com> wrote:
> >
> > Alternatively, info-apropos could be associated with C-h C-i by
> > default.  As far as I can tell there is nothing that uses that binding
> > in vanilla Emacs.
>
> My suggestion to repurpose 'C-h I' was to conform to the pattern
> in that table of binding wherein an uppercase letter implements a
> deeper, more verbose version of its lowercase counterpart.  Such
> patterns facilitate (my) memorization.
>
>

Re: finding stuff

[Jude DaShiell]

First run info emacs, next hit the slash key and key in a search string. 
That's from the command line.


On Sun, 24 Jan 2021, Tomas Hlavaty wrote:

> Hi,
>
> is there a way to search "everything" which comes with Emacs?
>
> Example: I do not remember Local Variables section syntax and have to
> look it up.  I try various things, fail and end up using web browser.
> That is far from ideal.
>
> Today I invested a bit more time and found C-h d command so C-h d "local
> variables" and then C-s "local variables:" finds something: one hit
> only.  Now I discovered add-file-local-variable function.  But still not
> the syntax of the Local Variables section.
>
> Searching info is still a mystery to me.  Is there a way to search
> across all info files?
>
> Is there a way to search everything which comes with emacs,
> e.g. function names, docstrings, info, NEWS etc?
>
> Cheers,
>
> Tomas
>
>

Re: finding stuff

[Tomas Nordin]

Tomas Hlavaty <tom@logand.com> writes:

> Hi,
>
> is there a way to search "everything" which comes with Emacs?
>
> Example: I do not remember Local Variables section syntax and have to
> look it up.  I try various things, fail and end up using web browser.
> That is far from ideal.
>
> Today I invested a bit more time and found C-h d command so C-h d "local
> variables" and then C-s "local variables:" finds something: one hit

Thanks, that seems useful. Did you try 'C-u C-h d'? Or set the variable
apropos-do-all to non-nil? That should yeild a more extensive search.

> only. Now I discovered add-file-local-variable function. But still not
> the syntax of the Local Variables section.
>
> Searching info is still a mystery to me.  Is there a way to search
> across all info files?
>
> Is there a way to search everything which comes with emacs,
> e.g. function names, docstrings, info, NEWS etc?
>
> Cheers,
>
> Tomas

Re: finding stuff

[Tomas Hlavaty]

On Sun 24 Jan 2021 at 11:58, Tomas Nordin <tomasn@posteo.net> wrote:
> Did you try 'C-u C-h d'? Or set the variable apropos-do-all to
> non-nil? That should yeild a more extensive search.

Thanks Tomas, this helped!

- There is an example in no-byte-compile directly shown in the results.

- I discovered ps-begin-cut-regexp and ps-end-cut-regexp related to the
  thing I was doing.

People suggested many ways of finding different things.  I can not
remember them all and know in each context which one to choose.

grep through emacs sources seems to give me fastest way of finding
stuff.  It is not perfect but I don't have to remember anything.

   (grep "grep -r -nH --color -i -e 'local variables:' ~/mr/emacs")

or

   (grep "rg -nH --no-heading -i 'local variables:' ~/mr/emacs")

This topic also led me to discover eev, which I find amazing.

Thanks to all for suggestions!

Re: finding stuff

[Eduardo Ochs]

On Fri, 26 Feb 2021 at 22:10, Tomas Hlavaty <tom@logand.com> wrote:
>
> On Sun 24 Jan 2021 at 11:58, Tomas Nordin <tomasn@posteo.net> wrote:
> > Did you try 'C-u C-h d'? Or set the variable apropos-do-all to
> > non-nil? That should yeild a more extensive search.
>
> Thanks Tomas, this helped!
>
> - There is an example in no-byte-compile directly shown in the results.
>
> - I discovered ps-begin-cut-regexp and ps-end-cut-regexp related to the
>   thing I was doing.
>
> People suggested many ways of finding different things.  I can not
> remember them all and know in each context which one to choose.
>
> grep through emacs sources seems to give me fastest way of finding
> stuff.  It is not perfect but I don't have to remember anything.
>
>    (grep "grep -r -nH --color -i -e 'local variables:' ~/mr/emacs")
>
> or
>
>    (grep "rg -nH --no-heading -i 'local variables:' ~/mr/emacs")
>
> This topic also led me to discover eev, which I find amazing.
>
> Thanks to all for suggestions!


Hey! Thanks for the mention to eev!!! =)

I just realized that there was something missing in eev, and I fixed
that and commited the fix to the git repository... here is a quick
explanation. When eev-mode is active the key sequence `M-h M-h' runs
`find-here-links', that generates a temporary buffer with "links to
here", as explained in:

  http://angg.twu.net/eev-intros/find-here-links-intro.html
  http://angg.twu.net/2020-find-here-links.html

Now, after the fix, typing `M-h M-h' on a grep buffer generates a
temporary buffer whose last lines are something like this:

  (let ((default-directory "~/bigsrc/emacs27/lisp/"))
    (grep "grep --color -niH --null -e 'local variables:' *.el")
    )

this a (3-line) elisp hyperlink that doesn't need eev to run, and that
should make sense to non-eev users... and they should find the
directory part trivial to adapt.

  Cheers, thanks, and apologies for the shameless plug =),
    Eduardo Ochs
    http://angg.twu.net/#eev
    http://angg.twu.net/emacsconf2020.html

Re: finding stuff

[Tomas Hlavaty]

On Fri 26 Feb 2021 at 23:57, Eduardo Ochs <eduardoochs@gmail.com> wrote:
> Now, after the fix, typing `M-h M-h' on a grep buffer generates a
> temporary buffer whose last lines are something like this:
>
>   (let ((default-directory "~/bigsrc/emacs27/lisp/"))
>     (grep "grep --color -niH --null -e 'local variables:' *.el")
>     )

Thank you.

I get this:

# See: 
# (find-eev-quick-intro "4.1. `find-here-links'")
# (find-emacs-keys-intro "1. Basic keys (eev)" "M-h M-h")
# (find-here-links-intro "4. `find-here-links-3'")


(let ((default-directory "~/git/notes/"))
  (grep nil)
  )

Maybe evaluating grep form does not add it to grep-history?

Re: finding stuff

[Eduardo Ochs]

On Sat, 27 Feb 2021 at 05:36, Tomas Hlavaty <tom@logand.com> wrote:
>
> I get this:
>
> (let ((default-directory "~/git/notes/"))
>   (grep nil)
>   )
>
> Maybe evaluating grep form does not add it to grep-history?

It doesn't! See:

  (find-efunction 'grep)
  (find-efunction 'grep "read-shell-command")
  (find-efunction 'read-shell-command)
  (find-efunction 'read-shell-command "read-from-minibuffer")
  (find-efunctiondescr 'read-from-minibuffer)
  (find-efunctiondescr 'read-from-minibuffer "add-to-history")

To be honest I've never transferred grep arguments from a sexp
hyperlink to the M-x grep prompt, only the reverse... I find much
easier to edit the arguments in a "real"/"normal" Emacs buffer than in
the minibuffer - and, btw, I almost always duplicate the sexp hyperlink
with M-h M-2 before editing it, and this lets me have my recent
grep-history all in sight, in an format like this:

  (find-ghcgrep "grep --color -nRH --null -e  foldr   libraries/base/*")
  (find-ghcgrep "grep --color -nRH --null -e 'foldr ' libraries/base/*")

[[]], E. =)

Re: finding stuff

[Tomas Hlavaty]

On Sat 27 Feb 2021 at 14:33, Eduardo Ochs <eduardoochs@gmail.com> wrote:
> On Sat, 27 Feb 2021 at 05:36, Tomas Hlavaty <tom@logand.com> wrote:
>> I get this:
>>
>> (let ((default-directory "~/git/notes/"))
>>   (grep nil)
>>   )
>>
>> Maybe evaluating grep form does not add it to grep-history?
>
> It doesn't! See:
>
>   (find-efunction 'grep)
>   (find-efunction 'grep "read-shell-command")
>   (find-efunction 'read-shell-command)
>   (find-efunction 'read-shell-command "read-from-minibuffer")
>   (find-efunctiondescr 'read-from-minibuffer)
>   (find-efunctiondescr 'read-from-minibuffer "add-to-history")

Interesting, thanks for the pointers.

I found that in addition to grep-history there is also
grep-find-history.

Maybe it should not take the argument from grep-history but from the 4th
line of the grep buffer.

> To be honest I've never transferred grep arguments from a sexp
> hyperlink to the M-x grep prompt, only the reverse...

I did not transfer anything.  I evaluated (grep "...") and then pressed
M-h M-h and then I got (grep nil) in the links buffer.

> I find much easier to edit the arguments in a "real"/"normal" Emacs
> buffer than in the minibuffer - and, btw, I almost always duplicate
> the sexp hyperlink with M-h M-2 before editing it, and this lets me
> have my recent grep-history all in sight, in an format like this:
>
>   (find-ghcgrep "grep --color -nRH --null -e  foldr   libraries/base/*")
>   (find-ghcgrep "grep --color -nRH --null -e 'foldr ' libraries/base/*")

Interesting, I'll try that.

M-h M-2 is not bound in (eev-beginner) so I might be getting advanced:-)

Re: finding stuff

[Tomas Hlavaty]

On Sun 28 Feb 2021 at 00:25, Tomas Hlavaty <tom@logand.com> wrote:
> M-h M-2 is not bound in (eev-beginner) so I might be getting
> advanced:-)

hmm, it is bound, i did something wrong

Re: finding stuff

[Robert Thorpe]

Tomas Hlavaty <tom@logand.com> writes:

> Hi,
>
> is there a way to search "everything" which comes with Emacs?
>
> Example: I do not remember Local Variables section syntax and have to
> look it up.  I try various things, fail and end up using web browser.
> That is far from ideal.
>
> Today I invested a bit more time and found C-h d command so C-h d "local
> variables" and then C-s "local variables:" finds something: one hit
> only.  Now I discovered add-file-local-variable function.  But still not
> the syntax of the Local Variables section.
>
> Searching info is still a mystery to me.  Is there a way to search
> across all info files?
>
> Is there a way to search everything which comes with emacs,
> e.g. function names, docstrings, info, NEWS etc?

I think a way of searching all those things would be useful.  As others
have mentioned there are separate ways of searching most of them.  I
think "info-apropos" is the most useful for your wishes.

Another possibility that people haven't mentioned is to build Emacs from
source then to load the tags-table and search that.

However, I still think that info-apropos is best.  Things like grep or
the Emacs source can bring too many hits to be useful.

BR,
Robert Thorpe

Re: finding stuff

[Tomas Hlavaty]

On Sun 28 Feb 2021 at 06:20, Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
> I think a way of searching all those things would be useful.  As others
> have mentioned there are separate ways of searching most of them.  I
> think "info-apropos" is the most useful for your wishes.

info-apropos looks interesting.

I just have to be careful what do I search for.  For example

   (info-apropos "local variables:")
   (info-apropos "Local Variables:")

gives: No matches found.

   (info-apropos "local variables")

Gives good links.

But it is much slower than grep.

> Another possibility that people haven't mentioned is to build Emacs from
> source then to load the tags-table and search that.

That is more complicated than grep.

Re: finding stuff

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2021-02-28 10:40]:
> On Sun 28 Feb 2021 at 06:20, Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
> > I think a way of searching all those things would be useful.  As others
> > have mentioned there are separate ways of searching most of them.  I
> > think "info-apropos" is the most useful for your wishes.
> 
> info-apropos looks interesting.
> 
> I just have to be careful what do I search for.  For example
> 
>    (info-apropos "local variables:")
>    (info-apropos "Local Variables:")
> 
> gives: No matches found.
> 
>    (info-apropos "local variables")
> 
> Gives good links.

It would be good to have a cross platform general search engine that
would find any similar terms and also work with various languages.
But we do not have such.

Sometimes avoiding plurals may find more results. Of course removing
any punctuation is advised, but the underlying search engine should
be doing that work.

I just guess that excess spaces should be removed by the underlying
program. But I don't think that 

(info-apropos "local  variables")
works same as 
(info-apropos "local variables")