all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Howard Melman <hmelman@gmail.com>
To: Alan Third <alan@idiocy.org>
Cc: 54961@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>,
	Juri Linkov <juri@linkov.net>
Subject: bug#54961: 28.1; info-display-manual completions issues
Date: Wed, 20 Apr 2022 15:10:48 -0400	[thread overview]
Message-ID: <550AC908-448C-4AFD-A098-69D40022B304@gmail.com> (raw)
In-Reply-To: <YmA8XMuTj2U3Kf54@idiocy.org>

On Apr 20, 2022, at 1:01 PM, Alan Third <alan@idiocy.org> wrote:
> 
> My uneducated guess is that it's possible to have a "UNIX" style
> install already on a machine, which might be in /usr and then want to
> run the self-contained version and not pick up the files in /usr
> before the self-contained version's files.
> 
> I've no idea if that's plausible.

Yes this sounds plausible.  MacOS comes with a /usr/share/info/ with
some manuals for the very old versions of somethings it ships with.
homebrew, a popular package manager for mac installs manuals in
/usr/local/share/info/.  

As you said, apps on a mac are installed in a special directory type,
ending in .app and that the window manager knows how to use. Double
clicking on Emacs.app runs the program inside it and it can be dragged
to the trash to delete.  In the Emacs.app is an info/ directory with the
manuals emacs ships with.  

It definitely makes sense that I'd want these three directories ordered as:

("/Applications/GnuEmacs.app/Contents/Resources/info/"
 "/usr/local/share/info/"
 "/usr/share/info/")

IIRC on other systems when building emacs it would install the emacs manuals
in a standard place.  In the NS build it would put it in the .app and of 
course something would need to tell the emacs info reader where that place is.  It 
sounds like older code modified INFOPATH via another NS trick and that
confused users and instead this code just modifies Info-directory-list
directly, which makes more sense.  I'm not sure a standalone info
reader would find it but if that was wanted a user could set INFOPATH
themselves to include the Emacs.app path.

I'm not sure how this interacts with package info files installed in
 ~/.emacs.d/elpa/.  You'd want those directories ahead of the Emacs.app
one and that is what I see happening.  So I think all this is fine.

I think my problem with headings disappearing is entirely the effect
of Info-streamline-headings and it's default value that merges all
headings with Emacs in them to one Emacs heading.  That isn't what
I want, I'm not sure if that's what's wanted by default since the dir
that ships with Emacs has more useful and specific headings, though I think
they could be improved.  I haven't looked if this streamlining preserves
ordering, but the order of manuals listed in the constructed dir need
not be the same as the order of Info-directory-list where they will
be searched for.  The first is just presentation and is what I was commenting
about.

Howard




      reply	other threads:[~2022-04-20 19:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-15 19:04 bug#54961: 28.1; info-display-manual completions issues Howard Melman
2022-04-16  9:39 ` Lars Ingebrigtsen
2022-04-16 11:27   ` Howard Melman
2022-04-16 14:00     ` Lars Ingebrigtsen
2022-04-16 14:38 ` Lars Ingebrigtsen
2022-04-16 15:21   ` Howard Melman
2022-04-16 15:23     ` Lars Ingebrigtsen
2022-04-18 19:02     ` Juri Linkov
2022-04-18 19:45       ` Howard Melman
2022-04-18 21:28       ` Howard Melman
2022-04-19  5:35         ` Eli Zaretskii
2022-04-19 13:27           ` Howard Melman
2022-04-19 16:55             ` Eli Zaretskii
2022-04-19 18:43               ` Howard Melman
2022-04-19 18:55                 ` Eli Zaretskii
2022-04-19 19:28                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-20  5:39                     ` Eli Zaretskii
2022-04-20 12:00                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-20 12:38                         ` Eli Zaretskii
2022-04-19 19:07                 ` Howard Melman
2022-04-19 19:24                   ` Eli Zaretskii
2022-04-19 19:24                   ` Juri Linkov
2022-04-20 17:01               ` Alan Third
2022-04-20 19:10                 ` Howard Melman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550AC908-448C-4AFD-A098-69D40022B304@gmail.com \
    --to=hmelman@gmail.com \
    --cc=54961@debbugs.gnu.org \
    --cc=alan@idiocy.org \
    --cc=juri@linkov.net \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.