~technomancy/fennel#76: 
complete command returns unrelated items

Full list of completions returned when completion begins with a # symbol:

Welcome to Fennel 0.10.1-dev on Lua 5.4!
Use ,help to see available commands.
Try installing readline via luarocks for a better repl experience.
>> ,complete #
#
>> ,complete #0
bor     while   local   for     fn      =       or      doc     var     tset    //      hashfn  lua     set-forcibly!   - *+       <=      values  .       /       %       quote   #       rshift  and     eval-compiler   macros  >       require-macros     ~=      band    bnot    ^       lshift  ..      not     set     comment not=    >=      <       include bxor    letlength  global  do      each    if      :       λ       ->>     -?>     ?.      ->      partial -?>>    pick-args       macrodebug collect doto    accumulate      import-macros   lambda  macro   icollect        with-open       pick-values     match      when    pairs   debug   print   _VERSION        pcall   next    require type    table   utf8    math    ipairs  tostring   error   warn    dofile  arg     io      select  rawequal        os      rawlen  coroutine       string  rawget  loadfile   load    setmetatable    rawset  package getmetatable    collectgarbage  _G      xpcall  tonumber        assert
>> 

Happens for ,complete #abcdef, ,complete #"", and so on.

Status
RESOLVED FIXED
Submitter
~andreyorst
Assigned to
No-one
Submitted
2 months ago
Updated
a month ago
Labels
1.0 bug

~technomancy a month ago

Did some digging on this and the problem is that the complete command uses the parser to read a token, rather than having raw access to the input bytestream. This means that the parser expands #0 to (hashfn 0) which cannot really be used as a completion input.

The only way to fix this is to change the way repl commands work to no longer use the parser exclusively, which will be a very large change.

~andreyorst a month ago

can't complete command only work when the token matches a certain regex? e.g. not starting with a parenthesis

~technomancy a month ago

In fact, it does strip out parens before doing the completion, but that just means it ends up with an empty input, which is why you get "all the matches" as the results. We can work around that problem but it doesn't really address the root cause, which is that some repl commands need to read a line and not a form.

A related problem is that you can just run ",complete" and it will do nothing until it reads a form, which can be really confusing. The root cause is the same: we need a way to read a line, not a form.

I think there may be a simpler fix for this specific bug using the chars table, but solving the "read a line, not a form" problem is bigger.

~technomancy a month ago

Here's a fix just for this one issue but I'm not sure it's the best solution: https://p.hagelb.org/0001-Provide-raw-chars-to-repl-commands.patch.html

~andreyorst a month ago

just realized that when parser macros would be a thing, writing @something would trigger the expansion in the repl process?

~technomancy a month ago

Yes, exactly. The value given to the command by read will be expanded. The patch above preserves the original input text and uses it for completion, but it doesn't fix the problem of ,complete with no argument doing nothing and waiting for a complete form to be entered.

~technomancy REPORTED FIXED a month ago

Went ahead and merged this; it's an improvement even if it's not a perfect fix.

Register here or Log in to comment, or comment via email.