Consider default.nix:
{
aaa-bbb = 1;
aaa-ccc = 2;
}
Pointing nix-repl at this, completions are as follows:
nix-repl> a
aaa-bbb aaa-ccc abort
nix-repl> aaa-
__add __findFile __langVersion __stringLength builtins
__addErrorContext __foldl' __length __sub derivation
__all __fromJSON __lessThan __substring derivationStrict
__any __functionArgs __listToAttrs __tail dirOf
__attrNames __genList __match __toFile false
__attrValues __genericClosure __mul __toJSON fetchGit
__catAttrs __getAttr __nixPath __toPath fetchMercurial
__compareVersions __getEnv __nixVersion __toXML fetchTarball
__concatLists __hasAttr __parseDrvName __trace import
__concatStringsSep __hashString __partition __tryEval isNull
__currentSystem __head __pathExists __typeOf map
__currentTime __intersectAttrs __readDir __unsafeDiscardOutputDependency null
__deepSeq __isAttrs __readFile __unsafeDiscardStringContext placeholder
__div __isBool __replaceStrings __unsafeGetAttrPos removeAttrs
__elem __isFloat __seq __valueSize scopedImport
__elemAt __isFunction __sort aaa-bbb throw
__fetchurl __isInt __split aaa-ccc toString
__filter __isList __storeDir abort true
__filterSource __isString __storePath baseNameOf
Essentially completion here is same as if no input was entered (since linenoise completion callback breaks at dashes on our behalf.)
This is unfortunate (too many suggestions) but not incorrect.
nix-repl> aaa-b
baseNameOf builtins
This is just wrong :(.
AFAICT this behavior is the same when using linenoise or linenoise-ng, but does not occur in readline-based nix-repl.
Not sure if there's an easy answer-- perhaps we can punt on linenoise breaking things for us entirely (instead of teaching it how to kinda parse Nix expressions) and handle this in our completion callback?
I'm not sure what other edge cases might be problematic... I suppose spaces after a "dot" should be ignored...? (readline gets this "wrong" as well)
Anyway it doesn't need to be perfect of course but I think a reasonable goal is to reasonably auto-complete the sorts of expressions/attributes commonly used in nixpkgs.
@dtzWill Are you talking about nix-repl or nix repl (which is from an unreleased version of nix 1.12). If it is nix-repl the correct repository is here: https://github.com/edolstra/nix-repl
nix repl sorry, updated the issue title.
I came here to report this, now that nix 2 has hit unstable, and nix-repl no longer works. Glad to see it's already known.
It's significantly more of a usability problem than I would have expected at first, due to the combination of dashes commonly occurring as word separators in identifiers and big nested collections like emacsPackagesNg.
For example, if I want to find emacs packages related to Haskell it's natural to do:
nix-repl> emacsPackagesNg.haskell<TAB>
At which point the completion engine notices that every possibility continues with a dash, so it fills that in for me, giving me this:
nix-repl> emacsPackagesNg.haskell-<TAB><TAB>
Display all 8666 possibilities? (y or n)
:(
The only way I can see what I want is to delete enough characters so that there are other maatches that don't start with haskell-, which by definition includes other things I was trying to filter out; in this case emacsPackagesNg.hask<TAB><TAB> works, due to the existence of emacsPackagesNg.hasky-extensions, but it's easy to imagine scenarios where the only prefix that also includes things not leading up to the dash also includes an impractically large amount of other stuff.
Quick testing shows that https://github.com/dtzWill/nix/tree/fix/nix-repl-hyphen resolves your immediate problem. It's what my quick idea for fixing this was but not sure if it has any negative consequences.
(in particular https://github.com/dtzWill/nix/commit/cd317fb500c0e289286145f98522fd18fd773348)
https://github.com/dtzWill/nix/commit/cd317fb500c0e289286145f98522fd18fd773348 is such a minor change, and does seem to solve the problem. What is the potential downside of merging it?
Yeah, this is pretty annoying given that the convention for attribute names seems to be moving towards foo-bar instead of fooBar.
I just updated to nix 2.1.3 from nixos-unstable, but still have the issue that any variable names with "-" in them stops all auto-completion (updated with nix-channel --update; nix-env -iA nixpkgs.nix).
The issue is actually much more painful then described because it stops auto-completion of items in a derivation with a "-" in its name. So, pkgs.nodePackages.nodejs-8_x.<tab><tab> returns nothing. The only workaround I have found is to chain lets like this, let t = pkgs.nodejs-8_x in t.<tab><tab> so I can inspect derivations.
The recently-merged move to editline (or whichever)
addresses this problem!
So hopefully in a release or two this'll be fixed by default :).
Otherwise you may want to use a copy built from latest master,
but it's safer to wait for it to reach a stable release.
On Tue, 04 Dec 2018 17:14:10 -0800, Pfalzgraf Martin notifications@github.com wrote:
I just updated to nix 2.1.3 from nixos-unstable, but still have the issue that any variable names with "-" in them stops all auto-completion (updated with
nix-channel --update; nix-env -iA nixpkgs.nix).The issue is actually much more painful then described because it stops auto-completion of items in a derivation with a "-" in its name. So,
pkgs.nodePackages.nodejs-8_x.<tab><tab>returns nothing. The only workaround I have found is to chainlets like this,let t = pkgs.nodejs-8_x in t.<tab><tab>so I can inspect derivations.--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/NixOS/nix/issues/1756#issuecomment-444320657Non-text part: text/html