[autocomplete-css] Suggestions are ordered strangely

[hblamo]

Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Have you checked to make sure your issue does not already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

When starting to type something like "wid" in a CSS file, I get recommendations such as "windows" before something like "width".

Also when typing "padd" or "marg" I get suggestions for "padding-top" before "padding".
This used to not be the case when I first installed Pulsar (not sure the version) but recently its regressed.

Any suggestions would be great.

Pulsar version

1.105.0

Which OS does this happen on?

🐧 Arch based (Manjaro, Garuda, etc.)

OS details

N/A

Which CPU architecture are you running this on?

64-bit(x86_64)

What steps are needed to reproduce this?

N/A

Additional Information:

No response

[confused-Techie]

So I'm not sure there's an easy solution here.

Since previously in Atom, (and the version of autocomplete-css that we had when we first started Pulsar, which would be the versions you didn't see this issue) the team at Atom, seemingly was painfully sorting CSS values by popularity as reported by some third party websites. The thing is though, sorting these values could only be a very arduous and time consuming process.

So when it came time that we wanted to update autocomplete-css to be as up to date as possible, over on #398 I automated the whole process to update these completions, meaning there was no logical sorting to these values at all. Which is why you are seeing any valid matches, not matches based on popularity.

Now autocomplete-plus is still very likely sorting the values being returned to you, but again doesn't have any knowledge of popularity.

So I'm not sure what answer would be able to achieve what you are looking, other than us repeating the same thing, and taking the time to painstaking sort every value by popularity. So hopefully someone can find what may be an appropriate solution, but at the very least this is exactly what caused the behavior you are seeing

[hblamo]

@confused-Techie Thank you for your response.

I understand that it is likely a complicated process.
This may sound like a bit of a "noobie" question, but is there a way that I could edit this CSS value reference file to manually correct some of the sorting issues I come across? (locally)

I tried to find a way using the following repo: https://github.com/atom/autocomplete-css
Though I got a bit lost.

This repo does mention a reference that could be used to get started on my manual sorting journey.
https://chromestatus.com/metrics/css/popularity

Thanks again for all your help.

[confused-Techie]

So the Atom autocomplete-css package isn't what you'll want to edit. The code for the package we are dealing with is located in this repo actually ./packages/autocomplete-css.

Editing it is possible, but as by default it's in a compressed file might not be the easiest. But looking at our docs can hopefully lead you in the right place.

But really, if you are going to the effort of fixing this, it would be really awesome if you could contribute those efforts back to the community by making the changes then opening a PR. Since if this is concerning you, I'm sure it's concerning others as well.

When you look within the autocomplete-css folder, the completions.json is the file that contains all autocomplete information, and is partially what controls the order any values are returned. So you can absolutely change the order there to fix the ordering for your right now. But keep in mind the next time that those values are updated your changes would be lost. It'd likely be best if we could find a way to implement some sorting into update.js which is the script that completes the automatic updates of the completions.json

[savetheclocktower]

I think there might be some good rules that we can apply — at least for these examples.

In both cases, I think shorter completions should match before longer ones. So wid would prefer width over window because width is shorter — and, when it comes to CSS, shorter property names tend to be the ones used more often. Also, if I type padd and want to opt out of the padding choice, I can just add to or something to jump to padding-top — but I can't do that if the longer option is presented first.

Also, even if they were the same length, I'd want wid to match width before window because wid is a longer contiguous substring.

I haven't looked into how complicated this would be to implement, but I think we could get there without forcing ourselves to do manual curation of the suggestions.

[hblamo]

@confused-Techie Thanks for the info.
I am going to look into it and see if I can come up with a solution that could be rolled into production.

Out of curiosity. I am extremely new to the whole github thing. If I find a solution that may help others, would you be open to lending some guidance on submitting the PR? (just to make sure I am following the correct protocols/etc.)

If not, that's fine, I'll stumble my way through it. Just thought I'd ask.

Thanks!

[savetheclocktower]

OK, just looked at the code. I think that, ideally, some of these optimizations would be baked into fuzzaldrin, but this provider could also just do the filtering work on our side and implement my suggestions. I think that it's a good idea to prefer shorter completions in the general case, but I'm nearly certain that it's a good idea to prefer shorter completions in the case of CSS.

[savetheclocktower]

Out of curiosity. I am extremely new to the whole github thing. If I find a solution that may help others, would you be open to lending some guidance on submitting the PR? (just to make sure I am following the correct protocols/etc.)

Most certainly. If you get stuck, the Discord is a welcoming place.

[hblamo]

@savetheclocktower
I'll start playing around with the code during the off hours and see if I can come up with something that'd work.

In the meantime, I'll close this issue.

Thanks again @savetheclocktower & @confused-Techie!
More to come soon.

[savetheclocktower]

Nah, it's worth keeping open. It's a valid complaint and I think we can fix it. Thanks for reporting it in the first place!

[hblamo]

@savetheclocktower @confused-Techie
I think I found a solution, my current issue is that I highly doubt it'd be accepted as a change, though it may lead to further progress down the road.

Basically my solution was to use the list google provides to reorder the properties in the completions.json file.

The way I solved it was using PHP. (I am not very well versed in JS)
It loops over the google rankings and if it finds a matching property in the completions file it'll unset it and prepend it to the top of the properties array.

Then once its finished the reordering process, it'll save a new json file (completions_new.json) which I reference in the provider.coffee code so that the new completions can be used in the editor. (I chose not to override the existing file during testing.)

COMPLETIONS = require('../completions_new.json')

<?php
//Get propular CSS properties from google's managed list.
//Pretend like this will never go away...
$curl = curl_init();
curl_setopt_array($curl, array(
  CURLOPT_URL => 'https://chromestatus.com/data/csspopularity',
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_ENCODING => '',
  CURLOPT_MAXREDIRS => 10,
  CURLOPT_TIMEOUT => 0,
  CURLOPT_FOLLOWLOCATION => true,
  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
  CURLOPT_CUSTOMREQUEST => 'GET',
));

$response = curl_exec($curl);
//reverse and convert to json.
$google = array_reverse(json_decode($response, true));
curl_close($curl);

//List of current completion values.
$list = json_decode(file_get_contents('completions.json'), true);
//Gather only the properties.
$prop_list = $list['properties'];
//Output file where we will be saving the new json file (for testing.)
$outputFile = fopen("completions_new.json", "w") or die("Unable to open file!");

//Loop over google properies and reorder the list from current properties.
foreach ($google as $property) {
  $name = $property['property_name'];
  if(isset($prop_list[$name])){
    $temp = array($name => $prop_list[$name]);
    unset($prop_list[$name]);
    $prop_list = array_merge($temp, $prop_list);
  }
}

//get pseudo selectors so they can be appended
$pseudoSelectors = $list['pseudoSelectors'];

//remove properies from array
unset($list['properties']);
//remove pseudoSelectors from array
unset($list['pseudoSelectors']);

//Add both properies (reordered) and pseudoSelectors back.
$list['properties'] = $prop_list;
$list['pseudoSelectors'] = $pseudoSelectors;

//Write the new json file.
$new_file = json_decode(file_get_contents('completions_new.json'), true);
$json = json_encode($list, true);
fwrite($outputFile, $json);
fclose($outputFile);
 ?>

Not sure if anyone would be able to easily translate this to JS, but that would likely be more inline with the project.
After cloning the autocomplete-css package and running all this locally is solved the problem for me.

I guess this could also be used in place of actually manually updating the completions file as well. Since it does much of the hard work of moving the popular properties to the top of the array.

[confused-Techie]

@hblamo Well I didn't realize they exposed this data as a JSON endpoint.

This very well could work in the short term. As I do agree with @savetheclocktower that changing the way autocomplete-plus or then fuzzyfinder itself sorts results will be the best thing to do in the long run, this totally could work as our stop gap. Sort all items by popularity, then sort the resulting items by length.

I really appreciate you coming up with a solution here, and will take a look at implementing this into JavaScript, and adding it directly to the script that generates the COMPLETIONS.json

[savetheclocktower]

Yeah, I think this is a fine way of ordering the suggestions in the JSON, and would be useful even if Google stopped generating this data in the future.

[m1ga]

@confused-Techie is there anything I'll need to do in order to use it?
A normal CSS file doesn't show properties, SCSS works

simplescreenrecorder-2023-06-13_17.00.29.mp4

Pulsar : 1.105.2023061119

[confused-Techie]

@m1ga No nothing special should be required.

On my near stock install on my work PC typing pad in a blank CSS file gives me the following:

(Fair warning, the version of Pulsar on my work PC seems slightly out of date, but I wouldn't imagine this has broken from these changes, unless someone wants to confirm)

I'd really ensure that the following package's are enabled:

• autocomplete-plus
• autocomplete-css

As well as I'd check all of your settings for autocomplete-plus and ensure nothing is wonky there, or otherwise reset those settings back to the defaults. And if this still doesn't resolve your issue I'd suggest creating a new issue, but hope that helps!

EDIT:

I stand corrected Pulsar 1.105.2023061120 seems to have broken CSS autocompletions. I'll go ahead and make an issue for this

[m1ga]

Thanks for the feedback. You have the old order, padding should be on top (works fine for me in SCSS).
I've just updated pulsar to test the new css order.

I'm using Fedora linux here. Going to test an older version again and also boot up windows to check it there!

I stand corrected Pulsar 1.105.2023061120 seems to have broken CSS autocompletions. I'll go ahead and make an issue for this

Ah, ok 😄 Thanks!