Group the list of currently supported filetypes by categories

[victordomingos]

The list is growing and is starting to need some sort of organisation. Currently, it displays 4 columns and 29 lines, with items being sorted alphabetically first by line, them by column. It would be a little more readable if it was sorted alphabetically by column instead.

But grouping by filetypes would probably be a great help, even if it makes the list a bit longer.

[NataliaBondarenko]

Hello!
We may not show the entire list at once, but we suggest the user to select the desired extensions.
Please take a look at this code example and write your opinion when you have time.
In any case, the changes for the supported types will be in a separate pull request.

def check_supported_types(a):
    from count_files.settings import SUPPORTED_TYPES
    extensions = [x.strip() for x in a.split(',')]
    if len(extensions) == 1:
        if extensions[0] in SUPPORTED_TYPES['text']:
            print(f'Supported: {extensions[0]}')
        else:
            print(f'Not supported: {extensions[0]}')
    else:
        st = set(SUPPORTED_TYPES['text'])
        e = set(extensions)
        if e == {''}:
            print('Not entered any value.')
        else:
            supported = st.intersection(e)
            not_supported = e.difference(st)
            if supported:
                print(f'Supported: {", ".join(supported)}')
            if not_supported:
                print(f'Not supported: {", ".join(not_supported)}')


def show_supported_types():
    from count_files.settings import SUPPORTED_TYPES, SUPPORTED_TYPE_INFO_MESSAGE
    msg = 'SUPPORTED_TYPE_INFO_MESSAGE\n' \
          'Press Enter to quit.\n' \
          'Enter a single extension or a comma-separated list of extensions ' \
          'to check if they are in the list of supported types.\n' \
          'Enter ALL to see all supported extensions.\n'
    print(msg)
    while True:
        user_input = input('  > ')
        if len(user_input.strip()) == 0:
            break
        elif user_input == 'ALL':
            from count_files.settings import simple_columns
            print(simple_columns(SUPPORTED_TYPES["text"], num_columns=4))
            break
        else:
            check_supported_types(user_input.lower())

show_supported_types()

Preview:

C:\Users\Net\Count-files>count-files -st
SUPPORTED_TYPE_INFO_MESSAGE
Press Enter to quit.
Enter a single extension or a comma-separated list of extensions to check if they are in the list of supported types.
Enter ALL to see all supported extensions.

  > py,foo,txt
Supported: txt, py
Not supported: foo
  >

C:\Users\Net\Count-files>

I'm currently doing tests for preview functions with the "file" command. This week, I want to finish the preview branch, tests, and documentation.
Then we will need to check everything on different operating systems. Check if everything is working correctly.
If you are not on vacation or have some free time, we can release the new version in September.

[victordomingos]

In first place, I am noticing that our current list could probably fit in a standard 80x24 screen, using 2 or 3 additional columns.

Now... Your idea seems to point in the right direction, but I would insist in the idea of extension groups. The message could include the list of categories or groups and then the options to view a group (v text/view python ), search for extensions (s/search txt) or display all (a/all).

Currently I am on a full time job, but I will try to get some time at night or weekend to review any pull requests, translate documentation changes and do some testing.

We are not in a hurry to release this, since the current version seems to be pretty stable (not that many complaints, right? 🙂). So we may take the necessary time to make sure everything is properly put together.

[NataliaBondarenko]

In first place, I am noticing that our current list could probably fit in a standard 80x24 screen, using 2 or 3 additional columns.

The number of columns may depend on the size of the terminal window.

[NataliaBondarenko]

The message could include the list of categories or groups and then the options to view a group (v text/view python ), search for extensions (s/search txt) or display all (a/all).

"a", "all", "v", "text" - can be names of extensions. I suggest using upper case for group names and lower case for extension names.

Groups:
CODE - Source code, shell scripts, html, style sheets
PYTHON - Python files
DATA - Config, settings, data files, markup
OTHER - Other text documents

[NataliaBondarenko]

to view a group (v text/view python ), search for extensions (s/search txt) or display all (a/all)

to view a group (upper case):
> PYTHON

search for extension (lower case):
> foo

search for extensions (lower case):
> py,csv,svg
> py, csv, svg

display all (upper case):
> ALL

[NataliaBondarenko]

We are not in a hurry to release this, since the current version seems to be pretty stable (not that many complaints, right? ). So we may take the necessary time to make sure everything is properly put together.

It is an open source project. We can take our time. We can stretch the work until the end of the year.

September
Complete all significant changes to the code (file preview and --supported-types text).
Update the documentation for new features.

Autumn
Testing.
Bug fixes and revision if necessary.
Correction of typos, clarifications, and additions to the text of the help or documentation, if necessary.

Winter
Release.
Tag for new version, generate docs for RTD.

Is this option right for you?

[victordomingos]

to view a group (v text/view python ), search for extensions (s/search txt) or display all (a/all)

to view a group (upper case):
> PYTHON

search for extension (lower case):
> foo

search for extensions (lower case):
> py,csv,svg
> py, csv, svg

display all (upper case):
> ALL

Do you mean using the entered text's case to implicitly indicate which action should be performed? If so, I disagree. It's an unnecessarily unconventional behaviour.

With regards to the timing, it's ok. We will continue doing it at our own pace.

[victordomingos]

The message could include the list of categories or groups and then the options to view a group (v text/view python ), search for extensions (s/search txt) or display all (a/all).

"a", "all", "v", "text" - can be names of extensions. I suggest using upper case for group names and lower case for extension names.

Groups:
CODE - Source code, shell scripts, html, style sheets
PYTHON - Python files
DATA - Config, settings, data files, markup
OTHER - Other text documents

I understand.

All the current versions had st as a run-once-and-return-immediately command. So, adding a prompt would change the existing user interface at the interaction level, which in the end may not be a good idea. We could opt to add a new set of commands instead, keeping the old one around as a way to maintain more compatibility with previous versions:

• count-files -st / count-files --supported-types--> (the old command) display the new supported types message, which should explain that there are many different supported types across several groups and listing the following commands. If we have enough space in a 80x24 terminal, we may display a few top results for each group, as examples.

Then, some new commands

1. View a specific supported types/extensions group:

count-files -stg  python
count-files --supported-types-group python

2. Search the supported types list for one or more extensions, like txt:

count-files -sts txt
count-files --supported-types-search txt

3. view an alphabetical list of all the supported types (equivalent to the current -st option):

count-files -sta
count-files --supported-types-all

4. View the list of all the supported types, grouped by category:

count-files -stag
count-files --supported-types-all-grouped

Since these new commands are getting too long, I would probably keep only the shorter form, maintaining the old one with both forms.

Also, I am not sure if we should keep the current -st behaviour instead (show all extensions), which would be more compatible with previous versions. If so, the new command number 3 above would not be needed, which would leave us with just 3 new commands to implement (numbers 1, 2 and 4).

What do you think?

[NataliaBondarenko]

In this case, a different case is needed to distinguish the keyword from the extension name. It seems to me that this is the simplest option.

We have already organized the help search by the similar principle of entering arguments/keywords (--help-cmd).

We could opt to add a new set of commands instead, keeping the old one around as a way to maintain more compatibility with previous versions

If I understand correctly, are you suggesting adding new arguments to the parser?
In my opinion, the new set of commands is inconvenient. CLI already has a lot of arguments.
I think changing the appearance of the output of an existing argument won't do much harm to version compatibility. The call of the argument and its purpose remain the same.

Something like that:

C:\Users\Net\Count-files>count-files -st

<Some useful information will be here: about using "--preview file" and "--preview" without options.>
How to search in supported types:
Enter a single extension or a comma-separated list of extensions in *lower case* 
to check if they are in the list of supported types.
You can also use the following keywords in *upper case*.
Enter a group name to see all extensions included in that group:
  CODE - Source code, shell scripts, html, style sheets.
  PYTHON - Python files.
  DATA - Config, settings, data, markup files.
  OTHER - Other text extensions.
Enter GROUPS to see all supported extensions sorted by groups.
Enter ALL to see all supported extensions in alphabetical order.
Press Enter to quit.

  >

[NataliaBondarenko]

Another option is to categorize the supported types for now. Just divide the extensions into categories in this version, and that's it.
That is, display all extensions not in alphabetical order, as now, but all extensions sorted by groups.
This option allows you to organize the list of extensions a bit.
This option also preserves the "run-once-and-return-immediately" argument behavior.

[victordomingos]

Having more commands registered in the parser is not a big issue, I believe. The only problem is the help page getting a bit longer. That's why more and less exist in the unix shell.

I am still convinced that we should not change the behaviour of count-files -st to include a prompt. It should remain a run once and return immediately command. We may change the kind and length of the information being presented, but not the interaction process.

Another option is to categorize the supported types for now. Just divide the extensions into categories in this version, and that's it.
That is, display all extensions not in alphabetical order, as now, but all extensions sorted by groups.
This option allows you to organize the list of extensions a bit.
This option also preserves the "run-once-and-return-immediately" argument behavior.

It is a good idea, since it would be less work to do before the next release. It's basically number 4 as stated above:

4. View the list of all the supported types, grouped by category:

count-files -stag

We can keep the old alphabetical view (count-files -st) and just add this new one.