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

[RFC] Add vimexpect library and example gdb plugin #2314

Merged
merged 4 commits into from Apr 2, 2015

Conversation

Projects
None yet
7 participants
@tarruda
Member

tarruda commented Mar 31, 2015

This library makes it easier to script communication with interactive programs. It is similar to what the "expect" tcl extension does, but uses an object oriented API and is designed to integrate nicely with Neovim job control.

@marvim marvim added the RFC label Mar 31, 2015

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Mar 31, 2015

Member

What about publishing the plugin "standalone", e.g. in tarruda/nvim-gdb?

Member

fwalch commented Mar 31, 2015

What about publishing the plugin "standalone", e.g. in tarruda/nvim-gdb?

@philix

This comment has been minimized.

Show comment
Hide comment
@philix

philix Mar 31, 2015

Member

What about publishing the plugin "standalone", e.g. in tarruda/nvim-gdb?

+1 for that even though having a GDB plugin builtin would be nice.

Member

philix commented Mar 31, 2015

What about publishing the plugin "standalone", e.g. in tarruda/nvim-gdb?

+1 for that even though having a GDB plugin builtin would be nice.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 31, 2015

Or maybe just under neovim/nvim-gdb?

ghost commented Mar 31, 2015

Or maybe just under neovim/nvim-gdb?

@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Apr 1, 2015

Member

What about publishing the plugin "standalone", e.g. in tarruda/nvim-gdb?

I think Neovim still needs one extra feature before a debugger plugin can be polished enough for general use: mappings local to window and/or tabpage(That way the debugger shortcuts can be activated only in the "debugging view").

Plus this one is more a proof of concept, and the name is a bit misleading: It's not a generic gdb plugin for Neovim, but a gdb plugin specifically created for developing Neovim. Take :GdbDebugTest [string] for example, it will use [string] to filter tests using busted --filter option(this certainly doesn't apply to other C projects)

Member

tarruda commented Apr 1, 2015

What about publishing the plugin "standalone", e.g. in tarruda/nvim-gdb?

I think Neovim still needs one extra feature before a debugger plugin can be polished enough for general use: mappings local to window and/or tabpage(That way the debugger shortcuts can be activated only in the "debugging view").

Plus this one is more a proof of concept, and the name is a bit misleading: It's not a generic gdb plugin for Neovim, but a gdb plugin specifically created for developing Neovim. Take :GdbDebugTest [string] for example, it will use [string] to filter tests using busted --filter option(this certainly doesn't apply to other C projects)

Show outdated Hide outdated runtime/autoload/vimexpect.vim Outdated

tarruda added some commits Apr 2, 2015

eval: Add internal_refcount field to dict_T
Due to the way vimscript garbage collection handles cyclic references, its not
possible to rely on incrementing `dv_refcount` to prevent dicts still used
internally from being collected: If a object with dv_refcount > 0 isn't
reachable by vimscript code, it will be freed when `garbage_collect()` is
called. Add the `internal_refcount` field to prevent this.
eval: Ensure all job callbacks are invoked by `jobwait()`
A call to `event_poll` is required to ensure the exit callback from the last job
is invoked.
test: Remove indeterminism from `jobwait` tests
- Use on_exit instead of on_stdout since there's no guarantee that the OS will
  send the data in time(It fails randomly in slow environments such as
  travis/valgrind)
- Increase the timeout gap for the "jobwait with timeout" test
runtime: Add vimexpect library and example gdb plugin
This library makes it easier to script communication with interactive programs.
It is similar to what the "expect" tcl extension does, but uses an object
oriented API and is designed to integrate nicely with Neovim job control.

@tarruda tarruda merged commit 617878f into neovim:master Apr 2, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jszakmeister jszakmeister removed the RFC label Apr 2, 2015

@tarruda tarruda referenced this pull request Apr 2, 2015

Merged

Upcoming Newsletter #82

22 of 22 tasks complete

@justinmk justinmk added the tests label Apr 2, 2015

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Apr 2, 2015

Member

mappings local to window and/or tabpage

@tarruda What's wrong with buffer-local mappings? (nnoremap <buffer> foo ...) I was also wondering why :tnoremap is needed instead of using buffer-local mappings.

Member

justinmk commented Apr 2, 2015

mappings local to window and/or tabpage

@tarruda What's wrong with buffer-local mappings? (nnoremap <buffer> foo ...) I was also wondering why :tnoremap is needed instead of using buffer-local mappings.

@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Apr 2, 2015

Member

@justinmk Tab or window mappings would simplify the creation of debugger-specific mappings(continue, interrupt, step...) that are only active in the debugging tab.

tnoremap is used to enable the mappings even when the gdbclient terminal is focused

Member

tarruda commented Apr 2, 2015

@justinmk Tab or window mappings would simplify the creation of debugger-specific mappings(continue, interrupt, step...) that are only active in the debugging tab.

tnoremap is used to enable the mappings even when the gdbclient terminal is focused

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Apr 2, 2015

Contributor

@justinmk tnoremap is for terminal mode. It is needed because terminal mode has a great majority of differences with insert mode (e.g. you can’t move cursor using <C-o>h). Tabpage-local mappings have sense if you understand the idea of tab pages as workspaces with different purpose. Do not know why window-local mappings may be needed.

Contributor

ZyX-I commented Apr 2, 2015

@justinmk tnoremap is for terminal mode. It is needed because terminal mode has a great majority of differences with insert mode (e.g. you can’t move cursor using <C-o>h). Tabpage-local mappings have sense if you understand the idea of tab pages as workspaces with different purpose. Do not know why window-local mappings may be needed.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Apr 2, 2015

Member

Tab or window mappings would simplify the creation of debugger-specific mappings(continue, interrupt, step...) that are only active in the debugging tab

So the idea is that "debug mode" would be enabled in one tab, but not globally. I don't see why global mappings for debug mode would be a problem though (which are removed after debug mode is done). Maybe what we really need is a way for global (and buffer-local) mappings to temporarily mask global/buffer mappings and then restore the original mappings reliably after the mode is exited.

Tabpage-local mappings have sense if you understand the idea of tab pages as workspaces with different purpose.

If I load a buffer into such a tabpage, what happens with the buffer's FileType/ftplugin which sets up buffer-local mappings? This is a lot of cognitive overheard for the user.

Member

justinmk commented Apr 2, 2015

Tab or window mappings would simplify the creation of debugger-specific mappings(continue, interrupt, step...) that are only active in the debugging tab

So the idea is that "debug mode" would be enabled in one tab, but not globally. I don't see why global mappings for debug mode would be a problem though (which are removed after debug mode is done). Maybe what we really need is a way for global (and buffer-local) mappings to temporarily mask global/buffer mappings and then restore the original mappings reliably after the mode is exited.

Tabpage-local mappings have sense if you understand the idea of tab pages as workspaces with different purpose.

If I load a buffer into such a tabpage, what happens with the buffer's FileType/ftplugin which sets up buffer-local mappings? This is a lot of cognitive overheard for the user.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Apr 2, 2015

Contributor

If I load a buffer into such a tabpage, what happens with the buffer's FileType/ftplugin which sets up buffer-local mappings? This is a lot of cognitive overheard for the user.

Why do you think something should happen? Vim lived with two tables with mappings for years, adding third table should not make any difference. If code was sane enough to just iterate over tables in place of doing “loop unroll” manually that would even be trivial to implement.

I do not think there is much additional overhead to what is already there because of buffer-local mappings. I do not see much difference between “filetype is X” condition and “tabpage is Y” (as long as they are indicated properly).

Contributor

ZyX-I commented Apr 2, 2015

If I load a buffer into such a tabpage, what happens with the buffer's FileType/ftplugin which sets up buffer-local mappings? This is a lot of cognitive overheard for the user.

Why do you think something should happen? Vim lived with two tables with mappings for years, adding third table should not make any difference. If code was sane enough to just iterate over tables in place of doing “loop unroll” manually that would even be trivial to implement.

I do not think there is much additional overhead to what is already there because of buffer-local mappings. I do not see much difference between “filetype is X” condition and “tabpage is Y” (as long as they are indicated properly).

@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Apr 2, 2015

Member

So the idea is that "debug mode" would be enabled in one tab, but not globally. I don't see why global mappings for debug mode would be a problem though (which are removed after debug mode is done).

While this is possible, it makes things more complicated and error-prone for plugins which will repeat code for saving/restoring mappings. Not to mention it won't handle more complicated scenarios like this one:

  • plugin x opens a tabpage with custom mappings.
  • plugin y opens a tabpage with custom mappings while plugin x tabpage is active.
  • plugin x closes its tabpage, restoring user mappings.
  • plugin y closes its tabpages, but it will restore plugin x mappings(breaks user mappings).

With tab-local mappings this is greatly simplified because everything is handled by the mapping engine automatically.

Maybe what we really need is a way for global (and buffer-local) mappings to temporarily mask global/buffer mappings and then restore the original mappings reliably after the mode is exited.

Its another way to handle the problem, but still more complicated than tab-local mappings that have a predefined scope.

If I load a buffer into such a tabpage, what happens with the buffer's FileType/ftplugin which sets up buffer-local mappings? This is a lot of cognitive overheard for the user.

First search buffer, then tab, then global mappings.

Member

tarruda commented Apr 2, 2015

So the idea is that "debug mode" would be enabled in one tab, but not globally. I don't see why global mappings for debug mode would be a problem though (which are removed after debug mode is done).

While this is possible, it makes things more complicated and error-prone for plugins which will repeat code for saving/restoring mappings. Not to mention it won't handle more complicated scenarios like this one:

  • plugin x opens a tabpage with custom mappings.
  • plugin y opens a tabpage with custom mappings while plugin x tabpage is active.
  • plugin x closes its tabpage, restoring user mappings.
  • plugin y closes its tabpages, but it will restore plugin x mappings(breaks user mappings).

With tab-local mappings this is greatly simplified because everything is handled by the mapping engine automatically.

Maybe what we really need is a way for global (and buffer-local) mappings to temporarily mask global/buffer mappings and then restore the original mappings reliably after the mode is exited.

Its another way to handle the problem, but still more complicated than tab-local mappings that have a predefined scope.

If I load a buffer into such a tabpage, what happens with the buffer's FileType/ftplugin which sets up buffer-local mappings? This is a lot of cognitive overheard for the user.

First search buffer, then tab, then global mappings.

jdavis referenced this pull request in jdavis/neovim.github.io Apr 4, 2015

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Nov 3, 2015

Contributor

This looks like an ugly (and unneeded!) hack: you save those dictionaries in TerminalJobData structure, which is referenced through jobs static variable, and you can use it to set proper copyID.

Contributor

ZyX-I commented on 2b7f460 Nov 3, 2015

This looks like an ugly (and unneeded!) hack: you save those dictionaries in TerminalJobData structure, which is referenced through jobs static variable, and you can use it to set proper copyID.

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