Comments (5)
I would definitely be willing to accept stale completion info in exchange for better performance.
Yes. That's actually work-in-progress. However:
For a long time C++ part in this project has only one developer
It's hard to get all these stuff implemented by one person. This project needs to be sponsored & joint work.
Also, I wonder if the eval could be done incrementally/more lazily.
Yes. But this is non-trivial. I was thinking about introducing a delayed eval system by performing real evaluation on libnixf
but values coming from function args will be resolved later, via IPC. And thus keep the IPC worker immutable, just calculate workspace changes. Challenge again:
For a long time C++ part in this project has only one developer
from nixd.
I made a minimal example of how readTree is used here: https://github.com/andrewhamon/readTreeExample
So basically, i want to teach nixd
that the result of this expression:
(import (./.)).args
is what gets passed in to each of my files:
{ pkgs, root, ... }: # <- provide autocompletions for these args using the expression above
pkgs.writeShellScriptBin "hello2" ''
${root.packages.hello}/bin/hello
${root.packages.hello}/bin/hello
''
from nixd.
Ironic thing: allowing arbitrary args were landed before. That's exactly legacy nixd. You can read more details at:
from nixd.
I am a readTree user, so my repo consists of lots of files that are simple functions which accept arguments of my choosing. They look sort of like nixos modules, but i control all inputs, and there isn't any particular output schema like with nixos modules.
Then that will be difficult do deal with. 'Eval' a whole config by each workspace editing (i.e. edit any file, just a typing), approximately consumes 30s and 600M memory. People cannot accept this at all. That is a curse in nix community.
It would be amazing if it were possible to configure nixd to understand this structure. I imagine it would need a few pieces of information:
The only way to 'support' this is, allowing you write some sort of type annotations and builtin-integrate the logic.
I think this issue is somewhat similar to what it would take to support completion on specialArgs in nixos modules (not sure if that is supported already). Conceptually I think this feature request is equivalent to "support specialArgs on arbitrary files that aren't nixos modules" if that makes it any less confusing.
This feature is excatly the removed 'eval' section between 2.0 and 1.x.
The reason is: performance.
Yes, we can do this precise eval. But people don't like to configure it. And it is relatively slow.
from nixd.
I would definitely be willing to accept stale completion info in exchange for better performance.
Also, I wonder if the eval could be done incrementally/more lazily.
For example, in my readTree example, If i typed this in my editor:
root.packages.h # <- expect completion right here
Then it would only take traversing the next level below root.packages
.
For example:
time nix eval --impure --expr 'builtins.attrNames (import ./.).args.root.packages'
[ "__readTree" "__readTreeChildren" "hello" "hello2" ]
nix eval --impure --expr 'builtins.attrNames (import ./.).args.root.packages' 0.01s user 0.01s system 82% cpu 0.022 total
In 22ms we could supply hello
and hello2
as completions.
from nixd.
Related Issues (20)
- real world example HOT 4
- example of usage and configuration without flakes HOT 2
- support completions for lib HOT 1
- Option to use Flake's `outputs.formatter.${system}` for formatting HOT 5
- document nixf-tidy HOT 2
- nixd dies on shutdown but not in the way eglot expects? HOT 2
- unnecessary "definition is not used warning" HOT 3
- Anything after the first expression in one file is ignored HOT 1
- [bug] nixd uses too much RAM when opening large files HOT 2
- autocomplete for builtins HOT 3
- Complete outputs: (dev out) for `package_name.` HOT 1
- `nixd.options` with `$NIX_PATH` import expressions HOT 4
- auto-complete default value for option HOT 4
- Wrong suggestions for rec keyword. HOT 3
- Somehow group the multipart suggestions in Neovim.
- support & auto complete nixvim options HOT 4
- vendor: enable written regression tests in derivations HOT 3
- documentation for nixvim modules
- completion pops up in comment context HOT 1
- Invalid range when going to package definition HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nixd.