Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support VIM and/or GVIM (command-line and/or graphical version) #2156

Open
nvaccessAuto opened this issue Mar 8, 2012 · 17 comments
Open

Support VIM and/or GVIM (command-line and/or graphical version) #2156

nvaccessAuto opened this issue Mar 8, 2012 · 17 comments

Comments

@nvaccessAuto
Copy link

Reported by parham on 2012-03-08 07:34
VIM is a very popular programming editor in a lot of communities, and so is GVIM (the graphical interface for VIM). Unfortunately, none of these are properly supported on Windows:

  1. NVDA doesn't recognize anything when using the graphical interface (GVIM).
  2. In the command-line interface, a lot of garbage text is spoken when navigating.

I think these editors can be very appreciated amongst the blind community since they have the features of an IDE, in a purely textual environment that is not bogged down with accessibility problems or high CPU usage.

@nvaccessAuto
Copy link
Author

Comment 1 by jteh (in reply to comment description) on 2012-03-08 08:21
Replying to parham:

  1. NVDA doesn't recognize anything when using the graphical interface (GVIM).

This is covered by #812. In short, proper support for accessibility should be implemented in gvim in order for this to be usefully accessible.

  1. In the command-line interface, a lot of garbage text is spoken when navigating.

Please be more specific. It's just a console application, so NVDA just outputs the text that changes. Implementing specific support for particular console applications is problematic for several reasons, one of which being that when console apps are started from a shell, NVDA doesn't know the name of the app that was started, only the name of the shell.

@nvaccessAuto
Copy link
Author

Comment 2 by parham (in reply to comment 1) on 2012-03-08 09:02
Replying to jteh:

It's just a console application, so NVDA just outputs the text that changes.

This is very true, and is the cause for the garbage text. There is a line at the bottom of the window, giving you information about on which line and column you are. When navigating, these numbers change and produce what (in this context) is not-useful information.

I guess now the question is, is there a way for the user to suppress the reporting of these changes in the bottom line (which is the equivalent of status bar in graphical applications)?

@nvaccessAuto
Copy link
Author

Comment 3 by jteh (in reply to comment 2) on 2012-03-11 23:51
Replying to parham:

is there a way for the user to suppress the reporting of these changes in the bottom line (which is the equivalent of status bar in graphical applications)?

Not at present. However, you could use one of two work arounds for now:

  1. Disable the status bar in vim; or
  2. Disable reporting of dynamic changes while cursoring in vim by pressing NVDA+5.

@nvaccessAuto
Copy link
Author

nvaccessAuto commented Dec 3, 2014

Attachment gvim.py added by lpintes on 2014-12-03 11:49
Description:
An appModule for Gvim.

Edit:
Added attachment from old trac server. (Please rename to gvim.py)
gvim.py.txt

@nvaccessAuto
Copy link
Author

Comment 4 by lpintes (in reply to comment description) on 2014-12-03 12:02
Replying to parham:
I just attached an appModule for gvim.
You need the Gvim version with OLE support. It must be registered.

Things implemented

  • Reading of text area.

  • Reading of command lines including tab completion.

    Known problems

  • Word wrap only works properly when 'linebreak' is not set.

  • Say all stops on the incorrect position when interrupted inside the long wrapped line.

  • Line reading is confusing when tabs are used on wrapped lines.

  • Reading of status line is problematic, displayModel doesn't work well in the Gvim window.

  • ... and obviously many other things, because I am still learning Vim itself.

@bhavyashah
Copy link

@feerrenrut Could we please have the code which was provided as an attachment in #2156 (comment) on Github?

@feerrenrut
Copy link
Contributor

Added the attachment to #2156 (comment)

@Kerneels
Copy link

Kerneels commented Oct 3, 2017

Wow, this is very exciting! I got the gvim.py, and added some beep code (for testing) to fire on transitioning to an open gvim while NVDA is running - just to make sure the AppModule is being loaded by NVDA.

Apart from the beep test code sounding, nothing is spoken when moving the cursor around in gvim, in visual, normal or insert mode save for the keys pressed. What might I be doing wrong?

I do have a proper OLE gvim binary, since it works with my JAWS solution for making gvim accessible. If this could work well, it would be a great alternative to using JAWS to make gvim speak!

I'm in the process of revitalizing my JAWS solution (phonim) and will post a new link here shortly when it is done. Perhaps my use of the gvim OLE interface and commands could be helpful with this AppModule?

@Kerneels
Copy link

Kerneels commented Oct 3, 2017

Hi. In case this might be of any help, please see the atached JFW script that makes GVim work reasonably well.

As soon as I can get to it, I'll revitalize the phonim project, which is a collection of approaches on how to make GVim speak. For now I thought that the use of the Vim commands sent through the OLE connection, as well as the key interpretation might be helpful for a NVDA situation.

I'm trying an NVDA AppModule for GVim, but although the NVDA log shows no errors, nothing is spoken. I suspect the OLE linkup fails, but I'm too inexperienced with NVDA to debug this properly.

The JFW script also relies on a few Vim settings in _vimrc config file, to make GVim more palatable to JFW; not sure how much of that would be relevant for NVDA, but I will have all of that once revitalizing the phonim project happened.
gvim.jss.txt

@Kerneels
Copy link

Kerneels commented Oct 6, 2017

Hi. My suspicion was correct: the OLE linkup fails (see log below).
It seems that this OLE issue was tackled, but it is definately not working now. Any tips/ideas on how to get OLE communication to work: for this application, gvim.exe, OLE works fine from JAWS. Why I'm even exploring this is because the only thing that still ties me to JFW is that I can access gvim with it. If NVDA can work with gvim then I can ditch JFW for good.

ERROR - RPC process 17360 (nvda_slave.exe) (08:22:56.081):
__main__.main:
slave error
Traceback (most recent call last):
  File "nvda_slave.pyw", line 90, in main
  File "comHelper.pyo", line 22, in _lresultFromGetActiveObject
  File "comtypes\client\__init__.pyo", line 180, in GetActiveObject
  File "comtypes\__init__.pyo", line 1165, in GetActiveObject
  File "_ctypes/callproc.c", line 950, in GetResult
WindowsError: [Error -2147221021] Operation unavailable
ERROR - appModuleHandler.fetchAppModule (08:22:56.094):
error in appModule 'gvim'
Traceback (most recent call last):
  File "appModuleHandler.pyo", line 168, in fetchAppModule
  File "C:\Users\Kerneels\AppData\Roaming\nvda\appModules\gvim.py", line 175, in __init__
  File "comHelper.pyo", line 58, in getActiveObject
RuntimeError: Helper process unable to get object; see log for details

@lpintes
Copy link

lpintes commented Oct 6, 2017

Use comHelper.getActiveObject("Vim.Application",True)

@Kerneels
Copy link

Kerneels commented Oct 6, 2017

Hi. If I run NVDA as administrator, the OLE linkup succeeds, but the gvim.py module has other issues which I will attempt to address using my JFW script as reference.

This is very promising! See also NeoVim which might be a better option for future work.

@Adriani90
Copy link
Collaborator

@lpintes are you still working on your helpful app module? You could raise a pull request to be included in NVDA and then you will more probably get also valuable code reviews.

@dpy013
Copy link
Contributor

dpy013 commented Aug 19, 2021

Are currentissues still going on?

@saxomagic
Copy link

I've made a repo with the latest version of my plugin. I'll add to the docs soon. Let me know if it works for any of you - it is extremely helpful for me:
https://github.com/saxomagic/nvdavim

@saxomagic
Copy link

@dpy013 and others, revisiting this here since I really would like NVDA to work better with vim/gvim.
In the latest Windows Terminal application, when running command line vim, NVDA speaks :

  • lines if you use the arrow keys to move the cursor over the line, just like in say Notepad
  • words if you use Ctrl + left/right arrow, just like in say Notepad
  • the line and column position of the cursor is also spoken, but this can be disabled by hiding them using the .vimrc config file for vim

Ideally, in command line vim one would like the speech output to track the cursor movement such that, when you move the cursor one line up or down while in vim normal mode, the line you move over gets spoken, and same thing for chars and words and sentences.
Note that my nvdavim plugin, which is based on the one provided here some years ago, does the above already.
What would be great is if NVDA could be made to track the cursor and respond accordingly as per the plugin, which keeps track of the position and then based on the new position would voice the appropriate text.
For example, if the cursor line position changed then the whole line is voiced, and if the cursor column position change with more than one then voice the current word, else voice the current char.

Currently, NVDA seems to be aware of the cursor position because if I move the cursor to the first line using gg in vim normal mode, and I follow that with NVDA Key + l to voice the current line, then NVDA reads that line.
Same thing if the cursor was moved with the arrow keys, but in that case each line the cursor goes over gets read.

So, I do understand that NVDA cannot be aware of which command line program is running in a terminal, but in general, if terminal support in NVDA could be altered so that the most appropriate text is spoken right after a cursor movement, then no special script for vim would be required, and any other command line editor could also work.

Currently, only moving the cursor with the arrow keys will cause NVDA to speak (also dynamic text changes gets spoken). It does not seem like too big of a challenge. What do you think?

@Adriani90
Copy link
Collaborator

cc: @codeofdusk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants