Re: Implementation direction for shell-script-mode with tree-sitter

["João Paulo Labegalini de Carvalho" <jaopaulolc@gmail.com>]

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

N.B that shell-script-mode supports shells other than bash, so maybe a
> tree-sitter-bash based variant should be spun off into its own
> `bash-mode', as opposed to possibly interfering with the support for all
> of rest?
>

That is a very good point and that is the reason why I am pursuing an
implementation that reuses the work from the existing fontification code.

My goal is to use the `sh-feature' function to retrieve everything that
needs to be fontified for the buffer's shell variant.

It has worked well for most built-in commands (e.g. alias & source) but not
as great for reserved words like "time" and "coproc". As Stefen pointed
out, some reserved words complicate the grammar, so I believe that is the
reason why the tree-sitter-bash folks decided to keep them out of the
grammar.

This becomes a nuisance because then I have to use two queries to match
keywords. One simple query to match the recognized keywords and another
that matches all commands but only fontifies the ones that belong to the
un-recognized list. To build such a list I have to explicitly construct a
list of recognized keywords using literals and that goes against my goal of
reusing pre-existing functionality by relying on `sh-feature'.

Built-in commands are a lesser nuisance as some of them (e.g. local,
declare, and typeset) are not commands but declaration_commands in
tree-sitter-bash grammar. But for those I just have two queries and I don't
need to create a variable per shell variant.

Aside from that, I am trying to extract the keywords in `sh-font-lock-{var,
var-1, var-2}' variables to replicate the fontification based on the level
selected by the user. But parsing those is more intricate as the return is
a list where each element is either a list of the form:

   - (regex level font-face), or
   - (regex list [list]), where list is of the form (level face) or (level
   function function-args).

The logic to parse those I believe exists within font-lock-mode or
font-core, but I am not sure if I would be able to use the forms above as
they use functions that depend on variables that the user might tweak. I
don't know if the compiled queries in *-treesit-settings would be
recompiled to achieve the same flexibility as the existing fontification
code.

-- 
João Paulo L. de Carvalho
Ph.D Computer Science |  IC-UNICAMP | Campinas , SP - Brazil
Postdoctoral Research Fellow | University of Alberta | Edmonton, AB - Canada
joao.carvalho@ic.unicamp.br
joao.carvalho@ualberta.ca

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