From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.help Subject: Re: Requiring elisp that comes with Emacs Date: Tue, 31 Jan 2017 15:39:11 +0100 Message-ID: <87d1f39tv4.fsf@wanadoo.es> References: <874m0gv6ba.fsf@gmail.com> <87k29bl4v0.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1485885213 26869 195.159.176.226 (31 Jan 2017 17:53:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2017 17:53:33 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jan 31 18:53:29 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYccT-0006od-Ke for geh-help-gnu-emacs@m.gmane.org; Tue, 31 Jan 2017 18:53:29 +0100 Original-Received: from localhost ([::1]:39866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYccZ-0002uX-2l for geh-help-gnu-emacs@m.gmane.org; Tue, 31 Jan 2017 12:53:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYbkW-0000ym-B4 for help-gnu-emacs@gnu.org; Tue, 31 Jan 2017 11:57:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYbkR-0005DX-N4 for help-gnu-emacs@gnu.org; Tue, 31 Jan 2017 11:57:44 -0500 Original-Received: from [195.159.176.226] (port=36956 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cYbkR-0005DD-Gy for help-gnu-emacs@gnu.org; Tue, 31 Jan 2017 11:57:39 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cYZaU-0002PO-Eq for help-gnu-emacs@gnu.org; Tue, 31 Jan 2017 15:39:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 45 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:4QXeLs85s0ez47OIGNQwzw/L0ng= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-Mailman-Approved-At: Tue, 31 Jan 2017 12:04:32 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:112213 Archived-At: Narendra Joshi writes: >> What happens when we do `require'? >> >> >> It guarantees the relevant feature is available, generally as a side >> effect of loading the named package. I believe the package much >> "provide" its name. If not found, an error is raised. Full details >> can be found here: >> >> https://www.gnu.org/software/emacs/manual/html_node/elisp/ >> Named-Features.html > > My question was more about whether we need to `require` packages that > come with Emacs itself, e.g. org-mode. Emacs comes with lots of packages. A typical user only needs a fraction of those packages. Every package takes some time to load and then uses resources. Loading everything by default would be a waste. Another reason for explicitly requiring a package such as `vc' (which typically is automatically loaded when certain conditions are met) is to ensure that certain functions and/or variables are available because you use them in your code (in your .emacs, for instance). >> While under the covers I imagine the implementation is much >> different, I my mental model is similar to Python's import statement >> or C++'s namespace statement. All three make a series of names >> available to you, though require is a global operation, not local to >> a particular module or translation unit. > > I think every file in the `load-path' would need to be read for a > (provide 'something) at the end while trying to > (require 'something). Languages that make sure that the name of the > module is the same as the name of the file do not have to look inside > the file. This is all speculation and I do not know how exactly things > are done in reality. Type C-h f require [ENTER] A *Help* buffer will popup with the docstring for `require'. There it is explained that the file for the require-d package is inferred from the package name.