GNU bug report logs - #26712
other-window/frame versions of find-library

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26712 in the body.
You can then email your comments to 26712 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: bug-gnu-emacs <at> gnu.org
Subject: other-window/frame versions of find-library
Date: Sat, 29 Apr 2017 21:46:22 +0200

[Message part 1 (text/plain, inline)]

Attached is a patch to add other-window/frames version of the 
`find-library' command.

BTW, after I added the two new commands and rebuilt Emacs (with just 
`make'), I could not complete to them with `M-x find-library- TAB'.  I 
could only do this after loading the `find-func' library that contains 
them.  So I ran `make bootstrap' instead and then I could complete to 
them as expected.  I guess this means the autoloads had not been updated 
with just `make'... which command should I have run?  Bootstrapping 
takes awhile.

[0001-find-library-other-window-find-library-other-frame-N.patch (text/x-patch, attachment)]

Message #8 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>, 26712 <at> debbugs.gnu.org
Subject: RE: bug#26712: other-window/frame versions of find-library
Date: Sat, 29 Apr 2017 13:33:19 -0700 (PDT)

> Attached is a patch to add other-window/frames version of the
> `find-library' command.
> 
> BTW, after I added the two new commands and rebuilt Emacs (with just
> `make'), I could not complete to them with `M-x find-library- TAB'.  I
> could only do this after loading the `find-func' library that contains
> them.  So I ran `make bootstrap' instead and then I could complete to
> them as expected.  I guess this means the autoloads had not been updated
> with just `make'... which command should I have run?  Bootstrapping
> takes awhile.

FWIW, I proposed this in March 2007 ("Please add
`find-library-other-window'")
http://lists.gnu.org/archive/html/emacs-devel/2007-03/msg01073.html

I was told not to propose new features at that time.

I proposed it again in June 2007 ("how about a
find-library-other-window command?",
http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg01306.html).

That thread was hijacked to a discussion about simulating
all `-other-*' commands automatically (still one of Stefan's
quests, I believe).

I more than once tried to bring the discussion back on topic.
http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg01319.html

["This is all beginning to sound a bit complex. Perhaps worth
exploring, but, in the meantime, could we at least add
`find-library-other-window'? ;-)"]

RMS, at least, responded favorably, asking for a patch.

Juri complained that "polluting the namespace is not a good
thing.  There are too many commands that display a new buffer,
and don't have the duplicate name with the `-other-window'
suffix, and adding more redundant commands will increase the mess."

I sent the patch anyway.
http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg01428.html

RMS agreed to it and asked that someone install it.

Juri complained that the code was repetitive for the 3
commands.  It was never installed.

Glad to see it finally added to Emacs.  I've been using it
for 10 years.  I bind it to `C-x 4 l'.  (I never use plain
`find-library'.)

Message #11 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: Drew Adams <drew.adams <at> oracle.com>, 26712 <at> debbugs.gnu.org
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Sun, 30 Apr 2017 20:16:31 +0200

Not sure why this mundane feature generates so much contention...

Message #14 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>, Drew Adams <drew.adams <at> oracle.com>,
 26712 <at> debbugs.gnu.org
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Mon, 01 May 2017 11:11:28 +0000

[Message part 1 (text/plain, inline)]

Charles A. Roelli <charles <at> aurox.ch> schrieb am So., 30. Apr. 2017 um
20:17 Uhr:

> Not sure why this mundane feature generates so much contention...
>

Parkinson's law of triviality.

[Message part 2 (text/html, inline)]

Message #17 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: 26712 <at> debbugs.gnu.org
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Sat, 6 May 2017 11:56:50 +0200

Ping!  Comments?

On 29/04/2017 21:46, Charles A. Roelli wrote:
> Attached is a patch to add other-window/frames version of the
> `find-library' command.
>
> BTW, after I added the two new commands and rebuilt Emacs (with just
> `make'), I could not complete to them with `M-x find-library- TAB'.  I
> could only do this after loading the `find-func' library that contains
> them.  So I ran `make bootstrap' instead and then I could complete to
> them as expected.  I guess this means the autoloads had not been updated
> with just `make'... which command should I have run?  Bootstrapping
> takes awhile.

Message #20 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>, 26712 <at> debbugs.gnu.org
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Sun, 07 May 2017 12:08:17 +0000

[Message part 1 (text/plain, inline)]

My approach has been lately: if nobody has commented on a patch for a week,
then just install it.

Charles A. Roelli <charles <at> aurox.ch> schrieb am Sa., 6. Mai 2017 um
11:57 Uhr:

> Ping!  Comments?
>
> On 29/04/2017 21:46, Charles A. Roelli wrote:
> > Attached is a patch to add other-window/frames version of the
> > `find-library' command.
> >
> > BTW, after I added the two new commands and rebuilt Emacs (with just
> > `make'), I could not complete to them with `M-x find-library- TAB'.  I
> > could only do this after loading the `find-func' library that contains
> > them.  So I ran `make bootstrap' instead and then I could complete to
> > them as expected.  I guess this means the autoloads had not been updated
> > with just `make'... which command should I have run?  Bootstrapping
> > takes awhile.
>
>
>
>

[Message part 2 (text/html, inline)]

Message #23 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, 26712 <at> debbugs.gnu.org
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Sun, 7 May 2017 15:36:27 +0200

I would install it, but I don't have commit access.  I'll put in a 
request for that now on Savannah, since I'd also like to work on a few 
issues with the NS port.

Message #26 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>, 26712 <at> debbugs.gnu.org
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Sun, 07 May 2017 13:45:00 +0000

[Message part 1 (text/plain, inline)]

Charles A. Roelli <charles <at> aurox.ch> schrieb am So., 7. Mai 2017 um
15:36 Uhr:

> I would install it, but I don't have commit access.


Ah, OK. Then a couple of minor comments:

- Consider renaming `find-library-read' to `find-func--read-library' to
make it internal. It's probably not intended as a public API.

- (funcall 'foo ...) should be written as (foo ...)

- Please revert unrelated whitespace changes (changing tabs to spaces in
find-function-do-it)

[Message part 2 (text/html, inline)]

Message #29 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, "Charles A. Roelli"
 <charles <at> aurox.ch>, 26712 <at> debbugs.gnu.org
Subject: RE: bug#26712: other-window/frame versions of find-library
Date: Sun, 7 May 2017 08:07:37 -0700 (PDT)

> - Consider renaming `find-library-read' to
>   `find-func--read-library' to make it internal.
>   It's probably not intended as a public API.

Why?  No.  Please do not consider that.  Not for a moment.

FWIW, I completely disagree with this point of view and
approach to Emacs Lisp.  Just the opposite.  Unless there is
some _very_ important reason why something _must_ be branded
as "internal", it should not be.

It may be a hard habit to break, but the notion of a "public
API" is generally inappropriate for Emacs Lisp.  Emacs users
are also Emacs-Lisp developers. And yes, they do write their
own libraries that read input.

Just imagine, if an input-reading function such as
`ffap-read-file-or-url', `read-file-name', `completing-read',
`read-face-name', or `read-char' were declared at the outset
to be "internal".  What's the point of such an artificial 
separation?

In fact, I'd suggest that the library prefix be removed from
`find-library-read' - just call it `read-library-name'.
Elevate it; don't hide or suppress it.

GNU Emacs in particular, and free software in general, have
the explicit intention that users _are_ developers and that
they look under the hood, tinker with engine parts, modify
or make their own use of them, to create new and better
things.

And yes, Emacs development is driven not only by its
maintainers or those most active in its C code or fixing
its bugs.  It is driven also, and importantly, by users,
who write their own code for their own uses, and who
sometimes extend that code into 3rd-party libraries.

Some such development even finds its way into distributed
Emacs itself - either directly, by incorporating it, or
indirectly, by copy or inspiration.  The latter happens
more than most people, including Emacs maintainers, are
aware of.

Emacs would not be what it is today if it did not offer
features written by its users (think Org).  And this has
been true of Emacs since Day One - even before GNU Emacs.

So let's please stop with the tendency to view Emacs
development as an internal-vs-external thing: we core
developers and the code we maintain vs you "lusers" and
your customizations.

If we are to have _any_ "internal" functions or variables
then the burden should be to demonstrate strongly why
a given one really _needs_ to be internal.  A priori,
every single one should be "external" or, more exactly, 
"nil-ternal".

I see no good reason why a general function that reads a
library name should be flagged "internal".  Why should
anyone be discouraged from using it in their code?  Why
shouldn't everyone be encouraged to use it, if they want
to read a library name?

This kind of not-for-the-users attitude smacks of
elitism, or at least seems control-freakish, even if it
is unconscious.  Open the corral, please.  Emacs, and
all of its code, belongs to its users.

There is nothing special about this function.  It is
useful generally.  And it should be called something
like `read-library-name'.

Message #32 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: Drew Adams <drew.adams <at> oracle.com>,
 Philipp Stephani <p.stephani2 <at> gmail.com>, 26712 <at> debbugs.gnu.org
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Tue, 16 May 2017 21:08:07 +0200

[Message part 1 (text/plain, inline)]

I agree.  Not sure if the `read-library' function should go in a 
different file, but in any case it makes sense to let users take 
advantage of it in their code.


Attached is a revised patch with Philipp's other suggestions taken into 
account.


On 07/05/2017 17:07, Drew Adams wrote:
>> - Consider renaming `find-library-read' to
>>    `find-func--read-library' to make it internal.
>>    It's probably not intended as a public API.
> Why?  No.  Please do not consider that.  Not for a moment.
>
> FWIW, I completely disagree with this point of view and
> approach to Emacs Lisp.  Just the opposite.  Unless there is
> some _very_ important reason why something _must_ be branded
> as "internal", it should not be.
>
> It may be a hard habit to break, but the notion of a "public
> API" is generally inappropriate for Emacs Lisp.  Emacs users
> are also Emacs-Lisp developers. And yes, they do write their
> own libraries that read input.
>
> Just imagine, if an input-reading function such as
> `ffap-read-file-or-url', `read-file-name', `completing-read',
> `read-face-name', or `read-char' were declared at the outset
> to be "internal".  What's the point of such an artificial
> separation?
>
> In fact, I'd suggest that the library prefix be removed from
> `find-library-read' - just call it `read-library-name'.
> Elevate it; don't hide or suppress it.
>
> GNU Emacs in particular, and free software in general, have
> the explicit intention that users _are_ developers and that
> they look under the hood, tinker with engine parts, modify
> or make their own use of them, to create new and better
> things.
>
> And yes, Emacs development is driven not only by its
> maintainers or those most active in its C code or fixing
> its bugs.  It is driven also, and importantly, by users,
> who write their own code for their own uses, and who
> sometimes extend that code into 3rd-party libraries.
>
> Some such development even finds its way into distributed
> Emacs itself - either directly, by incorporating it, or
> indirectly, by copy or inspiration.  The latter happens
> more than most people, including Emacs maintainers, are
> aware of.
>
> Emacs would not be what it is today if it did not offer
> features written by its users (think Org).  And this has
> been true of Emacs since Day One - even before GNU Emacs.
>
> So let's please stop with the tendency to view Emacs
> development as an internal-vs-external thing: we core
> developers and the code we maintain vs you "lusers" and
> your customizations.
>
> If we are to have _any_ "internal" functions or variables
> then the burden should be to demonstrate strongly why
> a given one really _needs_ to be internal.  A priori,
> every single one should be "external" or, more exactly,
> "nil-ternal".
>
> I see no good reason why a general function that reads a
> library name should be flagged "internal".  Why should
> anyone be discouraged from using it in their code?  Why
> shouldn't everyone be encouraged to use it, if they want
> to read a library name?
>
> This kind of not-for-the-users attitude smacks of
> elitism, or at least seems control-freakish, even if it
> is unconscious.  Open the corral, please.  Emacs, and
> all of its code, belongs to its users.
>
> There is nothing special about this function.  It is
> useful generally.  And it should be called something
> like `read-library-name'.

[0001-New-commands-find-library-other-window-find-library-.patch (text/x-patch, attachment)]

Message #35 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 26712 <at> debbugs.gnu.org, p.stephani2 <at> gmail.com, drew.adams <at> oracle.com
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Tue, 16 May 2017 22:36:36 +0300

> From: "Charles A. Roelli" <charles <at> aurox.ch>
> Date: Tue, 16 May 2017 21:08:07 +0200
> 
> Attached is a revised patch with Philipp's other suggestions taken into 
> account.

Thanks.  A few comments:

> +** Two new commands 'find-library-other-window' and
> +'find-library-other-frame'.

This is too terse.  A few words regarding what these do would be much
better.

> +(defun find-library (library)
> +  "Find the Emacs Lisp source of the LIBRARY near point.

This is confusing, IMO.  Suggest to reword:

    Find the Emacs Lisp source of LIBRARY.
  Interactively, prompt for LIBRARY using the one at or near point as
  the default.

> +(defun read-library-name ()
> +  "Read and return a library name, defaulting to the one near point."

I would explain here what constitutes a "library name", i.e. how does
the function determine the library name at point.

> +(defun find-library-other-window (library)
> +  "Find, in another window, the file defining LIBRARY at or near point.

Any reason why the wording is different from that of find-library?

Message #38 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26712 <at> debbugs.gnu.org, p.stephani2 <at> gmail.com, drew.adams <at> oracle.com
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Wed, 17 May 2017 21:16:57 +0200

[Message part 1 (text/plain, inline)]

Thank you for your comments.  Please see again the attachment.

On 16/05/2017 21:36, Eli Zaretskii wrote:
>> +** Two new commands 'find-library-other-window' and
>> +'find-library-other-frame'.
> This is too terse.  A few words regarding what these do would be much
> better.

Updated:

+** Two new commands for finding the source code of Emacs Lisp
+libraries: 'find-library-other-window' and 'find-library-other-frame'.
+

>> +(defun find-library (library)
>> +  "Find the Emacs Lisp source of the LIBRARY near point.
> This is confusing, IMO.  Suggest to reword:
>
>      Find the Emacs Lisp source of LIBRARY.
>    Interactively, prompt for LIBRARY using the one at or near point as
>    the default.

Thanks, I've updated it.

>> +(defun read-library-name ()
>> +  "Read and return a library name, defaulting to the one near point."
> I would explain here what constitutes a "library name", i.e. how does
> the function determine the library name at point.

+A library name is the filename of an Emacs Lisp library located
+in a directory under `load-path' (or `find-function-source-path',
+if non-nil)."

>> +(defun find-library-other-window (library)
>> +  "Find, in another window, the file defining LIBRARY at or near point.
> Any reason why the wording is different from that of find-library?

Nope, I've also amended this.

[0001-New-commands-find-library-other-window-find-library-.patch (text/x-patch, attachment)]

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Howard Melman <hmelman <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Fri, 19 May 2017 20:54:50 -0400

I didn't see this in the patch, but can I suggest that
find-function-setup-keys bind these new commands (and find-library) to "C-x L",
"C-x 4 L" and "C-x 5 L"?

-- 

Howard

Message #44 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Howard Melman <hmelman <at> gmail.com>, 26712 <at> debbugs.gnu.org
Subject: RE: bug#26712: other-window/frame versions of find-library
Date: Fri, 19 May 2017 19:04:07 -0700 (PDT)

> I didn't see this in the patch, but can I suggest that
> find-function-setup-keys bind these new commands (and find-library) to "C-x
> L", "C-x 4 L" and "C-x 5 L"?

+1.  But personally I'd prefer lowercase `l', not `L'.  I almost
_never_ use `count-lines-page', and I use `find-library-other-window'
several times a day.  And I'm probably one of the few people who
actually does use page commands.  That's just not that useful a
command, for me.)

FWIW, I suggsested in my original request for this, years ago, that
we use `C-x 4 l' for other-window.  I've been using that for years.
(I use non-nil `pop-up-frames', so I `other-window' acts like
other-frame.)

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Howard Melman <hmelman <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Fri, 19 May 2017 23:24:01 -0400

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

>> I didn't see this in the patch, but can I suggest that
>> find-function-setup-keys bind these new commands (and find-library) to "C-x
>> L", "C-x 4 L" and "C-x 5 L"?
>
> +1.  But personally I'd prefer lowercase `l', not `L'.  I almost
> _never_ use `count-lines-page', and I use `find-library-other-window'
> several times a day.  And I'm probably one of the few people who
> actually does use page commands.  That's just not that useful a
> command, for me.)
>
> FWIW, I suggsested in my original request for this, years ago, that
> we use `C-x 4 l' for other-window.  I've been using that for years.
> (I use non-nil `pop-up-frames', so I `other-window' acts like
> other-frame.)

I suggested L because it matches with the other bindings in
find-function-setup-keys and I'll remember them better if
all are on upppercase letters rather than some on upper and
some on lowercase.

-- 

Howard

Message #52 received at 26712-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: p.stephani2 <at> gmail.com, 26712-done <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Sat, 20 May 2017 14:47:19 +0300

> Cc: drew.adams <at> oracle.com, p.stephani2 <at> gmail.com, 26712 <at> debbugs.gnu.org
> From: "Charles A. Roelli" <charles <at> aurox.ch>
> Date: Wed, 17 May 2017 21:16:57 +0200
> 
> Thank you for your comments.  Please see again the attachment.

Thanks, pushed.

A couple of nits for the future:

 . etc/NEWS changes should be mentioned in the commit log.
 . If the patches were posted as a bug report, please mention the bug
   number in the log message.
 . We prefer quoting symbol names 'like this', not `like this'.

Message #55 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Howard Melman <hmelman <at> gmail.com>
Cc: 26712 <at> debbugs.gnu.org
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Sat, 20 May 2017 23:23:20 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think find-function is more useful to put on a key than
find-library.  Or perhaps they can be combined.  It should not be hard
to accept an argument and try it first as a function, then as a library.

If the name is both a function and a library, the function definition
is almost surely in that library.
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Message #58 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: bug-gnu-emacs <at> gnu.org
Cc: 26712 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Mon, 29 May 2017 21:39:10 +0200

[Message part 1 (text/plain, inline)]

Good idea.  Is the attached patch OK?  It augments 'C-x F', 'C-x 4 F'
and 'C-x 5 F' to suggest library names too.

On 21/05/2017 05:23, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I think find-function is more useful to put on a key than
> find-library.  Or perhaps they can be combined.  It should not be hard
> to accept an argument and try it first as a function, then as a library.
>
> If the name is both a function and a library, the function definition
> is almost surely in that library.
>

[0001-New-commands-find-function-or-library-other-window-f.patch (text/x-patch, attachment)]

Message #64 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 26712 <at> debbugs.gnu.org, eliz <at> gnu.org, hmelman <at> gmail.com,
 drew.adams <at> oracle.com
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Wed, 31 May 2017 00:23:13 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Your change does what I had in mind.  (I haven't checked the code.)

But why should we have find-function-setup-keys?
Why not make those bindings standard and document them as such?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Message #67 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: rms <at> gnu.org
Cc: 26712 <at> debbugs.gnu.org, eliz <at> gnu.org, hmelman <at> gmail.com,
 drew.adams <at> oracle.com
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Fri, 2 Jun 2017 20:39:19 +0200

Sounds good to me.


Where do you think the documentation should go in the Emacs manual?

It seems "(emacs) Misc Help" could be ok.


On 31/05/2017 06:23, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Your change does what I had in mind.  (I haven't checked the code.)
>
> But why should we have find-function-setup-keys?
> Why not make those bindings standard and document them as such?
>

Message #70 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 26712 <at> debbugs.gnu.org, hmelman <at> gmail.com
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Sat, 03 Jun 2017 22:54:36 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It seems "(emacs) Misc Help" could be ok.

I agree.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Message #73 received at 26712 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: rms <at> gnu.org
Cc: 26712 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, hmelman <at> gmail.com
Subject: Re: bug#26712: other-window/frame versions of find-library
Date: Sun, 11 Jun 2017 12:44:56 +0200

[Message part 1 (text/plain, inline)]

Please see the attached two patches.  The first implements
'find-function-or-library' (what I sent previously).  The second patch
makes the 'find-function-setup-keys' bindings by default, and they're
documented in the manual.


On 04/06/2017 04:54, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>    > It seems "(emacs) Misc Help" could be ok.
>
> I agree.
>

[0001-New-commands-find-function-or-library-other-window-f.patch (text/x-patch, attachment)]

[0002-Make-find-function-setup-keys-bindings-default.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.