[ELPA] New package: kixtart-mode

[ELPA] New package: kixtart-mode

[morgan]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

I'd like to submit language support for KiXtart as a GNU ELPA package
(patch is attached).

KiXtart (http://www.kixtart.org/) is a Windows scripting language which
doesn't have much in the way of modern editor support.

This is the first Emacs package that I've made but I'm fairly confident
there is nothing too terrible in there and I am actively using it.

There is a slight complication in that there is an old kixtart-mode
package on MELPA which just provided some font locking. I do have
permission from the author of this previous package to take over the
package name, effectively replacing the MELPA package with the new GNU
ELPA package. See confirmation from the author of the previous package
here: https://github.com/ryrun/kixtart-mode/issues/2

I have gone through the FSF copyright assignment process and received
confirmation that it was successfully completed.

Would there be any issues in adding the package?

Thanks,
Morgan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-kixtart-mode-New-package.patch --]
[-- Type: text/x-patch, Size: 923 bytes --]

From f36cc5d26b9992db0463a65c883b4ffc82484466 Mon Sep 17 00:00:00 2001
From: Morgan Willcock <morgan@ice9.digital>
Date: Wed, 9 Nov 2022 19:24:43 +0000
Subject: [PATCH 1/1] * elpa-packages ("kixtart-mode"): New package

---
 elpa-packages | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index 412e266..ad8ed95 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -421,6 +421,10 @@
  ;; Kiwix.el is not on Github any more, but hasn't found a new home yet.
  ("kiwix"		:url nil ;Was "https://github.com/stardiviner/kiwix.el"
   :ignored-files ("*.png" "LICENSE"))
+ ("kixtart-mode"	:url "https://github.com/morganwillcock/kixtart-mode"
+  :ignored-files (".dir-locals.el" "LICENSE" "Makefile" "README"
+                  "kixtart-mode-tests.el" "syntax.kix")
+  :readme "README")
  ("kmb"			:url nil)
  ("landmark"		:url nil)
  ("leaf"		:url "https://github.com/conao3/leaf.el"
-- 
2.30.2

Re: [ELPA] New package: kixtart-mode

[Philip Kaludercic]

"morgan@ice9.digital" <morgan@ice9.digital> writes:

> KiXtart (http://www.kixtart.org/) is a Windows scripting language which
> doesn't have much in the way of modern editor support.

Just to get this out of the way: GNU ELPA requires packages to have no
hard dependencies on non-free software.  Is this the case with KiXtart?
Are there free implementations that run on free operating systems?

Re: [ELPA] New package: kixtart-mode

[Morgan Willcock]

On Wednesday, November 09, 2022 21:10 GMT, Philip Kaludercic <philipk@posteo.net> wrote:

> "morgan@ice9.digital" <morgan@ice9.digital> writes:
>
> > KiXtart (http://www.kixtart.org/) is a Windows scripting language which
> > doesn't have much in the way of modern editor support.
>
> Just to get this out of the way: GNU ELPA requires packages to have no
> hard dependencies on non-free software.  Is this the case with KiXtart?
> Are there free implementations that run on free operating systems?

There is no free-software KiXtart interpreter, but the interpreter is
not required to edit the scripts, so I wouldn't class that as a hard
dependency for the package.

Typically when I use the package I am not using it on Windows.

Re: [ELPA] New package: kixtart-mode

[Stefan Monnier]

Hi Morgan,

> I'd like to submit language support for KiXtart as a GNU ELPA package
> (patch is attached).

Thanks, looks good.  Find below my sig a suggested patch to fix a few
minor issues I found along the way (the main one is arguably the way
`kixtart-tempo-tags` is passed to `tempo-define-template`).

> There is a slight complication in that there is an old kixtart-mode
> package on MELPA which just provided some font locking. I do have
> permission from the author of this previous package to take over the
> package name, effectively replacing the MELPA package with the new GNU
> ELPA package. See confirmation from the author of the previous package
> here: https://github.com/ryrun/kixtart-mode/issues/2

Looks fine from here.

> I have gone through the FSF copyright assignment process and received
> confirmation that it was successfully completed.

The only issue on my side is that your name doesn't yet appear in the
`copyright.list` file I can get from the FSF.  Sometimes the FSF clerk
forgets to update the file on the server, so it's nothing to worry about
(and sometimes it's a mismatch in the names I use which make my searches
fail).

> Would there be any issues in adding the package?

There is one issue, yes: is KiXtart Free Software?
According to Wikipedia, the license is "Closed source Careware".
And indeed, I can't find any source code on http://www.kixtart.org/.
If that's indeed proprietary code, then I think we probably wouldn't
want to host `kixtart-mode` on (Non)GNU ELPA.


        Stefan


diff --git a/kixtart-mode.el b/kixtart-mode.el
index 0cb8b9edc4..72b7dc6724 100644
--- a/kixtart-mode.el
+++ b/kixtart-mode.el
@@ -848,7 +848,7 @@ removed when template insertion is interactive."
                  (remove 'p template)
                template))))
 
-(defconst kixtart-tempo-tags nil
+(defvar kixtart-tempo-tags nil
   "Tempo tags for KiXtart Mode.")
 
 (define-abbrev-table 'kixtart-mode-abbrev-table nil
@@ -863,18 +863,17 @@ TAG, DOCUMENTATION, and ELEMENTS are passed directly to
 `tempo-define-template'.  TAG is also used as the abbrev string
 which will be expanded to the template."
   (declare (indent 2))
-  (let ((template (gensym)))
-    `(let ((,template (tempo-define-template (concat "kixtart-" ,tag)
-                                             (quote ,@elements)
-                                             ,tag
-                                             ,documentation
-                                             kixtart-tempo-tags)))
-       (define-abbrev kixtart-mode-abbrev-table ,tag "" (identity ,template)
+  (let ((funname (intern (concat "kixtart-template-" tag))))
+    `(progn
+       (defalias ',funname
+         (tempo-define-template (concat "kixtart-" ,tag)
+                                (quote ,@elements)
+                                ,tag
+                                ,documentation
+                                'kixtart-tempo-tags))
+       (define-abbrev kixtart-mode-abbrev-table ,tag "" #',funname
          :system t)
-       (put (identity ,template) 'no-self-insert t)
-       (defalias (intern (concat "kixtart-template-" ,tag))
-         (identity ,template)
-         ,documentation))))
+       (put ',funname 'no-self-insert t))))
 
 (kixtart--define-template
     "while"
@@ -962,16 +961,16 @@ which will be expanded to the template."
     (define-key map (kbd "C-c C-t C-b") #'tempo-backward-mark)
     (define-key map (kbd "C-c C-t C-f") #'tempo-forward-mark)
     (define-key map (kbd "C-c C-t C-t") #'tempo-complete-tag)
-    (define-key map (kbd "C-c C-t I") 'kixtart-template-ifelse)
-    (define-key map (kbd "C-c C-t c") 'kixtart-template-case)
-    (define-key map (kbd "C-c C-t d") 'kixtart-template-do)
-    (define-key map (kbd "C-c C-t e") 'kixtart-template-foreach)
-    (define-key map (kbd "C-c C-t f") 'kixtart-template-for)
-    (define-key map (kbd "C-c C-t i") 'kixtart-template-if)
-    (define-key map (kbd "C-c C-t l") 'kixtart-template-else)
-    (define-key map (kbd "C-c C-t s") 'kixtart-template-select)
-    (define-key map (kbd "C-c C-t u") 'kixtart-template-function)
-    (define-key map (kbd "C-c C-t w") 'kixtart-template-while)
+    (define-key map (kbd "C-c C-t I") #'kixtart-template-ifelse)
+    (define-key map (kbd "C-c C-t c") #'kixtart-template-case)
+    (define-key map (kbd "C-c C-t d") #'kixtart-template-do)
+    (define-key map (kbd "C-c C-t e") #'kixtart-template-foreach)
+    (define-key map (kbd "C-c C-t f") #'kixtart-template-for)
+    (define-key map (kbd "C-c C-t i") #'kixtart-template-if)
+    (define-key map (kbd "C-c C-t l") #'kixtart-template-else)
+    (define-key map (kbd "C-c C-t s") #'kixtart-template-select)
+    (define-key map (kbd "C-c C-t u") #'kixtart-template-function)
+    (define-key map (kbd "C-c C-t w") #'kixtart-template-while)
     (define-key map (kbd "C-c C-u") #'kixtart-up-script-block)
     map))
 

Re: [ELPA] New package: kixtart-mode

[Morgan Willcock]

On Wednesday, November 09, 2022 22:04 GMT, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > Would there be any issues in adding the package?
>
> There is one issue, yes: is KiXtart Free Software?
> According to Wikipedia, the license is "Closed source Careware".
> And indeed, I can't find any source code on http://www.kixtart.org/.
> If that's indeed proprietary code, then I think we probably wouldn't
> want to host `kixtart-mode` on (Non)GNU ELPA.

There is no dependency or inter-op with the interpreter, and the package
was developed independently - since the source code is not available it
is also impossible for me to create any link to it.

But if this is the final decision I'll live with it.

> Find below my sig a suggested patch to fix a few minor issues I found
> along the way (the main one is arguably the way `kixtart-tempo-tags`
> is passed to `tempo-define-template`).

Thanks for taking a look. Are you happy if I take your patch, regardless
of where the package ends up?

Re: [ELPA] New package: kixtart-mode

[Stefan Monnier]

Morgan Willcock [2022-11-09 23:48:25] wrote:
> On Wednesday, November 09, 2022 22:04 GMT, Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>> > Would there be any issues in adding the package?
>> 
>> There is one issue, yes: is KiXtart Free Software?
>> According to Wikipedia, the license is "Closed source Careware".
>> And indeed, I can't find any source code on http://www.kixtart.org/.
>> If that's indeed proprietary code, then I think we probably wouldn't
>> want to host `kixtart-mode` on (Non)GNU ELPA.
>
> There is no dependency or inter-op with the interpreter, and the package
> was developed independently - since the source code is not available it
> is also impossible for me to create any link to it.

Yes, I understand this.  The question is rather one of policy/strategy
than one of copyright.

> But if this is the final decision I'll live with it.

I can never remember exactly what is the policy in such cases, so I'm
hoping Richard will chime in.  AFAIK the general rule is that we don't
want to distribute packages which are only meaningful when you use
proprietary software, but the details matter (e.g. is it likely that
someone will choose to use another editor to edit their KiXtart code, is
it likely that someone will start to use KiXtart because it has a nice
Emacs mode, ...).

>> Find below my sig a suggested patch to fix a few minor issues I found
>> along the way (the main one is arguably the way `kixtart-tempo-tags`
>> is passed to `tempo-define-template`).
> Thanks for taking a look. Are you happy if I take your patch, regardless
> of where the package ends up?

Yes, of course :-)


        Stefan

Re: [ELPA] New package: kixtart-mode

[Morgan Willcock]

On Wednesday, November 09, 2022 23:58 GMT, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Morgan Willcock [2022-11-09 23:48:25] wrote:
> > On Wednesday, November 09, 2022 22:04 GMT, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> > Would there be any issues in adding the package?
> >>
> >> There is one issue, yes: is KiXtart Free Software?
> >> According to Wikipedia, the license is "Closed source Careware".
> >> And indeed, I can't find any source code on http://www.kixtart.org/.
> >> If that's indeed proprietary code, then I think we probably wouldn't
> >> want to host `kixtart-mode` on (Non)GNU ELPA.
> >
> > There is no dependency or inter-op with the interpreter, and the package
> > was developed independently - since the source code is not available it
> > is also impossible for me to create any link to it.
>
> Yes, I understand this.  The question is rather one of policy/strategy
> than one of copyright.
>
> > But if this is the final decision I'll live with it.
>
> I can never remember exactly what is the policy in such cases, so I'm
> hoping Richard will chime in.  AFAIK the general rule is that we don't
> want to distribute packages which are only meaningful when you use
> proprietary software, but the details matter (e.g. is it likely that
> someone will choose to use another editor to edit their KiXtart code, is
> it likely that someone will start to use KiXtart because it has a nice
> Emacs mode, ...).

If I were to argue the case I would state that:

1. There aren't actually many alternatives to this package for
   up-to-date language support in any editor, so the chances of someone
   using Emacs specifically to use the package is not zero.

2. Emacs already contains bat-mode.el which explicitly states that it is
   for editing Windows specific scripts and also includes functionality
   to execute those scripts using the proprietary interpreter:

   ;;; Commentary:
   ;;
   ;; Major mode for editing DOS/Windows scripts (batch files).  Provides syntax
   ;; highlighting, a basic template, access to DOS help pages, imenu/outline
   ;; navigation, and the ability to run scripts from within Emacs.

Re: [ELPA] New package: kixtart-mode

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On Thu, Nov 10, 2022 at 1:21 AM Morgan Willcock <morgan@ice9.digital> wrote:


> 2. Emacs already contains bat-mode.el which explicitly states that it is
>    for editing Windows specific scripts and also includes functionality
>    to execute those scripts using the proprietary interpreter:


Many years ago I wanted to install a tiny fix to work around a difference
between cmd.exe and 4DOS/4NT (a proprietary command shell for Windows), and
was told not to. IIRC, it wasn't even a change to bat-mode, but to one of
the .bat scripts used back then to build Emacs on Windows. Something
similar happened with CVS support vs CVSNT (it was a question of adding a
non-standard parameter that CVSNT required to be silent).

[-- Attachment #2: Type: text/html, Size: 1162 bytes --]

Re: [ELPA] New package: kixtart-mode

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I have gone through the FSF copyright assignment process and received
>> confirmation that it was successfully completed.
>
> The only issue on my side is that your name doesn't yet appear in the
> `copyright.list` file I can get from the FSF.  Sometimes the FSF clerk
> forgets to update the file on the server, so it's nothing to worry about
> (and sometimes it's a mismatch in the names I use which make my searches
> fail).
>

Is the list is public, or is it accessible only to the maintainers?

-- 
Akib Azmain Turja --- https://akib.codeberg.page/
GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social, Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [ELPA] New package: kixtart-mode

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: morgan@ice9.digital,  emacs-devel@gnu.org
> Date: Thu, 10 Nov 2022 14:16:20 +0600
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> I have gone through the FSF copyright assignment process and received
> >> confirmation that it was successfully completed.
> >
> > The only issue on my side is that your name doesn't yet appear in the
> > `copyright.list` file I can get from the FSF.  Sometimes the FSF clerk
> > forgets to update the file on the server, so it's nothing to worry about
> > (and sometimes it's a mismatch in the names I use which make my searches
> > fail).
> >
> 
> Is the list is public, or is it accessible only to the maintainers?

The latter.

Re: [ELPA] New package: kixtart-mode

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Akib Azmain Turja <akib@disroot.org>
>> Cc: morgan@ice9.digital,  emacs-devel@gnu.org
>> Date: Thu, 10 Nov 2022 14:16:20 +0600
>> 
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>> >> I have gone through the FSF copyright assignment process and received
>> >> confirmation that it was successfully completed.
>> >
>> > The only issue on my side is that your name doesn't yet appear in the
>> > `copyright.list` file I can get from the FSF.  Sometimes the FSF clerk
>> > forgets to update the file on the server, so it's nothing to worry about
>> > (and sometimes it's a mismatch in the names I use which make my searches
>> > fail).
>> >
>> 
>> Is the list is public, or is it accessible only to the maintainers?
>
> The latter.

Thanks for the quick response.

-- 
Akib Azmain Turja --- https://akib.codeberg.page/
GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social, Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [ELPA] New package: kixtart-mode

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > There is no dependency or inter-op with the interpreter, and the package
  > > was developed independently - since the source code is not available it
  > > is also impossible for me to create any link to it.

  > Yes, I understand this.  The question is rather one of policy/strategy
  > than one of copyright.

That is true.

  > > But if this is the final decision I'll live with it.

  > I can never remember exactly what is the policy in such cases, so I'm
  > hoping Richard will chime in.

Our general policy makes a subtle distinction between these two cases:

1. If a nonfree program FOO is not well known, we don't even mention that
it exists.  Because we don't want to promote using FOO.

2. If a nonfree program FOO is well known and widely used, something to
help and encourage FOO's users to use some GNU packages along with FOO
is good.

3. Anything that would encourage the existing users of some GNU packages
to use FOO with them is bad.

Is SickStart the main scripting language for Windows now?  If so, it
will surely be widely used, so case 2 would apply.  Then we would want
to include support for editing it.

BUT, it is a bad thing if people use SickStart to write scripts
that they could have written in a free scripting language.
Is there anything we can do to urge people to use Perl or Python
or Bash instead of SickStart?

Why would someone, on Windows, use SickStart rather than those other
scripting packages?  Does it have some major advantage, for use on
Windows?

Or is it that Microsoft is going to tell everyone that "SickStart is
the scripting language for Windows!  Be the first on your block to try
SickStart!" and people will be led by the nose?

Maybe we can come up with a way to encourage people to choose some
free and portable scripting language, even when using Windows.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [ELPA] New package: kixtart-mode

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 12 Nov 2022 23:18:26 -0500
> 
> Our general policy makes a subtle distinction between these two cases:
> 
> 1. If a nonfree program FOO is not well known, we don't even mention that
> it exists.  Because we don't want to promote using FOO.
> 
> 2. If a nonfree program FOO is well known and widely used, something to
> help and encourage FOO's users to use some GNU packages along with FOO
> is good.
> 
> 3. Anything that would encourage the existing users of some GNU packages
> to use FOO with them is bad.
> 
> Is SickStart the main scripting language for Windows now?

No.

> BUT, it is a bad thing if people use SickStart to write scripts
> that they could have written in a free scripting language.

There are no scripting languages for MS-Windows that are Free
Software, AFAIK.

> Is there anything we can do to urge people to use Perl or Python
> or Bash instead of SickStart?

These are not native Windows scripting languages, and so are either
unable to access advanced Windows features, or require a lot of
additional non-default setup for doing so (and even after that they
are unable to access some of those advanced features).

> Why would someone, on Windows, use SickStart rather than those other
> scripting packages?  Does it have some major advantage, for use on
> Windows?

Yes, it has many advantages.  (I don't use it, but I've skimmed the
manual.)

> Or is it that Microsoft is going to tell everyone that "SickStart is
> the scripting language for Windows!

KiXtart isn't a Microsoft product, AFAICT.

> Maybe we can come up with a way to encourage people to choose some
> free and portable scripting language, even when using Windows.

One would have to be written first.

Re: [ELPA] New package: kixtart-mode

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There are no scripting languages for MS-Windows that are Free
  > Software, AFAIK.

  > > Maybe we can come up with a way to encourage people to choose some
  > > free and portable scripting language, even when using Windows.

  > One would have to be written first.

That is bad news, but thanks for giving that information.

In that situation, we have little possibility of making the situation
any better, whatever we might do.  Basically, there is nothing here we
can hope for except perhaps to make Emacs a little more popular
among Windows users.

  > > Why would someone, on Windows, use SickStart rather than those other
  > > scripting packages?  Does it have some major advantage, for use on
  > > Windows?

  > Yes, it has many advantages.  (I don't use it, but I've skimmed the
  > manual.)

  > > Or is it that Microsoft is going to tell everyone that "SickStart is
  > > the scripting language for Windows!

  > KiXtart isn't a Microsoft product, AFAICT.

If we want to provide better support in Emacs for some nonfree Windows
scripting language, for the same of encouraging use of Emacs on the widely
used system Windows, which Windows scripting language should it be?

All else being equal, it would be better to support the most widely used
Windows scripting language.  That would be most effective at the one
goal that matters to us here -- encouraging use of Emacs on Windows.

All the other goals that some might consider pertinent are part of
their wish to "Make use of Windows better and more convenient" using
nonfree software.  That is not a goal for us!

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [ELPA] New package: kixtart-mode

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> BUT, it is a bad thing if people use SickStart to write scripts
>> that they could have written in a free scripting language.
>
> There are no scripting languages for MS-Windows that are Free
> Software, AFAIK.

After a cursory look at kixtart, I would say with confidence that Tcl/Tk
with the twapi package provides a superset of its features.

Re: [ELPA] New package: kixtart-mode

[North Year]

On 22/12/12 12:50AM, Óscar Fuentes wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>>> BUT, it is a bad thing if people use SickStart to write scripts
>>> that they could have written in a free scripting language.
>>
>> There are no scripting languages for MS-Windows that are Free
>> Software, AFAIK.
>
>After a cursory look at kixtart, I would say with confidence that Tcl/Tk
>with the twapi package provides a superset of its features.

Isn't powershell a free software that can script in MS-Windows and is
the official shell for MS-Windows?

Re: [ELPA] New package: kixtart-mode

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Sun, 11 Dec 2022 18:33:38 -0500
> 
> If we want to provide better support in Emacs for some nonfree Windows
> scripting language, for the same of encouraging use of Emacs on the widely
> used system Windows, which Windows scripting language should it be?

I don't know.  I don't use scripting much, neither on Windows nor
anywhere else.

Re: [ELPA] New package: kixtart-mode

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 12 Dec 2022 00:50:23 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> BUT, it is a bad thing if people use SickStart to write scripts
> >> that they could have written in a free scripting language.
> >
> > There are no scripting languages for MS-Windows that are Free
> > Software, AFAIK.
> 
> After a cursory look at kixtart, I would say with confidence that Tcl/Tk
> with the twapi package provides a superset of its features.

Does Tcl/Tk provide access to the low-level Windows APIs, like
Registry and Win32 functions?

Re: [ELPA] New package: kixtart-mode

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> BUT, it is a bad thing if people use SickStart to write scripts
>> >> that they could have written in a free scripting language.
>> >
>> > There are no scripting languages for MS-Windows that are Free
>> > Software, AFAIK.
>> 
>> After a cursory look at kixtart, I would say with confidence that Tcl/Tk
>> with the twapi package provides a superset of its features.
>
> Does Tcl/Tk provide access to the low-level Windows APIs, like
> Registry and Win32 functions?

Registry access is provided by Tcl out of the box. Access to Windows
APIs is provided by the twapi package.

https://twapi.magicsplat.com/

Re: [ELPA] New package: kixtart-mode

[Morgan Willcock]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> >> BUT, it is a bad thing if people use SickStart to write scripts
>>> >> that they could have written in a free scripting language.
>>> >
>>> > There are no scripting languages for MS-Windows that are Free
>>> > Software, AFAIK.

To clarify on exactly what type of scripting language this is: KiXtart
is not a general purpose scripting language it was specifically designed
to be used as a Windows logon script processor.

It would not make sense to port it to a non-Windows platform because the
majority of functionality is derived from wrapping Win32 API calls.

A free software alternative can exist but primarily it would have to
operate by making Win32 API calls.

>>> After a cursory look at kixtart, I would say with confidence that Tcl/Tk
>>> with the twapi package provides a superset of its features.
>>
>> Does Tcl/Tk provide access to the low-level Windows APIs, like
>> Registry and Win32 functions?
>
> Registry access is provided by Tcl out of the box. Access to Windows
> APIs is provided by the twapi package.
>
> https://twapi.magicsplat.com/

An equivalent in functionality would a self-contained Tcl kit which
includes the TWAPI library, but this is less appealing for three reasons
(and bear in mind that I like Tcl):

- When I looked into building a Tcl kit from source there was no
  documented or standard method to build one, what is recommended is to
  download a pre-built binary and trust it

- The self-contained Tcl kit would be significantly larger than the
  KiXtart binary, this will get copied across the network whenever a
  user logs in

- When I tried querying and mapping printers with TWAPI it didn't seem
  to work correctly

I'm sure it can be argued that any scripting language with an FFI
interface is suitable, but in practical terms the only options which
don't require crafting your own portable interpreter are VBScript,
JScript, and PowerShell - these are already available locally.

P.S. If anyone was still interested to look at the package it has now
moved to sourcehut: https://git.sr.ht/~mew/kixtart-mode

Thanks,
Morgan