Regarding KeepHistory

[aplteam]

Getting more and more into Git I think acre's own history files should go.

At the very least the default should be off now.

]Undo and ]Redo would need to go as a consequence.

[PhilLast]

The default is off. And has been so since October.

But the history files are there because acre is and I hope will remain a tool for APL developers who haven't necessarily got more and more into Git and perhaps just want to work with projects but without saving workspaces or perhaps want to use some other SCM.

[norberturkiewicz]

I think the history files are only useful if using acre as the SCM. With git, svn,... they’re just in the way.

My .02 is that we’re at the point that everyone should bite the bullet, learn sow thing new, and adopt one of the mainstream solutions.

[PhilLast]

only useful if using acre as the SCM

Probably

they’re just in the way

But by default they're Off and require positive action to set them On after which they're fulfilling the purpose reasonably well.

should bite the bullet

But should is a lot different from MUST and I don't think we are necessarily the authority to insist unless we want to drive potential users away before we have any.

[aplteam]

Good point Phil.

In that case I suggest to change ]undo and ]redo so that they produce an error message in case there is no history. Currently they are silent.

Also, the documentation states they are "only available" whith KeepHistory←'On which is not quite right: they are always available but might might not do anything.

[PhilLast]

As you've pointed out some commands never produce any log messages and you want all to do so merely to record that they have run. But both Undo and Redo produce message

History is disabled for project .../folder/

when it's true as do Changes, PurgeHistory and Restore. Of course it you have ]log hide in operation you won't see it.

Perhaps unfortunately, it's impossible to make a command unavailable mid session, especially for a selection of arguments so it seems to me in the circumstances that disabling a command is tantamount to making it unavailable. Nevertheless in the wiki would -

Note that ]acre.Undo is disabled with KeepHistory←'Off'

not only suffice but be clearer than

Note that ]acre.Undo is only available with KeepHistory←'On'

?

[aplteam]

When somebody calls ]undo or ]redo while KeepHistory is off I think they should both throw an error.

[PhilLast]

When somebody calls ]undo or ]redo while KeepHistory is off I think they should both throw an error.

They both issue informational messages. Here is a session

      )clear
clear ws
      ]log show
      'projA' 'projB' ⎕ns¨⊂''
      projA.this←{'this n that'}
      projB.here←{'here n there'}
      ]createproject projA projA -keephistory=on
#.projA
      ]createproject projB projB
#.projB
      projA.this←{'these and those'}
      projB.here←{'hither and thither'}
      ]setchanged projA.this projB.here
  #.projA.this    #.projB.here
      projA.this←{'dies und das'}
      projB.here←{'hierhin und dorthin'}
      ]setchanged projA.this projB.here
  #.projA.this    #.projB.here
      ]undo projA.this projB.here
  #.projA.this

And here the associated log

2019-04-07 08:34:24 ]Log show
2019-04-07 08:34:24 ]CreateProject projA  projA
2019-04-07 08:34:24 ]CreateProject projB  projB
2019-04-07 08:34:24 ]SetChanged projA.this  projB.here
2019-04-07 08:34:24 SetChanged wrote 1 file
2019-04-07 08:34:24 SetChanged wrote 1 file
2019-04-07 08:34:24 ]SetChanged projA.this  projB.here
2019-04-07 08:34:24 SetChanged wrote 1 file
2019-04-07 08:34:24 SetChanged wrote 1 file
2019-04-07 08:34:24 ]Undo projA.this  projB.here
2019-04-07 08:34:24 #.projA.this -  1 of 2
2019-04-07 08:34:24 History is disabled for #.projB .../Desktop/acre4projects/projB

You'll see that the acre framework calls ]SetChanged and ]Undo (and all other item commands) multiple times (under key ⌸ and previously under UT.ky ⍝ 2008-05-29 10:39) according to how many open projects are represented in the argument. This capability has existed since ]Erase became the first acre method to be implemented as a user command and over several months the instance methods were given an alternative life as shared methods until the code was generalised.

If anything actually goes wrong then the user command framework forces the error back to the session. I'm loth to introduce an artificial error reflecting a user mistake that would confound the situation where one call was perfectly OK as above and the other not.

[aplteam]

I see. I would still replace the word "available" by "functional" in the documentation in order to clarify matters.

[PhilLast]

Closing this as the substantive issue is fixed