takikawa / drracket-vim-tool Goto Github PK

I tend to use these a lot in racket :)

If I hit 'r' at the end of a line to replace a character, after the character is replaced, the cursor goes back two spaces in the line.

(This is not a super big issue, because the correct character does get replaced at least.)

Space acts incorrectly under the following two circumstances.

1. If you are on the last character of the last line of the file and press space, the cursor loops around to the first character of that line, rather then doing nothing.
2. If the line is empty and the user presses space, the cursor doesn't do anything, rather than going to the first character of the next line.

In visual mode it takes two l to move one position right initially.

Here I'm using Racket 5.1.1. Running raco pkg install drracket-vim-tool/ as specified on README.md doesn't work. Seems pkg option is removed from raco.

There is a setup option in the usage message of raco which I suspect would be replacement for pkg. But running it returns something more nasty:

collection-path: collection not found: #<path:install> in any of: (#<path:/home/santosh/.racket/5.1.1/collects> #<path:/usr/share/racket/collects>)

 === context ===
cloop
/usr/share/racket/collects/setup/setup-unit.rkt:197:6
/usr/share/racket/collects/racket/private/more-scheme.rkt:390:13: hash-ref!
/usr/share/racket/collects/racket/list.rkt:240:0: filter-map
/usr/share/racket/collects/setup/setup-go.rkt: [running body]
/usr/share/racket/collects/setup/main.rkt: [running body]
/usr/share/racket/collects/raco/main.rkt: [running body]

In command mode, the s-expression that DrRacket highlights is the one to the immediate left of the cursor, rather then the one over the cursor.

When the end user presses space in command mode, the cursor should go to the next character. Additionally, when the end user presses space at the end of a line, it should go to the first character on the next line.

The r command will not replace any capital letters, or any letters that require you to press shift, such as +.

To reproduce: type in any buffer type 'xp'

expected result: the selected character i moved one char to the right

actual result: the selected character is deleted, and whatever is in your copy/paste buffer gets pasted in

Again, I'm not 100% sure if this is vim mode, or just a bug in drracket.

But when I try to type a for loop, I get incorrect indetation

Given the code:

(for ([i (in-range 10)])
  i)

When I hit tab on the second line, the i gets indented as if for was a regular function.

If I have line wrapping for DrRacket enabled, and I hit 'o' on a line that is wrapped to multiple lines (not on the last line of the wrap) to create a new line, it splits the line at the end of the line, and puts the text at the end of the line, rather than putting a new line at the end.

Inside of the repl, the tool returns to the regular DrRacket keybindings, rather then using the vim ones.

If I search for something using '/term', and hit enter, the first 'term' shows up. However, when I hit 'n' it does not go to the next instance of it.

When I disable vim mode, DrRacket fails to return back to it's previous state, and the cursor continues to highlight a single character.

To replicate:

1. Enter Vim mode (if not already in it).
2. Try to leave vim mode.

You see that the key bindings go back to normal, however the cursor still is a block.

I'm not 100% sure if this is due to vim mode, or a bug in DrRacket. However, whenever I put the cursor over a paren the s-expression I surround does not get highlighted.

Furthermore, extraneous closing parens are no longer marked. Thus making it hard to determine when to stop hitting closing paren.

In command mode, V selects line select mode.

However, from there, when I go up, it only selects previous line up to where the text ends, rather then highlighting the entire line.

If you are on an empty line (not at the end of the file) and you press o, it creates a new line, but then places your cursor on the line below the new line, rather than on the new line.

When I install it in my Racket 6.2:

Error invoking tool #path:/Users/user/Library/Racket/6.2/pkgs/drracket-vim-tool;("tool.rkt")

Users/bialy/Library/Racket/6.2/pkgs/drracket-vim-tool/private/text.rkt:181:15: conjoin: unbound identifier in module
in: conjoin

For example, when in visual mode, if I hit 10j, it ignores the the 10, and just goes down one line.

(If I'm not in visual mode it does work fine though...)

In vim, I can make (or open) a new file with :e. Vim mode does not seem to do this.

Lowercase a is currently equivalent to lowecase i. It should append to the current cursor position rather then insert there.

When doing a search (via hitting /), I can hit n to go to the next result, however, when I reach the bottom most result in the file, it does not loop around to the first result in the file.

In vim, I can type a number, say 10, and then hit j, and the cursor will go down by ten lines. This behavior appears to be missing in drracket-vim-tool.

I'm currently using 5.3 version Drracket, when I tried to install your tool, some error occur like below.

Error invoking tool #<path:C:\Program Files\Racket\vim-tool\drracket-vim-tool>;(
"tool.rkt")

C:\Program Files\Racket\vim-tool\drracket-vim-tool\private\text.rkt:78:9: enqueu
e-front!: unbound identifier in module
in: enqueue-front!
channel-put: contract violation
expected: channel?
given: #f
context...:
C:\Program Files\Racket\collects\racket\private\misc.rkt:168:2: channel-put

How can I get it right?

If the first line of your file is an empty line, and you hit dd, then the cursor simply goes to the second line without deleting the first line.

I'm not satisfied with the way that keyboard commands are currently parsed. I'd like to specify commands declaratively, keeping around a table mapping either sequences of keys or regular expressions of keys to procedures.

I can start up vim mode in normal mode but once I go to insert I can't go back - It used to work I'm not sure what changed. I am using Dr. Racket 6.1.1

In vim pressing ctrl-c leaves insert mode. It is an alternative to pressing the escape key. Could that be implemented here? My muscle memory is committed to Ctrl-c!

When hitting the capital J key, the current line, and next line, get appended together on the same line. However, these two line are supposed to be separated by a space.

So for example, hitting J on line one of the following file:

Line 1 Text
Line 2 Text

Should result in:

Line 1 Text Line 2 Text

However, in vim-tool, the space is missing, giving you:

Line 1 TextLine 2 Text

Perhaps it makes sense to make :q close the current tab, like it does in vim.

If I type :a, and then hit escape, and decide I want to type another colon command again, when I hit :, the text that was previously there appears again.

How can I install this plugin on DrRacket 5.2.1?

P.S. I'm a beginner for DrRacket. I also like VIM very much.

In vim, I can move my cursor to a letter, hit r, and then another letter, and the letter under the cursor will be replaced with the letter I just pressed.

This behavior appears to be missing in drracket-vim-tool.

If I past text into vim, the cursor should move to the end of where the paste happened. Currently the cursor stays in the same place after pastes.

If you hit l on an empty line, it goes to the next line (rather then doing nothing, as it should.

Likewise, if you are on the beginning of a line, and hit j, it goes to the previous line, rather then doing nothing, as it should.

If you type :w, and start typing some more text, you cannot backspace further beyond the w.

So, type ':w foo', and keep hitting backspace, and the ':w' will stay there.

When I hit a on an empty line in command mode, the cursor goes to the next line, rather then staying on the same line.

I get the following error when I run dd on an empty file:

kill in text%: bad argument combination: 0 -1 1
context...:
next
/Users/leif/rsrc/drracket-vim-tool/private/text.rkt:309:6: do-delete method in ...ool/private/text.rkt:51:4
/Users/leif/rsrc/drracket-vim-tool/private/text.rkt:144:17
/Users/leif/rsrc/gui/gui-lib/mred/private/wxme/editor-canvas.rkt:457:2: on-char method in editor-canvas%
/Users/leif/racket/racket/collects/racket/private/more-scheme.rkt:148:2: call-with-break-parameterization
/Users/leif/racket/racket/collects/racket/private/more-scheme.rkt:265:2: call-with-exception-handler
/Users/leif/rsrc/gui/gui-lib/mred/private/wx/cocoa/window.rkt:790:4: dispatch-on-char method in window%
/Users/leif/rsrc/gui/gui-lib/mred/private/wx/common/queue.rkt:454:6

I noticed that visual block mode editing is not available as part of this plugin. Is that possible to implement?

This one is a doozy, and I'm not sure what the issue is. So I'll just give you the steps to reproduce it.

1. Start with the following 10 line buffer:

   #lang racket
   
   (define x
     (compile
      #'(begin
          +
          (define + 5)
          +)))
   
   
   

2. Copy lines 3-8 by:
   2a. Starting on line 3, hit V.
   2b. Hit j 5 times.
   2c. Hit y.

3. Go to line 9 and hit p to paste.

Note that the new buffer is:

#lang racket

(define x
  (compile
   #'(begin
       +
       (define + 5)
       +)))
 (define 
  (compile
   #'(begin
       +
       (define + 5)
       +)))

First, note that the second s-expression is magically indented, and note the lack of a second x.

In vim, you can hit y then space to yank a single character. This doesn't work in vim mode.

It would be nice (although not strictly required) to have the cursor go into a single line (rather than a block) when we go into insert mode.

When I hit the capital 'J' to combine lines, it currently always adds a space. While this mostly correct, it is only supposed to do this if there is not already a space as the last character of the line.

If you hit V to use visual line selection, the amount of text that is select only grows and never shrinks.

To replicate:

Hit V to enter visual line mode.
Press j and k to move the cursor up and down.

Each time you hit j or k, one more line should be highlighted.

If I write out a word, and highlight it with the mouse, and hit 'x', it only deletes the first character of the word, rather than the whole word.

If however, I hit v, and then highlight it with the mouse, and hit 'x', it deletes it.

I suspect what the issue here is that highlighting text doesn't enter visual mode, which it likely should. (Unless maybe it's in command mode?)

Note though that highlighting and hitting 'd' does work find though.