From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id yL9QDpZRmF8+TgAA0tVLHw (envelope-from ) for ; Tue, 27 Oct 2020 16:57:58 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id UB0zCpZRmF+nfQAAbx9fmQ (envelope-from ) for ; Tue, 27 Oct 2020 16:57:58 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CD07D9402DD for ; Tue, 27 Oct 2020 16:57:57 +0000 (UTC) Received: from localhost ([::1]:45150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kXSIG-0001Py-JC for larch@yhetil.org; Tue, 27 Oct 2020 12:57:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56936) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXSDm-0005qg-4C for guix-devel@gnu.org; Tue, 27 Oct 2020 12:53:19 -0400 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]:39383) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kXSDj-0004eX-6R for guix-devel@gnu.org; Tue, 27 Oct 2020 12:53:17 -0400 Received: by mail-qt1-x842.google.com with SMTP id i7so1491239qti.6 for ; Tue, 27 Oct 2020 09:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=43Sn+vtx2AeZ002m2eO8nZSQYybdjuZB0bPXnNPq7cg=; b=YilpjfO9d4iBq8fuSwy9SuHbu+y3KcRcjjLlUpdM679cwya0z010snfjvGVdkNNt7F tE4yVQ2DfoC1eHWgRpZJ0ac173UzKMQgnMRjyWtT39pRMBoPwCEwsmuZFlu4KBJPkN9f 5sjNasUQvspPK3VWbxoUR0dmOG6mZmU/Ei67dEGNe76BBQ4xXPNBHOOjXjTGq9jrRxD3 2V013tk+n1lBsEKUhiDKw6DuvjRPneKUYb+Hxd1FnaDhI5r8irnqvEzlwhwlvumufmmN NMlRy4EwiutbOkDIkcuooo42EbIM35xI2OMafAQjokNR7exAVFNBkuEmsv+Vqcrl6bS6 2oxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=43Sn+vtx2AeZ002m2eO8nZSQYybdjuZB0bPXnNPq7cg=; b=YOY/z5uFGyY9TzZSWEfci5rktTQmXTfZIFTMxnXLVeLZsN+n9yPamP5fkso2PnAXqd qt6qqBumapTBzlgwiTs2av+0l8ODd7r9qMJuKcQtcKi0IjYN9iBLjmr0s8TQ6iDRsD7E 1HDhbtj3TAyff8KhYnUbLumVo6Nhe1RVYxOOe4lrFRr0bbJ7X7qcwxnhYuj0ROaoJOI0 mn5SdM7qqzNtQP7JGjx265fL6XXnMcuuELQNGMfSKt0IDz2bi2QZrmfQMLrLLTbPXCf0 ZiFvwdoe/DQ6Xu/loZu5sr4reoT6Rj4xCNFYMKJhqPuHkU0Hwv7RJRl0gkNcxmgHGjzG +n8w== X-Gm-Message-State: AOAM530uQV8leJmZ4jp/BHL1xPPdGOSzb1lOd5uU8UuYGhPGWRZiOrZo UFEdHtNifF5sCNSANZ7biYw= X-Google-Smtp-Source: ABdhPJwaxOv88/f1yzjugiovds+jphTYWSOYb/+kJefokJ3WTwvWbsBtveUCBbGa+Kv9vtzfKqPlRA== X-Received: by 2002:ac8:5a53:: with SMTP id o19mr3053332qta.183.1603817594039; Tue, 27 Oct 2020 09:53:14 -0700 (PDT) Received: from hurd (dsl-152-107.b2b2c.ca. [66.158.152.107]) by smtp.gmail.com with ESMTPSA id n63sm1034976qka.45.2020.10.27.09.53.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2020 09:53:13 -0700 (PDT) From: Maxim Cournoyer To: Miguel =?utf-8?Q?=C3=81ngel?= Arruga Vivas Subject: Re: [PATCH v2] .dir-locals.el: Automatically set the GEISER-GUILE-LOAD-PATH variable. References: <87o8kqowa5.fsf@gmail.com> <20201026055316.25592-1-maxim.cournoyer@gmail.com> <877drdp68p.fsf@gmail.com> Date: Tue, 27 Oct 2020 12:53:12 -0400 In-Reply-To: <877drdp68p.fsf@gmail.com> ("Miguel =?utf-8?Q?=C3=81ngel?= Arruga Vivas"'s message of "Mon, 26 Oct 2020 12:38:14 +0100") Message-ID: <87y2jrwqyv.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::842; envelope-from=maxim.cournoyer@gmail.com; helo=mail-qt1-x842.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=YilpjfO9; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: 0.09 X-TUID: n1P5zAiATLw1 Hello Miguel! Miguel =C3=81ngel Arruga Vivas writes: > Hello, Maxim! > > Thanks for your effort in this, some comments with the quotes for > context. Thanks for your comments, they've already made this proposed change much better! > Maxim Cournoyer writes: >>> This fails if geiser-guile-load-path does not exist (void-variable). >>> The cleanup removes other guixes, isn't it? I suggest making the >>> variable buffer-local and forget about hard-coded names. :-) >> >> That's a good suggestion! I toyed with it and it's a bit tricky but I >> think the v2 patch I'll send as a follow-up does the trick. My concern >> was also supporting when a user has previously set >> geiser-guile-load-path in their .emacs init file, e.g.: >> >> (setq geiser-guile-load-path (list (expand-file-name "~/src/guix") >> (expand-file-name "~/src/shepherd"))) >> >> That would mean their entries don't get cleaned up (it seems this >> doesn't matter in my latest tests with the v2 patch though!). > > That cleanup seems to me responsibility of that .emacs maintainer > instead of something to take into account in .dir-locals. ;-) Indeed, it could be seen that way! The good news is that it doesn't seem to cause any problems anyway, should they forget an entry for Guix there. >>> (eval . (setq guix-directory >>> (locate-dominating-file default-directory ".dir-locals.el"))) >>> (eval . (when (boundp 'geiser-guile-load-path) >> >> This check makes it so that if geiser-guile-load-path is not already >> defined, nothing happens. It is likely that this is the case, as when >> relying on just Geiser's autoloads, it is not loaded. The user would >> have to either set explicitly before hand or call (require >> 'geiser-guile), which we can't rely on. But we can drop this check. > > You're right, as you can only bind the keys and enable it when used, not > at file load as I do, great catch. :-) > >> One thing that worried me was the %load-compiled-path not appearing in >> the order defined from guile-geiser-load-path, but in my latest tests as >> mentioned above it didn't matter. > > With the right directories (meaning no-conflicts between modules) it > shouldn't matter, but it's weird. Looking into geiser-guile.el the load > path is provided to guile through -L parameters in > geiser-guile--parameters, and the extra path for Geiser code is added > with geiser-guile--set-geiser-load-path (that's why it is not added to > %load-compiled-path)... I'd have to check Guile to be sure why are the > differences, but they seem harmless. OK, thank you for investigating! >> + (unless (fboundp 'geiser-guile-load-path) >> + (defvar geiser-guile-load-path '())) > > This checks the function definition, not the variable, as Emacs Lisp has > two separate namespaces. Oops, good catch! >> I ended up using `cl-pushnew' here instead of push, as otherwise >> repeated entries were accumulated. > > I wanted to avoid exactly that check, as the variable should end up with > duplicated entries only when you call it twice from the same buffer, how > could that happen? > >> + (make-local-variable 'geiser-guile-load-path) >> + (cl-pushnew root-dir* geiser-guile-load-path >> + :test #'string-equal))))) > > If there is some way this may happen, then this call is OK, but I'd try > to stay with a cheaper push unless it's really needed, as O(1) < O(n), > for almost every n. :-) The way I could easily trigger this was to open a dired buffer, and hitting 'g' to refresh its contents. > Again, thank you very much for taking care of this, as it would make > life easier for everybody of us who uses Geiser. I'm glad to read it! :-) I'll be sending a v3 with the fboundp woopsie above fixed. Maxim