Do you use the preferences?

[#1]

Via File/Preferences, you can change the standard settings of Jmp.

Very cool to adjust Jmp to your needs

But I found a subtle issue - in combination with the functionality to automatically generate JSL code (save to script, advanced log, Dashboards, log, Workflow Builder ...)

The below code changes the preferences, so - please think twice if you want to try it .

The story:

A user adjusts some settings via File/Preferences - an then generates a report with the default setting:

Names Default to Here(1);
dt = Open( "$SAMPLE_DATA/Big Class.jmp" );

Set Preferences(
	Data Filter Conditional( 1 ),
	Column Switcher Retain Axis Setting( 1 )
);


Graph Builder(
	Variables( X( :height ), Y( :weight ), Overlay( :sex ) ),
	Elements( Points( X, Y, Legend( 1 ) ), Smoother( X, Y, Legend( 2 ) ) ),
	Local Data Filter(
		Conditional(0),
		Add Filter(
			columns( :sex, :name )
		)
	),
	Column Switcher( :weight, {:age, :weight},Retain Axis Settings( 0 ) )
)

Then he optimized the Report via the GUI and saves the script. This Script will look like the below one
(for sake of clarity: neglecting the "optimization" step):

Graph Builder(
	Variables( X( :height ), Y( :weight ), Overlay( :sex ) ),
	Elements( Points( X, Y, Legend( 1 ) ), Smoother( X, Y, Legend( 2 ) ) ),
	Local Data Filter(
		Add Filter(
			columns( :sex, :name ),
			Display( :name, N Items( 15 ), Find( Set Text( "" ) ) )
		)
	),
	Column Switcher( :weight, {:age, :weight} )
)

i.e.: all default settings are automatically removed from the code - as they won't have an effect for a standard system.

Same happens if the uses uses the Report inside a Dashboard (!) - all default settings won't be added.

Now, the user runs the code again - imagine how the Report will look like ...

I can understand why it is like this - it is no bug it's a cool Feature that Jmp automatically cleans code to remove unnecessary lines.

But in combination with a user who dares to change settings in the preferences it acts like a bug.

My current workaround: Just change preferences where you are sure that you won't use the default setting.

This is great for 100 - 0% ... 50 - 50% and the special case: 0 - 100%  (future usage of: % default - %different setting).
But hurts for the range  above 20 - 100% 
... and hurts especially for something like 99 - 1%.

Is there a better solution - how do YOU solve this issue in daily work life?

[#2]

Accoring to Jmp support (TS-00061254):

this is working as designed.

So:
With CHANGED settings in the preferences, a user loses the chance to use Dashboard Builder to generate Dashboards which open platforms on his system with STANDARD settings

Workaround: 

Open the source script of the Dashboard and manually add the code for the standard setting.

[#3]

Jmp support suggested to write a post for the wish list.

Here it is:
Changed Settings in the Preferences -> fix the issue 

[#4]

@hogi, I tried your code and see what you mean.  having changed the preference for the filter and the column switcher and then using choices that match the preference defaults (not the current preference) you make a report.  Then saving script doesn't bother to include the settings that match the defaults so the script doesn't reproduce your report.  And you are interpreting that  (and support claimed?) that this is intentional to clean out anything that wouldn't be needed if you had left your system at the default preferences?  ie. Conditional(0) not included because it wouldn't be needed if you had default preference even though it's relevant currently?

But that is not what I see for the preferences for Graph Builder itself.  If I change my Preference for Graph Builder to not show title, for example, and then I make a graph builder and ask (either in JSL or manually after the fact) to show title,  I do get a script with showtitle(1) included.  The kind of redundant setting that conditional(0) could be seen as, one you don't need if you have default preferences.  I think what I see generally is it does not include settings that aren't needed with the preferences I have currently.  Now that I turned off showing title in my Preferences, if I ask for showtitle(0) it doesn't bother to mention that in the script.

So, seems like 2 issues: (1) one might like to capture all the options regardless of whether they match your preferences or not and (2) the "get script" type options appear to me to treat the filter and col switcher differently than they treat the rest of the platform.  it fails to give you a script that works with your current preferences like it does for platform preferences. I can appreciate that removing unnecessary clauses is intentional but not that the definition of unnecessary is different for filter than for settitle().?

2. seems like a bug to me that it's eliminating things not for being same as current preferences but for being same as defaults.

1. seems like it is indeed similar to my wish list item about Use Thousands Separator (interrogate Use Thousands Separator using JSL - JMP User Community), where maybe one solution could be an option for a more verbose script to be returned, one that doesn't eliminate anything as just "same as preferences".

Great, now my preferences are all screwed up... 

[#5]

100% agree

especially the
- I can appreciate that removing unnecessary clauses is intentional

- but not that the definition of unnecessary is different for filter than for settitle().?

there are many more settings which behave like the column switcher and the data filter - even settings which directly affect Graph Builder:

If you change the default settings for Summary Statistics, Graph Spacing etc. in the preferences, all your automatically generated JSL code will have a section with:
Summary Statistic( "Median" ),
Graph Spacing( 4 )

... till you try to set it back to the default values. If you hit the default setting, the settings will not show up in the generated JSL script - with a similar issue like Conditional: no chance to generate a JSL code automatically with the default settings.

[#6]

As there is so much room between 
- removing "unnecessary" clauses

- writing all settings such that the result is the same on ANY system - independent of the current settings.

So, how about a verbose(0), verbose(0.3), verbose (0.5), verbose(0.7), verbose(1)

- 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 user settings 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.

0.7: super useful - my favorite!
- 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)?