Feature request: enable key bindings without modifier keys

Mikhail V

please ignore my ignorance but why do you think this is useful?

:-) You can ignore my ignorance too, but it seems that you think that
this is not useful and I know that it is very useful. And you ignoring
many VIM users who after getting used to this ‘unusual’ way are
agreeing that it is simply the better way of doing things.
The main problem here is that most users are not aware of anything else than traditional
“always edit” mode thus not being able to judge it in a non-biased manner.

I am not telling it is always useful, but when you are becoming more proficient with
code editing, this is very handy.
The thing is, code is not like plain text. Code is a restricted structure, imagine
a tree with branches and you need to jump around this tree making various manipulations.
There are a lot of cases when you don’t even need to type text - you need
to jump from one line to another, make line selections, comment, un-comment, move
chunks around, etc, etc. And that is not some ‘magic’ as you say, but it is called frequently
used commands. And there are more and more commands you need when you improve
the editing skills.

As I understand, you have to switch between input mode and normal mode anyway.
So you need another shortcut or button to be pressed two times in addition.

You understand it correctly, and this is how it works :-)

Isn’t the normal way that you type text

There is no ‘normal’ or ‘not normal’ - there are dozens of commands that I
must perform with the source code in a structured manner. Holding modifier
keys to do it becomes simply an annoyance with time.

What do I miss?

You do miss one important thing that I have noted in the request - with an additional
mode (you don’t like the word “normal”, ok let’s call it “navigation” mode?)
you still could use the “edit” mode always, i.e. just never go into “navigation”
mode, which is like it is now. So it should not affect the current behavior in any way.

You know, I can offer you a brain quiz which probably will make the case more clear.
Imagine such a scenario: in some time Notepad++ achieves a nice new feature.
For example the feature that will allow you to efficiently scroll the window contents with the
mouse: you move the mouse and the window scrolls. Sounds good right?
But how would you get into this scroll mode in the first place?
You will say probably, ok we need some key so I hold this key and scroll the
window with the mouse. But do you realize that you literally don’t have any keys
apart from modifier keys under your left hand that you can use for this.

In this sense it is a serious ‘blocker’ for any further usability features.
But I can understand it is not understood from the point of view of regular user.

Mikhail V

@NippurDeLagash said:

Like Claudia and Scott, I do not see the point of adding vi features into Notepad++.

Gentlemen, let’s please keep the conversation constructive and non-biased.
Your personal problems with VIM are not relevant here. I am not asking
about VI plugin, I am adressing concrete issues.
Ergonomics of input is not VIM’s invention, it is just common sense for
any software with heavy input requirements.

Mikhail V

@Scott-Sumner said:

So the OP is asking for this “command versus input mode” as a standard feature (won’t ever happen) but for requests like this, plugins are really where it belongs.

Ok, this is closer the the topic. So does it mean, I can write a Plugin which catches keyboard events and blocking
them from going further? I.e. for a split mode to work, it must catch or pass the events depending on
which mode i am currently in. Probably you can give some examples on plugins with this functionality?

Something like the OP’s desire (or even “WordStar emulation”) is easily achieved in Pythonscript for example.

Pythonscript as I understand can address editor component, but it seems it has nothing to do with catching/redirecting keyboard input on a lower level than the editor. Or am I wrong?

1% features don’t belong in the standard product, and this is a 1% or less feature (meaning useful to very few users).

Let me gently propose not to guess that. Users are such interesting people - you give them a feature,
they use it for some time, then you give them a better feature and they start with that common “we want our bad old feature back”. But probably they will like it? When I was starting with VIM I thought -
what the heck? these stupid modes? But only later I did realize why it is made so.
If I were to make up a new editor I would definitly include at least a navigation mode.

Scott Sumner

@Mikhail-V

If I were to make up a new editor

I think that is a key point. Notepad++ is NOT a NEW editor; and its keymapping model is what it is. I don’t see it changing but I am not a developer on it. :-D

does it mean, I can write a Plugin which catches keyboard events and blocking

Yes.

Pythonscript as I understand can address editor component, but it seems it has nothing to do with catching/redirecting keyboard input on a lower level than the editor.

It is possible to do some amazing low-level things with the PS plugin. When I said “easily achieved in Pythonscript” I meant the base method: getting to keypresses BEFORE Notepad++ itself can act on them–you hook the Notepad++ message loop (using the ctypes functions) so that your Python sees the messages first, look for keyboard related (WM_KEYDOWN, etal) messages, and consume them so that N++ doesn’t see them (or not) in the Python code–and of course do any additional processing necessary for two modes. Beyond that I haven’t thought too much about it as, like I said, such a dual-mode input scheme doesn’t interest me.

And okay, maybe it isn’t “easy” if you haven’t done it or seen it, but there are examples here on this site that serve to demystify it.

Let me gently propose not to guess that. Users are such interesting people - you give them a feature,
they use it for some time, then you give them a better feature and they start with that common “we want our bad old feature back”. But probably they will like it?

I cannot argue…these are valid points. :-)

Good luck with your campaign for this type of input. You are discussing it in a good place, but if you want to really request it your best option is to make a feature request or a change-in-functionality request here: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/ by opening a “New issue”.

Claudia Frank

@Mikhail-V

just to make it clear - my comment was basically a question of understanding and shouldn’t be
taken as an offense.

I still can’t see the benefit, but hey, that’s me, others might find it useful and as Scott already wrote,
make the request at github so the main developer(s) do get noticed and if you are lucky it will
get implemented one day.

Cheers
Claudia

Mikhail V

@Scott-Sumner said:

Good luck with your campaign for this type of input. You are discussing it in a good place

Thanks. I have asked before about this on tracker but did not become any comments, so here at least you gave some good info. Making a plugin (I cannot do it) or fighting for a feature without knowing it is needed by users is no necesary.

I only was a bit confused how it is not clear why such things are useful in general.
Just looking into recent posts here on forum - people who (it seemed to me) like single keys to get to “search next” or “replace” commands in the search dialog and have to switch the context away from text input line (that’s how native widgets define behaviour I suppose). I am always instinctively finding these small tricks to release strain by repeated commands.
This indicates the general idea which I was trying to deliver.

I mean, think of current editing like text area and a side panel with a huge command list, but you can get into the panel with commands only by holding Ctrl.
It is easy in some cases when the right hand is on the keybord (just hold RightCtrl),
but not easy at all when using the mouse+keyboard or repeated commands.

Hmmm. [thoughtfully scratching my beard]

Now I am looking into Autohotkey app, it has capabilities to achieve similar results to what I want. Emulating, say, {Ctrl down} state globally and toggling it, I could warp directly into shortcuts that are defined with Ctrl, so that may work.
I am not sure about that 100 prcent, and how bad side-effects can be, but if it works, it’s a workaround for me.
But thats of course just “simulating” in best case. OTOH it is “for free”, compared to
plugin development.

bycn82 bbbb

as a heavy vi editor user, I think what you described is definitely a brilliant idea about how to improve the input performance. and after inspired by your ideas, i wrote a plugin as you suggested. and it is named vi simulator. please check https://github.com/bycn82/visimulator/

chcg

@bycn82-bbbb Is this related to the old visimulator mentioned at http://docs.notepad-plus-plus.org/index.php/Plugin_Central#V? Or a newly written one?

Mikhail V

@bycn82-bbbb
Hi, thanks for the note.
So I see a dll file on the page. Just to make it clear - is your plugin a configurable tool?
There is no any info, besides a list of commands.
Say I need to switch from normal to edit mode first, and of course I need
a way to bind keys to toggle modes. Then I would start binding keys in normal mode.
But it seems you have all keys hardcoded as in default VIM install?
If so then I can’t make much use of it unfortunately.

bycn82 bbbb

@chcg It is a newly written one, the previous version is lost.

I rewrite a new one because I need to use it with notepad++ x64 version.

type "ESC" 3 times to enable/disable the plugin. after that, it is same as previous version.

Don’t have time to implement all the features, If you have any requirement, please let me know.

chcg

@bycn82-bbbb See further questions ar https://github.com/bycn82/visimulator/issues/1

bycn82 bbbb

@Mikhail-V Configurable? You can only config to keep it or delete it I think.