last commit that fixes layout problems, simplifying things a lot

[oleg-shilo]

All done txs.

In the dev I also provided a work around that initialization problem (double-clicking does not work at startup until the map is re-generated).

Unfortunately over the time the plugin has lost its original stateless nature. It became statefull in the response to the various challenges brought by various limitations of the hosting API. And violating stateless paradigm is never without the consequences. All those painful reappearing issues were largely because of that.

Anyway, I have introduced persistence for the codemap (source file thus at least one aspect of being stateless has been addressed. Now double-clicking does not require prior map generation.

And in general, after your latest changes the plugin seems much smoother. And that trick with marshaling for fast double-clicking doesn't seem to be required.

[mg979]

In the dev I also provided a work around that initialization problem (double-clicking does not work at startup until the map is re-generated).

In the latest commits I had simplified a lot of things that I had introduced, and that I thought necessary, but in the last commit I removed all those limitations, at least I thought so. I thought general auto-synching behaviour was just like before, but maybe something had changed(I had to synch a couple of times to say the truth, when not expecting having to do it). Important is that it works for you, and that's stable and smooth. I didn't have crashes or misbehaviours for now, so for me it's ok for now.

About that 'marshaling' thing, unfortunately my programming knowledge isn't enough to even know what you're talking about :). But it's not important, as long as the plugin doesn't have problems.

Just one thing about that marshaler, I think it's better if you rename the class to something more specific(such as code_map_marshaler, because it's a window command and command names overwrite each other, that is if they have the same name. If it's not in use it could override something with the same name that is in use.

Unfortunately over the time the plugin has lost its original stateless nature

The way I left it in my last commit, is that it becomes inactive when switching projects, but it auto-activates again if the CodeMap file is loaded again(because present in the loaded project, for example), and it should have also auto-activate at start. That should have covered most of the cases. I don't know why you had to synch at start. Maybe you had to restart Sublime? Listeners often need a restart to be updated. But maybe I forgot something, because I also had to resynch a couple of times. I will switch a bit between branches to see if I notice some difference. Again, important is that it works for you.

[oleg-shilo]

because it's a window command and command names overwrite each other,

Fair point. Will do.

...in the last commit I removed all those limitations...

Indeed you did. And it does show.

But at least one minor usability issue was still there. The map is not generated at the ST startup. It's not usually a problem except if the first action the user does is double-clicking the map node. In this case _code_mapgenerator does not have yet source file associated with it even if the map view has a valid map content. Map view is statefull and it is in a wrong state for double-clicking. This is what I have addressed with the name of the last source used for map being persistent. It was the last bit ther required the attention.

With the latest codebase I actually was unable to detect any issues at all. Well at least yet :) Interestingly enough I even didn't have to use that marshaler of mine. Your simplification has removed the actual cause and the need for marshaling. I just decided to keep the marshaler, as there is a good chance it will be needed in the future.

... About that 'marshaling' thing,...

Marshaling is a generic term for transforming objects for passing them between incompatible runtime environments. It often goes beyond passing just simple data. In UI environments all calls (callbacks) involving resources shared between main and background threads need to be marshaled. I.E. listening to event (in background thread) and when it signals update the UI element.

Thus ST3 documentation indicates that they had in past various issues with the view content being edited from the inappropriate runtime context. The resolution was to prevent editing completely and allow it only from the dedicated command TextCommand. It was their marshaling solution. I found (and you too) that the same technique (moving routines into commands) helps with listeners too.

[mg979]

With the latest codebase I actually was unable to detect any issues at all. Well at least yet :) Interestingly enough I even didn't have to use that marshaler of mine. Your simplification has removed the actual cause and the need for marshaling

I'm just glad I simplified all that I had introduced because I risked to make a mess, now it's rather close to the original code, in the sense that there aren't unnecessary functions and commands. Also focus and layout stuff seem to much better than before, so I'd say it's not been wasted work. I will keep testing it as I do other stuff, if you notice some problem you can also tell me.

Did the trick for Favorites support work for you?

[oleg-shilo]

Yes it did. No problems there :)

BTW I want to thank you for all this time spent.

Despite the brilliance of ST3 in general, having done something that is outside of its mainstream functionality (e.g. fake panels) can be extremely painful. Thus I am not completely surprised the development took all this effort.

[mg979]

In general I think that there is a lot of non-mainstream functionalities that ST could be adapted to. I think having panels with clickable boxes and even with drag&drop is totally possible, only a pain to code the first time. ST compared to VS Code is lacking in things like debugger and a good Git integration, for the rest ST gives me more freedom. I'm sticking with ST for now.

[oleg-shilo]

I am getting ready for the release. I want to provide a brief description of the Universal mapper. Can you verify that the new content is accurate?

[mg979]

Except one thing, yes. There is no 'using_universal_mapper' setting. I updated a bit the readme adding navigation/depth and expanding a bit universal mapper section.

https://gist.github.com/mg979/5359946684d97018d2d68c9fea8f3ca8

[mg979]

In the final version you may also want to change this:

https://github.com/oleg-shilo/sublime-codemap/blob/a28e272bdc1179e562aa1c6d98b0bdc58c95490e/code_map.sublime-settings#L121

in Packages/Python/Python.tmLanguage

[mg979]

In this line:

https://github.com/oleg-shilo/sublime-codemap/blob/a28e272bdc1179e562aa1c6d98b0bdc58c95490e/code_map.py#L43

extension 'ts' should be added otherwise the custom mapper won't be copied to the user dir

[oleg-shilo]

Was it like that before? Modifying plugin is not an option. User must be able to add a custom mapper without waiting a new release of the plugin. Particularly because after the installation _codemap.py is not available at all. It a compressed packages.

Back to the drawing board.

[oleg-shilo]

No... I think you are mistaken in this case. It's a good thing to be wrong :)

I tested the custom TS plugin without modifying default_mappers. Will check again.

[mg979]

It's not really an issue that breaks anything.. but in plugin_loaded() the custom mappers are copied to the user dir. Here:

https://github.com/oleg-shilo/sublime-codemap/blob/a28e272bdc1179e562aa1c6d98b0bdc58c95490e/code_map.py#L84

it checks for that variable and copies the custom mappers with that extension in the user folder. If 'ts' isn't in default mappers variable the file won't be copied. I just verified, I added 'ts' and the file has been copied to 'User/CodeMap/custom_mappers'. Maybe the mapper works also if it's not present there, I don't know. But for sure it isn't copied in the User dir if 'ts' isn't added to 'default_mappers' in plugin_loaded().

[oleg-shilo]

Yes it makes sense. My bed. I misinterpreted your comment. Sorry. I was afraid that the user provided custom mappers cannot be located unless _codemap.py is updated. But you are talking about default mappers. Makes perfect sense. And during my test I placed the mapper in 'user' manually.

[mg979]

No problem, I'm not even sure it has any effect to have them there, or if they're searched also in the package.

[oleg-shilo]

I'm not even sure it has any effect...

Yes it does. You see, if the package is compressed there is no easy way to discover what custom mappers are included. Thus I captured themin the predefined list. Today I am a bit busy but will try to do the release tonight. I was using ST3 for the last 1-2 days and the plugin behaved really well.

---

On unrelated note. On weekend I have implemented the Favorites plugin for VSCode. Have a look: https://marketplace.visualstudio.com/items?itemName=oleg-shilo.favorites

In the animated gif I tried to capture the major functionality and it clearly show the shortcomings of ST3 hosting model. But... I am still coming back to ST again and again for the simple everyday tasks :)