When replacing 1 python file in Packages/CodeMap/ ( without extracting all files ) there is an error looking for custom_languages md.sublime-syntax

[Acecool]

SublimeText allows us to keep packages unextracted and still replace files as needed... I replaced code_map.py in an otherwise empty folder to resolve the rubberbanding issue and a small bug.

The problem is that this error shows up when you do that:

Traceback (most recent call last):
  File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 210, in on_api_ready
    m.plugin_loaded()
  File "C:\Users\UserName\AppData\Roaming\Sublime Text 3\Packages\CodeMap\code_map.py", line 108, in plugin_loaded
    shutil.copyfile(src_syntax, dst_syntax)
  File "./python3.3/shutil.py", line 109, in copyfile
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\UserName\\AppData\\Roaming\\Sublime Text 3\\Packages\\CodeMap\\custom_languages\\md.sublime-syntax'

This should be corrected in code_map.py to follow SublimeText directives so single-files can be replaced without needing to extract other files..

The issue level is LOW PRIORITY - because it is easily solved by extracting custom_languages folder... However, the logic when looking for custom_languages files should be to look in Packages/CodeMap/custom_languages/ and if file exists, load it.. Otherwise look in Packages/User/CodeMap/custom_languages/ and if file exists, load it... otherwise, if a default location is given such as Packages/MD/MD.sublime-syntax or MD.tmLanguage and file exists, then load it...

This would allow for easy replacements ( I'm not a fan of single-file replacements or replacements in my mod anyway so this, for me, is low but may be important for others - especially now as mods are starting to happen )...

[oleg-shilo]

Agree. I didn't know about this replacing technique. Will have a look at this issue. Txs.

[Acecool]

Cheers. As noted, it is low priority because it is easily remedied with adding the one folder and not many are bound to do this ( and I try to avoid it )...

I'd suggest looking at combining the code to reduce repetition in code_map.py near all locations of "for syntax in " code, and surrounding. A lot of those changes can be automated or a simply if or ternary to adjust the base-path prior to running the logic would slim the code down quite a bit... It's low priority but would make the readability jump up a bit because it isnt being repeated ( the human mind melds words, etc.. together so the more likeness there is between code the more likely we ignore certain aspects making it harder to process ).. If you don't get around to it and I end up having extra time in the coming months I don't mind editing it and submitting it to show what it could look like...

[oleg-shilo]

After reading your post above I have realized that you are talking about merging the source code modules into a single file. Correct me if I am wrong.

If I am right and you are indeed calling for merging all code together then, sorry it's not something that I would consider.

[Acecool]

What I am talking about is altering the code to reduce repetitions... For example, there seems to be 4 or more locations where almost identical code is used in code_map.py - I'm saying consider taking that code and turning it into a function and then replacing those 4 or so locations with a function call. So instead of 10 lines being repeated 4 times you have 1 line repeated 4 times for the function call and then if that code ever needs to be maintained you have 1 place to alter it instead of 4...

I apologize if I wasn't clear on this - but this is similar to what I was talking about merging with the features of my system - not redesigning the entire system ( when I talk of design I talk about flow-chart design to reduce repetition, and also how the code is written so when editing there is a code-standard / design in place so additions don't end up using many different styles for local vars suchAsThis OrThis _or_this or_this, etc... so it is uniform... )...

The way I prefer to code is to create building blocks out of code that read easily and do exactly what you'd expect so building complex systems becomes incredibly easy and much smaller in size than they'd otherwise be... any time I repeat code, I use a helper-function in its place and so on... It makes maintenance much much easier and quicker.

[oleg-shilo]

OK, thank you. I perfectly understand where you are coming from and agree that code duplication should be avoided when possible.

However please keep in mind that you are mostly talking about code duplication in two modules code_map.py and code_map_support.py. These two are loosely coupled and were developed at different times thus some logical duplication is unavoidable. When I say "logical duplication" I mean something like when your VSCode extension has code fragments that are identical to the source code of VSCode itself. I am exaggerating of course.

Saying that I am willing to give it special attention and see what can be improved when I visit the code next time.

Slowly growing source code entropy is an unfortunate reality of any project. Particularly the open-source ones. The most effective way of addressing it is to shield the developers from the internal imperfections of the framework by a strict interface. As in this case, you, as a mapper developer, do not suffer from these code duplications. Your mapping code has an absolute 0 dependency on the extension. The only requirement you have is that your mapper module has to have def generate(file): method.

Anyway, I will have a look at it eventually.

[oleg-shilo]

Closing as not impacting the functionality and UX The fix is an enhancement and indeed would make it a bit easier for the plugin maintainer (but not the plugin user) to do the development but the cost/value ratio does not justify the the fix.