LustyJuggler dumps all my key maps when started

[christfo]

so I'm having an issue that arrived at the following version:
be929b3

I'm not fully understanding what is occurring, but maybe there is a 'map' command that is being run on juggler start that isn't silent?

This results in a page of text being dumped to the console, with detail of all the home row key mappings. Unfortunately this is more than my buffer height, so I need to press an additional space or q key to page it out of the way before I can get to the juggle window.

I can't rule out some interaction with other plugins, but any insight would be welcome since this is otherwise one of my favourite plugins.
Many Thanks,
Chris.

[sjbach]

Thanks for the report. Any chance you could send a screenshot? Does the output look the same as what you see when you run :map at the Vim command line?

[christfo]

Thanks for the response.

the text from lusty is (for example):

which is a subset of my mappings, for example :map a is:

The full list from juggler comprises of the home row keys, then 0,,v,b and i. Once I page it away (space), the normal juggler appears as before.

One other point of interest is if I quit (q) instead, I can get to a place where Lusty Juggler does not start at all:

undefined method `%' for nil:NilClass                                                                                                         
(eval):328:in `run'                                                                                                                           
(eval):1:in `block in <main>'                                                                                                                 
(eval):251:in `profile'                                                                                                                       
(eval):1:in `<main>'  

I should also mention that I am getting this behaviour across several machines, both ubuntu and osx, so it is likely something in my vimrc / plugin interaction (my dotfiles on my github if you are truly curious, but they're not pretty)

[jcelliott]

I've been seeing this same issue. I haven't noticed a pattern of when it happens, but when it does the only way to fix it is to quit and restart vim. Next time I see it I'll try to do some investigation.

[MatthewChang]

I just tried setting up LustyJuggler for the first time and this is happening for me every time. My symptoms may be slightly different from christfo's as I have mappings for non-homerow keys showing up as well. But it's certainly not the entire :map output. I'm running on neovim 0.1.7 if it matters. Attached is a screen of the dump that I get when I launch :LustyExplorer

[sjbach]

Thanks Matthew. I wonder if you'd be willing to send me your .vimrc and .vim directory? That would probably help me diagnose the bug.

[mtrudel]

I can verify that this occurs with a functionally empty vimrc (just pathogen loader bits) and no other plugins installed.

I'm running macos 10.13.1, and this occurs on both system vim and homebrew vim (both 8.0, but different patchlevels)

https://github.com/mtrudel/lusty is a fork of this repo with be929b3 reverted, and the error doesn't occur there.

The issue still occurs even with that particular commit reverted; I was mistaken.

[sjbach]

Thanks. I'm still unable to reproduce on a platform/config similar to yours. Maybe next time this shows up, someone could try adding the following line just before this line:

LustyJ::d("restore_cmd: [[#{restore_cmd}]]")

And the following line just before this line:

LustyJ::d("redir => s:needs_script | #{mode}map #{key} | redir END")

And then report back what gets output to stderr. Seems probable the bug is here, but it's sly.

[mtrudel]

Super. I'll work this into my private branch and report back.

FWIW, I've had zero occurrences of the issue since switching to a fork that reverts the commit in question (master...mtrudel:master is the relevant diff). Before I would get the flash on almost every invocation of the buffer juggler and that diff looks pretty benign so yeah, sly's the word.

[mtrudel]

Done. Screenshot is also attached in case you wanted to see it in context

   76   end    * "_ddrestore_cmd: [[nnoremap d "_d]]
   77 end                                           redir => s:needs_script | smap     redir END
+  78
+  79          * "_d
+  80          * "_ddrestore_cmd: [[snoremap d "_d]]
+  81                                               redir => s:needs_script | xmap     redir END
+  82
+  83          * "_d
+  84          * "_ddrestore_cmd: [[xnoremap d "_d]]
+  85                                               redir => s:needs_script | omap     redir END
+  86
+  87          * "_d
+  88          * "_ddrestore_cmd: [[onoremap d "_d]]
+  89                                               redir => s:needs_script | nmap     redir END
+  90
  ~;             :restore_cmd: [[nmap ; :]]
  ~                                        redir => s:needs_script | nmap <Tab> | redir END
  ~
  ~<Tab>         irestore_cmd: [[nmap <Tab> i]]
  ~                                            redir => s:needs_script | imap <Tab> | redir END
  ~
  ~<Tab>         <Plug>SuperTabForwardrestore_cmd: [[imap <Tab> <Plug>SuperTabForward]]
  ~                                                                                    redir => s:needs_scrip  ~ nmap c | redir END
  ~
  ~c           * "_crestore_cmd: [[nnoremap c "_c]]
  ~                                                redir => s:needs_script | smap c | redir END
  ~
 VISUAL   13 ~0 -0   <ore_cmd: [[snoremap c "_c]]                     100% ☰   90/90  :  1 
activity_collection_helpers.ex|test.exs

[sjbach]

Thanks for the text and the screenshot.

The output's a little tricky as it interleaves/overwrites the editor's anatomy, but it looks like what's happening is the VIM::command in the needs_script? function is returning multiple mappings for the key argument rather than just a single mapping. I don't think that's ever intended. Then, because :redir echoes its output to the screen in addition to writing it to a variable (which seems like a strange default to me, but that's Vim for you), it looks screwy when there are multiple mappings.

So, maybe two bugs:

1. The key that the plugin provides to needs_script? is somehow not correct here; your output shows it as redir => s:needs_script | nmap redir END, (i.e. spaces) when it's supposed to have been redir => s:needs_script | nmap d redir END (i.e. d, I think, based on context). The former prints a bunch of mappings, the latter would print only one.
2. The :redir screen output should probably be suppressed. :help suggests an ugly workaround:
   To stop the messages and commands from being echoed to the screen, put the commands in a function and call it with ":silent call Function()".

But, I don't think (2) should be fixed until (1) is fixed, because (2) will probably prevent (1) from exhibiting. I still don't understand how (1) is happening, if that is what's happening.

Maybe @jszakmeister, the author of be929b3, has a thought.

[jszakmeister]

@sjbach do you know what the value of key being passed to map_key() is? Looking at the output above, it looks like the value of key is being lost. Perhaps it's a bindings issue or something else along those lines? Or it could be that a literal space character is getting passed in, in which case we probably need to escape it. Also, if there is a nested mapping, something like <space><space> and <space>a, then both will be listed--so that could be a problem too. One thing I'm not quite understanding is if we received more output than expected, how would that be a problem? needs_script? on returns true or false, not any actual content.

It could be that there is a better way to detect the issue these days, but I'm not seeing it. maparg() is certainly more capable than it used to be, but even the dictionary form doesn't return the required bit of information.

Sorry I couldn't be of more help... it's been a long time since I've looked at this problem. :-)

[sjbach]

Thanks @jszakmeister for taking a look. I think the issue with receiving more output than expected is that it splashes into the editor, which is distracting. We can work around that.

I'm still unable to reproduce, though. @mtrudel, would you be willing to send me the :*map bindings of your Vim config? I know you noted earlier that you can surface the bug with a functionally empty .vimrc, but I can't, so the bindings are my only lead. :-)

[mtrudel]

My vim config is public: https://github.com/mtrudel/vimfiles (note the use of mtrudel/lusty in lieu of yours).

In terms of vim version, it's sourced from my dotfiles: https://github.com/mtrudel/dotfiles, which reduces down to brew install vim --with-override-system-vi.

[sjbach]

Cool, thanks for the pointer.

The mappings from your config that surface the output splash are these:

• noremap d "_d from your .vimrc;
• <Tab> to <Plug>SuperTabForward from ervandew/supertab;
• <BS> to "-d from netrw (I think);

These are also the mappings for which needs_script? is called, i.e. they're pre-existing mappings that LustyJuggler wants to temporarily remap. Makes sense.

None of these mappings individually cause Vim to output multiple lines in the redir call in needs_script? as I supposed in an earlier comment. Instead, I guess it's that since all of the redir calls happen at almost the same time, Vim (or some versions of Vim) treats the individual lines as a single multi-line output rather than interspersing wipes of the message area.

The suggested workaround is to wrap the redir call in a custom Vim function, called with :silent. Commit incoming.

[mtrudel]

Works here too! Thanks for the work!

[sjbach]

Glad to hear it. :-) Thanks for the help.

[christfo]

+1 - back on master again.
Thanks for all your help!