GNU bug report logs - #74235
[PATCH] ; Remove 'nil' from some 'lua-ts-mode' options

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: john muhl <jm <at> pub.pink>
Cc: 74235 <at> debbugs.gnu.org
Subject: bug#74235: [PATCH] ; Remove 'nil' from some 'lua-ts-mode' options
Date: Thu, 07 Nov 2024 07:58:42 +0200

> From: john muhl <jm <at> pub.pink>
> Date: Wed, 06 Nov 2024 15:22:34 -0600
> 
> * lisp/progmodes/lua-ts-mode.el (lua-ts-luacheck-program):
> (lua-ts-inferior-program): Remove 'nil' as it is never a valid
> choice.  (Bug#74235)

IMO, the use of these options in the code is not clean: if these
programs are not installed, the commands which reference these options
will signal errors whose diagnostic might not clearly indicate the
root cause.  I would like to see a cleaner handling of such
contingencies by this mode.  Does this make sense, and if so, would
you like to suggest changes to that effect?

>  (defcustom lua-ts-luacheck-program "luacheck"
>    "Location of the Luacheck program."
> -  :type '(choice (const :tag "None" nil) string)
> +  :type 'string
>    :version "30.1")

I think if we require this to be the name of a program, 'file' is a
better value for :type, because it allows completion if the user types
an absolute file name.

>  (defcustom lua-ts-inferior-buffer "*Lua*"
> @@ -83,7 +83,7 @@ lua-ts-inferior-buffer
>  
>  (defcustom lua-ts-inferior-program "lua"
>    "Program to run in the inferior Lua process."
> -  :type '(choice (const :tag "None" nil) string)
> +  :type 'string
>    :version "30.1")
>  
>  (defcustom lua-ts-inferior-options '("-i")
> -- 
> 2.47.0
> 
> john muhl <jm <at> pub.pink> writes:
> 
> > Tags: patch
> >
> > For some silly reason the lua-ts-{inferior,luacheck}-program
> > options ended up with an option for “None”. Obviously setting your
> > Lua interpreter or linter program to nil is not going to work.
> >
> > Any chance it could make it into emacs-30?

lua-ts-mode is new in Emacs 30, so we can install these changes on the
release branch, as a stopgap.  But I'd like to see a cleaner solution
installed later, even if we decide to install that on master due to
its complexity.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.