let codemap adapt to all layouts

[mg979]

I changed the way the codemap is added to the window, it simply adds to the right of whatever groups you have open, and scales them down a bit. In this way, the horizontal panes are conserved, and less common layouts with many panes are possible too. You can also set the width in the settings.

Not sure if it did before (I don't think so), but now the codemap will not close the group it was in, if there were other tabs (it fixes an annoying issue with FileHistory too).

I also included the markdown mapper in the main file (I didn't see a good reason to leave it among the custom syntaxes, it's just more work to have it running)

You can also check my test branch, it has more features:

• open codemap on the left side
• support for custom languages (for codemap visual only, necessary if one uses improved language definitions and has to deactivate for example Python package)
• more visual settings (hide the : <line> part, font size/padding

I was thinking about adding navigation with arrows in the codemap, and change a bit behaviour like this:

alt+m, alt+m:	open or close
alt+m, alt+space	focus to map and back
arrows:	navigate and scroll to definition in source

I don't know it it's possible, but I think it would be useful if it could map also unsaved buffers, one could then have maps for git commit diffs and other stuff.

[oleg-shilo]

Hi there,

Thank you for the contribution.

I am glad you are looking at this. I was always feeling that the layout management it is the area where it's possible to bring some new user experience and improvements.

Can you please have a look at a few things before I can merge your pull request.

• I would like to ask you to roll back the embedding markdown mapper and let it back into a standalone py module. The idea behind keeping it this way was that it could be an easy to access sample for custom mappers. So users can take it and create their own mappers using code_map.md.py as a benchmark/template. And if they feel like, they can commit their mappers (one mapper - one py file) to be distributed with CodeMap.
  However I see the problem with the current arrangement. I was convinced by ST3 support that it is better to distribute the plugin as a compressed package. And only now I realized that by agreeing on this I efectively completely prevented access to the code_map.md.py. Thus I will need to address it from the master branch

• it looks like there is something broken as close group only if alone is still misbehaving. I did only a black-box testing though:

Thank you

[mg979]

I followed your suggestions, here I have:

• fixed autoclose
• removed md mapper from script
• automatic extraction of custom mappers in packages dir when plugin is installed
• custom mappers are automatically recognized (no need to specify paths in settings)
• support for custom syntaxes for visuals (made one for markdown as an example)
• copied python mapper also in custom_mappers dir so that it can be overridden (and you can set custom syntax)

When mappers are extracted, the new code_map.py.py isn't, you should uncomment some lines in the following commit if you want to add that file. I would add it because it's easier to make custom mappers from python mapper than from md mapper (it has already indented sublevels).

Option for codemap on the left side is on my other branch, I'll try to import it later if you'd like it.

[oleg-shilo]

Excellent. Thank you. I will be on the move this week so will be able to process your pull request only next week.

Cheers, Oleg

[mg979]

Ok, if you find some unexpected behaviour, just tell me. Sorry for a couple of small commits, I'm not very practical with git yet, maybe you can do a rebase or something, if too many commits bother you (they bother me generally but I don't know if it's normal or if there is something one should do about it).

[oleg-shilo]

Thank you. I just merged your branch.

I will need to do some extra testing before releasing it as I have added support for loose packages.

[mg979]

Ok, I'm taking a short break from plugin making right now, is it all working to your tastes? I will try to add some more feature later (left side, fast switch side, keyboard navigation).

[oleg-shilo]

Yes all seems OK. I just made the release yesterday.

Effectively it's your layout solution plus support for loose packages. The only actual change i did is the location of the custom mappers. I moved them under [InstalledPackages]\User\CodeMap\custpm_mappers. That's it.

Enjoy your break :)

[mg979]

Did you test it? Because to let them go in Packages\User\Codemap I think you should use sublime.packages_path(), not sublime.installed_packages_path(), but I'm not sure. I thought installed_packages_path is just for Package Control compressed packages. It seems ok in the commit though, maybe you meant [Packages] not [InstalledPackages].

[oleg-shilo]

Yes I did the test. Though in the release I did it path.join(sublime.packages_path(), 'User'...) But sublime.installed_packages_path() is arguably a better way. But the release still works. gtg now.

[mg979]

Ok, if it works I'd leave it like that, I have doubts thatsublime.installed_packages_path() would work well. Good night.

[oleg-shilo]

sublime.installed_packages_path() supposed to be a better choice as if ST starts placing user folder in some other location the CodeMap would be automatically remapped. I simply overlooked it and will test it the next time I visit the code.

Though even your approach (placement) was OK. It's just ST dev team encourages anything that is a part of user alterable data to be placed in User.

[mg979]

Yes your current approach (in Packages\User\CodeMap) is better than mine, what I mean is that something like InstalledPackages\User\CodeMap\ or InstalledPackages\CodeMap\ wouldn't work in my opinion, I don't think the files there would be recognized at all, because I don't think ST checks that folder structure for files.

[oleg-shilo]

OK, I see the problem, I misinterpreted what sublime.installed_packages_path() does. My bad, I thought that it returns Packages\User\ while sublime.packages_path() returns Packages\.

I am not sure where I got this idea from :). But according the ST3 API docs I am plain wrong.

All makes sense now. Thus the current implementation is to stay unchanged.

[mg979]

All clear now :)