Comments (17)
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
fromervandew/supertab
;<BS>
to"-d
fromnetrw
(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.
from lusty.
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?
from lusty.
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)
from lusty.
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.
from lusty.
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
from lusty.
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.
from lusty.
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.
from lusty.
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.
from lusty.
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.
from lusty.
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
from lusty.
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:
- The key that the plugin provides to
needs_script?
is somehow not correct here; your output shows it asredir => s:needs_script | nmap redir END
, (i.e. spaces) when it's supposed to have beenredir => 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. - 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.
from lusty.
@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. :-)
from lusty.
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. :-)
from lusty.
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
.
from lusty.
Works here too! Thanks for the work!
from lusty.
Glad to hear it. :-) Thanks for the help.
from lusty.
+1 - back on master again.
Thanks for all your help!
from lusty.
Related Issues (20)
- LustyBufferGrep does not load all buffers HOT 2
- needs_script is slow sometimes (in MacVim?) HOT 1
- cannot load such file -- rubygems.rb vim (7.4.979) (OSX) HOT 6
- Encoding issue HOT 10
- ::Fixnum is deprecated HOT 3
- ruby incompatible library HOT 1
- Ruby not detected HOT 4
- unkown encoding name - latin1 HOT 3
- bignum too big to convert into `long' (MacVim) HOT 2
- OSX Mountain Lion 10.8.1 Abort trap: 6 / __stack_chk_fail error HOT 2
- Error on switching buffers HOT 3
- Allow listing of not-yet-loaded buffers HOT 1
- Problems using if : is remapped HOT 1
- problem when the file path has spaces HOT 1
- Problem with files of the same name HOT 5
- LustyExplorer stays open, clobbers buffer, unable to quit vim w/stacktrace HOT 7
- Screenshot please? HOT 1
- Setting notimeout makes keys d and g malfunction.
- 'No other buffers' when there is only one listed buffer
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lusty.