From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Marco Antoniotti Newsgroups: gmane.emacs.help Subject: Re: Retrieving the "include" directory for Emacs Modules Date: Mon, 9 Dec 2024 10:58:57 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33639"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 09 11:00:22 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tKaYv-0008Wl-Fk for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 09 Dec 2024 11:00:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKaYJ-0003y0-B4; Mon, 09 Dec 2024 04:59:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKaXs-0003we-4J for help-gnu-emacs@gnu.org; Mon, 09 Dec 2024 04:59:16 -0500 Original-Received: from mail-yw1-x112d.google.com ([2607:f8b0:4864:20::112d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tKaXo-00050D-JN for help-gnu-emacs@gnu.org; Mon, 09 Dec 2024 04:59:15 -0500 Original-Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-6efe81c8958so1152917b3.0 for ; Mon, 09 Dec 2024 01:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733738350; x=1734343150; darn=gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=x/rnddkp5x5hxvDMXsBl/DCviXWHKeamymcaYAH16uU=; b=g3VhMSPdyPDYR9wkgCqKrrx3S++3rwgxVEjOOvZHE7trjgmEijJHCO/rFcPoRv1Mw5 n/OZ82/q3SnmuEdCb4cd9qbVoQ2Nh1J+rpsqzsVCgcXuLUG8SVBbqXTMaard/S76ZGIx Vai14Piid4oK5OnMg6pbTZcpmwP9CpYTO60IRiXZoIAy2A1aNucpoUtTc93pvRPSwHOm fIcOzzEZ9rb1hw6PSvj1VpnbP1kdiNpRDuoOasHs1fgAeTBph5RxIbonbiVjNQug2pK9 s819ljZJvebghSuvhZ+WknDErCLbbDh+6hAnaI7P9p0js4c9/m0WFxgQ88vpihVaIN1k PuNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733738350; x=1734343150; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x/rnddkp5x5hxvDMXsBl/DCviXWHKeamymcaYAH16uU=; b=PHhl67Kdx3tQM3k0g9DmWCxISrFdAZxE8lPEj7dOeZ1DJ8i0NDGNEvjdhi8VotzDxs noZtvdRgRmW+WNoKykxb26H9+ClKXcCssqZ1xelC9/cHnMNLBofT27BJJwEQq5/9dFtx 8XR7rqOspofeqFskUQrGO1YAAJv8lx5SMKGFQ/1wBSzJYg5OiXHxvE3zxOVNmFsjF8uP cOsnoDfXIpi8osjUt0CIMNx+JI/cKH3/M9HJRFOlkBw7V2KM1eT6TBP6IOj9b1EQ8K// /aoy9ro2vJRtogClz+SUTk/HR4kXuGip7e+ROyv7zD3VqCY8iTAGiyLOWY7rOaHj3fJ6 P93A== X-Gm-Message-State: AOJu0YweLiWJIUoIAL6I/eZy5v8tRQ8KSy30YS8rqYvDXPpEAWVlk8tr T5+cjzWpa51Fp50eww5bQYbDmroZG/+GY2f/kp6ra2Ydt+itcRn/o/EiYo3e+Pant1S39ixSGLO 9yt7gWIreNZATg9UNYKu7AgqFkR+Hrg== X-Gm-Gg: ASbGncvsRxkXfVRx1pIxlq3SFgyB1bRMCDZUTWBdKjfVWkhVJB6FXxMghpSt2Zdtw58 xQFzdQFV9fCLZC1qNFTamypj/H//hqJM= X-Google-Smtp-Source: AGHT+IHRKZ3383ok67nbxHdFt7upL8DtGVNiXS14Ij2yIkD0RsqEFOJuF971cDbU0cJxk2Oak2aLVSs84/Hi7VydHSo= X-Received: by 2002:a05:6902:15c3:b0:e38:b7b8:51a8 with SMTP id 3f1490d57ef6-e3a0b513179mr4699740276.7.1733738350320; Mon, 09 Dec 2024 01:59:10 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::112d; envelope-from=marcoxa@gmail.com; helo=mail-yw1-x112d.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:148715 Archived-At: 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=E2=80=AFPM wro= te: > 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=C3=B6rn Bidar) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 08 Dec 2024 19:46:11 +0200 > From: Eli Zaretskii > 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 > > >> > > > >> > 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, i= t > > >> would make a lot of sense for this "ambient" Emacs to be able to tel= l > > >> `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 > To: Eli Zaretskii > Cc: help-gnu-emacs@gnu.org > Subject: Re: Unicode and text editors > Message-ID: > > protonmail.com> > > Content-Type: text/plain; charset=3Dutf-8 > > > On Monday, December 9th, 2024 at 4:32 AM, Eli Zaretskii > 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 > 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 > > 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 > To: Eli Zaretskii > Cc: help-gnu-emacs@gnu.org > Subject: Re: Unicode and text editors > Message-ID: > > protonmail.com> > > Content-Type: text/plain; charset=3Dutf-8 > > > > > > > Sent with Proton Mail secure email. > > On Monday, December 9th, 2024 at 6:44 AM, Eli Zaretskii > 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 showin= g > > > 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 > 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 > > 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 > 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 > To: Eli Zaretskii > Cc: help-gnu-emacs@gnu.org > Subject: Re: Unicode and text editors > Message-ID: > > protonmail.com> > > Content-Type: text/plain; charset=3Dutf-8 > > > On Monday, December 9th, 2024 at 7:07 AM, Eli Zaretskii > 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=C3=B6rn Bidar > To: Yuri Khan > Cc: Eli Zaretskii , help-gnu-emacs@gnu.org > Subject: Re: Transforming paths in compilation output (containerized > builds) > Message-ID: <87frmy2c38.fsf@> > Content-Type: text/plain > > Yuri Khan writes: > > > On Sun, 8 Dec 2024 at 12:43, Eli Zaretskii 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 o= n > 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 > *********************************************** > --=20 Marco Antoniotti Somewhere over the Rainbow