[BUG] Arrows not moving cursor properly

[Rudi9719]

Describe the bug Arrow keys aren't moving cursor properly in view?

To Reproduce Steps to reproduce the behavior: On a view with editable text in it

1. view.SetCursor(0,0)
2. view.SetOrigin(0,0)
3. view.MoveCursor(x, y, true) <- x,y being end of text
4. Move cursor using arrows
5. Enter text

Expected behavior Text should be entered under the cursor. It seems like the left and right arrows work properly, however up and down arrows move cursor either left or right by one char rather than up or down.

Screenshots If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: Ubuntu 19.04
• Version go1.13.1

Additional context Trying to pop up a view, clear it of any cruft, populate it with a string, and move the cursor to the end of the string. I tried making a func moveCursorToEnd() to try and move the cursor to the end of a view to get around this, however the func is also causing the same issue https://github.com/Rudi9719/kbtui/tree/bugs/edit-cursor

[mjarkk]

Thanks for reporting this,
I believe there is also another issue when if text is line wrapped and a user start typing on not the first line it also adds chars on the first text line in-staid of the cursor position.

I hope i can find some time this week to fix the issue seems like something important to fix.

[Rudi9719]

That's the same issue I'm having, except I can move where the chars are sent using the arrow keys. But it seems like the up/down arrow keys just do left/right.

Thanks for looking into it!

[mjarkk]

Looked into this yesterday and it seems there is a fix for this build into gocui but it's supper crappy.

Right now when you are typing at the end of a sentence and you reach the end of a line it just insert a new line in-staid of adding a char to the end of the current line. (just star typing something till it line wraps and then resize the window)
But the wired think is when you are not at the end of a sentence it won't do this and thus get this bug where the chars are not places at the cursor it's position.

It seems like the first wired behavior was build as fix for the second one but the solution doesn't seems to work at all.
Tomorrow i have a lot of free time so i'll look into it then and see if i can rework the code so it doesn't have this wired behavior

[mjarkk]

I've put up a pr to fix you issue #48

can you test it on your repo and see if it fixes the issue because the pr has quite a bit of changes and i'm not sure if i may have accidentally have broken something?

[Rudi9719]

Sorry! I didn't see this, give me one sec and I'll build it in

[Rudi9719]

Seems like this doesn't fix the issue we were having with input, it actually makes it a little worse now as we can't scroll horizontally to the part of the string we want to edit.

What it does now is it seems to lock the cursor to a specific point, unless we edit after a newline

[mjarkk]

Thanks for the feedback i'll see if i can fix it.

[mjarkk]

I think it's fixed now, can you try it again?

Also you might already know this but gocui also has a nice view argument called v.Wrap what makes editing inside gocui a bit nicer (at least that's what i think)

[Rudi9719]

I can't seem to pull your branch due to merge conflicts. As for v.Wrap - we have that set to True for the input views, otherwise they will stay on one line at all times and not wordwrap

[mjarkk]

I don't think is a merge conflict,
It's probably because i force pushed to the branch to cleanup the commits.

[Rudi9719]

Still no dice, for some reason the insert is happening at cursorY - 1 instead of cursorY so when the cursor is at (8,1) the insert happens at (8,0) instead of under the cursor. However if I move the cursor to be normalY+1, it inserts at the proper spot - which isn't a part of the previous string and breaks backspace. To get up to the string I have to arrow key up, which then the input jumps back up to cursorY-1. Is there some logic that interferes with when the cursor is at (X,1)? Since it works when Y=2, or if I move up so Y=0. If I manually move the cursor up to Y=0, the input aligns with the cursor. The moment I back down to Y=1, the input still happens at Y=0, if I cursor down again to Y=2, which is out of the string, it prints on the proper line and appends to the string with no newline or space

[mjarkk]

Can you maybe provide a working go file with the problem,
I just can't get the problem locally.

[Rudi9719]

I'm not sure how to, it's the same project as last time https://github.com/Rudi9719/kbtui - the exact code that is being run is

func moveCursorToEnd(viewName string) {
    g.Update(func(g *gocui.Gui) error {
        inputView, err := g.View(viewName)
        if err != nil {
            return err
        }
        inputString, _ := getInputString(viewName)
        stringLen := len(inputString)
        maxX, _ := inputView.Size()
        x := stringLen % maxX
        y := stringLen / maxX
        inputView.SetCursor(0, 0)
        inputView.SetOrigin(0, 0)
        inputView.MoveCursor(x, y, true)
        return nil

    })
}

[mjarkk]

Can you try this:

func moveCursorToEnd(viewName string) {
    g.Update(func(g *gocui.Gui) error {
        inputView, err := g.View(viewName)
        if err != nil {
            return err
        }

        inputView.SetCursor(0, 0)
        inputView.SetOrigin(0, 0)

        lines := v.ViewBufferLines()
        x := len(lines[len(lines)-1])
        y := len(lines)-1

        // If this gives a compile error you don't have the latest changes  
        inputView.MoveCursor(x, y) 

        return nil
    })
}

[Rudi9719]

That causes some interesting behavior, now it flat out ignores up and down unless there are newlines, so navigating a string works however there is no way to jump up or down at all

[mjarkk]

This is how an editor should behave right?
Or did you want to move the cursor to the most bottom off the view and start editing there even if there is no text there at all?

[Rudi9719]

Yes and no, this fixes the issue by removing the ability to cause it in the first place. Most editors allow you to (like here in github you can test this in a comment) just hit the up arrow to go to the line above. Before the fix, you could do that however the insert wasn't happening at the cursor. Now the insert does always happen at the cursor, at the loss of being able to use the up and down arrows. Either way, it works now :)

[mjarkk]

Ah yes i think i see what you mean..

If for example this is the text:

A long string with lots of chars, that is line wrapped

And this is on screen:

|A long string with lot|
|s of chars, that is li|
|ne wrapped|           |

If the cursor is | and you press up nothing happens.
I've left this behavior in the code on purpose because i don't think it's logic to go from a line to the same line and beside that most text editors do the same thing when line wrapping is on.