Re: Retrieving the "include" directory for Emacs Modules

[Marco Antoniotti <marcoxa@gmail.com>]

Hi Eli

somewhere, somehow (don't ask me), the "data" directory where emacs keeps
its stuff is created and its location recorded.

The emacs-module.h is the only thing that sits in the include directory.

Now.  On my Windows machine, where I install Emacs downloading the
installer from one of the links available on the main website, the
installation seems, AFAIK, to be up to your standards.

On my Mac, If I install emacs as a "formula" (i.e., not a s an app) things
seem installed as they should be.  OTOH the brew "cask" (which installs a
.app in the Application directory) seems to create something that Apple
likes, but that STILL may be told to have a pointer to the include
directory as it does to the data-directory.

This is obviously something that the brew folks should deal with, but the
notion of having a variable that tracks the include directory still has
merit.  At least as an extra guideline to people like the brew maintainers.

All the best

Marco









On Sun, Dec 8, 2024 at 8:45 PM <help-gnu-emacs-request@gnu.org> wrote:

> Send help-gnu-emacs mailing list submissions to
>         help-gnu-emacs@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/help-gnu-emacs
> or, via email, send a message with subject or body 'help' to
>         help-gnu-emacs-request@gnu.org
>
> You can reach the person managing the list at
>         help-gnu-emacs-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of help-gnu-emacs digest..."
>
>
> Today's Topics:
>
>    1. Re: Retrieving the "include" directory for Emacs Modules
>       (Eli Zaretskii)
>    2. Re: Unicode and text editors (Heime)
>    3. Re: Unicode and text editors (Eli Zaretskii)
>    4. Re: Unicode and text editors (Heime)
>    5. Re: Unicode and text editors (Eli Zaretskii)
>    6. Re: Checking conditions unrelated to expression
>       (Michael Heerdegen)
>    7. Re: Unicode and text editors (Heime)
>    8. Re: Transforming paths in compilation output (containerized
>       builds) (Björn Bidar)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 08 Dec 2024 19:46:11 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Retrieving the "include" directory for Emacs Modules
> Message-ID: <865xnuf4po.fsf@gnu.org>
>
> > Date: Sun, 08 Dec 2024 11:48:24 -0500
> > From:  Stefan Monnier via Users list for the GNU Emacs text editor <
> help-gnu-emacs@gnu.org>
> >
> > >> >   #include <emacs-module.h>
> > >> >
> > >> > and that's it.  Or what am I missing?
> > >>
> > >> That presumes that Emacs is installed system-wide (and "properly").
> > >
> > > What other way is there to install Emacs?
> >
> > Compile manually and run from the build tree?
>
> That's called "run uninstalled".  And in that case, the user who does
> that knows very well where the header lives: in the same directory
> from which he/she runs Emacs.
>
> > Uncompress a downloaded pre-compiled archive into a directory and just
> > use it from there (AFAIK, very common under macOS and Windows)?
>
> If that doesn't place emacs-module.h in the system-wide include
> directory, it is a broken installation.
>
> > With luck on some systems the C (or other) compiler is installed in
> > a similar way (i.e. in its own subdirectory, siloed from Emacs).
>
> That's not how multi-package installation should be organized if the
> user wants the packages to cooperate.
>
> > >> When the compilation of the module is initiated from within Emacs, it
> > >> would make a lot of sense for this "ambient" Emacs to be able to tell
> > >> `make/gcc/younameit` explicitly and reliably where its own
> > >> `emacs-module.h` can be found.
> > > But if Emacs is "not installed properly", we don't know that.
> >
> > Emacs *should* know that, just like it knows where is its
> > `lisp-directory`.
>
> That's impractical expectation.  Recall how hard we worked to find the
> pdumper file and the preloaded *.eln files, what with all the tricks
> people use when installing Emacs.  I'm not interested in adding
> another burden to our maintenance so that Emacs will paper over broken
> installations.  Sorry.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 08 Dec 2024 17:54:43 +0000
> From: Heime <heimeborgia@protonmail.com>
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Unicode and text editors
> Message-ID:
>
> <VpTsRgeCxJL-JNeghs40Qt5cLBHbFykIIGYBA6zMT8AkgKUGc_RobIkWbXrtJnf4MVOF_oHrD4iCYJk1jS92lbFA2SjCpB_1htjcPAV0gv0=@
> protonmail.com>
>
> Content-Type: text/plain; charset=utf-8
>
>
> On Monday, December 9th, 2024 at 4:32 AM, Eli Zaretskii <eliz@gnu.org>
> wrote:
>
> > > Date: Sun, 08 Dec 2024 15:15:31 +0000
> > > From: "W. Greenhouse" via Users list for the GNU Emacs text editor
> help-gnu-emacs@gnu.org
> > >
> > > Heime via Users list for the GNU Emacs text editor
> > > help-gnu-emacs@gnu.org writes:
> > >
> > > > Is this becoming the norm? What about emacs?
> > > >
> > > > Does emacs encourage use of unicode characters (UTF-8) in code
> comments
> > > > and documentation?
> > >
> > > UTF-8 represents Emacs' internal text encoding
> >
> >
> > No, the internal encoding is different (it's a superset of UTF-8).
> >
> > > and also its default preference for new files.
> >
> >
> > That is only true if the user's locale has UTF-8 as its codeset.
> >
> > > When visiting existing files it attempts to
> > > detect the encoding, and maintain it while editing.
> >
> > That is correct.
>
> Does this mean that we should not worry when we use UTF-8?   Would
> UTF-* be supported, and detected.  With the appropriate symbols showing
> as they should.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 08 Dec 2024 20:44:42 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Unicode and text editors
> Message-ID: <861pyif205.fsf@gnu.org>
>
> > Date: Sun, 08 Dec 2024 17:54:43 +0000
> > From: Heime <heimeborgia@protonmail.com>
> > Cc: help-gnu-emacs@gnu.org
> >
> > > > When visiting existing files it attempts to
> > > > detect the encoding, and maintain it while editing.
> > >
> > > That is correct.
> >
> > Does this mean that we should not worry when we use UTF-8?   Would
> > UTF-* be supported, and detected.  With the appropriate symbols showing
> > as they should.
>
> I was talking about Emacs.  Your original question was about other
> editors.  I'm not familiar with other modern editors enough to tell
> whether you should or should not worry.  In particular, I don't know
> how they recognize UTF-8, and am not sure that Emacs coding cookies
> are supported by them.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 08 Dec 2024 18:55:52 +0000
> From: Heime <heimeborgia@protonmail.com>
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Unicode and text editors
> Message-ID:
>
> <p6vv68VE9KE4Y8ML-nAfy75EPmsnsFPaRGtZglz_qmAeKRH62jOOy9XqbeinPnf0-5GkV3BhYTB2gR6QAV_YA85x5teM-wfdi5SXLgsW4W4=@
> protonmail.com>
>
> Content-Type: text/plain; charset=utf-8
>
>
>
>
>
>
> Sent with Proton Mail secure email.
>
> On Monday, December 9th, 2024 at 6:44 AM, Eli Zaretskii <eliz@gnu.org>
> wrote:
>
> > > Date: Sun, 08 Dec 2024 17:54:43 +0000
> > > From: Heime heimeborgia@protonmail.com
> > > Cc: help-gnu-emacs@gnu.org
> > >
> > > > > When visiting existing files it attempts to
> > > > > detect the encoding, and maintain it while editing.
> > > >
> > > > That is correct.
> > >
> > > Does this mean that we should not worry when we use UTF-8? Would
> > > UTF-* be supported, and detected. With the appropriate symbols showing
> > > as they should.
> >
> >
> > I was talking about Emacs. Your original question was about other
> > editors. I'm not familiar with other modern editors enough to tell
> > whether you should or should not worry. In particular, I don't know
> > how they recognize UTF-8, and am not sure that Emacs coding cookies
> > are supported by them.
>
> Is it reasonable to expect that UTF-* characters are recognised and
> supported?
> What is your school of thought regarding emacs?
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 08 Dec 2024 21:07:47 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Unicode and text editors
> Message-ID: <86wmgadmd8.fsf@gnu.org>
>
> > Date: Sun, 08 Dec 2024 18:55:52 +0000
> > From: Heime <heimeborgia@protonmail.com>
> > Cc: help-gnu-emacs@gnu.org
> >
> > > I was talking about Emacs. Your original question was about other
> > > editors. I'm not familiar with other modern editors enough to tell
> > > whether you should or should not worry. In particular, I don't know
> > > how they recognize UTF-8, and am not sure that Emacs coding cookies
> > > are supported by them.
> >
> > Is it reasonable to expect that UTF-* characters are recognised and
> supported?
>
> Reasonable? yes.  But the problem is not trivial: Emacs itself not
> always recognizes UTF-8 reliably.  So there could be problems.
>
> > What is your school of thought regarding emacs?
>
> I don't understand the question, sorry.
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 08 Dec 2024 20:19:57 +0100
> From: Michael Heerdegen <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Checking conditions unrelated to expression
> Message-ID: <87ikruouci.fsf@web.de>
> Content-Type: text/plain
>
> Hello,
>
> the only thing I want to add to Stefan's answer: the 'let' pattern can
> be (despite the name) used as a full-featured "sub-pcase".  But also see
> 'app' etc. - just see the pattern descriptions in the fine docs.
>
> Michael.
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 08 Dec 2024 19:39:55 +0000
> From: Heime <heimeborgia@protonmail.com>
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Unicode and text editors
> Message-ID:
>
> <Be0XIegjOn-QFIHzjODCIV_jnl-68E45AFCdDLeqeQ6cYw8sH6hMgQudQVXE_Jx4REYEV96IgFMaEtOaIlDTWDY7QbsIDrY61z-feuEjIpM=@
> protonmail.com>
>
> Content-Type: text/plain; charset=utf-8
>
>
> On Monday, December 9th, 2024 at 7:07 AM, Eli Zaretskii <eliz@gnu.org>
> wrote:
>
> > > Date: Sun, 08 Dec 2024 18:55:52 +0000
> > > From: Heime heimeborgia@protonmail.com
> > > Cc: help-gnu-emacs@gnu.org
> > >
> > > > I was talking about Emacs. Your original question was about other
> > > > editors. I'm not familiar with other modern editors enough to tell
> > > > whether you should or should not worry. In particular, I don't know
> > > > how they recognize UTF-8, and am not sure that Emacs coding cookies
> > > > are supported by them.
> > >
> > > Is it reasonable to expect that UTF-* characters are recognised and
> supported?
> >
> >
> > Reasonable? yes. But the problem is not trivial: Emacs itself not
> > always recognizes UTF-8 reliably. So there could be problems.
> >
> > > What is your school of thought regarding emacs?
> >
> >
> > I don't understand the question, sorry.
>
> Should we comfortable use UTF Characters in source code when using Emacs?
> When there are problems, do they usually get looked into and fixed if
> possible?
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Sun, 08 Dec 2024 21:45:15 +0200
> From: Björn Bidar <bjorn.bidar@thaodan.de>
> To: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  help-gnu-emacs@gnu.org
> Subject: Re: Transforming paths in compilation output (containerized
>         builds)
> Message-ID: <87frmy2c38.fsf@>
> Content-Type: text/plain
>
> Yuri Khan <yuri.v.khan@gmail.com> writes:
>
> > On Sun, 8 Dec 2024 at 12:43, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> > > Is compilation-transform-file-match-alist what you are looking for?
> >> >
> >> > The variable talks only about errors. Does it apply to all messages
> not just
> >> > the errors?
> >>
> >> It is applied to all messages.
> >
> > In my experience, it is not applied to messages as such. It is
> > consulted when building text properties while fontifying the messages
> > so that the user can jump to error locations; but the actual visible
> > text in the buffer remains unmodified.
>
> That the actual text remains unmodified is good, it's actually better
> since it doesn't reveal any private information/makes the output depend on
> the
> users machine.
>
> As long as it applies to all messages it's good. Maybe the description
> or the name of the variable should be changed then.
>
> I looked at the integration for the other container engines for
> inspiration on how to solve this issue.
> None of them handle this issue or are affected.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> help-gnu-emacs mailing list
> help-gnu-emacs@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-gnu-emacs
>
>
> ------------------------------
>
> End of help-gnu-emacs Digest, Vol 265, Issue 40
> ***********************************************
>


-- 
Marco Antoniotti
Somewhere over the Rainbow