From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron Newsgroups: gmane.emacs.devel Subject: Re: [NonGNU ELPA] New package: sweep Date: Wed, 28 Sep 2022 09:46:54 +0300 Message-ID: References: <877d1qlynt.fsf@posteo.net> <874jwsn214.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24312"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) Cc: emacs-devel@gnu.org, Jan Wielemaker To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 28 15:14:26 2022 Return-path: Envelope-to: ged-emacs-devel@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 1odWtN-00068E-Uh for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Sep 2022 15:14:25 +0200 Original-Received: from localhost ([::1]:52264 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odWtN-0000q0-0U for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Sep 2022 09:14:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odQqX-0008A0-7O for emacs-devel@gnu.org; Wed, 28 Sep 2022 02:47:13 -0400 Original-Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]:35668) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1odQqS-0003hy-IM for emacs-devel@gnu.org; Wed, 28 Sep 2022 02:47:04 -0400 Original-Received: by mail-ej1-x629.google.com with SMTP id sd10so25129879ejc.2 for ; Tue, 27 Sep 2022 23:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date; bh=SO2hWLHGodxxnBsRPki/PtR0CqzWKOP0wzf+99bn3tc=; b=aBPhV8LHeIV+U0EbJNSJH8Zx67WaMvxJlZun+/OnT637c040uD5Mr9KatSKd3xLxoM 2/vHyq6oVbQ+zTPEjxYjUDfftOhaeTh43HHXNeWL4h1z+sNmom+ZmiRF4KlnqZ849gyH cLy89xYE5MGmap/3UX7slBRt/6nb46D0Jr7ZEpkz7C7mqnygB5pvlUs8FyCZ7E0v/OFo jv939eMercigXclvcGx1duHzxT63syF//wVLTJpEInKlaefV7zm+derFHUcNI0c9He9E DrSO3UgKIMztvb5B1XKOFkDBZlHKcN7B6hVOOmsOsuHz7oghaTEzfpzJMOa0r85q72mz NTFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date; bh=SO2hWLHGodxxnBsRPki/PtR0CqzWKOP0wzf+99bn3tc=; b=0nyrM0RTPinvwo9xBsdHk2qqngchm4PtOleYmFwBg+5dFpirj94l9WO2TvFIJ3bDSy vym9YDuVymyE1/JHnf6YGRwneICU+95n2gOF2R8LPa3kvwNEFafHnJaaH8jnXrmJrGgx 1XGkSqs9Z09DVbiTZM7PFz7QO0Xb9i2OJRiOqVhWm9QurtpAh3+1ubN87bhPz95cA4+X bVx6yjdxWkE/m0JqVSTeZLVQmxmqEgC5QCDO84lB5LzYUl0ajKS0nY202DpYcg5HpEWv 1Riu/XntwLYJ/JLlWbs589CnceEBNBLjnDHe5jo2aps5fJuvu044N0JWMmtuAB9or3i4 zNZA== X-Gm-Message-State: ACrzQf3FmmjqqLLB1jHisuSLcG1hVH2wOtX0P76P2V3TB9xU2Q3uu6Dr 0W+BN5Byv0WZIc05AYu2sPM= X-Google-Smtp-Source: AMsMyM7RoK+dJ6doE/OVzVjJG0ubYzcYPurgI5UN8hfibNc2MH9hXWR3cMevVGINJJRxofEnkfPu/g== X-Received: by 2002:a17:907:628f:b0:72f:57da:c33d with SMTP id nd15-20020a170907628f00b0072f57dac33dmr25659580ejc.374.1664347617337; Tue, 27 Sep 2022 23:46:57 -0700 (PDT) Original-Received: from esmac.lan ([2a0d:6fc0:bef:7b00:8462:a4f8:723:ac83]) by smtp.gmail.com with ESMTPSA id kv12-20020a17090778cc00b0072af4af2f46sm1878169ejc.74.2022.09.27.23.46.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Sep 2022 23:46:56 -0700 (PDT) In-Reply-To: <874jwsn214.fsf@posteo.net> (Philip Kaludercic's message of "Tue, 27 Sep 2022 17:46:31 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::629; envelope-from=eshelshay.yaron@gmail.com; helo=mail-ej1-x629.google.com 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-Mailman-Approved-At: Wed, 28 Sep 2022 06:58:44 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:296392 Archived-At: Philip Kaludercic writes: > Eshel Yaron writes: > >> Philip Kaludercic writes: >> >>>> I would like to submit a new package to NonGNU ELPA, called "sweep": >>> >>> May I ask what the name is supposed to mean? >> >> Of course, but there's not a lot of depth to it, basically its derived >> from "SWI-P(rolog)", with the "I" replaced with two "e"s for >> "Emacs-Embedded". So a possible backronym may be >> "SW(I) Emacs-Embedded Prolog". > > I agree with RMS () that it might > be nice to have a more indicative name, or at least something that > includes "Prolog". Mor eso because "sweep" makes me think of something > that cleans. I've given it some thought, and all in all I would like to keep the name `sweep` for this project. I do see however why this name may be unhelpful for Emacs users who are not familiar with SWI-Prolog, or who are looking for some "cleaning" package... As a possible solution, I'd be happy to change the name of the Elisp package to `sweeprolog` while still referring to the project as a whole as `sweep` (e.g. in the manual). Does that sounds alright? >>> From briefly skimming through the code I see that you define a new major >>> that doesn't inherit from the default `prolog-mode'. Is there a reason >>> not to do so, or even implement sweep as a minor mode? >> >> I am not opposed to building on top of `prolog-mode`, but since >> `sweep-mode` has access to the actual SWI-Prolog runtime including >> notably its parser, we can (and do) provide better implementations for >> many of the features of `prolog-mode`, at the cost of targeting only >> SWI-Prolog where `prolog-mode` is more implementation agnostic. >> For example, `sweep-mode` defines an `indent-line-function` which takes >> into account the dynamic operator definitions that may occur in Prolog >> code. >> So currently I'm not sure what will be the benefits of inheriting >> from `prolog-mode`, but I'll gladly revisit it as missing features in >> `sweep-mode` pop up. Does that make sense? > > The main advantage I see would be that anyone who uses `prolog-mode' > could inherit their customisations when using sweep. And it shouldn't > be an issue if sweep-mode overrides most of what `prolog-mode' defines. That makes sense, thanks. I'll try deriving from `prolog-mode` and if no unexpected issues come up I'll go with that. > Is the error self-explanatory, in the sense that a user would be able to > understand that SWI Prolog is outdated? Currently it's a generic `file-missing` error, I'll improve on that. > There are some packages that build software themselves > (e.g. pdf-tools), but I don't think that issue has ever been solved in > a clean and robust way. Yes, I've also taken notes from the `vterm` package, which seems to take a rather ad-hoc approach (see e.g. `vterm-module-compile`). Best, Eshel