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 (Conditional & Column Switcher Retain Axis Setting) via File/Preferences
- an then generates a report with the default setting (he has do this manually, no chance to generate the code via enhanced log):

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 adjusts the Report interactively via the GUI and saves the script (using the enhanced log functionality of JMP).

The generated script will look like this:

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} )
)

Please note:
Conditional(0) -> removed automatically!

Retain Axis Settings( 0 ) -> removed automatically!

The finding:
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 (!) - 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 definitely acts like a bug - a severe bug!

My current workaround: Just change preferences where you are sure that you won't EVER (!!!) use the default setting.
This rule hurts  - especially for cases where I use the adjusted setting in 99% of the cases - and 1% the default setting.
Then, the rule doesn't allow me to adjust the preferences. I am forced lo live with the default setting and have to manually adjust the setting in 99% of the cases.

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

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)?