☐ cool new feature
☐ could help many users!
☑ feels like a bug
☐ nice to have
☐ nobody needs it
What inspired this wish list request?
code that is generated via << save script will generate JSL code to reproduce the same behavior - in combination with the settings in the preferences. So far so good.
But the same code - in combination with (other) settings on another system can generate a completely different behavior.
One could say: so far so good - the user on the other system might have some idea why he adjusted the settings.
But things get funny when the code was generated on a system with adjusted settings in the preferences.
Then
- (most *) setting which fit to the current (non-standard) settings in the preferences will NOT be saved in the JSL script - and now when such code will be executed on a standard system such non-standard standard settings will be missing in the code → leading to a different behavior on a standard system.
- (other **) settings which fit to the standard settings will NOT be saved in the JSL script - and therefore when being executed again on the same system (with non-standard settings) will be missing.
*) like color gradients: it's not possible to specify a gradient for a plot in JSL (via << save script) which equals the gradient in the preferences
**) like Conditional settings of the Data filter: on a system with Conditional enabled in the preferences, it's not possible to generate a JSL code (via << save script()) for a non-conditional data filter
collateral effects:
With there are CHANGED settings in the preferences, a user loses the chance to use Dashboard Builder to generate Dashboards which opens platforms on his system with STANDARD settings 
Do you use the preferences?
The only workaround: Open the source script of the Dashboard and add the respective code manually.
What is the improvement you would like to see?
Although current behavior is as designed - it is not always as expected by the users.
Please optimize the behavior in a future version of Jmp.
Why is this idea important?
If a user changes settings in the preferences he should still have the chance to generate Dashboards which use the standard settings.
more wishes submitted by 
following a suggestion by @hardner : https://community.jmp.com/t5/JMP-Wish-List/interrogate-Use-Thousands-Separator-using-JSL/idc-p/737356/highlight/true#M5364
one could use a verbose option for << save script:
With verbose = 1 the script should be generated with all settings that are necessary to produce the same result on ANY system - independent of the actual settings in the preferences.
As many users use the command from the red-triangle menu
or the icon in the report toolbar:
one has to add a Shift - click option to trigger the verbose option ...
how about intermediate levels of verbose:
- 0: strip all the "unneccessary" code like now - compatibility mode
- 0.3: generate all the JSL code that is necessary to generate the same result on this system. [fixes the issue with Conditional]
- 0.5: generate all the JSL code that is necessary to generate the same result on a default system. [fixes the issue with the user defined gradient setting]
- 0.7: based on the generated graphs/ reports of the last 6 months, include all settings which are changed >=3 times. Generate a code which is robust against all the settings.
- 1: JSL code robust against any settings in the preferences.
my favorite: 0.7:
super useful !
- who cares about 5 additional lines of code - if they will generate a more robust result on any system of your colleages.
- how often did you generate a concatenate and wondered later about the exact wording of append to main table(1)?
Today I just learned about
Ignore Platform Preferences(1)
Ignore Preferences(1) could fix some of the mentioned issues - but it doesn't seem to exist
