Issue with custom_mappers naming system - Python uses decimals to denote change in folder therefore these files aren't recognized...

Acecool commented 6 years ago

I'm working on separating out the extra classes now so code_map.lua_user.py can exist but there is an issue... The naming system being code_map.lua.py is flawed - the general idea is to not use import imp and not use file-names with decimals as decimals in import are to separate folders...

If I use import imp then locate files named code_map.xxx<ex .py> then it'll work.. For now the custom ones will be named either code_map_lua_user or xcodemapper_lua_user and the primary will use code_map.x.py or I'll end up using that for the base file and then redirecting to the proper naming sequence but then it just creates a lot of files....

I was looking into separating out the XCodeMapper_Lang_Project so the files would be shorter and the projects would be more isolated. There is a way to reload the files - import sublime_project and sublime_project.reload_plugin( name ) - right now I'm using DEVELOPER_MODE = True and if DEVELOPER_MODE then reload... this way I can edit the files in real-time but by default use the caching system for speed...

This is me asking to please update the naming sequence to either custom_mappers.code_map_lua or custom_mappers.lua so the file is code_map_lua.py or simply lua.py - It is already inside of the Packages/User/CodeMap or Packages/CodeMap/ folder thereby associated with CodeMap.

Searching 5 files for "code_map."

C:\Users\Acecool\AppData\Roaming\Sublime Text 3\Packages\CodeMap\code_map.py:
   71          for syntax in default_mappers:
   72              if not path.isfile(mapper_path(syntax)):
   73:                 zip.extract('custom_mappers/code_map.'+syntax+'.py', dst)
   74  
   75          for syntax in custom_languages:
   ..
   86  
   87          for syntax in default_mappers:
   88:             src_mapper = path.join(plugin_dir, 'custom_mappers', 'code_map.'+syntax+'.py')
   89              dst_mapper = mapper_path(syntax)
   90              if not path.isfile(dst_mapper):
   ..
  118  
  119  def mapper_path(syntax):
  120:     return path.join(sublime.packages_path(), 'User', 'CodeMap', 'custom_mappers', 'code_map.'+syntax+'.py')
  121  
  122  
  ...
  488  
  489                  # try with mappers defined in files next
  490:                 script = 'code_map.'+extension+'.py'
  491  
  492                  # print('trying to get...', script)

7 matches across 2 files but only 4 are needed

For now I'd like to replace all instances of code_map.'+(syntax|extension)+'.py' with 'codemap'+$1+'.py' because the imported files, albeit circular, need to know about the base and the base needs to know to include it because of the generate function...

Either way, the code_map.ext.py naming sequence is flawed in terms of the standards most Python developers follow.

oleg-shilo commented 6 years ago

Yes I see your point. I completely forgot about this Python limitation (it cannot distinguish between file name delimiters and path directory separators). If you ask me, it's rather an unfortunate Python's by-design flaw.

Anyway, I am leaning towards the simple <syntax>.py naming convention. Will try to do it asap. It shouldn't take long. Just a day or two.

oleg-shilo commented 6 years ago

Done. Please have a look at the latest codebase. I will release it early next week is no problems reported.

Changes

The new naming convention: <syntax>.py
On plugin startup any of the detected default custom mappers that are named according the old naming rules renamed to meet the new requirements: code_map.py.py -> py.py code_map.md.py -> md.py code_map.ts.py -> ts.py

Acecool commented 6 years ago

Cheers - I'm renaming all of my XCodeMappers now to match the new design. I also agree that it is a limitation as many files use a dual extension naming scheme.. Not being able to include them without using the python back-end is a huge flaw and leads to developers having to write hacks to support them, or do what you did - renaming all dual-extension file-types...

I'll be releasing the next version of mine shortly with quite a few improvements... and better logic to detect going in and out of classes to support nested classes ( right now the logic works great on indenting and unindenting but when there are nested classes, it seems to get confused even though my logic looks sound, I have an error somewhere or I'm missing something so I'm seeing what I can come up with - and I added a new hook to run on every line of code for this - OnProcessLine )

Also, because of this change, I can now separate out project classes from each language - so the primary file can be the loader and hold the config ( unless I switch to sublime config system which may be nicer and I can set it up to auto load meaning I can get rid of one or more callbacks and I can also auto generate the AccessorFuncs too based on what is used.... ) but there's still the issue of not being able to load the child first leading to circular imports.

Anyways, cheers for doing this... It'll allow the project classes more breathing room...

When, or rather IF, I add the sublime configuration system - would you be willing to add a chunk of code to the back-end that I'd write... Basically the loader for the config to read which class to load as the primary... So if the config file exists, and if the value exists for which class name or file-name to load - to bypass loading lua.py, for example, to load lua_acecool.py or lua_garrysmod.py, etc...? This would get rid of the circular imports by importing child first which would import the parent - as the parents don't need to know about the children but the children do need to know about the parents, this should work...

If you don't want to add that modification, I'd understand - but it would be a small and simple bit of logic O( 1 ) so the affected speed would be negligible.... I'm trying to keep XCodeMapper ( still haven't decided what to name the final non development version ) as isolated as possible but not being able to load the child first means its still better to keep all of the project classes together to avoid circular imports...

Let me know :-) and thanks again for making the modification to the names.

oleg-shilo / sublime-codemap

Issue with custom_mappers naming system - Python uses decimals to denote change in folder therefore these files aren't recognized... #23