A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg00556.html below:

Re: feature/package-vc has been merged

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] From: Eli Zaretskii Subject: Re: feature/package-vc has been merged Date: Thu, 10 Nov 2022 09:23:08 +0200 
> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: Philip Kaludercic <philipk@posteo.net>,  Eli Zaretskii <eliz@gnu.org>,
>   rms@gnu.org,  emacs-devel@gnu.org
> Date: Thu, 10 Nov 2022 01:40:33 +0200
> 
> I'm exactly talking about you reference but with addition that there's
> no standard load-path for native modules. Regular lisp modules which are
> unless native compilation is used interpreted or byte compiled go to
> /usr/share.
> 
> But native modules should go to /usr/lib/emacs/site-lisp or something
> similar in name.
> 
> But Emacs doesn't configure a load path for such packages by default.

Emacs looks for modules in the same directories as Lisp files: along
load-path.  So I don't understand why you say that there's no standard
path for native modules: there certainly is, from my POV.

If Emacs can find Lisp files that are part of a package, Emacs should
also be able to find the modules that are part of the package.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4