wip: fix #396, #395 and #398 #409

wgrr · 2021-08-01T00:27:37Z

The intention of this draft is mostly get feedback on how configurations should look like for plugins.
I feel doing all at the same place would be better than spread them across plugins. I made up a quick-lint-js search function from node_modules, however I'm unsure if it's the desire, currently the user must choose one or implement their search function, or by default use emacs built-in 'exec-path search function, i think we might want by default try npm, then exec-path? Lint requests timing is a missing unified configuration too.

Also, currently to find node_modules folder, we search backwards from buffers default-directory until we found it or not, Emacs 27 has a yet unstable API for a builtin library for projects named project, after version 0.3.0 it has a function project-root we could use or try before instead, but it's only available from elpa or emacs >= 28, which still in development.

@strager What you feel? is this on the right track?

strager

See must fix comment. Otherwise, this looks good.

I made up a quick-lint-js search function from node_modules, however I'm unsure if it's the desire, currently the user must choose one or implement their search function, or by default use emacs built-in 'exec-path search function, i think we might want by default try npm, then exec-path?

We must not search node_modules by default until code signing (#133) and signature checking is implemented. Otherwise, the plugin introduces an arbitrary code execution security risk.

Must fix: I don't want to even make node_modules searching an option, because people will enable it without understanding the security risks. If we do want the feature, we should discourage its use with a scary message.

strager · 2021-08-04T02:13:56Z

plugin/emacs/flymake-quicklintjs.el

+               "quick-lint-js exited with a deadly signal.\n\
+Please consider filing a bug at\
+ https://github.com/quick-lint/quick-lint-js/issues/new\n\
+qjls-stderr-buf:\n\
+%s\n"


strager · 2021-08-04T02:14:40Z

plugin/emacs/flymake-quicklintjs.el

+      (when (zerop (buffer-size))
+        (goto-char (point-min))
+        (insert-char ?\())
+      ;; the above left a '(' danlging or crashed and


Typo:

Suggested change

;; the above left a '(' danlging or crashed and

;; the above left a '(' dangling or crashed and

strager · 2021-08-04T02:18:21Z

plugin/emacs/flycheck-quicklintjs.el

-            (eval (let ((file (buffer-file-name)))
-                    (if file
-                      `("--path-for-config-search" ,file)
-                      ())))


Did you intentionally rewrite this code in this commit? This change seems unrelated to unifying settings. (The change looks fine, though.)

Did you intentionally rewrite this code in this commit?

No, I think I merged the wrong piece on a conflict, i'll revert

strager · 2021-08-04T02:23:39Z

@strager What you feel? is this on the right track?

Unifying the plugin settings is a good idea!

wgrr · 2021-08-04T13:23:52Z

I don't want to even make node_modules searching an option, because people will enable it without understanding the security risks. If we do want the feature, we should discourage its use with a scary message.

Oh, i made this becasue if im not mistaken, i recall you mentioned on a past code review a "what if quick-lint-js was installed with npm problem", i infered that meant "look for quick-lint-js in node_modules", if that's not it, there's any secure way to do it? or should we gave up on that?

strager · 2021-08-05T00:53:14Z

i recall you mentioned on a past code review a "what if quick-lint-js was installed with npm problem",

Yup.

i infered that meant "look for quick-lint-js in node_modules",

I did want that feature. I started implementing it for Vim, then realized the security problem with it. So I changed my opinion for now. I do eventually want the feature though.

if that's not it, there's any secure way to do it?

Not yet. We need a way to ask "is this a trusted executable?". I haven't built that infrastructure yet. I filed #411 for making this feature.

or should we gave up on that?

Let's give up on node_modules for now. We can save your patch for later.

This is causing diagnostics to not be cleared sometimes (see quick-lint#398), it was first introduced for developement, because restarting Flymake without changes in buffers would not delete old diagnostics, I think it's fine if we not specify this option. However I suspect this is a bug in Flymake. Signed-off-by: wagner riffel <[email protected]> (cherry picked from commit 6a223f8)

Currently there is at least two customizeble variables per plugin, using more than one plugin at time is annoying to configure, this change generalize and centralize configuration in a single place. This commit also adds configuration for searching quick-lint-js executable, along with helper to find it under npm folder structure. Signed-off-by: wagner riffel <[email protected]>

Signed-off-by: wagner riffel <[email protected]>

Unlike M-x lsp, M-x lsp-quicklintjs doesn't prompt for a root folder. It does this by always before calling (lsp) saving on its own state file the buffer default directory as a project root. Signed-off-by: wagner riffel <[email protected]>

wgrr · 2021-08-11T17:52:38Z

@strager Could you review these CMake files? i havent written one in ages. Also, I'm still unsure about their need, i've written them because i'm unsure if emacs generated files are forward and backward compatible, so i left that to the host building the package decide (that's what happens in elpa/melpa, for example). But i have a feeling we could generate and track those files beforehand.

wgrr · 2021-08-11T18:23:58Z

Also, explaining how #395 and #396 are fixed

7646781 fixes #396 by relying on Emacs builtin package library which automatically loads *-autoloads.el files, and those files are generated by quicklintjs-pkg.el. (the suggestion in the issue doesn't fix the issue because it would just move the problem elsewhere, e.g: it would need the user to add a (add-to-list ...) instead of require). Furthermore, this change will make the local installed symetric with the remotes i will add later (melpa and dpkg). Another path i could've taken is making a site-start.el which is a magic file automatically loaded by emacs, but using the builtin package library looks like the standard.

316e270 fixes #395 by adding a wrapper command which marks the default-directory as the root folder, unfortunately i think we can't transparently fix this, my first attempt was to use lsp-mode provided callback lsp-before-initialize-hook, but this is called after the prompt. I oppose to set the workaround variable lsp-auto-guess-root because it overwrites a global user setting and may leave lsp-mode in a broken state if projectile or project are previously misconfigured.

remove require on cl-seq not present in emacs24, cl-remove-if-not is loaded by default. Signed-off-by: wagner riffel <[email protected]>

strager

@strager Could you review these CMake files?

They look good to me.

strager · 2021-08-13T04:48:00Z

plugin/emacs/CMakeLists.txt

+  install(
+    DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/lsp-quicklintjs-0.0.1
+    DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/emacs/site-lisp/elpa)
+endif ()


Why do we need five separate packages? Could we make just one package? Seems simpler to make one package IMO.

Could we make just one package?

Yes, to use what emacs calls "multi-file" packages, it would require tar available while building the packages tho, i didn't use it here because i imagine that's unlikely to tar be available on a Windows machine, what you think? i'm fine with both ways.

it would require tar available while building the packages tho, i didn't use it here because i imagine that's unlikely to tar be available on a Windows machine, what you think?

CMake provides a tool to create tar archives: https://cmake.org/cmake/help/v3.21/manual/cmake.1.html#run-a-command-line-tool

$ cmake -E tar czf src.tar.gz src $ file src.tar.gz src.tar.gz: gzip compressed data, last modified: Fri Aug 13 18:15:35 2021, from Unix, original size 1392640

@strager i made the change to use a tar archive as a single package, besides that it feel clunky, it's discouraged by package archives, do you think the last "problem" in this list applies here? i do think. https://github.com/melpa/melpa/blob/5d49574/CONTRIBUTING.org#fixing-typical-problems

it's discouraged by package archives

Having multiple .el files in a package is discouraged? O_o I'm unsure if that's what the documentation actually says.

do you think the last "problem" in this list applies here? i do think. https://github.com/melpa/melpa/blob/5d49574/CONTRIBUTING.org#fixing-typical-problems

It says:

MELPA only looks at the main .el file (or -pkg.el file, if provided, though we discourage that).

What does it mean to "look at" an .el file?

What does it mean to "look at" an .el file?

In short, an .el file can be package on its own, its format something along the lines:

;;; <name>.el --- ;;; <headers> <code> ;;; <name>.el ends here

so when it says "look at" an .el file, is an .el file which is in this package format, when a package has multiple .el files, this format is not used, instead there should be a tar archive that contains all .el files along with a magic <name>-pkg.el, which must call (define-package ...args).

[a tar archive is] discouraged by package archives, do you think the last "problem" in this list applies here? i do think. https://github.com/melpa/melpa/blob/5d49574/CONTRIBUTING.org#fixing-typical-problems

I think we should do one of two things:

merge all of our .el files into one .el file

create a tar, even though MELPA docs say "we discourage that"

I'm happy with the tar if it's already implemented and if it makes developing the plugin easier for us.

strager · 2021-08-13T04:57:56Z