zigtools / zls

A Zig language server supporting Zig developers with features like autocomplete and goto definition
MIT License
2.96k stars 295 forks source link

no type completions for primitive types like u16, u32, f32 etc. #1995

Open MariaSolOs opened 2 months ago

MariaSolOs commented 2 months ago

Zig Version

0.13.0

Zig Language Server Version

Not sure how to check this

Client / Code Editor / Extensions

Neovim

Steps to Reproduce and Observed Behavior

Start typing const x: u. No completions for the variable type are shown.

Expected Behavior

For completions like u16 to be displayed.

Relevant log output

No response

Techatrix commented 2 months ago

completions for integer types were intentionally removed in #1681. I am not necessarily against adding them back but the PR has given a good reason for their removal. If we were to add them back, we would to find a way to make them less annoying when they are unwanted.

MariaSolOs commented 2 months ago

@Techatrix as someone that just started learning Zig, the lack of valid type completions does feel a bit odd. However I also understand how they might become annoying when other completion options are preferred... Perhaps we could bring them back but tweak their priority/order in the completion list so that they're shown further down? Or maybe further tune when to show them, such as in when completing a type annotation.

Techatrix commented 2 months ago

Perhaps we could bring them back but tweak their priority/order in the completion list so that they're shown further down?

If we can ensure that other completions take priority over things like integer types then I don't see why we couldn't add them back. A while ago, I experimented with improving the order of completion items. I did not quite get it to be what I wanted but I just haven't spent much time on it.

Related #1792

Or maybe further tune when to show them, such as in when completing a type annotation.

filtering completions when completing a type annotation is definitely something that should be considered. This is similar to what I have a proposed in #1845 since type annotation also have Result Locations. I will add another example to that issue.

MariaSolOs commented 2 months ago

@Techatrix that sounds reasonable! I definitely think that an specific change for this isn't worth it if there's already ongoing work/discussions around completions :)

mnemnion commented 1 week ago

Integer type completions for u and i seem like a non-starter, there are more than 64 thousand integer types in Zig. Floats don't have that issue, but I agree with #1681, typing the full name of a float type is faster and less distracting than selecting a completion. Providing only the "natural" i and u types (8, 16, 32, 64, u21 as a special case) seems wrong to me, for reasons which are hard to pinpoint, but it's basically that the others are valid so it's weird to leave them off.

There may be circumstances where in fact only a subset of those integer types are valid completions, but I'm struggling a bit to pinpoint when that might be. A case could be made that []| having a const u8 completion is so common that it's worth special casing, just as a user affordance. I'm narrowly against that actually, upon reflection, but getting into why would take me more off topic.

Either way, const u8 is eight keystrokes, u32 is two keys after the u, and unless it was right on top that's less typing than selecting and accepting the completion.

I do recognize that integer type completions might be somewhat useful for learners, but I think it's better to favor intermediate and advanced users on this point, where such completions would just be noise. Even for learners, the absence of oddball types like, say, u42, might imply that they don't exist, when they do. So in balance I favor not adding them back.