WIP: Adds dataExplorer.useLanguagePackFormatOptions setting, to format the Data Explorer using R or Python options

[juliasilge]

• Closes Add backend-controlled format options to data explorer #11051
• Addresses Data Explorer - scientific notation - does not adhere to options(scipen = xxx) #4818
• Depends on Add R backend-controlled format options to data explorer ark#987

This is a non-fork PR applying the commits from #11051 by @kv9898 because of the problems outlined in #6628. I agree with @dfalbel in the review on posit-dev/ark#987 that it is arguable whether R's defaults are better than what we have here for the Data Explorer (and we can't really tell if the user has changed from R defaults for these options), so I don't think we can use language pack options by default.

There is still a fair amount of work here to do, around:

• what happens when the language pack options are changed
• Python support

@:data-explorer

Release Notes

New Features

• Data Explorer: the new dataExplorer.useLanguagePackFormatOptions setting now supports formatting via R or Python options

Bug Fixes

• N/A

QA Notes

WIP

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:data-explorer

^{readme  valid tags}

[juliasilge]

@dhruvisompura when you get a chance (no rush), can you do an initial glance at this PR and weigh in for me on what is a good way to address how the backend updating any of these options like scipen should play with the Data Explorer deciding to update, when updating an existing Data Explorer tab?

• We could try out triggering updateBackendState() when requestFocus() is called to get fresh format options from the backend, but I worry about how expensive that is.
• We could add a getFormatOptions() backend method to call during requestFocus(), that only fetches format options, which would be cheaper than full state.
• We could have the R/Python backends emit an event when the global format options change (e.g., when options(scipen=...) is called) and the frontend could listen and invalidate the cached format options. I guess we could even update an existing Data Explorer tab with that?
• Run away from home and live in the woods?

[dhruvisompura]

@dhruvisompura when you get a chance (no rush), can you do an initial glance at this PR and weigh in for me on what is a good way to address how the backend updating any of these options like scipen should play with the Data Explorer deciding to update, when updating an existing Data Explorer tab?

• We could try out triggering updateBackendState() when requestFocus() is called to get fresh format options from the backend, but I worry about how expensive that is.
• We could add a getFormatOptions() backend method to call during requestFocus(), that only fetches format options, which would be cheaper than full state.
• We could have the R/Python backends emit an event when the global format options change (e.g., when options(scipen=...) is called) and the frontend could listen and invalidate the cached format options. I guess we could even update an existing Data Explorer tab with that?
• Run away from home and live in the woods?

I am leaning towards option 3 where we have the R/Python backends emit an event when the global format options change so that open data explorer tabs can re-render with the new format options.

For option 1, calling updateBackendState() when requestFocus() is called does sound expensive and it doesn't handle the scenario where a format option is set while a data explorer tab is already open if I am understanding things correctly.

Option 2 doesn't address updating open Data Explorer tabs in the scenario where the user updates the setting after opening the Data Explorer, so we'd still need something like option 3.

I'd be curious to know what other folks thing about the backend emitting an event for this.

[dhruvisompura]

Minor nit: I feel like this file could use a rename to make it clear that this contains the configuration options for the data explorer, especially given that USE_LANGUAGE_PACK_FORMAT_OPTIONS_KEY is not specific to the summary panel but the entirety of the data explorer.

Normally, we stick these settings in the contribution file or in the main service file which could be an option but calling it positronDataExplorerConfigurations.ts or something like that is probably good enough.

[dhruvisompura]

minor nit: we could be a bit more generic in this description and just say:

Suggested change

	'Use formatting options from the R or Python language pack when displaying data values. When enabled, settings like R\'s scipen option will affect number formatting in the Data Explorer.'
	'Use formatting options from the language pack when displaying data values. When enabled, settings like R\'s scipen option will affect number formatting in the Data Explorer.'

I don't think we have to explicitly call out the language packs and this means one less thing to update if/when we support other languages.