feature: Implement Search Settings Ability

[confused-Techie]

This PR adds a new side panel to settings-view titled Search.

This panel now allows users to search Pulsar for the setting they are looking for. Without mattering if this is a core setting, editor setting, or a packages setting.

Here is a quick example of the feature in action:

As you've likely noticed the search does not provide the ability to directly change any settings, rather links to the page where they are located. While ideally you'd be able to change settings on this page, or could be linked to their location within the page, I wasn't able to find any simple way of doing so. Such as having the ability to change them on page would need to essentially recreate the majority of the existing settings-view functionality.

Realistically I think our best approach may be to highlight the setting on the page once the user navigates to it. Which again may not be currently possible but is a good thing to keep in mind. This behavior would be very similar to how Android handles searching in the settings app.

How it Works

This new feature is really powered by the Longest Common Subsequence Algorithm which determines a similarity score between what the user has typed and certain fields of the settings entry.

In doing so, the following fields of a package are considered:

• Title of the Setting
• Description of the Setting
• Package or Setting Sidebar location, of where the setting resides
• Finally the settings key entry itself. As would be seen in the package.json of the package.

After calculating the similarity score of each discrete field using LCS, we then go ahead and award ranking bonus' depending on a few factors, with different factors resulting in a higher ranking bonus.

• The Title having a similarity score over 0.8 awards a 0.2 ranking bonus
• The Description having a similarity score over 0.5 awards a 0.5 ranking bonus.
• The Package name having a similarity score over 0.8 awards a 0.2 ranking bonus.
• The Setting Key having a similarity score over 0.8 awards a 0.2 ranking bonus.

Then finally ranking bonus' are applied to items that have a 1.0 similarity score (The highest score that can be given). Which means whatever the user typed in does exist exactly within the field.

• Title Perfection Bonus: 0.1
• Description Perfection Bonus: 0.1
• Package Name Perfection Bonus: 0.2
• Setting Key Perfection Bonus: 0.1

The values here were all chosen off what made the ordering of results 'feel' correct. I know they are rather arbitrary, but could always be tweaked further, or if we really wanted to could be exposed as a configurable setting.

Finally after awarding bonus' each setting entry is given it's total score, which is all previous scores adding together, and we filter the resulting items based on the searchSettingsMinimumScore which is a configurable value for end users. With this being a new entry into the settings of settings-view.

The Caveats

• Search Settings is unable to search the side panels of Pulsar
• Search Settings is unable to search for installed packages
• Search Settings is unable to search for keybindings
• Search Settings is unable to search for installable packages
• The settings for URI Handling or otherwise core.uriHandlerRegistration cannot be linked to. Ironically enough there is no URI (as far as I can tell) that is able to link to the settings page of URI Handling, so if a setting for that item, which the only one there is, is the one listed above, is ever clicked on Pulsar will create a notification informing the user that this page cannot be linked to, and to go ahead and click on "URI Handling" on the settings sidebar.

---

But with all of that said please let me know what you think. I thought this would be a fun new feature to add into Pulsar, and something the Atom creators wanted to do way back when in 2015 but wanted to wait on a total rewrite of settings to do so. So I really do think this could be a bonus for users that may have trouble finding settings.

Especially if they are package settings. Since previously if I wanted to find a packages settings I'd have to navigate to "Settings", then "Packages" then search or scroll until I find my package and click on it.

But now if I know what setting I want to change I can just search here for it and get linked to the right place.

I do feel like it's a good idea to mention real fast, that this new 'Search' page is not the default page of settings, that is still given to 'Core' and has not been changed.

Ideas for Improvement or slightly different Implementations

The two biggest improvements I'd want to see here, if I or anyone else can get to them or wants to talk about them:

1. When you search it'd be pretty cool to have the text highlighted that caused a settings entry to be returned.
2. Then of course linking directly to the location on the page that has the setting you've clicked, and could maybe even highlight it temporarily or until clicked out of.

The biggest blocker to something like the above, is that as far as I can tell, there's no way to do this via an Atom URI. But who knows maybe we could add support to the URI's being able to link to refs on the page or even some utility function that could find a ref and apply some class to it, to be able to highlight it.

PS. Sorry that my last few PR's have been huge with the longest PR descriptions, I'm just trying to find more to get familiar with within the core of the editor and am halfway writing such long PR descriptions for myself or the next person.

[savetheclocktower]

Looks good, but specs would be great for such a large new feature.

[confused-Techie]

Looks good, but specs would be great for such a large new feature.

Yeah you make a good point. I'll go ahead and add some here after looking at the existing ones to see how they are testing this section

[confused-Techie]

So I do definitely plan on adding some tests here, but wanted to add some quick stats I was able to generate about how it runs.

With the below being the search term used, followed by how long it took to generate and rank the entire list of settings in milliseconds. (There was some variability, but this wasn't a super scientific test or normalized at all)

• tabs: 21.91ms
• handler: 20.35ms
• file system: 8.72ms
• big long string: 10.69ms
• tab: 9.53ms

So not sure why such a huge difference between tabs and tab other than the entries already being in memory, but happy to assume performance won't be a huge issue, but even if it is there is a built in loading bar while results are computed

[icecream17]

is there a difference between builtin packages and installed packages that makes installed packages not work?

[confused-Techie]

Surprisingly the URI for the settings page of all packages is exactly the same. Made sure this functioned for either the core packages or community packages.

Only thing not explicitly tested for is Git installed packages, but I'd imagine they should work as well, especially since the settings-view showPackage() function is written identically.

But of course anyone with Git installed packages on their system could double check by navigating to this URI format in the browser and letting it open up Pulsar

[savetheclocktower]

I've been using the package-settings package for ages in order to jump quickly to a given package's settings, and this is the exact method that package uses. Never observed it not to work, no matter how a package is installed.

[icecream17]

Ah I got confused, that's relieving. I think for clarity, the packages caveat means:

• Does not search for the names of any packages

[confused-Techie]

Ah I got confused, that's relieving. I think for clarity, the packages caveat means:

• Does not search for the names of any packages

Ahh I see how that can be confusing. Yeah just means it's not the search that's available on the "Packages" pane, as in it won't accomplish the same thing.

(Although technically you could search by package name to help bring your package up, but it will only show results for packages that have settings. As the name of the package is considered when doing a search. But this makes the whole thing a little confusing, so though it was easier to say it doesn't search for packages)

[DeeDeeG]

I'm for the concept of this, it seems like a really good idea! ✅

Haven't looked over all the code yet or anything, but I'm generally in favor! Thanks for doing this!

[DeeDeeG]

Very cool feature!

I am testing this now, and it does let you jump to the package where the setting it finds is! (The basic premise of the feature is working, which is not at all a given in reviewing PRs! EDIT: More helpful thing to say: works on my machine too, not just the author's machine. Which it should, JS is cross-platform, but yeah!)

A couple of thoughts:

• Would be amazing if we could jump to the specific setting within the package's settings page. Since the search results are so specific, but they can only jump to [the top of] the package's settings page.
  • But I can see why this would not be easy -- we would have to add stuff like id= attributes onto the settings page of the different packages, and I'm not sure if anchors like #setting-name would work in the atom:// URIs this is using???
• Would be amazing if there was some "back" button to go back to search.
  • Counter-point: the search button in the sidebar is effectively exactly this, since it jumps to the search exactly as it was before the user visited the given package. Just not obvious, slightly clunky UX going back and forth a lot. (But again, the fact this works at all is cool, this is just nit-picking.)
• It's a little unintuitive what's going on if you type something with no truly relevant results. Searches such as "hello" and "onomatopoeia" have several results that seem unrelated. I don't know if it's a problem to show results in this case, but it does feel unexpected at least.

This feature existing at all is frankly really cool. So consider the above to just be any areas I could think of for improvement after some brief testing. Not expecting these things to be implemented necessarily.

Thanks! ✅

[confused-Techie]

@DeeDeeG yeah the fact it doesn't jump to search results on the page is a bummer. Doesn't seem that the URI parses anything after the direct path to the config, and iirc in my testing the URI wouldn't accept it even, as the regex used wouldn't validate it.

One thing I am currently working on, is trying to highlight the portion of search results that caused a match, which could help in determining why you sometimes get bunk results. But otherwise you could try increasing the new setting within setting-view of searchSettingsMinimumScore to something higher, if that helps to get rid of unwanted results we could bump the default value there to help protect against this.

Or as we can now say, just paste that into settings search and click the results to go ahead and change it!

[confused-Techie]

Alright, so @DeeDeeG I may have lied. That new feature I wanted is seemingly a lot more complicated than I hoped to add. So I may leave that to another day if we plan to have this in anytime soon.

But otherwise I've added some small tests here. Frontend testing is not my strong suite, but there are some tests to help prevent any regressions mainly focusing on the data format

[Spiker985]

This looks awesome! I am rerunning the checks though, just to be sure. It looked like there was an additional package test that failed, which doesn't normally

[confused-Techie]

This looks awesome! I am rerunning the checks though, just to be sure. It looked like there was an additional package test that failed, which doesn't normally

I'll keep a lookout if one does happen to fail, thanks for checking that. But thanks for the approve!

[Spiker985]

@confused-Techie The spec for settings-view needs to be updated to (presumably) point to index [1] over index [0], since the Search panel isn't the active panel by default, and Core still is

[confused-Techie]

@confused-Techie The spec for settings-view needs to be updated to (presumably) point to index [1] over index [0], since the Search panel isn't the active panel by default, and Core still is

Ahh thanks for catching this, I'll get on that

[Daeraxa]

Just to preface this, this is amazing and definitely something sorely needed.
The reason for the preface is because the below is going to sounds like I'm complaining and I'm not. The current implementation does work and honestly is pretty close that we can include it.
There are a few items which I think are things that maybe should be considered for the context of this PR and the others are things that I think would/could improve this feature later on as an iterative improvement.
Some of these have already been covered in the PR text or by others but I think its worth putting them in one place anyway for completeness.

Warning - words. I'm sorry.

Things for this PR

Again, amazing that it works so well already. I don't really have much to say on the technical aspects of how stuff is ranked other than it seems to work well. Most of this is UI or UX stuff that I can see being brought up.

• Settings names not being displayed

  • This was already discussed on discord but basically there are some items which don't have titles. I understand that the reasoning for this is that atom.config.scheme.properties doesn't have a title but it seems that Pulsar itself is creating the setting title based on the settings key.
  • I see two potential solutions - either the search results should apply this same logic and "construct" a settings title based on the key or we leave it and make sure that every settings option has a title. The latter I imagine is an issue 1) because of the overhead of changing all the packages and 2) there are probably a ton of community packages that don't do this.

• Package cards are clickable but not linked

  • I'm assuming this is inherited from the standard package card but it seems that the card can be clicked (and changes the cursor to indicate as such on hover) but it has no link behind the action - the link is purely on the anchor around the package name and value.
  • Either the card should not be clickable or it should also link to the setting.

• Text wrapping within the card

  • The card displays the package name and value in a 2 col layout but for particularly long items this wraps somewhat awkwardly and for longer settings it can be a bit crowded and hard to look for stuff at a glance.
    e.g.
    Allow Backspace To Trigger Autocomplete autocomplete
    -plus.backspaceTriggersAutocomplete
  • Options I see here would be to either remove the 2 col layout in favour of just having two stacked span lines or do this dynamically where if the text overflows to the next line then move it to its own line.
  • Related to this issue - maybe the value should be further de-emphasised with a little transparency? It seems a little prominent but isn't info most people are looking for at a glance.

• Some slightly weird search results

  • For example search Theme. It will return a whole bunch of stuff but none of them seem to have anything to do with themes at all - at least not within any of the settings options or in the Readmes. Theme produces over 70 search results including core.ProjectHome and find-and-replace.useRipgrep and find-and-replace.scrollToResultOnLiveSearch gets top billing.
  • It seems to be returning some settings that aren't actually exposed in the settings menus. For example as above search Theme and scroll down until you find core.themes which simply takes you back to the core page (where the user will not find that setting) and not to Themes.

Things for future development of the feature

• Change the Search page to a settings "Home"

  • At the moment, navigating to the settings brings you straight to the Core settings. This unfortunately means the Search option isn't actually that obvious. My proposal here would be to create a new settings view that has links and descriptions to each of the settings (think welcome pane) but also features the settings search prominently. We could then potentially deprecate Core and Editor, URI Handling and System in favour of a more unified view which would de-clutter the side bar - I mean who needs quick access to URI Handling???

• Scroll to item

  • Already discussed in the PR along with the searched value highlighting but I think this would be an important usability feature.
  • Alternatively expose the setting value in the search result and allow it to be edited directly without going to the actual settings page.

• Make it more obvious what package a setting belongs to

  • Although it does show what package each setting relates to it really isn't that obvious to a more casual user. This comes at the risk of cluttering things up unfortunately but maybe we could make a more "human readable" inclusion on the package card to show what package or settings area it relates to
  • An extension of this would be "grouping" which could be enabled to allow all settings that match a search term to be not only ranked as they currently are but grouped into their package or core area. Potentially with an option to only search core packages and not look through community ones.

• Provide a new menu option under Packages for searching

  • To search only within package settings it would be good to add a new menu option here that allows one to search only within package settings (see above for the idea of grouping and filtering).

• Expose a search syntax that allows more precise searching to a targeted package or section.

  • For example if I know what I want is in core I could search for core: project home.

This is all I can really think of for the moment, I'm sure I'll have some other idiotic demanding insightful ideas in the future but that isn't necessarily for here and now.

[confused-Techie]

@Daeraxa I appreciate the insight on this one. And these are all amazing points.

The one thing I have given some serious consideration to that you mentioned, is being able to search only core settings, or only package settings, do we think this could function as a flag? Such as !core search-term I realize it's not much different than what you mentioned like core: search-term but to me falls more in line with how power users may be used to searching, as those same style flags are supported on DuckDuckGo. Just an idea, but again otherwise fantastic pointers, and I'd be happy to see what I could attempt to work on prior to shipping.

The easiest one I think would be making the package something comes from more obvious, and adding a click handler to the entire card. Since you are correct, the cards are nearly identical to the package cards, but we could change that without much issue.

[Daeraxa]

Such as !core search-term I realize it's not much different than what you mentioned like core: search-term

Honestly so long as it is documented I personally don't mind what the syntax should be. However I wasn't familiar with the !search term but regularly use site: on google and ddg which is what I was referencing. (For others not familiar with it, !search is a !bang and allows you to target another website's search engine from within DDG, e.g. !w Atom would search wikipedia for Atom).

The one objection I can see to this is that we already use this exact same syntax for excluding stuff in the project find package. For example using !packages would exclude the search from returning anything from the packages dir within the project search.

[savetheclocktower]

I've been too deep in tree-sitter stuff to check this PR out, but from the screencast above, my main feedback is that I'd love to get the package name displayed more prominently, and I think it might even be a good idea to group the results by package.

I can pretty easily see people using this search screen to jump to the settings for a particular package. Thus they'd search for tab because they want a quicker (or more memorable) way to get to the settings for the tabs package. (Or they'd search for tab because they want to find all the settings that control tabs, likely not knowing or not caring about how we organize Pulsar's functionality into packages.)

In the screencast above, you search for tab, then see a bunch of options, with a couple of themes' tabSizing settings in the top five. I would argue that all settings for the package tabs should be shown above any other settings that just happen to mention tab in the setting name or description. This would lend itself to the grouping of results so you could see the hierarchy — here are all the tabs settings that match your query, then all the one-dark-ui settings… and so on.

Failing that, I think that all settings for package X should receive a massive relevancy score boost if the user's entire search term matches X. When you search for tab, you'd see all the settings for the tabs package before any other settings. If you expanded your search to (e.g.) tab siz, you'd no longer see all of tabs's settings in the results, because not all of them match, and at that point the settings that do match would be free to interleave with settings from other packages in the results list.

[savetheclocktower]

My other impulse is that this screen should not show any settings from themes that are not the active UI theme and syntax theme.

I notice that atom.config.schema.properties excludes settings from disabled packages. But it doesn't exclude settings from themes that aren't active, because Pulsar doesn't expose that concept to theme packages — they're displayed in a different section of the settings, and their package cards don't have a Disable button on them.

For our purposes, I think a UI or syntax theme that isn't currently active is the equivalent of “disabled,” and the search results should exclude them even if atom.config.schema.properties doesn't.

[icecream17]

The general feeling I get from this is that this sounds like a feature that needs more feedback, maybe in a beta version, or something, so that different designs and ideas can be experimented with more. (I'm not sure that a beta would actually generate feedback though).

One bodge for highlighting would be to add "#highlight-this" to the url, and have atom.workspace.open somehow process that and highlight the respective setting.
I'm not sure how the checkboxes or inputs actually leads to the setting change internally or whether this could be done for community packages.

Another thing is that "tab" could also refer to indentation settings... like "move cursor as if tab" was harder to find than I expected.

[savetheclocktower]

@icecream17 raises a good point about how to treat visible new features that we want to get feedback on but don't necessarily want to push out to everyone.

We're talking about shipping the new tree-sitter implementation behind a hidden/experimental setting and making it opt-in, so maybe that's worth doing here? Then we can all use it for a few weeks and decide what we like/dislike about it.

[confused-Techie]

I love the amount of feedback I'm getting on this PR, but to try to answer everyone.

@Daeraxa : You make a fantastic point about using search modifiers. Tbh I had forgotten that DDG bangs only search other websites. Meanwhile core: is more similar to search modifiers like deciding date or site or such. Plus with the overlap of this syntax to the find package would absolutely be confusing. So good point. If we move forward with that idea, then absolutely we should use colon style search modifiers. So great points there.

@savetheclocktower : So it'd be trivial to increase the bonus for having the search match high with the package name itself, although I do still wonder that if that should be higher than having the setting key or title match. Since if someone types tabSize they will still get a 1 (The highest score) using LCS for the package title, so if we award the bonus that would still push the tabs package to the top, even though tabSize also has a 1. Since LCS can't determine what's closer related to other searches, only knowing how closely typed is one result to another.

But you also make a good point about grouping search results. One that has also been brought up before. I wouldn't be at all opposed to this, but feel like the section would have to be collapsible. Since if the option is incorrect I'd hate to make people scroll to far to get past it. Although I do personally feel the best matching searches being first no matter the package feels better to me, but we can absolutely change that, or even make it configurable?

@icecream17 I also totally agree I'd love to make URI's accept # then an anchor section on the page. But that may be a bit of a bigger PR as that support doesn't yet exist anywhere, but would be really curious on having something like that made.

But finally about the feature flags I think this could be cool. I went ahead and posted a bit on Discord, since I feel we would have to flesh out that idea a little bit more and wanted to get more ideas. But thanks to everyone, I'll take a look at what I can today

[confused-Techie]

Alright, so while trying to consider everyone's points and the things are easily doable now:

• The main card is no longer clickable. Leaving only the text that actually goes anywhere as clickable.
• The package title is now shown at the side of the card. There is some debate as to how it should look. But that's minor compared to putting it there.
• I've pulled the function that settings-view.js used to create a setting name when none had existed and put it into a new file rich-title.js, following the existing structure of rich-description.js now both settings-view.js and search-setting-view.js utilize this function to create the settings title when none is available by default.
• The settings path will always appear on a newline to avoid the weird newline issues.
• Also the failing specs have now been resolved.
• We provide a moderately (0.3) higher perfect bonus when the search term gets a 1 on the setting namespace (or package name)
• We provide a slightly higher (0.2) perfect title bonus on the setting title as well
• Also added an icon to appear next to the package namespace on the side to help increase emphasis. The icon used is either matching the icon used for Core or Editor or Package settings.

Here's an updated look of our search results with the above changes:

EDIT: The package icons now appear on the left side of the title. Based on feedback on Discord

[confused-Techie]

Alright some new changes.

• Now that we show the setting namespace or package name on the side bar showing the path isn't really needed. So the opacity on the path when shown has been reduced to decrease it's importance.
• Additionally next to the path we now display a search score, to aid in troubleshooting of how to improve or fix the search in the future. Or hackability for others.
• And the entire settings path and search score being shown is now configurable and off by default. Where when off users won't see the path or search score at all, but can be turned on for those that want to see this data. All controlled by settings-view.searchSettingsMetadata boolean.
• Now we also support some search filters!
  • core: <search-term> will only display results for core settings
  • editor: <search-term> will only display results for editor settings

I am still trying to figure out how best to accomplish this for packages settings, but this is a good step forward on that front, and works without any issue in my testing.

Search result with Metadata enabled

Search result with Metadata off, like it is by default

Using the core search filter

[confused-Techie]

Feel free to let me know if there's anything else we wanna see fixed. Since if possible I'd love to get this in the next release

[Daeraxa]

The work on the UI side is great and it all seems to work perfectly well. If we wanted to get this into the next release I suggest we might need to add a caveat or notice to the top saying that this is experimental or under active development or something as I've definitely got some issues with the searching side of things.

My one main issue is that the results are still rather odd, is a score of 2 too low? Some of the scoring seems a bit random too.

For example wrap returns some things correctly but also some inappropriately.
So with my score set to 2 I get 53 results of which I think only 8 have anything to do with wrap.

An example of a good match is Show Search Wrap Icon with a score of 4.15.
However the very next one on the list is Allow Backspace to Trigger Autocomplete with a score of 3.85 and a description of:

If enabled typing backspace will show the suggestion list if suggestions are available. If disabled, suggestions will not be shown while backspacing.

The next valid one is at position 4 - Wrap Selection in Brackets with a score of 2.90.

I would suggest putting the score up to 3 which drastically cuts down the number of matches but also cuts of some stuff that seems perfectly valid.

Any idea why settings seem to be getting high scores when they don't even seem to have that string in the title or description?

[savetheclocktower]

Yeah, I'd be hesitant to ship this unless it was behind an experimental config setting. I'm quite sure that we'll have a bunch of ideas for fixes once we use this for a while.

[icecream17]

However the very next one on the list is Allow Backspace to Trigger Autocomplete with a score of 3.85 and a description of:

If enabled typing backspace will show the suggestion list if suggestions are available. If disabled, suggestions will not be shown while backspacing.

seems like the length of the longest shared substring needs to be prioritized more?

another smaller change might be to somehow use that space is used to separate words

[confused-Techie]

So fair enough, thanks everyone for the feedback, just excited about this one. But I can absolutely put this behind a config for now then and not have it enabled by default.

Until then I'll play around more with the search, and already have some ideas around improving it such as maybe using Levenshtein's Distance w/ Word separators, or could try multi indexing on stop characters, or even normalizing stop characters altogether. But will take a look at all that in another PR.

Sounds like the best thing to do for now is put this all behind a config and we can continue this features development on the next PR or over Discord, if that sounds good?

[Daeraxa]

Fine with me yeah, I'm only thinking about fending off issues that we already know about or that people think this is the final iteration of it.

[confused-Techie]

Alright @Daeraxa @savetheclocktower it's now hidden behind a setting.

Within settings-view we now have enableSettingsSearch which is disabled by default, and when enabled allows the new feature to be used, without, things look exactly as they did before.

The text of this new setting says:

"title": "Enable Experimental Settings Search Feature",
"description": "Will enable or disable the new Experimental Settings Search.",

So if this sounds good, what do we think about merging?

[Daeraxa]

Honestly that sounds good to me, the main question now is how we socialise it, I suspect it deserves its own blog post + announcements so that people can see it and know to enable it.

[confused-Techie]

Honestly that sounds good to me, the main question now is how we socialise it, I suspect it deserves its own blog post + announcements so that people can see it and know to enable it.

I'd be happy to write up a blog post for it! And especially listing it on the changelog might be enough

[DeeDeeG]

👍 to include this.

[ EDIT: IMO it would be great to see this search feature mentioned in the release text (GitHub Releases page + release blog post if there is one) as a thing folks should try and give us feedback on. ]

I would personally lean toward some text warning this is experimental but enabling it by default. Maybe we include a link to a dedicated issue, where people can post feedback + where we invite feedback on Discord, wherever folks prefer.

Simply because it's useful even if results are casting a real wide net. And because getting it in front of more people is the surest way/might be a prerequisite to get more feedback. And users are not harmed by loose results, especially with the knowledge this is still under active development, other than if we are being protective of first impressions of the feature, I suppose.

So I do lean toward enabled by default with a warning about being experimental being visible somewhere on the search page.

(EDIT: Unless we see dev team members as the primary consumers/audience for feedback at this early stage? Eh, but I think folks who made the jump from Atom to Pulsar is a group biased toward those who are aware of how open-source and volunteer projects work and aren't afraid of a little WIP stuff if it's as feature-complete and usable as this, and so totally optional to use or not use as this is/harmless as this is IMHO. And the intent is clearly positive, even if the results algorithm could be tuned. Hmm.)

But I approve in general and of the particular implementation based on my testing that it essentially worked.

[confused-Techie]

@DeeDeeG I do actually really like this implementation.

Obviously as the author I'd love for it to be available by default, but of course still with the option to turn off.

If we are okay with having a proper warning at the top of the page should I put that in? And absolutely the dedicated issue would be a great idea to cut down on any issues created about it. Do we think that sounds good?

[DeeDeeG]

Hmm, so there is one failing test at the moment:

https://github.com/pulsar-edit/pulsar/actions/runs/4421243758/jobs/7755862129?pr=416#step:9:279

SettingsView
  .addCorePanel(name, iconName, view)
    it adds a menu entry to the left and a panel that can be activated by clicking it
      Expected '<li name="Editor"><a class="icon icon-code">Editor</a></li>' to have class 'active'.
        at jasmine.Spec.<anonymous> (/home/runner/work/pulsar/pulsar/node_modules/settings-view/spec/settings-view-spec.coffee:106:55)

[confused-Techie]

Hmm, so there is one failing test at the moment:

https://github.com/pulsar-edit/pulsar/actions/runs/4421243758/jobs/7755862129?pr=416#step:9:279

SettingsView
  .addCorePanel(name, iconName, view)
    it adds a menu entry to the left and a panel that can be activated by clicking it
      Expected '<li name="Editor"><a class="icon icon-code">Editor</a></li>' to have class 'active'.
        at jasmine.Spec.<anonymous> (/home/runner/work/pulsar/pulsar/node_modules/settings-view/spec/settings-view-spec.coffee:106:55)

Ahhhh I think I remember this one.

This test originally passed. I changed it to check the next index of the side panel since we were adding a new panel to the top.
The test now fails because I've disabled the search panel by default. So if we do decide to enable it by default the test will pass. Otherwise if we leave it disabled by default then I'll have to revert the changes of that test.

But thanks for catching that, but here's the diff.

[confused-Techie]

Alright with the final choices in to fix some styling and getting everything squared aware lets go ahead and merge this one.

Thanks a ton to everyone that has helped out and provided feedback here, I appreciate all of you!