Issue + Possible Solution: Toggling Code Map with show_code_map cmd causes active view / file to close ( whether using the keybind or calling directly )

[Acecool]

I only just noticed this by adding a context menu option to toggle the command ( some people are having issues with holding alt and pressing m 2 times because it's an odd method )... I confirmed the issue by using the key-bind.

Issue: When closing the Code - Map Panel, the source-code file is also closed.

Expectation: When closing the Code - Map Panel, the files opened remain unaffected.

if

w.run_command("close_by_index", {"group": g, "index": i})

is commented out - the panel doesn't close AND the file remains unaffected - so a callback which uses this, the command itself, or the number of views in the group is to blame.. Commenting the line isn't a solution because the panel won't be toggled.

Altering the line under elif ACTIVE: in show_code_map function from above to:

            w.focus_view( map_view )
            w.run_command( "close" )

resolves the issue because empty groups will be closed ( likely if that setting is true and by default it is )... So when you toggle it, and it is open, the code - map panel is focused and then closed. CodeMap doesn't execute when the panel is closed so there are no issues there either.

Edit: For some reason it's reverted to closing both again... I'll look into it further.. the issue is still an issue.

[oleg-shilo]

Can you please describe the steps to reproduce. Using "Toggle Visibility" command does not trigger any problems.

[Acecool]

I figured out why it closes another file....

If the view has Scratch set to True, and the view is closed manually by a user ( tab X or middle mouse ) and it is alone in the group - the empty group will close and the next file which takes focus will be closed with it...

The solution is to ensure the view Scratch is set to False in your EventListener - on close should be called just before the view is closed - I've had success with this fix...

    ##
    ## Callback - Called when a file / view is closed...
    ##
    def on_close( self, _view ):
        ##
        ## Bug Fix - Called when ACMS - If Scratch is set to True, and it is in a group by itself, and the file is closed manually by the user - then it'll close the Scratch file, and the next file which takes focus... Ensuring Scratch is false corrects the issue...
        ##
        if ( IsSublimeView( _view ) and _view.file_name( ) !=  None ):
            if ( AcecoolString.GetFileName( _view.file_name( ) ) == ACMS( ).__panel_name__ ):
                AcecoolSublime.SetViewScratch( _view, False )

note:

## IsSublimeView
def IsSublimeView( _data ):     return _data != None and str( type( _data ) ) == '<class \'sublime.View\'>'

##
class AcecoolString
    ## Returns the filename with file extension from path/to/file.ext
    def GetFileName( _file = '' ):
        return _file.split( '\\' )[ - 1 ]

##
## Acecool Sublime Text Library - This is not an object - self is not used...
##
class AcecoolSublime:
    ## Sets the Scratch Value for the given view...
    def SetViewScratch( _view, _value = False ):                                    return _view.set_scratch( _value )

Note: This may not resolve the OTHER issue where using the hotkey to toggle it, or using a menu item to call the command, will still close another file.... I don't have this issue in my system, only the manual close issue because of scratch.... but you have the issue on manual close, and also using the command...

I hope that it is related because it'll resolve 2 to 4 similar issues in 1 go...

If the other issue still occurs - you could try what I did originally ( lasted 10 minutes before I found the actual cause ) which is on_close create a new file if closing Code - Map, then close it... That'll ensure the group gets closed by a blank file and shouldn't have any issues then...

As for the file closing on the command - there may be an issue with the way you close the group / file - I use a different method, similar to the solution I submitted before... Hopefully that points you in the right direction.

[oleg-shilo]

Sorry for the delayed response.

Hopefully that points you in the right direction.

Not really :)

I feel a bit uneasy about this one. You haven't provided any description of how to trigger the problem you are observing. I still have no way to reproduce it. I also have no other reports about the behavior you described.

Though I have no doubts that you indeed experience what you describe. Thus, considering that the solution you are proposing (view.set_scratch(False)) is safe and does not exhibit any change in the user experience I have incorporated it in the latest codebase: 0e9cf0b0acc1bc12d410c1d73070ed499a3cd2b8

I will release the new package shortly.

Thank you