iswitchb

iswitchb

[Richard Stallman]

After trying iswitchb for several days, I concluded it was not very
helpful, and was occasionally a pain in the neck.

It is not very helpful for me because I know what buffer I want to go
to and I start typing the beginning of it without looking at anything.
The only way iswitchb could help me is if I were to look at its
display to try to find a shorter string that would work.  But that
would slow me down.

iswitchb was a pain in the neck when I wanted to go to buffer inout
and it kept taking me to 4inout and 5inout instead.  I did not at first
even see what was happening.  When I did see, I still didn't know
a way to prevent it.  I suppose there is some iswitchb feature I
could use, but rather than learn it, I turned off iswitchb.

I don't think this feature should be enabled by default.

Re: iswitchb

[paul r]

2008/3/19, Richard Stallman <rms@gnu.org>:
> After trying iswitchb for several days

Thanks for that.

>  It is not very helpful for me because I know what buffer I want to go
>  to and I start typing the beginning of it without looking at anything.
>  The only way iswitchb could help me is if I were to look at its
>  display to try to find a shorter string that would work.  But that
>  would slow me down.

In some cases, I think it can help, especially for buffers you did not
open yourself but were opened automatically by emacs or by some mode.

>  iswitchb was a pain in the neck when I wanted to go to buffer inout
>  and it kept taking me to 4inout and 5inout instead.  I did not at first
>  even see what was happening.  When I did see, I still didn't know
>  a way to prevent it.  I suppose there is some iswitchb feature I
>  could use, but rather than learn it, I turned off iswitchb.

I warned about this eventuality when you asked how does iswitchb
behave, last week.
IIRC, in this thread, some people agreed that :
  - what is really helpful in iswitchb in the possibility to enter any
substring of the buffer name to find it, but this could be implemented
into current default switch-to-buffer.
  - occasionaly, real-time display of matching buffer can help, but if
you think it clutters, that could be disabled by default. Or at least
it could be let to the user to disable it as an option.
  - C-s and C-r to cycle through matches are not intuitive enought,
some better idea about how to disambiguate buffer names should be
proposed.

Re: iswitchb

[Don Armstrong]

On Wed, 19 Mar 2008, paul r wrote:
>   - what is really helpful in iswitchb in the possibility to enter
> any substring of the buffer name to find it, but this could be
> implemented into current default switch-to-buffer.

What probably should be adjusted here is the ordering when you've
typed in the exact name of a buffer; that buffer should just come to
the front of the list (with possible exceptions for foo<1> et al?).
That way iswitchb will get out of the way of people who expect the old
behavoir, but allow people to gradually learn the new behavoir.

>   - C-s and C-r to cycle through matches are not intuitive enought,
> some better idea about how to disambiguate buffer names should be
> proposed.

This is how most everything does forward and reverse searching, so
it's not that unintuitive.


Don Armstrong

-- 
"I'm a rational being--of a sort--rational enough, at least, to see the
symptoms of insanity around me. And I'm human, the same as the people
I think of as victims when my guard drops. It's at least possible I'm
even crazier than my fellows, whom I'm tempted to pity.
"There seems only one thing to do, and that's get drunk"
 -- Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p390)

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: iswitchb

[Daniel Colascione]

On Wednesday 19 March 2008 10:51:28 pm Don Armstrong wrote:
> >   - C-s and C-r to cycle through matches are not intuitive enought,
> > some better idea about how to disambiguate buffer names should be
> > proposed.
>
> This is how most everything does forward and reverse searching, so
> it's not that unintuitive.

What about this?

(define-key iswitchb-mode-map [(left)] #'iswitchb-prev-match)
(define-key iswitchb-mode-map [(right)] #'iswitchb-next-match)

I think of buffer switching as a funny kind of isearch.

Re: iswitchb

[paul r]

> What probably should be adjusted here is the ordering when you've
>  typed in the exact name of a buffer; that buffer should just come to
>  the front of the list (with possible exceptions for foo<1> et al?).
>  That way iswitchb will get out of the way of people who expect the old
>  behavoir, but allow people to gradually learn the new behavoir.

Yes, that what I thought later, reading again RMS case. In any case,
*exact match* should alway take you to this buffer, with the exception
of when you already are in this buffer.
More generaly, I agree iswitchb should behave like switch-to-buffer
for features they share.

Re: iswitchb

[Stefan Monnier]

>> What probably should be adjusted here is the ordering when you've
>> typed in the exact name of a buffer; that buffer should just come to
>> the front of the list (with possible exceptions for foo<1> et al?).
>> That way iswitchb will get out of the way of people who expect the old
>> behavoir, but allow people to gradually learn the new behavoir.

> Yes, that what I thought later, reading again RMS case. In any case,
> *exact match* should alway take you to this buffer, with the exception
> of when you already are in this buffer.
> More generaly, I agree iswitchb should behave like switch-to-buffer
> for features they share.

The completion package that I use (and that I ultimately would like to
install as the default, tho it needs a lot of work or a rewrite) does
the following:
1 - first try completion the old way.
2 - if that fails, try completion the partial-completion-mode way.
3 - if that fails, try it with a substring search.

So compared to the current default completion, the behavior should be
different only if the default completion finds no completion.

Combined with icomplete-mode, it is reminiscent of ido and iswitchb.


        Stefan

Re: iswitchb

[paul r]

2008/3/20, Stefan Monnier <monnier@iro.umontreal.ca>:

> The completion package that I use (and that I ultimately would like to
>  install as the default, tho it needs a lot of work or a rewrite) does
>  the following:
>  1 - first try completion the old way.
>  2 - if that fails, try completion the partial-completion-mode way.
>  3 - if that fails, try it with a substring search.
>
>  So compared to the current default completion, the behavior should be
>  different only if the default completion finds no completion.
>
>  Combined with icomplete-mode, it is reminiscent of ido and iswitchb.

Sounds good. Is there somewhere we can find this package ?

minibuffer completion functions [was: iswitchb]

[Drew Adams]

> The completion package that I use (and that I ultimately would like to
> install as the default, tho it needs a lot of work or a rewrite) does
> the following:
> 1 - first try completion the old way.
> 2 - if that fails, try completion the partial-completion-mode way.
> 3 - if that fails, try it with a substring search.

I certainly hope that will _not_ be adopted as the default behavior. Add it
as another, alternative behavior, if you like, but please leave the default
behavior alone.

It is not necessarily the case that a user or a Lisp caller of
`completing-read' (or another completing function) _wants_
partial-completion or substring completion to occur when the standard prefix
completion fails. There must be a way to get today's default behavior (and
that way should remain the default behavior).


The change that I would like to see for minibuffer completion is just to
have `completing-read' and `read-file-name' do the following:

1. Retain their current signatures (arg lists) - no change.

2. Funcall the value of a global variable: `completing-read-fn' or
`read-file-name-fn', if non-nil, to perform the completion. Else call a
default completing function, `completing-read-default' or
`read-file-name-default'.

That is, move the current behavior of `completing-read' and `read-file-name'
to new functions that perform that behavior as the default case. Change the
current completion functions to be just wrappers that call either the value
of a variable or the default function.

This simple change would keep the behavior we have now as the default. But
it would also allow flexibility for packages and users that want to use
different completion mechanisms, and it would help such packages play better
together.


Example: Icicles (just an example that I'm familiar with) and Viper mode
each adapt `read-file-name', in different ways, for their own use. Icicles
does this by redefining `read-file-name' when in Icicle mode (it is restored
when you leave the mode). Viper does it by advising `read-file-name'. If you
load Icicles first, the two play well together; if you load Viper first,
they do not, obviously. Neither redefining nor advising is a great approach
here, IMO.

With what I propose, a package can define its own completion function. That
function would have the same signature as `read-file-name' (or
`completing-read'), and it would bind or set its completion function as the
value of `read-file-name-fn', for use in some context (e.g. a minor mode).

This function definition for a package could then, to do part of its job,
call either `read-file-name-default' or the function that was the current
value of `read-file-name-fn' at the time of the package's own definition of
that variable. Or it could just do its own thing altogether, from scratch.
That is, the package's completion function could reuse the existing
completion mechanism (default or current) in some way, or it could ignore it
altogether. This is similar to the various defadvice possibilities (before,
after, replace).

I think this would be a simple and clean way to provide flexibility for
minibuffer completion. It is an alternative to using advice that I think is
better, in this case.

You might ask why a package doesn't just define and then use its own
completion function - why have it make the standard `completing-read' or
`read-file-name' adopt the package's way of completing? The reason is that
by going through the standard Emacs completion functions as a dispatcher,
all code that calls `completing-read' or `read-file-name' can take advantage
of the package's completion mechanism.

This is why, for instance, Icicles redefines `completing-read', even though
its redefinition never calls the original `completing-read'. The idea is to
let users take advantage of Icicles completion everywhere that
`completing-read' (or `read-file-name') is used (while in Icicle mode). Your
code need not be rewritten to call `icicle-completing-read'; it is enough
that it calls `completing-read'.

I don't want to argue about this (but I'm willing to clarify or discuss it).
If you don't like such an approach, fine. But in that case, please at least
leave the signature and default behavior of `completing-read' and
`read-file-name' alone. Some users and some packages count on those
functions doing what they do now.

If you do adopt an approach like I suggest, then you can always write a mode
or package that does what you want (tries prefix-, then partial-, then
substring-completion), and your preferred behavior will be available to
users without altering the default behavior. Just like any other completion
package.

Re: iswitchb

[Richard Stallman]

I am not trying to propose any change in iswitchb.
If the people who use it like it, why change it?
However, I object to making it the default.

Re: iswitchb

[Don Armstrong]

On Thu, 20 Mar 2008, Richard Stallman wrote:
> I am not trying to propose any change in iswitchb.

Sure, but I did.

> If the people who use it like it, why change it?
> However, I object to making it the default.

The suggestion was a change that would overcome (from what I saw) the
major problem that you and others like you who are used to the current
behavoir had, hopefully allowing it to become the default.

I know I personally wish I had known about iswitchb far earlier than I
learned about it, and I suspect that I'm not the only one.

Don Armstrong

-- 
Do not handicap your children by making their lives easy.
 -- Robert Heinlein _Time Enough For Love_ p251

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: iswitchb

[Richard Stallman]

    The suggestion was a change that would overcome (from what I saw) the
    major problem that you and others like you who are used to the current
    behavoir had, hopefully allowing it to become the default.

Thanks but no thanks.

Re: iswitchb

[Robert Pluim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> (superseded by the default use of substring completion in C-x b,

If that's documented somewhere, I've not been able to find it in the
docstring for `switch-to-buffer'. etc/NEWS.24 just says:

*** New completion style `substring'.

*** Completion of buffer names uses `substring' completion by default.

without explaining what substring means. It certainly has surprising
behaviour (with emacs-26):

src/emacs -Q
C-x C-f src/xdisp.c
C-x b di
C-x b sc TAB => *scratch*
C-x b di TAB => di [sole completion] ; I expected xdisp.c as well.

Is the actual behaviour substring-unless-exact-match or something?

Robert

Re: iswitchb

[Eli Zaretskii]

On March 12, 2018 12:22:58 PM GMT+02:00, Robert Pluim <rpluim@gmail.com> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > (superseded by the default use of substring completion in C-x b,
> 
> If that's documented somewhere, I've not been able to find it in the
> docstring for `switch-to-buffer'. etc/NEWS.24 just says:
> 
> *** New completion style `substring'.
> 
> *** Completion of buffer names uses `substring' completion by default.
> 
> without explaining what substring means. It certainly has surprising
> behaviour (with emacs-26):
> 
> src/emacs -Q
> C-x C-f src/xdisp.c
> C-x b di
> C-x b sc TAB => *scratch*
> C-x b di TAB => di [sole completion] ; I expected xdisp.c as well.
> 
> Is the actual behaviour substring-unless-exact-match or something?
> 
> Robert

The completion styles are documented in the Emacs user manual, node
"Completion Styles".

Re: iswitchb

[Eli Zaretskii]

On March 12, 2018 1:21:44 PM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
> On March 12, 2018 12:22:58 PM GMT+02:00, Robert Pluim
> <rpluim@gmail.com> wrote:
> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > 
> > > (superseded by the default use of substring completion in C-x b,
> > 
> > If that's documented somewhere, I've not been able to find it in the
> > docstring for `switch-to-buffer'. etc/NEWS.24 just says:
> > 
> > *** New completion style `substring'.
> > 
> > *** Completion of buffer names uses `substring' completion by
> default.
> > 
> > without explaining what substring means. It certainly has surprising
> > behaviour (with emacs-26):
> > 
> > src/emacs -Q
> > C-x C-f src/xdisp.c
> > C-x b di
> > C-x b sc TAB => *scratch*
> > C-x b di TAB => di [sole completion] ; I expected xdisp.c as well.
> > 
> > Is the actual behaviour substring-unless-exact-match or something?
> > 
> > Robert
> 
> The completion styles are documented in the Emacs user manual, node
> "Completion Styles".

Btw, completion of buffer names uses '(basic substring), which is why you see
what you see.  See minibuffer.el.

Re: iswitchb

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> 
>> The completion styles are documented in the Emacs user manual, node
>> "Completion Styles".

Ah, I'd missed the very last sentence of that node.

> Btw, completion of buffer names uses '(basic substring), which is why you see
> what you see.  See minibuffer.el.

I don't think I should have to read minibuffer.el to discover that. I
can get the information from the user manual, but the docstring of
switch-to-buffer doesn't help me get there. It says:

 See `read-buffer' for features related to input and completion
 of buffer names.

read-buffer's docstring then leads to completing-read, which in turn
points at the Emacs Lisp Reference Manual.[1]

In short: there's a missing link, and I'm not sure where to put it.

Robert

Footnotes: 
[1]  Info-goto-node only works if you're in an *info* file.  Should it
be taught to work from *Help* buffers as well? Or perhaps
"(filename)Node name" strings should be clickable?

Re: iswitchb

[Noam Postavsky]

On Mon, Mar 12, 2018 at 9:57 AM, Robert Pluim <rpluim@gmail.com> wrote:

> [1]  Info-goto-node only works if you're in an *info* file.  Should it
> be taught to work from *Help* buffers as well? Or perhaps
> "(filename)Node name" strings should be clickable?

It works if you say "Info node `(filename) Node name'" (not if you say
"Info nodeS `(filename) Node name' etc"), so completing-read docstring
could be changed to

See also Info node `(elisp) Basic Completion' for the details
about completion, and Info node `(elisp) Programmed Completion'
for expectations from COLLECTION when it’s a function.

(The linking is done in help-make-xrefs.)

Re: iswitchb

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

Noam Postavsky <npostavs@gmail.com> writes:

> On Mon, Mar 12, 2018 at 9:57 AM, Robert Pluim <rpluim@gmail.com> wrote:
>
>> [1]  Info-goto-node only works if you're in an *info* file.  Should it
>> be taught to work from *Help* buffers as well? Or perhaps
>> "(filename)Node name" strings should be clickable?
>
> It works if you say "Info node `(filename) Node name'" (not if you say
> "Info nodeS `(filename) Node name' etc"), so completing-read docstring
> could be changed to
>
> See also Info node `(elisp) Basic Completion' for the details
> about completion, and Info node `(elisp) Programmed Completion'
> for expectations from COLLECTION when it’s a function.

Indeed, that works, as does

Info node `(elisp)Basic Completion'

(without the space after the right paren)

Patch for this and one other instance of the same issue attached. I've
also attached a proposed patch for hiding the 'Info node' and 'URL'
prefixes in *Help* buffers, since I find they just get in the way.

First one could go to either emacs-26 or master. Second one I think is
master-only (does it require a NEWS entry?).

Robert


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Correct-Info-link-markup.patch --]
[-- Type: text/x-diff, Size: 1864 bytes --]

From a59d3fc1a7059064518f3842140f0df2e19799a1 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Mon, 12 Mar 2018 17:43:23 +0100
Subject: [PATCH 1/2] Correct Info link markup

* lisp/gnus/gnus-agent.el (gnus-agent-auto-agentize-methods):
Correct markup for Info link.
* src/minibuf.c (Fcompleting_read): Likewise.
---
 lisp/gnus/gnus-agent.el | 2 +-
 src/minibuf.c           | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/gnus/gnus-agent.el b/lisp/gnus/gnus-agent.el
index ada148d20b..628c9430c9 100644
--- a/lisp/gnus/gnus-agent.el
+++ b/lisp/gnus/gnus-agent.el
@@ -172,7 +172,7 @@ gnus-agent-expire-unagentized-dirs
 (defcustom gnus-agent-auto-agentize-methods nil
   "Initially, all servers from these methods are agentized.
 The user may remove or add servers using the Server buffer.
-See Info nodes `(gnus)Server Buffer', `(gnus)Agent Variables'."
+See Info node `(gnus)Server Buffer' and Info node `(gnus)Agent Variables'."
   :version "22.1"
   :type '(repeat symbol)
   :group 'gnus-agent)
diff --git a/src/minibuf.c b/src/minibuf.c
index 95e62cedda..d4484efb04 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -1626,8 +1626,8 @@ COLLECTION can also be a function to do the completion itself.
 PREDICATE limits completion to a subset of COLLECTION.
 See `try-completion', `all-completions', `test-completion',
 and `completion-boundaries', for more details on completion,
-COLLECTION, and PREDICATE.  See also Info nodes `(elisp)Basic Completion'
-for the details about completion, and `(elisp)Programmed Completion' for
+COLLECTION, and PREDICATE.  See also Info node `(elisp)Basic Completion'
+for the details about completion, and Info node `(elisp)Programmed Completion' for
 expectations from COLLECTION when it's a function.
 
 REQUIRE-MATCH can take the following values:
-- 
2.16.1.72.g5be1f00a9


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Hide-URL-and-Info-node-markup-in-help-buffers.patch --]
[-- Type: text/x-diff, Size: 2012 bytes --]

From de6c4f2ba6defa8dca15e13d64c6371f3f23e6af Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Mon, 12 Mar 2018 17:50:08 +0100
Subject: [PATCH 2/2] Hide URL and Info node markup in help buffers

* lisp/help-mode.el (help-make-xrefs): Make URL and Info node
markup invisible.
---
 lisp/help-mode.el | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lisp/help-mode.el b/lisp/help-mode.el
index 4fb3fb85c9..f64915e541 100644
--- a/lisp/help-mode.el
+++ b/lisp/help-mode.el
@@ -470,17 +470,23 @@ help-make-xrefs
                 ;; Info references
                 (save-excursion
                   (while (re-search-forward help-xref-info-regexp nil t)
-                    (let ((data (match-string 2)))
+                    (let ((data (match-string 2))
+                          (beg (match-beginning 0))
+                          (end (match-beginning 2)))
                       (save-match-data
                         (unless (string-match "^([^)]+)" data)
                           (setq data (concat "(emacs)" data)))
 			(setq data ;; possible newlines if para filled
-			      (replace-regexp-in-string "[ \t\n]+" " " data t t)))
+			      (replace-regexp-in-string "[ \t\n]+" " " data t t))
+                        (put-text-property beg end 'invisible t))
                       (help-xref-button 2 'help-info data))))
                 ;; URLs
                 (save-excursion
                   (while (re-search-forward help-xref-url-regexp nil t)
-                    (let ((data (match-string 1)))
+                    (let ((data (match-string 1))
+                          (beg (match-beginning 0))
+                          (end (match-beginning 1)))
+                      (put-text-property beg end 'invisible t)
                       (help-xref-button 1 'help-url data))))
                 ;; Mule related keywords.  Do this before trying
                 ;; `help-xref-symbol-regexp' because some of Mule
-- 
2.16.1.72.g5be1f00a9

Re: iswitchb

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 12 Mar 2018 17:56:59 +0100
> 
> Patch for this and one other instance of the same issue attached. I've
> also attached a proposed patch for hiding the 'Info node' and 'URL'
> prefixes in *Help* buffers, since I find they just get in the way.
> 
> First one could go to either emacs-26 or master.

Documentation changes should go to emacs-26.

> Second one I think is master-only (does it require a NEWS entry?).

Not unless you provide an option to get back old behavior (which I
think you should, if we accept this change).  Personally, I'm not so
sure it's a good idea to install that, as having Info called out
explicitly has its merits.

Re: iswitchb

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Emacs developers <emacs-devel@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Mon, 12 Mar 2018 17:56:59 +0100
>> 
>> Patch for this and one other instance of the same issue attached. I've
>> also attached a proposed patch for hiding the 'Info node' and 'URL'
>> prefixes in *Help* buffers, since I find they just get in the way.
>> 
>> First one could go to either emacs-26 or master.
>
> Documentation changes should go to emacs-26.
>

OK. That means someone has to install it on my behalf, since I don't
have commit privileges. Unless I could have those?

>> Second one I think is master-only (does it require a NEWS entry?).
>
> Not unless you provide an option to get back old behavior (which I
> think you should, if we accept this change).  Personally, I'm not so
> sure it's a good idea to install that, as having Info called out
> explicitly has its merits.

I just find it's visual noise, since I don't really care whether it's
an URL or an Info link that I'm looking at, but I appreciate some
people might not like the markup disappearing. Version with option +
NEWS update some time tomorrow.

Robert

Re: iswitchb

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

Robert Pluim <rpluim@gmail.com> writes:

>>
>> Not unless you provide an option to get back old behavior (which I
>> think you should, if we accept this change).  Personally, I'm not so
>> sure it's a good idea to install that, as having Info called out
>> explicitly has its merits.

Proposed patch attached. I've boldly defaulted the functionality to
enabled, but we can flip that if people feel strongly about it. I
documented it in the lisp reference manual, but we can put it in the
user manual as well.

Robert


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Hide-URL-and-Info-node-markup-in-help-buffers.patch --]
[-- Type: text/x-diff, Size: 3923 bytes --]

From b374d99ae7e9d16a99ce6a178ab06ab3d5634044 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Tue, 13 Mar 2018 17:03:11 +0100
Subject: [PATCH] Hide URL and Info node markup in help buffers

* lisp/help-mode.el (help-mode-hide-markup): New custom variable.
(help-make-xrefs): Make URL and Info node markup invisible.
* etc/NEWS: Describe help markup hiding changes.
* doc/lispref/tips.texi (Documentation Tips): Document
  'help-mode-hide-markup'
---
 doc/lispref/tips.texi |  7 +++++++
 etc/NEWS              |  5 +++++
 lisp/help-mode.el     | 22 +++++++++++++++++++---
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/doc/lispref/tips.texi b/doc/lispref/tips.texi
index c62cfcfa8f..3a623541e5 100644
--- a/doc/lispref/tips.texi
+++ b/doc/lispref/tips.texi
@@ -756,6 +756,13 @@ Documentation Tips
 `https://www.gnu.org/').
 @end smallexample
 
+@vindex help-mode-hide-markup
+By default, the prefixes that are used to indicate Info and URL
+hyperlinks (such as @samp{Info node} and @samp{URL}) are hidden when
+the documentation string is displayed.  This behavior can be changed
+by customizing  @code{help-mode-hide-markup} to
+@code{nil}.
+
 @item
 Don't write key sequences directly in documentation strings.  Instead,
 use the @samp{\\[@dots{}]} construct to stand for them.  For example,
diff --git a/etc/NEWS b/etc/NEWS
index 57236b52f0..bdefc0970c 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -202,6 +202,11 @@ and commands in the same format as the edit buffer of
 the buffer generated by 'view-lossage' to the "*Edit Macro*" buffer
 created by 'edit-last-kbd-macro', and to save the macro by 'C-c C-c'.
 
++++
+*** New variable 'help-mode-hide-markup'.
+When non-nil, help-mode buffers will not display the 'Info node' and
+'URL' prefixes to hyperlinks.  Default is t.
+
 ** Ibuffer
 
 ---
diff --git a/lisp/help-mode.el b/lisp/help-mode.el
index 4fb3fb85c9..bca160a7d2 100644
--- a/lisp/help-mode.el
+++ b/lisp/help-mode.el
@@ -98,6 +98,14 @@ help-mode-hook
   "Hook run by `help-mode'."
   :type 'hook
   :group 'help)
+
+(defcustom help-mode-hide-markup t
+  "If non-nil, hide markup used for Info and URL links.
+Otherwise, show explicit 'Info node' and 'URL' markup in help
+buffers."
+  :version "27.1"
+  :type 'boolean
+  :group 'help)
 \f
 ;; Button types used by help
 
@@ -470,17 +478,25 @@ help-make-xrefs
                 ;; Info references
                 (save-excursion
                   (while (re-search-forward help-xref-info-regexp nil t)
-                    (let ((data (match-string 2)))
+                    (let ((data (match-string 2))
+                          (beg (match-beginning 0))
+                          (end (match-beginning 2)))
                       (save-match-data
                         (unless (string-match "^([^)]+)" data)
                           (setq data (concat "(emacs)" data)))
 			(setq data ;; possible newlines if para filled
-			      (replace-regexp-in-string "[ \t\n]+" " " data t t)))
+			      (replace-regexp-in-string "[ \t\n]+" " " data t t))
+                        (when help-mode-hide-markup
+                          (put-text-property beg end 'invisible t)))
                       (help-xref-button 2 'help-info data))))
                 ;; URLs
                 (save-excursion
                   (while (re-search-forward help-xref-url-regexp nil t)
-                    (let ((data (match-string 1)))
+                    (let ((data (match-string 1))
+                          (beg (match-beginning 0))
+                          (end (match-beginning 1)))
+                      (when help-mode-hide-markup
+                        (put-text-property beg end 'invisible t))
                       (help-xref-button 1 'help-url data))))
                 ;; Mule related keywords.  Do this before trying
                 ;; `help-xref-symbol-regexp' because some of Mule
-- 
2.16.1.72.g5be1f00a9

Re: iswitchb

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 13 Mar 2018 17:42:35 +0100
> 
> Proposed patch attached. I've boldly defaulted the functionality to
> enabled, but we can flip that if people feel strongly about it. I
> documented it in the lisp reference manual, but we can put it in the
> user manual as well.

Thanks.  A few comments below:

> --- a/doc/lispref/tips.texi
> +++ b/doc/lispref/tips.texi
> @@ -756,6 +756,13 @@ Documentation Tips
>  `https://www.gnu.org/').
>  @end smallexample
>  
> +@vindex help-mode-hide-markup
> +By default, the prefixes that are used to indicate Info and URL
> +hyperlinks (such as @samp{Info node} and @samp{URL}) are hidden when
> +the documentation string is displayed.  This behavior can be changed
> +by customizing  @code{help-mode-hide-markup} to
> +@code{nil}.

I think this is the wrong place to put this text.  This is a user
option of no particular importance to Lisp programmers, so it should
be in the user manual, not in the ELisp manual.

> ++++
> +*** New variable 'help-mode-hide-markup'.
> +When non-nil, help-mode buffers will not display the 'Info node' and
> +'URL' prefixes to hyperlinks.  Default is t.

I think if we change the default behavior, this entry should be
reworded to describe the changed behavior.  Like this:

  *** The "Info node" and "URL" prefixes to hyperlinks are now hidden.
  Help mode buffers no longer display these prefixes when they show
  links to Info manuals and Web pages.  Customize 'help-mode-hide-markup'
  to nil to get previous behavior.

> +(defcustom help-mode-hide-markup t

I'd prefer a more specific name for the variable, like
help-mode-hide-info-and-url-prefix.  Yes, that's a mouthful, but if we
don't expect to many people changing that, I think it's OK.