I plan to categorize win-vind by tier.

[pit-ray]

Currently, win-vind has been extended too far from its original purpose of moving the mouse in a Vim-like manner, and is messing around. Perhaps it is because the documentation is underdeveloped, but even though it claims to be Vim-friendly, when you look at the cheat sheet, there are a large number of commands that confuse the user.

Therefore, I would like to establish a hierarchical structure for functions like we are taking in Vim. For example, tiny, small, normal, big, huge. Then, multiple binaries are available, and the main launcher selects them to call.

If you have an opinion, please give it.

[gilbh]

What you write here is obviously of major importance, but could you please provide a link or two for resources that explain the hierarchical structure you refer to in relation to Vim?

[pit-ray]

You can refer the smallest version of Vim feature with :help version in Vim.

[gilbh]

Thanks.

I am not sure I found the right place. :help version brings up only one row that says:

							*:ve* *:ver* *:version*
:ve[rsion]		Print editor version and build information.
			See also |feature-compile|.

-- (but I am using neovim, not vim, maybe that's the reason?).

I tried searching online and I think the gist of the idea is having multiple builds with different levels of functionality to avoid conflict?

To me, vind does an excellent job in moderating between different modalities : GUI, vim motions, macro activation. These are different functionalities that do not always flow from one to the other.

But the main thing I want to say is that I think vind is doing excellent work in navigating these different roles. I, for one, am using vind mostly for: 1) text editing (vim motions and all), and 2) click control via keyboard (gridmove and easyclick). While these two roles are not fulfilled by vind in a perfect or complete manner, I am very satisfied. In fact, it already feels strange to me to work in Windows without having vind around. That's is awesome!!

What might be an area of weakness, in my view, is the conceptualization and documentation that clearly explain all the wonderful features of vind. I think the project is very young and dynamic, and it is very natural that vind would change dramatically. How to conceptualize these changes is a real challenge.

I am not sure I am addressing the issues you raise, but would love to continue the conversation.

Love vind!!

[pit-ray]

In the original Vim, the :help version describes the smallest version for the hierarchical feature as the following.

:ve :ver :version
:ve[rsion] Print the version number of the editor. If the
compiler used understands "DATE" the compilation
date is mentioned. Otherwise a fixed release-date is
shown.
The following lines contain information about which
features were enabled when Vim was compiled. When
there is a preceding '+', the feature is included,
when there is a '-' it is excluded. To change this,
you have to edit feature.h and recompile Vim.
To check for this in an expression, see |has()|.
Here is an overview of the features.
The first column shows the smallest version in which
they are included:
T tiny (always)
S small
N normal
B big
H huge
m manually enabled or depends on other features
- never, feature was removed
(none) system dependent
Thus if a feature is marked with "N", it is included
in the normal, big and huge versions of Vim.
....

As you said, the documentation of vind is cheap and it is high learning costs for newcomers to understand the concept of vind.
The aspect of the documentation is improvable by our contributions, but the aspect of the easy-to-understand concept will be achieved by categorizing a lot of features. To classify the functions, I plan to employ the concept of the smallest version (tier) as mentioned in the title.

Smallest Version	Supported Feature
Tiny	Mouse, System Command
Small	Process, Window
Normal	Vim Emulation
Big	Virtual Desktop, Tab, Hotkey
Huge	File, Extend Option

I think the light user wants to use only EasyClick/GridMove, but the heavy user wants to operate all of the things in the Vim manner.
Therefore, in the tiny version, vind has only the mouse movement feature, the minimum mode concepts (easy-to-understand), the minimum default mapping, and the minimum memory usage. Big has features that can be solved with macros such as Virtual Desktop, Tab, Hotkey, etc., and Huge is for extra over-the-top convenience options, which were added initially.

However, in contrast to the original Vim, the installation way does not change. The vind has multiple binaries and the user selects the smallest version with the initial setting GUI.

Thanks for the discussions, please give your opinions.

[gilbh]

Thank you!

First off, I think your idea of layering the features according to these five tiers is excellent: it brings clarity to the newbie user and delivers the power of vind in small digestible chunks. Kudos!! Documentation, indeed, will follow, after the conceptualization is more mature.

I am less excited from the idea of actually having multiple binaries and the user select specific version (if I understood you correctly). What is the point in this? Vim's multiple binaries are meant to solve very real problems of multiple platforms, hardware and software conflicts, limitation of binary size on embedded platforms, and so on. From what I understand, vind has none of these limitations/troubles (but please correct me if I am wrong).

What I am saying is that tiers are great as a concept for making vind more focused and for teaching newbies how to effectively use vind in different contexts inside Windows and apps. The concept of multiple tiers can also be implemented in terms of how each tier is configured in .vindrc and so own. BUT -- assuming there are no real conflicts between the usage and binaries of the different tiers -- I would not recommend actual separate binaries, or having the user choose among the tiers because I don't see what is the added value in that. Only more labor for everyone.

Looking forward to continuing this interesting brainstorming!

[pit-ray]

Essentially, the concept of multiple binaries do not mean much to the tier separation.
I think it is also possible to change the default mapping by writing a .vindrc like defaultmap tiny.

My attempt to separate the binaries is just an added bonus merit.

Currently, vind uses a GUI framework called wxWidgets to build a system tray, which is very slow to build. The system tray and the core of vind are compiled as the same binary but are separated and run in separate threads at startup.

If in the future we adopt a GUI framework with a fluent design such as WinUI or another language GUI framework, the GUI will be divided into an another binary and vind-core will be compiled as a CLI. In that case, GUI will have to use win-vind.exe --command to communicate. #103 (comment)
In other words, GUI will be able to choose any binary as the core program. For example, if there are two core binaries: win-vind-tiny.exe and win-vind-huge.exe, the GUI binary win-vind.exe selects one chosen at an initial setup such as win-vind-tiny.exe --command "<exit>". I would like to note that the user does not select the binary and the GUI process selects automatically.
This attempt reduces memory usage as a bonus to this separation of GUI and core process. (In fact, the huge uses twice as much memory as the tiny.)

But as you say, this may be over-optimization. Maybe just changing the default mapping would be a quick implementation.
For now, I will only add the default mapping classification and the initial setup screen.
Thanks.

[pit-ray]

Currently, the reclassified description is being documented in the tier topic master branch. If you are willing to help with documentation, please set up an environment to view the home page, and edit the markdown file in the docs directory, and send us a pull request.

How to build the environment
https://github.com/pit-ray/win-vind/blob/master/CONTRIBUTING.md#setup-local-test-environment

[pit-ray]

The following document is the most delayed.
https://github.com/pit-ray/win-vind/blob/tier/docs/cheat_sheet/functions/index.md

[pit-ray]

The correctness of the content will be reviewed in pull request, so please feel free to contribute. Those who contribute a lot will be noted in the README.

[pit-ray]

I released the new version (5.2.1) including tier-based feature. However, the documentation is on the way.

[gilbh]

Thanks for the details instructions. In principle, I would like to take up the task of working on documentation. However, I have very little experience with git/github.

For starter, even my curl is broken:

(utils) C:\Dropbox\Documents_and_Writings\Research\Digital_Humanities\Python>git update-git-for-windows
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

Any idea how to solve this so I can start pulling stuff?

[pit-ray]

This seems to be caused by an anti-virus.
https://stackoverflow.com/questions/60420446/command-failed-git-update-git-for-windows

However, you can cotribute its documentation by the following commands with Chocolatey and powershell simply.

1. Setup the environment for GitHub Pages

choco install ruby
ridk install
gem install jekyll bundler

2. Press the Fork button of win-vind.

3. Build the document.

git clone https://github.com/[your-name]/win-vind.git
cd win-vind
git checkout -b dev   # Change the branch like dev to send pull requests later.
cd docs
bundle install
bundle exec jekyll serve

4. Change the document by rewriting the markdown files in docs directory.

5. Commit changes.

git add .
git commit -m "Here is a brief comment on what you did."
git push -u origin dev   # Specify the branch created by checkout -b

6. Open pull request https://github.com/pit-ray/win-vind/pulls

Please let me know if you have any questions.

[gilbh]

First of all, I am grateful for your willingness to help with the process!!

Indeed, disabling my antivirus (Avast) solved the curl issue. Fantastic!

Now, I successfully installed ruby, but the second command:

ridk install

-- returned this error:

(utils) C:\Dropbox\Documents_and_Writings\Research\Digital_Humanities\Python>ridk install
'ridk' is not recognized as an internal or external command,
operable program or batch file.

What's going on?

[pit-ray]

Probably because the path has not been updated. Try reopening the terminal.

[gilbh]

Right. Reran the cmd and managed to get ridk install to run and install via manual installer:

Process completed and I attach here the installation log:
InstallationLog.txt

But now the next line:

gem install jekyll bundler

-- does not recognize MSYS2:

(utils) C:\Dropbox\Documents_and_Writings\Research\Digital_Humanities\Python>gem install jekyll bundler
MSYS2 could not be found. Please run 'ridk install'
or download and install MSYS2 manually from https://msys2.github.io/

I tried to rerun cmd and also refreshenv but still same result.

(comment: I installed MSYS2 under c:\tools, which is not the default c:\msys2 -- could that be the reason??).

Thanks!

[pit-ray]

Please refer this documentation.
https://jekyllrb.com/docs/installation/windows/

[pit-ray]

You can rewrite the markdown in your forked win-vind documentation directly on GitHub, although you won't see the correct preview.

[gilbh]

Thanks.

I manged to complete the installation, I think choco install ruby messed things up by not installed DevKit. Only manually installing the asset with DevKit from here https://rubyinstaller.org/downloads/ solved it.

I'll continue this journey and let you know.

[gilbh]

Okay, managed to run bundle locally but instead of building local site from current directory (win-vind\docs) the bundle used a neighboring directory (`Pyhton'):

(utils) C:\Dropbox\Documents_and_Writings\Research\Digital_Humanities\GitHub\win-vind\docs>bundle exec jekyll serve
Configuration file: none
            Source: C:/Dropbox/Documents_and_Writings/Research/Digital_Humanities/Python
       Destination: C:/Dropbox/Documents_and_Writings/Research/Digital_Humanities/Python/_site
 Incremental build: disabled. Enable with --incremental
      Generating...
                    done in 56.959 seconds.
  Please add the following to your Gemfile to avoid polling for changes:
    gem 'wdm', '>= 0.1.0' if Gem.win_platform?
 Auto-regeneration: enabled for 'C:/Dropbox/Documents_and_Writings/Research/Digital_Humanities/Python'
    Server address: http://127.0.0.1:4000
  Server running... press ctrl-c to stop.
[2023-06-19 11:40:19] ERROR `/favicon.ico' not found.

Is it because Configuration file: none or some other reason?

Thanks for your help.

[az-pz]

A bit too late here but I'd suggest that you use only two tiers. Beginner and Advanced. Beginner should have basic most common scenarios. Advanced can contain all the nitty gritty. You can also add full API reference to the advanced. Adding too many tiers seems enticing but ends up being confusing to users.

[pit-ray]

Most people who visit win-vind are interested in easyclick or gridmove, so the simplest tiny will be sufficient for them. The tier only changes the default .vindrc, so someone can distribute a .vindrc for beginners.

[az-pz]

Thanks for the clarification.
Tangential question: Are there performance advantage of using tiny config over larger ones? I want to use only easyclick ( to replace https://github.com/iscooool/KeyMouse ) and I want it to be as performant as possible. I am using this config:

set initmode guii
imap <ctrl-space> <easy_click_left>

Can I make any changes to my config to get easyclick to be more performant?

[pit-ray]

The fewer matching targets in win-vind, the better the performance, but I think you cannot feel it.

If you are using EasyClick only, I recommend the uiacachebuild option, which scans the UI asynchronously in advance. However, the time depends on the capabilities of individual computers, so some minor tuning may be necessary.

version tiny
set initmode=i  " It requires = and pass a mode prefix. 

imap <ctrl-space> <easyclick><click_left>  " <easy_click_left> is deprecated

" Scan UI objects asynchronously
set uiacachebuild

" Hold UI cache for 5 sec.
set uiacachebuild_lifetime=5000  

" Generate a cache between 0.5 and 2.0 seconds after the operation stops.
set uiacachebuild_staybegin=500
set uiacachebuild_stayend=2000

Thanks.

[az-pz]

Thank you very much. I can feel a difference when using easy click for the first time in a new window. The hints appear sooner than before.

[Dawid-Deszcz]

Introducing categorize was an excellent idea, it is very helpful to start from "tiny" level when you are a newcomer. One more thing which would be useful for the new people would be to add option ":set showcmd" I used it a lot when I was learning VIM on linux and I think it could also help on win-vind.

[pit-ray]

Thanks for the feature request of showcmd. I received the same request before, but I didn't get around to it. Now, I understand the need for this feature, so I will implement this with high priority. #236

[Dawid-Deszcz]

Thanks a million @pit-ray!!!! Do I understand correctly that now I need to wait for this branch to be merged with master branch, and as soon as it is merged I can intsall new version of win-vind and enjoy ;-) showcmd on my computer?

I am also trying to write a manual for win-vind, I am a strong believer that manuals should be written by new users that way they are more "new-users-friendly". Experienced users often assume that something is obvoius and their manuals might not be as easy to use for new users. When I am done I can send it to you and if you like it you can include it in your tutorials sections. I wanted to add/create some easy to follow video but whenever I record the screen (or make a print-screen) win-vind text is not visible. Is it possible to change it?

Win-vind is a super useful software but I feel that initial learning curve is slightly steep for new users (especially for people who never had contact with vim but would like to use windows without a mouse) ..... and having an easy to follow tutorial might significantly increase the number of daily users. It is quite obvious that win-vind was inspired by vim, but it is very useful for windows users and I strongly believe that it has a potential to be widely adopted also by people who never used VIM and the only thing that is missing is an easy to follow tutorial and I will be happy to make it as a BIG THANK YOU to you for making this wonderful software :-)

[pit-ray]

Do I understand correctly that now I need to wait for this branch to be merged with master branch, and as soon as it is merged I can intsall new version of win-vind and enjoy ;-) showcmd on my computer?

Yes, I will carry out the pull request as my highest priority task. The next version of win-vind will be able to use showcmd.

I am also trying to write a manual for win-vind, I am a strong believer that manuals should be written by new users that way they are more "new-users-friendly". Experienced users often assume that something is obvoius and their manuals might not be as easy to use for new users. When I am done I can send it to you and if you like it you can include it in your tutorials sections.

You can create pull requests for the documentation by refering CONTRIBUTING.md.

I wanted to add/create some easy to follow video but whenever I record the screen (or make a print-screen) win-vind text is not visible. Is it possible to change it?

I have recorded the overlays of win-vind by using NVIDIA Geforce Experience.

If you could send me a pull request to make a tutorial, that would be very helpful.

[pit-ray]

@Dawid-Deszcz
I created a demo of showcmd, which, like Vim, does not display single character commands, only multiple commands such as gg. #236

Please try it out and give me feedback.

win-vind_5.11.3.1_64bit_portable.zip

[pit-ray]

@Dawid-Deszcz
I released this features in the v5.13.