Unable to set multiple extensions of robot files

[agagalski]

In my workspace I have both .txt and .robot, but I can't set them for scanning. I tried:

• "txt|robot"
• "txt robot"
• [".robot", ".txt"]
• ["robot", "txt"] ...

/* File extension defines which types of files the Robot Framework Assistant plugin will search and index from the folder defined in the robot_framework_workspace option.

    This setting does not affect to the which files are uses the
    syntax highlight.
*/

"robot_framework_extension": "robot",

[aaltat]

The syntax highlighting​ should work if you make a user setting for the syntax definition. At least that is my recollection on the matter.

But the robot_framework_extension setting doesn't support multiple extensions​. The setting is used to find the test and resource files from the workspace when the internal keyword and variable database is created. The internal database is used to provide keyword and variable completions, jumping to keywords and showing the keyword documentation.

Currently you have to choose from one extension and it can be a problem in this case. To fix this, it would require some work in the plugin. Would you be interested to provide a PR?

[agagalski]

My intention was to create internal database, so I will have working "keyword and variable completions, jumping to keywords and showing the keyword documentation". Currently it's not working, so I started looking for a reason. My guess was that is a problem with setting "robot_framework_extension", because my test suites, resources sometimes has .robot and sometimes .txt extensions, so I want to solve it first. If there is no workaround for this I can try to provide PR (I never did this before, but I I can follow information in https://help.github.com/articles/creating-a-pull-request/****)

Some more background information of my problem: After configuring just robot_framework_extension=robot keyword completion works, but when I try to 'Jump to keyword' I get in console: >>> Traceback (most recent call last): File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 818, in run_ return self.run(edit) File "C:\Users\meep_gaga\AppData\Roaming\Sublime Text 3\Packages\Robot Framework Assistant\commands\jump_to_keyword.py", line 51, in run keyword=keyword File "C:\Users\meep_gaga\AppData\Roaming\Sublime Text 3\Packages\Robot Framework Assistant\command_helper\get_keyword.py", line 61, in return_file_and_patter if self.rf_data(file_path_table): File "C:\Users\meep_gaga\AppData\Roaming\Sublime Text 3\Packages\Robot Framework Assistant\command_helper\get_keyword.py", line 159, in rf_data return file_path.endswith(self.rf_extension) TypeError: endswith first arg must be str or a tuple of str, not list

[aaltat]

As an workaround you could unify your test data to use single extension. Would that be suitable solution for you?

[agagalski]

I can't unify, because I'm pulling resources and test suites from many other contributors and all is linked together in this mixed .txt-.robot state.

[aaltat]

I understand your problem.

There has been discussion for Robot Framework to support also for .resource extension. Therefore it could be a good idea to add support for multiple extension in the plugin also.

If you want to look how to implement this improvement, good place to start reading would be here: https://github.com/andriyko/sublime-robot-framework-assistant/blob/master/commands/scan.py

Scan creates a tables, separately from each test suite, resource and library found from the workspace director. It should be possible to change scan to understand multiple file extensions and then you should not need to make changes elsewhere. Because rest of the functionality should rely on those tables to provide the plugin features.

[agagalski]

Unfortunately I cannot contribute. I hopped it will be some simple change in code, but it's beyond my skills, so as for now this feature request is open.

[aaltat]

I understand, that Sublime plugin API requires some level of understanding of the API. But I did reminded my self reading some of the code and the chance could be easy one. I will consider doing this if I have time to spare from the Selenium2Library Python 3 support.