Closed aplteam closed 5 years ago
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.
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.
Fine by me.
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.
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
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
That is a scary thought. But surely the user settings should be overriden by the project config?
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?
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.
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.
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?
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?
I believe acre 2 and 3 only had global settings.
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. :)
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
.