Visual mode doesn't work on text objects (vim)

[Hi-Angel]

As title says… When I press "v" in normal mode (vim keymap), it immediately starts selection instead of waiting for a text object.

I'm sorry, I actually didn't want to report a bug, I tried to fix it for getting more familiar with the code, and I even wrote some code for Operators.hs. But the problem is that I stuck on removing the old keybinding. I grepped all over the code for "v",'v', and even a regexp ".*v.*", I removed everything seemingly relevant; however after compilation "v" starts selection again and again.

How do I remove that old keybinding? I asked on IRC, but nobody seem to know anything. I also tried asking on mailing list one or two days ago, but my mails for some reason didn't appear there.

[jhance]

Are you using dyre?

If so, did you remember to remove your cached yi binary? If you don't remove it, and you don't change your config, all your changes have no effect.

Sorry, I'm not often on IRC and I should be on it more.

Btw, the old binding is in NormalModeMap.hs, specifically

    , ("v", enableVisualE Inclusive, resetCount . switchMode (Visual Inclusive))

That said I don't think I understand what the bug is here, I can't seem to get different behavior between vim and yi for pressing v. Vim also immediately starts selection.

[noughtmare]

Yi is lacking the ability to select text objects (in visual mode).

Edit: TextObjects are already implemented in Yi.Keymap.Vim.TextObject, but it is only used in NormalOperatorPendingMap.hs. I guess we also need to add them to visual mode.

[Hi-Angel]

@jhance is it ~/.cache/yi/yi-linux-x86_64? I didn't because after every rebuild I see a message about recompilation of it anyway. Anyway, I just removed it, it was recompiled, and "v" still starts selection.

[Hi-Angel]

@noughtmare I already found how to do it, it's pretty easy. There's a file Operator.hs, it have commands to work specifically on text objects, e.g. "d", "c", etc. It's just have to be added there.

Specifically, those commands simply accept a region (which is a text object here), and working on it. So I have just to write a function working on a region, and probably to add it somewhere besides the file.

I already wrote the code :Ь But I stuck on the silliest stage: I just can't remove that old keybinding! (and no, it's not the code I wrote triggering, I commented it out yet).

[noughtmare]

The issue is probably that you're not using your custom yi project in your configuration.

How do you install your customized yi project, do you use stack or cabal?

Is your configuration (~/.config/yi) inside a stack or cabal sandbox (or neither)?

[Hi-Angel]

@noughtmare I have only a single Yi source code, cloned from here. To build it I use cabal build, then running the resulting executable from the dist/build/yi/yi directory. I did use stack for experimenting in the office, but here I don't even have it installed.

[Hi-Angel]

@noughtmare perhaps you misunderstood me: I don't want to remove that old keybinding from the ~/.config/yi/yi.hs, I'm trying to remove it from the source code of the editor. I.e. I'm trying to fix visual mode to work on text objects, and as a part of that I have to remove the old keybinding, which I didn't manage to do yet.

[noughtmare]

When you launch yi, it checks if your configuration has changed and recompiles the configuration if necessary. The configuration will use the (systemwide) installed version of yi when recompiling (so it won't use your custom yi). To make your yi configuration use your custom yi, you have to run cabal install (I mainly use stack so this might be wrong) in your custom project to install it systemwide.

I like to use stack, because you can explicitly say which yi you want to use (cabal also has some other issues). I can't easily explain how to get yi working with stack, but we're working on simplifying the installation and configuration process (so even if I would explain it now it will probably change soon).

[Hi-Angel]

Wow, you're right! After cabal install and removing the ~/.cache/yi/yi-linux-x86_64 once again, selection disappeared! So, I fixed the problem with ln -s ~/.cabal/bin/ dist/build/yi ^^

Yeah, I know about cabal hell issue which led to stack creation, but with regard to Haskell in closest time I'm planning to work only with Yi to set it in more or less usable state to replace my Emacs+Evil before moving on. So cabal hell hardly would be a problem, at least not very soon.

[Hi-Angel]

Turned out I was wrong — ln -s didn't do the trick because there're other dirs, besides binaries. And as cabal install more time consuming than stack install, I switched to stack.

I'm wondering: can I build yi for profiling without installing profiling libs (i'm not interested in anything besides Yi)? It's that I'm stuck: method switchModeE $ Visual Inclusive works different for me than it does here (specifically, though it changes mode name, but visual selection doesn't appear). So I thought, perhaps something executed higher the stack changes the behavior there. I wanted to look at stacktrace, and that's why I need to compile with profiling support. But, adding -prof option triggers stack's complaints about libraries not built for profiling.

[noughtmare]

We have profiling instructions, but I don't know if they're up to date. I have never really done Haskell profiling, so I can't help you with that.

I think you also need to enableVisualE to start the selection. I don't know why it's not exported, but here's the source.

[jhance]

I believe those profile instructions were up to date, at least prior to the split packages.

You cannot install Yi for profiling without the profiling libs, because we execute code in those libs and thus they have to be profiled :)

And noughtmare is correct on the mode switching, because switchModeE is a low-level primitive I believe it only changes the internal state that tells the vim keymap what mode we are in, and does nothing else. (We should probably have a helper thing that "does the right thing" at a high-level, combining both switchModeE and enableVisualE for e.g. visual mode)

[Hi-Angel]

Yay, thank you very much, it works now!

I have a question though. I'm afraid whether removing this line would break anything; does anybody know, what the parseOperand function does?

I see that it referenced in textObject function, but neither parseOperand, nor textObject enlightens me for what they're used for. I mean, I know what "text object" is, but operations to work with text objects are in the other module (Operator.hs).

EDIT: in fact, I don't know where the function creating text object is defined. But textObject doesn't seem to be relevant, because it doesn't return a region.

[Hi-Angel]

Shall I make a separate file for sole purpose of enableVisualE function? It can not be exported from where it is now, because Module imports form a cycle, as ghc says. I tried also to move it into VisualMap.hs, but then Module imports form a cycle for Operator.hs file. I don't see an appropriate place besides those two files.

[jhance]

SGTM

I have to admit i dont know what a text object actually is...

[Hi-Angel]

In fact it is possible to just copy the function into Operator.hs (that's what I did to check that it worked), but I think that would be wrong.

[jhance]

No copy pasterino

[jhance]

Btw can you confirm to me what the bug is? In vim if I press v it immediately enters election and then I can press e.g. w to select a word.

[Hi-Angel]

Yes. And if you press vi( inside braces, it would select everything inside braces, while Yi didn't (it will now ^^).

Sorry, I gtg now.

[Hi-Angel]

Btw, vw selects not quite a word, it select everything from the point till the beginning of the next word. To select word at point in vim you have to press viw (which didn't work in Yi either).

[jhance]

Ok I see.

So it shouldn't affect the transition to visual mode then right? It should just be the i(

[Hi-Angel]

I'm not sure I understood you, but I just made it an operator, like d or c is, i.e. it simply accepts a region, enables visual selection, and stretches the selection to the region.

From what I tested it seems to work exactly as should.

[noughtmare]

@Hi-Angel viw is just a combination of two commands: v to switch to visual mode and iw to select the 'inner word' text object. The reason that it doesn't work in Yi is that Yi doesn't have the ability to select text objects in visual mode.

@jhance this site explains text objects pretty well.

[Hi-Angel]

@noughtmare oh, you're right! I didn't know that visual selection allows to enter iw more and more, i.e. I thought it is accepted only just after the switch.

Then, probably, I should fix it the other way than I did now. I ought to leave keybindings as is (in particular there's nothing to add to Operator.hs), and to look at the keybindings for visual mode.

[jhance]

Yes, this is why I was confused

[Hi-Angel]

Oh, it is so confusing… ☹ I spent a few hours wading through the code, and so far I come up with this: there's a parseOperand (which calls parseCommand) function which seem to have the magic of choosing a text object, but it seems needs to be called a few times in a row, somehow transformating the return type into its argument.

There's also textObject function, which seem to do the magic of calling parseOperand the right way™, but it is very big, it does a bunch of things, and its type from a list of operators to a single binding makes me completely lost.

I should thank peoples though, who set comments all over the code — without them I'd spend a few hours in the code.

I'm stuck :(

[Hi-Angel]

Oh, I declare the breaktrough, I have to try to work with stringToTextObject! I looked at it before, but probably at some point gone to see how it is used, and stuck.

[ethercrow]

@Hi-Angel: yes, stringToTextObject is helpful there. I've got viw to work here 610989e but it still needs work because vim can also handle counted text objects like v3iw

[Hi-Angel]

@ethercrow I don't understand, where it is committed? E.g. when I look the MatchResult.hs, I didn't see the committed changes. And your fork didn't have them either.

[noughtmare]

He pushed them to the visual-text-objects branch. MatchResult.hs for example is: https://github.com/yi-editor/yi/blob/visual-text-objects/src/library/Yi/Keymap/Vim/MatchResult.hs

This is the diff of his commit: 610989e

[Hi-Angel]

I have a question. I can't seem to get to work trace with Yi. E.g. I feel like an actual count to a function is actually never passed, so I'm trying to print its value with trace. But I doesn't see an output of trace anywhere :/ The code with trace definitely get executed, because if I hardcode the count to a number, the behavior changes.

[Hi-Angel]

Aha… I seem to find that… The output appears in the "messages" buffer. But I didn't see it, because every time new output appears (and it does appear very often), it overwrites the output of trace. So the only way to see that output, is to trigger trace while in that buffer, because one more action, and it would disappear.

Is it a bug, or do I do something wrong?

[ethercrow]

When I'm working on vim keymap, my usual debugging tools are stack test --file-watch and insertN "this should not happen".

[Hi-Angel]

@ethercrow well, stack test is useful to check that nothing broke, but if something did break, it is often useful to peek at particular values for runtime.

Anyway, while I'm figuring out how to get this branch into my fork (btw, I figured it out that I should've used fromMaybe ☺, don't say that), I'd like to bring up a question: is there a particular reason, why vsCount is a Maybe Int? I mean, Nothing is the same as 1, should we perhaps make it just a Int instead?

[noughtmare]

@Hi-Angel the insertN "your runtime error message here" is the command that @ethercrow uses to do his runtime debugging (with the vim keymap).

If vsCount was just an Int the mkDigitBinding function would not function properly anymore, because it wouldn't be able to tell if a digit has already been entered.

[Hi-Angel]

Fixed.