-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement "q:" command #2618
Implement "q:" command #2618
Conversation
I'm sorry I fixed code before receiving a comment. |
src/actions/commands/actions.ts
Outdated
@@ -371,7 +371,7 @@ class CommandInsertRegisterContentInSearchMode extends BaseCommand { | |||
@RegisterAction | |||
class CommandRecordMacro extends BaseCommand { | |||
modes = [ModeName.Normal, ModeName.Visual, ModeName.VisualLine]; | |||
keys = ['q', '<character>']; | |||
keys = [['q', '<alpha>'], ['q', '<number>']]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I supposed we should also allow q"
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing out bugs.
I fix this problem(22aabc8).
I wish I had seen the results of the vim command ":h recording" beforehand
src/cmd_line/commandLine.ts
Outdated
|
||
public save(): void { | ||
const fs = require('fs'); | ||
fs.writeFileSync(this._filePath, JSON.stringify(this._history), 'utf-8'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be asynchronous? I'd prefer to avoid synchronous file calls in general, but in this case, I don't see any advantage to do it synchronously.
Perhaps the other file calls should also be synchronous too, but I don't have a strong opinion on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have an external HDD that takes a while to spin up. It looks like right now history is being written to the extension folder, but if it was ever made per-project, I'm worried these sync calls could cause a ton of lag. No way around it for loading history, but at least for saving, can this be run async at the same time as the command (e.g. don't await it)?
Similarly for load, there's no way around a slow disk read, but will the sync call cause the editor to freeze if loading takes a long time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, if it's made asynchronous, it shouldn't lock up the editor. It won't be able to display until it's done loading, but I don't think that's avoidable. It should only need to load once per VSCode session though.
I'm leaning towards making all the file operations asynchronous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Async please. Especially considering you are reading it from memory on the gets
so there's no reason to block on the file write.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made file operations asynchronous.
0a635c3
Is it too overworked to save the command executed while loading the file?
Oh this is dope! I've thought it was irritating for a while that we couldn't implement |
extension.ts
Outdated
@@ -265,6 +265,8 @@ export async function activate(context: vscode.ExtensionContext) { | |||
} | |||
} | |||
|
|||
CommandLine.SetHistoryDirPath(context.extensionPath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I'm not entirely sure how I feel about this, if only for the selfish reason that it clutters up the development folder.
Nothing wrong with adding it to the .gitignore, but is there a better place to put this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As it's stored using the extension path which should be shared across vscode instances. we would effectively have one global history across workspaces/projects. do we want that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so. That's what vim seems to do, at least.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vim puts. viminfo in the home directory.
If so, is it better to put this history file in your home directory?
e.g. "~/.cmdline_history", "~/.VSCodeVim/.cmdline_history"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My vote is ~/.VSCodeVim/.cmdline_history
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, I set the file location to ~/.VSCodeVim/.cmdline_history.
a59b00a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm mostly concerned about the synchronous file commands.
src/cmd_line/commandLine.ts
Outdated
|
||
public save(): void { | ||
const fs = require('fs'); | ||
fs.writeFileSync(this._filePath, JSON.stringify(this._history), 'utf-8'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, if it's made asynchronous, it shouldn't lock up the editor. It won't be able to display until it's done loading, but I don't think that's avoidable. It should only need to load once per VSCode session though.
I'm leaning towards making all the file operations asynchronous.
src/actions/base.ts
Outdated
@@ -38,6 +38,14 @@ export let compareKeypressSequence = function(one: string[] | string[][], two: s | |||
); | |||
}; | |||
|
|||
const isSingleAlpha = (s: string): boolean => { | |||
if (s.length === 1 && (('a' <= s && s <= 'z') || ('A' <= s && s <= 'Z'))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regex? ^[a-zA-Z]$
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah!.
Should I use regex here?
isSingleNumber does not use regex, so I adapted it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isSingleNumber
could be regex too, but it's a little bit simpler so I'm more ambivalent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd optimize for readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fix it.
1cb61f1
src/cmd_line/commandLine.ts
Outdated
@@ -8,7 +8,75 @@ import * as parser from './parser'; | |||
import * as util from '../util'; | |||
import { VimError, ErrorCode } from '../error'; | |||
|
|||
class CommandLineHistory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you put this in it's own separate file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
e43686d
Thanks @KamikazeZirou! Also, please add tests. |
Thanks for yours comment! |
@jpoon I'm not sure our testing framework allows us to test this kind of stuff. |
@jpoon . I added tests. If there is no further indication, I think that this work is completed |
Thanks for the great work! |
What this PR does / why we need it:
I implemented "q:" command.
Which issue(s) this PR fixes
#2617
Special notes for your reviewer:
This "q:" command slightly differ from original.
Command is not immediately executed when the command is selected from the history.
Instead of executing command, display it on command-line.
Currently, there is no way to edit past commands, so I thought that this kind of action was better.