acre INI file

[aplteam]

I know we've discussed this before but now I can make a case:

With the introduction of SCMexit←'#.function.name I need to edit more than 50 (!) project specific acre config files. Of course I dislike the idea very much.

I would rather prefer to have an optional config file that is a sibling of the acre workspace and can be used to define defaults for settings like SCMexit.

[PhilLast]

If not specified it defaults to '' as do Open and StartUp that means don't do anything.

I assume you mean an override to the default for all projects that don't specify otherwise.

Could be done. But better would be as a sibling of acre.log which is recognised only in [LocalAppData]/acre/.

You can put acre.dws anywhere prior to )LOADing it to Install acre as a user command source.

)LOADing build.dws from the acre project folder that runs buildWsFromSource puts the ws in [LocalAppData]/acre[XX.X]/ according to the Dyalog version whence it's run but you can move it wherever you like.

[PhilLast]

I notice that 7159⌶ has been dropped from Dyalog 17.0 replaced by ⎕JSON. Until now acre has honoured acre.config encoded as JSON ({), APLAN ([) and APLScript (:). Emulators in acre are assumed to continue to work even after the enhancement that they emulate. This is different and would demand a new approach. I really don't want to implement JSON in dfns again having thrown it away as soon as 7159⌶ was implemented.

So if we go ahead with your RFE I should want to restrict it to APLAN and perhaps take the opportunity to remove the JSON and APLScript options from the project configs.

[aplteam]

Fine by me.

[e9gille]

I agree that it is better to just have one type of config. I would have preferred it being JSON, but I don't have a strong argument, just that if any non-apl tool was to inspect project files it would be easier to parse. Right now I can't think of why a non-apl tool would do that, so there you go.

[PhilLast]

Was about to commit this enhancement with notes as below but as I was writing them it occurred that this might not actually be desirable. Nota bene the second paragraph.

Acre 5.1.0+180 2019-05-08 09.08

Acre Desktop - Release Notes

Implements enhancement #171 acre INI file

An optional, additional, user-specific, config file with the same format can be created as [localAppData]/acre/acre.config. Its paramater values will be treated by ]OpenProject as overrides to the defaults and will apply to All Projects within the installation for this user in which the parameter is not otherwise specified.

Beware!!! This config file is not a part of any project and is therefore not accessible to any external source code management. Parameters set will be instantiated in the acre session for only the current user. They will not be reflected in the project as instantiated in any other user's session whether in the current machine or sharing the project across a SCM. For instance setting CaseCode←'Off' where the public version is 'On' (or vice versa) might affect the ability to distinguish case agnostic item names either locally or publicly.

@PaulMansour @e9gille @norberturkiewicz @aplteam

[e9gille]

That is a scary thought. But surely the user settings should be overriden by the project config?

[e9gille]

Sorry, let me expand on my previous comment. You are saying that any settings not explicitly defined on a project level will fall back on user config and then finally acre defaults.

Createproject surely must set the properties in the project config as per above. So the scenario you give on CaseCode would only happen if you explicitly remove a setting from the project file?

[PaulMansour]

Late to the party, but this looks like a bad idea. If it is not under source code management, you can't really share the project.

[PhilLast]

I'd have to check but I believe it's still the case that you can create a project by putting a vestigial config file in an otherwise empty folder and run ]openproject on it letting acre do the rest. But it wouldn't add the missing parameters to the existing file.

Not does acre add newly defined parameters (such as SCMexit) to existing files.

[PaulMansour]

Should SCMexit be considered a different kind of parameter than the rest? That is, it is an environmental acre parameter that is not project specific? If so, it should perhaps not be part of the project config file at all.

Also, as currently implemented, you could have a different call back for every project. Does this make sense? Is that the intended use case?

[PhilLast]

That is, it is an environmental acre parameter that is not project specific?

Perhaps this is what Kai was after with the original suggestion. Makes more sense to me. And maybe that's what this extra config file should be for, with no overlap between expected parameters in the two files. Did we have something like that in acre 2 or 3?

[norberturkiewicz]

I believe acre 2 and 3 only had global settings.

[norberturkiewicz]

I've come upon the JSON config file support bug #177. I'd still vote to have the config file in JSON beyond anything else. The dfn emulator is simple enough for basic JSON that it can be the defacto standard for AcreDesktop.

I guess my request goes against the current wiki. However, I still vote for JSON being the only standard. :)