From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: [NonGNU ELPA] New packages: Vcomplete, swsw Date: Sun, 22 May 2022 16:07:00 +0000 Message-ID: <87mtf9lfff.fsf@posteo.net> References: <875ylx4yvn.fsf@dsemy.com> <87h75hyehx.fsf@posteo.net> <87sfp15zp1.fsf@dsemy.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="708"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Daniel Semyonov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 22 18:08:52 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 1nso8S-000AXx-5e for ged-emacs-devel@m.gmane-mx.org; Sun, 22 May 2022 18:08:52 +0200 Original-Received: from localhost ([::1]:52842 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nso8Q-0004qq-Uh for ged-emacs-devel@m.gmane-mx.org; Sun, 22 May 2022 12:08:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53284) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nso6s-0003Wb-Aq for emacs-devel@gnu.org; Sun, 22 May 2022 12:07:14 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:40027) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nso6q-0001gr-27 for emacs-devel@gnu.org; Sun, 22 May 2022 12:07:13 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C1565240109 for ; Sun, 22 May 2022 18:07:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1653235626; bh=hs509kGHQON9bC8QTC0L5Q6yk7zSDsAs9tvC8x7BxbU=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=EMz+cGYhvkOzX67fjDFgBtvBC9hRHuRPgb3dgbhICD0zoUWjxNMH5PqByQpZy3qFn FeSe5jpYYkn/dJsHCoOp+T26oL0U4W2miqgWynmne+zLfo4gSs1AaV6cgmFxv3r0Dl 6N44NILCg/o+T2MPDY+bkEP7FgX6zIBM7wHZKgsaPj1HkYU5WK/NY6xMH7L9agQ+35 FDMuCmiE6JUbw9pjyvHpYdId54haMyY0m1XGyOUiVpEK2Gwlp3ryQCWHG4VBaemr/w 1uovWkrHcvrArnOHFHjVOSI0Dc8ZDp1rFuthysr3u1I0Eq23zXSyz0Gh20wzVQF6zZ CpNVysRvXUNXA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4L5lhp18Slz6tmJ; Sun, 22 May 2022 18:07:06 +0200 (CEST) Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: <87sfp15zp1.fsf@dsemy.com> (Daniel Semyonov's message of "Sun, 22 May 2022 18:55:54 +0300") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:290098 Archived-At: Daniel Semyonov writes: >>>>>> Philip Kaludercic writes: > > > - You add vcomplete-embark.el, that seems to be a package in it's > > own right (with a dependency on embark), but with your patch this > > will just be bundled into the same package. Is this intentional? > > Semi-intentional... now that you mention it, is it possible for two > (related) packages to share the same git repository? If so, > vcomplete-embark should be its own package. It is, though not advised if not necessary (it works by excluding all the files from package B in the specification for package A, and vice versa). A slightly more elegant approach is to use separate, detached branches but at that point you effectively have two repositories anyway (that you can associate as part of the same project on SourceHut). > In any case, I haven't tested this integration in a while, so I think it > would make more sense to completely exclude 'vcomplete-embark.el' for > now (this integration broke in the past due to changes to Embark and > Vcomplete, and might be broken in some way now as I don't currently use > Embark). I'll do some testing in the next few days. In that case I'd advise just adding it to a .elpaignore so that you don't have to change the package specification upstream. > > - Could the vector key syntax ([?\C-a]) be replaced with a (kbd > > "C-a")? I think the general trend nowadays is towards the latter, > > and more people are familiar with it. > > Now that you mention it, since it's just an example, wouldn't it make > more sense to use 'keymap-set' for it? (Although technically both > packages could be used with an Emacs version that doesn't support > 'keymap-set'). I wouldn't, as your package-dependency specification indicates that the minimal version is 25.1, and no release of Emacs has been made with the new keymap functions/macros. It is easy for enthusiasts to forget that most people are not tracking the master branch. > > Have you made up your mind about the name, or could you be > > convinced to change it to something like "window-switch" or > > "windswitch" (so that it sounds similar to windmove)? Just > > suggestions of course, I just anticipate a discussion on this > > question, because the name itself is not that expressive. > > I wouldn't mind changing the name (I agree it's not very good), however > I would have to change this name in quite a few places. > OTOH, with 'list-packages' showing a brief description of each package, > I'm not sure if I see a big benefit to changing the name. I'll have to > think about it. Ok, no problem. As I said it is just a suggestion, perhaps someone else has a better idea that might make the change worth the effort. > >> PS: I initially intended to submit these packages to GNU ELPA, > >> but unfortunately I probably won't be able to assign copyright > >> any time soon. (I'm assuming it would be possible to move them to > >> GNU ELPA in the future?) > > > It should be possible. > > Great! > > BTW, when the packages are first imported, would the latest commit be > used, or should I bump the version (after I make all relevant changes)? No, the last commit that bumps the version tag is always the one used. I can push the specifications, though I will wait for a bit to see if anyone wants to comment on anything discussed here.