the-carlisle-group / Acre-Desktop

A simple Dyalog APL IDE plugin that introduces "projects" and allows you to keep your source code in Unicode text files.
MIT License
11 stars 1 forks source link

How to stop acre from closing the edit window if file was not written to disk? #151

Closed norberturkiewicz closed 5 years ago

norberturkiewicz commented 5 years ago

@PhilLast I have a personal branch of acre where I do git branch state checking. If I answer 'NO' to the question I'd like to keep the edit window open. Can you advise where I need to make that change?

My two enhancements

 editFix←{⍺←⊢
     (⍵≡'Start'):{                                     ⍝ from Start
         (wx ⎕SE.⎕WX)←⎕SE.⎕WX 1 ⋄ qed←'⎕SE'⎕WG'Editor' ⍝ keep  ⎕WX
         SV.fixandafter←⊃if≢¨qed.(onFix onAfterFix)    ⍝ odd extra nesting!
         qed.(onFix onAfterFix)←⍬⍴⎕XSI ⋄ ⎕SE.⎕WX←wx    ⍝ reset ⎕WX
         {0}SV.itemvalue←editStore ⎕NS''               ⍝ create value store
     }''
     (⍵≡'Close'):{                                     ⍝ from Close
         qed←'⎕SE'⎕WG'Editor' ⋄ (wx ⎕SE.⎕WX)←⎕SE.⎕WX 1
         qed.(onFix onAfterFix)←SV.fixandafter ⋄ {0}⎕SE.⎕WX←wx
     }''
     (editor event value space name new)←6↑⍵           ⍝ so long as onFix unchanged
     first←event≡'Fix' ⋄ sn←1 ssp⊂⍕space               ⍝ is space scripted?
     {0::1 ⋄ 0∊SV.setupcomplete,⍴openProjects''}0:(⍎first⊃⌽SV.fixandafter)⍵
     fqn←(⍕space),(sn≤space=#)/'.',name new⊃⍨ren←(≢∘∊⍨new)∧2≠space.⎕NC name
     0=dat←whichProject fqn:(⍎first⊃⌽SV.fixandafter)⍵
     (('⎕'∊fqn)≥(⎕NC⊂fqn)∊0,validAPLType''):
     first:{nv←fqn MS.GU if null⊃¨1 0 1/getValue,⊂fqn
         z←SV.itemvalue editStore nv
     }''
     new←MS.GU≡oldval←SV.itemvalue editStore fqn
     (0≥#.⎕NC∘⊂)fqn:
     null dat caseOK fqn:
     (oldval≡newval←⊃2⊃getValue,⊂fqn):                 ⍝ unchanged
     type←⊃nameClass fqn
     exit←checkGitState dat
     exit:
     z←⍴dat∘putChange⍣(new⍱(⊂fqn)∊dat.changed)⊢fqn oldval type
     z←logMsg MS.DK,⊃dat setChange fqn type newval
⍝ ⍺ probably missing
⍝ ⍵ 'Start' or 'Close' or callback argument
⍝ ← 0 for 'Start' and 'Close' - else none
⍝ Phil 2018-10-23 19.51
 }
 checkGitState←{
     p←'"',⍵.source,'"'
     c←'git -C ',p,' branch'
     b←⎕CMD c
     b←0⊃('[*] (.+)'⎕S'\1')b
     b≢'master':0
     ⎕←'You are on the "master" branch.'
     ⎕←'Are you sure?'
     ⎕←''
     ⎕←'''YES'''
     ⎕←'''NO'''
     ok←⎕
     err←~(⊂ok)∊'NO' 'YES'
     _←{
         0=err:0
         ⎕←err/'Invalid response.'
         0
     }err
     err:1
     ok≡'NO'
 }
PhilLast commented 5 years ago
Dyalog APL/W-64 Version 16.0.34994
Serial No : 003280
Unicode Edition
Thu Feb 21 21:57:56 2019
      zz←'⎕se'⎕wg'Editor'
      zz.onFix
 ⎕SE.SALTUtils.EditorFix 
      zz.onAfterFix
 ⎕SE.SALTUtils.EditorFix 
      f00←{1}
      zz.onFix←'#.f00'
      )ed qwerty
      ⍝ create new function and escape
      ⎕cr'qwerty'
 qwerty←{    
     whatever
 }           
      f00←{0}
      )ed qwerty
      ⍝ changed but editor won't close
⍝ switch to session
      f00←{1}
⍝ back to editor and escape
      ⎕cr'qwerty'
 qwerty←{                      
 ⍝ 1 did this while f00 was {0}
     whatever                  
 }                             

So although I'm not sure exactly what you're trying to do, if you return zero on line exit: the editor will (or at least it should) stay open.

norberturkiewicz commented 5 years ago

I'm checking if my projects git branch is on "master" before allowing acre to update the file on disk. If the branch is on the master, I want to confirm that this is a valid operation. This goes with the workflow that a user should never work directly on master but we have no warning when branches are switched outside of apl.

If the branch is on master and the user says 'NO', the operation should be canceled and the edit window kept open.

aplteam commented 5 years ago

For precisely that reason I use my own user command ]OpenMyProject which gives me information like branch, Status etc.

If you don't switch branches while working in APL (you shouldn't really) then that should suffice.

PaulMansour commented 5 years ago

See Issue #152