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

[RFC] Remove "easy" mode. #1656

Merged
merged 1 commit into from Jan 21, 2015

Conversation

Projects
None yet
5 participants
@fmoralesc
Contributor

fmoralesc commented Dec 12, 2014

This removes vim's "easy" mode, as discussed in issue #1646:

  • remove the -y argument ("why" indeed)
  • remove support for evim and eview aliases
  • remove supporting files (runtime/evim.vim)
  • remove references to easy mode from the documentation
  • update man pages.

@marvim marvim added the WIP label Dec 12, 2014

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 12, 2014

Member

👍

Member

justinmk commented Dec 12, 2014

👍

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Dec 12, 2014

Member

translations (I need some hints on how to proceed here).

I think that unused messages are automatically commented out by gettext during the build, so you might not have to do anything here. You could add a commit where you run make update-po (in build), but that will include a lot of PO changes unrelated to this PR.

Member

fwalch commented Dec 12, 2014

translations (I need some hints on how to proceed here).

I think that unused messages are automatically commented out by gettext during the build, so you might not have to do anything here. You could add a commit where you run make update-po (in build), but that will include a lot of PO changes unrelated to this PR.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 12, 2014

Contributor

@fwalch In that case, I think I'll skip that for now. Since we are not adding new messages to translate, it shouldn't matter, right?

Contributor

fmoralesc commented Dec 12, 2014

@fwalch In that case, I think I'll skip that for now. Since we are not adding new messages to translate, it shouldn't matter, right?

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Dec 12, 2014

Member

I think so, yes. make update-po is only necessary before updating a translation. But ping @elmart to make sure.

Member

fwalch commented Dec 12, 2014

I think so, yes. make update-po is only necessary before updating a translation. But ping @elmart to make sure.

Show outdated Hide outdated runtime/doc/starting.txt Outdated
@@ -927,9 +926,6 @@ static void parse_command_name(mparm_T *parmp)
if (parse_char_i(&initstr, 'r'))

This comment has been minimized.

@ghost

ghost Dec 12, 2014

I can't seem to comment directly on it, but line 906 should be removed.

@ghost

ghost Dec 12, 2014

I can't seem to comment directly on it, but line 906 should be removed.

This comment has been minimized.

@fmoralesc

fmoralesc Dec 12, 2014

Contributor

👍

@fmoralesc

fmoralesc Dec 12, 2014

Contributor

👍

This comment has been minimized.

@justinmk

justinmk Jan 21, 2015

Member

@Pyrohh @fmoralesc I assume line 906 was moved after the rebase, so this comment was addressed?

@justinmk

justinmk Jan 21, 2015

Member

@Pyrohh @fmoralesc I assume line 906 was moved after the rebase, so this comment was addressed?

This comment has been minimized.

@ghost

ghost Jan 21, 2015

Yes, it's about 10 lines before currently.

On January 21, 2015 12:16:54 AM EST, "Justin M. Keyes" notifications@github.com wrote:

@@ -927,9 +926,6 @@ static void parse_command_name(mparm_T *parmp)
if (parse_char_i(&initstr, 'r'))

@Pyrohh @fmoralesc I assume line 906 was moved after the rebase, so
this comment was addressed?


Reply to this email directly or view it on GitHub:
https://github.com/neovim/neovim/pull/1656/files#r23278514

@ghost

ghost Jan 21, 2015

Yes, it's about 10 lines before currently.

On January 21, 2015 12:16:54 AM EST, "Justin M. Keyes" notifications@github.com wrote:

@@ -927,9 +926,6 @@ static void parse_command_name(mparm_T *parmp)
if (parse_char_i(&initstr, 'r'))

@Pyrohh @fmoralesc I assume line 906 was moved after the rebase, so
this comment was addressed?


Reply to this email directly or view it on GitHub:
https://github.com/neovim/neovim/pull/1656/files#r23278514

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 12, 2014

This looks good to me.

ghost commented Dec 12, 2014

This looks good to me.

@fmoralesc fmoralesc changed the title from [WIP] Remove "easy" mode. to [RFC] Remove "easy" mode. Dec 12, 2014

@marvim marvim added RFC and removed WIP labels Dec 12, 2014

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 13, 2014

Member

LGTM. Oddly, I couldn't find any handling for "eview", and if I alias eview=vimit does not open the file as readonly.

Member

justinmk commented Dec 13, 2014

LGTM. Oddly, I couldn't find any handling for "eview", and if I alias eview=vimit does not open the file as readonly.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 13, 2014

Contributor

@justinmk Shouldn't eview be the same as vim -Ry?

Contributor

fmoralesc commented Dec 13, 2014

@justinmk Shouldn't eview be the same as vim -Ry?

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 13, 2014

Member

Shouldn't eview be the same as vim -Ry

Yes, but I don't see anywhere that detects vim invoked as eview and sets -R.

Member

justinmk commented Dec 13, 2014

Shouldn't eview be the same as vim -Ry

Yes, but I don't see anywhere that detects vim invoked as eview and sets -R.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 13, 2014

Contributor

@justinmk This PR removed that here. The view part of it is handled later in the file, and I didnt touch it. I suppose an hypothetical nview won't be provided by nvim either, right? In that case, I could prepare a separate PR to remove that too.

Contributor

fmoralesc commented Dec 13, 2014

@justinmk This PR removed that here. The view part of it is handled later in the file, and I didnt touch it. I suppose an hypothetical nview won't be provided by nvim either, right? In that case, I could prepare a separate PR to remove that too.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 13, 2014

Member

an hypothetical nview won't be provided by nvim either, right

I would say not.

Member

justinmk commented Dec 13, 2014

an hypothetical nview won't be provided by nvim either, right

I would say not.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 15, 2014

As @fwalch said, updating the PO files would cause many translations to be updated not relevant to this PR. In my case, it was a few thousand changes for each language update, and 80k changes for a full make update-po.

I'm not knowledgeable in nvim's internationalization system, but an update like this seems like it would be better suited for a separate PR due to its size (or left to gettext at build time as previously mentioned).

ghost commented Dec 15, 2014

As @fwalch said, updating the PO files would cause many translations to be updated not relevant to this PR. In my case, it was a few thousand changes for each language update, and 80k changes for a full make update-po.

I'm not knowledgeable in nvim's internationalization system, but an update like this seems like it would be better suited for a separate PR due to its size (or left to gettext at build time as previously mentioned).

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 15, 2014

Contributor

For the changes in this PR, I think It would suffice to manually delete the lines referencing evim from the po files. Of course, the comments on the files would get outdated, but those don't matter anyway, and could get fixed in another PR bundling all the translation changes.

Contributor

fmoralesc commented Dec 15, 2014

For the changes in this PR, I think It would suffice to manually delete the lines referencing evim from the po files. Of course, the comments on the files would get outdated, but those don't matter anyway, and could get fixed in another PR bundling all the translation changes.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 16, 2014

I don't understand why you'd want to manually delete them in this PR, as those changes would be overwritten by a make update-po PR at a later date (if ever, again given what @fwalch said). If a PR was to be made, it'd probably be better to do everything at once, especially since make update-po is automated, so presumably has less possibility for error than manual deletion (assuming the translation updates are deterministic).

ghost commented Dec 16, 2014

I don't understand why you'd want to manually delete them in this PR, as those changes would be overwritten by a make update-po PR at a later date (if ever, again given what @fwalch said). If a PR was to be made, it'd probably be better to do everything at once, especially since make update-po is automated, so presumably has less possibility for error than manual deletion (assuming the translation updates are deterministic).

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 16, 2014

Given the general size of translation updates, perhaps they could only be done before releases? The changes could be in one monolithic commit, and a release could be tagged following that.

ghost commented Dec 16, 2014

Given the general size of translation updates, perhaps they could only be done before releases? The changes could be in one monolithic commit, and a release could be tagged following that.

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Dec 16, 2014

Member

In general, translations in PO files shouldn't be deleted at all (even commented out ones), because gettext will use them to generate "fuzzy" translations for new strings (which then should be properly translated by a human). This is maybe a borderline case because evim is removed for good, but I'd still opt for not removing translations, just because it's simpler and less error-prone.

Member

fwalch commented Dec 16, 2014

In general, translations in PO files shouldn't be deleted at all (even commented out ones), because gettext will use them to generate "fuzzy" translations for new strings (which then should be properly translated by a human). This is maybe a borderline case because evim is removed for good, but I'd still opt for not removing translations, just because it's simpler and less error-prone.

@oakes

This comment has been minimized.

Show comment
Hide comment
@oakes

oakes Dec 16, 2014

Contributor

It may be too late to register an opinion on this, but I definitely don't support removing easy mode. Although I don't use it myself, I am primarily interested in Neovim because I want to make a GUI for it that makes it more accessible to newbies. My plan was always to enable easy mode by default, and provide a button to toggle it off. It's a very useful feature for getting people's feet wet when they are initially trying to get started with the editor.

Contributor

oakes commented Dec 16, 2014

It may be too late to register an opinion on this, but I definitely don't support removing easy mode. Although I don't use it myself, I am primarily interested in Neovim because I want to make a GUI for it that makes it more accessible to newbies. My plan was always to enable easy mode by default, and provide a button to toggle it off. It's a very useful feature for getting people's feet wet when they are initially trying to get started with the editor.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 16, 2014

Contributor

@Pyrohh , @fwalch Just to make things clearer, I didn't intend to do anything else with the translations for this PR. I was just thinking out loud, mostly.

Off topic, I believe It would be helpful if the translations were updated soon. My native language translation (spanish) is not quite good, and it would be great to have a clean state to work on. I've seen some others (e.g) wanting to work on this too.

Contributor

fmoralesc commented Dec 16, 2014

@Pyrohh , @fwalch Just to make things clearer, I didn't intend to do anything else with the translations for this PR. I was just thinking out loud, mostly.

Off topic, I believe It would be helpful if the translations were updated soon. My native language translation (spanish) is not quite good, and it would be great to have a clean state to work on. I've seen some others (e.g) wanting to work on this too.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 16, 2014

Member

@oakes It's not too late, but let's identify what you need for your use case. Easy mode is essentially a small plugin combined with a bunch of manpages. Do we really need this in the core project?

Member

justinmk commented Dec 16, 2014

@oakes It's not too late, but let's identify what you need for your use case. Easy mode is essentially a small plugin combined with a bunch of manpages. Do we really need this in the core project?

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 16, 2014

Contributor

@oakes I understand that, but I strongly believe easy mode wets people's feet on the wrong thing. Easy mode feels very different to vim's regular usage, especially by taking normal mode out of the foreground. Perhaps we can ease people into using vim some other way? I would love to discuss it. What problems are most common when beginning to use vim? Which things should the user be most aware of when using it? Etc.

Contributor

fmoralesc commented Dec 16, 2014

@oakes I understand that, but I strongly believe easy mode wets people's feet on the wrong thing. Easy mode feels very different to vim's regular usage, especially by taking normal mode out of the foreground. Perhaps we can ease people into using vim some other way? I would love to discuss it. What problems are most common when beginning to use vim? Which things should the user be most aware of when using it? Etc.

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Dec 16, 2014

Member

Off topic, I believe It would be helpful if the translations were updated soon. My native language translation (spanish) is not quite good, and it would be great to have a clean state to work on. I've seen some others (e.g) wanting to work on this too.

It wanted to write that it might be better to wait for the release (or "release candidate phase", if something like that is planned) because messages will change until then. But it seems like messages didn't change that much; the German translation was fully updated a few months back; currently it has only 40 fuzzy and 26 untranslated messages.

Member

fwalch commented Dec 16, 2014

Off topic, I believe It would be helpful if the translations were updated soon. My native language translation (spanish) is not quite good, and it would be great to have a clean state to work on. I've seen some others (e.g) wanting to work on this too.

It wanted to write that it might be better to wait for the release (or "release candidate phase", if something like that is planned) because messages will change until then. But it seems like messages didn't change that much; the German translation was fully updated a few months back; currently it has only 40 fuzzy and 26 untranslated messages.

@oakes

This comment has been minimized.

Show comment
Hide comment
@oakes

oakes Dec 16, 2014

Contributor

@justinmk I was under the impression that there might be some other things besides vim scripts that it relies on. If I can still make use of it by shipping with that script, I suppose it's not a big deal.

The question of whether it belongs in the core project is beyond me to answer. I guess an important goal of Neovim is supporting user-friendly GUI development, so removing a user-friendly mode seems contrary to that.

More importantly, I think the null position for any decision Bram made is that it's a good idea until proven otherwise =) But like I said, if it's possible to work by shipping the appropriate script then I am not quite as fearful.

@fmoralesc The primary difficulty of vim is that it uses modes in a world of mostly non-modal editors, so I don't think one could make an easy mode that felt the same as vim's normal usage does.

Contributor

oakes commented Dec 16, 2014

@justinmk I was under the impression that there might be some other things besides vim scripts that it relies on. If I can still make use of it by shipping with that script, I suppose it's not a big deal.

The question of whether it belongs in the core project is beyond me to answer. I guess an important goal of Neovim is supporting user-friendly GUI development, so removing a user-friendly mode seems contrary to that.

More importantly, I think the null position for any decision Bram made is that it's a good idea until proven otherwise =) But like I said, if it's possible to work by shipping the appropriate script then I am not quite as fearful.

@fmoralesc The primary difficulty of vim is that it uses modes in a world of mostly non-modal editors, so I don't think one could make an easy mode that felt the same as vim's normal usage does.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 16, 2014

Contributor

@oakes @justinmk Assuming the defaults from #1667, evim.vim can be reduced to this

Contributor

fmoralesc commented Dec 16, 2014

@oakes @justinmk Assuming the defaults from #1667, evim.vim can be reduced to this

@oakes

This comment has been minimized.

Show comment
Hide comment
@oakes

oakes Dec 16, 2014

Contributor

@fmoralesc Fair enough; that is quite a simple script.

I still would not remove this mode personally. It may not affect my own project, it does of course mean that the standard nvim package won't have it. Features like this always have a precarious life, because project contributors are not its target and thus don't see their value. I understand the desire to remove "dead" code, like Amiga support, but people are clearly using easy mode. There is even a separate launcher included in gVim called gVim Easy.

Contributor

oakes commented Dec 16, 2014

@fmoralesc Fair enough; that is quite a simple script.

I still would not remove this mode personally. It may not affect my own project, it does of course mean that the standard nvim package won't have it. Features like this always have a precarious life, because project contributors are not its target and thus don't see their value. I understand the desire to remove "dead" code, like Amiga support, but people are clearly using easy mode. There is even a separate launcher included in gVim called gVim Easy.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 16, 2014

Member

removing a user-friendly mode seems contrary to that.

Understood, and we want to improve the defaults for everyone.

I think the null position for any decision Bram made is that it's a good idea until proven otherwise

Yes, I think I'm nearly the most conservative project contributor when it comes to removing things. Bram has spent a lot of time thinking about some decisions, but some other things have not been revisited in a decade or more.

people are clearly using easy mode. There is even a separate launcher included in gVim called gVim Easy.

Calling it a "mode" at this point is a bit grandiose, since it is only two lines. The other lines in https://gist.github.com/fmoralesc/d7f39118932fadbe1d29 are arguably candidates for Neovim defaults. (set backup may be enabled by default in an unobtrusive way after #78 is settled)

Also, the point about evim being a reserved command still stands. We would have to use a new name, and I don't think newbie users are going to like nvim -y. Any package maintainer who wants to mimic evim in Neovim can do this:

alias evim='nvim -c "runtime! mswin.vim" -c "set insertmode"'

(Try it!)

Member

justinmk commented Dec 16, 2014

removing a user-friendly mode seems contrary to that.

Understood, and we want to improve the defaults for everyone.

I think the null position for any decision Bram made is that it's a good idea until proven otherwise

Yes, I think I'm nearly the most conservative project contributor when it comes to removing things. Bram has spent a lot of time thinking about some decisions, but some other things have not been revisited in a decade or more.

people are clearly using easy mode. There is even a separate launcher included in gVim called gVim Easy.

Calling it a "mode" at this point is a bit grandiose, since it is only two lines. The other lines in https://gist.github.com/fmoralesc/d7f39118932fadbe1d29 are arguably candidates for Neovim defaults. (set backup may be enabled by default in an unobtrusive way after #78 is settled)

Also, the point about evim being a reserved command still stands. We would have to use a new name, and I don't think newbie users are going to like nvim -y. Any package maintainer who wants to mimic evim in Neovim can do this:

alias evim='nvim -c "runtime! mswin.vim" -c "set insertmode"'

(Try it!)

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 16, 2014

Contributor

@oakes Btw, I removed the <C-F> mapping because nvim doesn't have :promptfind (actually, console vim doesn't have it, which is the reason for evim launching the GUI I imagine). The GUI should provide that, like the python host does with :pydo et al. Something to keep in mind when building it ;)

people are clearly using easy mode. There is even a separate launcher included in gVim called gVim Easy.

I'm not so sure. Problem is, there is no data on what the rate of usage of evim really is, so the argument will tend to be philosophical. That said, when I queried r/vim for usage on aliases, nobody mentioned using evim at all, and some didn't even know it existed.

I personally think evim teaches the wrong things, and it merely hides the modal nature of vim. evim is still modal, but in this sense is even more opaque than regular vim. <C-l> to get into normal mode is pretty obscure (and you need it to get to the help(!), since nvim doesn't have a menu currently - this won't be a problem in your GUI, I imagine). Other argument against evim is that for inserting text, the user looses commands like a and o, unless the user wants to go to normal mode and then perform them. I believe learning to use vim is akin to learning a language, and some kind of immersion doesn't seem like a bad method; evim prevents it for the most part.

Yes, I think I'm nearly the most conservative project contributor when it comes to removing things.

@justinmk And thank you for that!

Contributor

fmoralesc commented Dec 16, 2014

@oakes Btw, I removed the <C-F> mapping because nvim doesn't have :promptfind (actually, console vim doesn't have it, which is the reason for evim launching the GUI I imagine). The GUI should provide that, like the python host does with :pydo et al. Something to keep in mind when building it ;)

people are clearly using easy mode. There is even a separate launcher included in gVim called gVim Easy.

I'm not so sure. Problem is, there is no data on what the rate of usage of evim really is, so the argument will tend to be philosophical. That said, when I queried r/vim for usage on aliases, nobody mentioned using evim at all, and some didn't even know it existed.

I personally think evim teaches the wrong things, and it merely hides the modal nature of vim. evim is still modal, but in this sense is even more opaque than regular vim. <C-l> to get into normal mode is pretty obscure (and you need it to get to the help(!), since nvim doesn't have a menu currently - this won't be a problem in your GUI, I imagine). Other argument against evim is that for inserting text, the user looses commands like a and o, unless the user wants to go to normal mode and then perform them. I believe learning to use vim is akin to learning a language, and some kind of immersion doesn't seem like a bad method; evim prevents it for the most part.

Yes, I think I'm nearly the most conservative project contributor when it comes to removing things.

@justinmk And thank you for that!

@oakes

This comment has been minimized.

Show comment
Hide comment
@oakes

oakes Dec 17, 2014

Contributor

@justinmk,

Calling it a "mode" at this point is a bit grandiose, since it is only two lines.

Perhaps, but it's in the title of this PR, and to a beginner there really is no difference between a two line script and 200 line script. Both require the same setup process prior to use.

@fmoralesc,

It is certainly hard to find data on beginner users, and I doubt one would find them on /r/vim. I agree that switching to normal mode with <C-l> is pretty wonky, but the goal of easy mode should be to make normal mode unnecessary. If it were possible to save and quit using nano-style Ctrl commands, that would be ideal.

I recommend you read wycat's experiences learning Vim for the first time. He pointed out that immersion led to frustration. It was only by learning Vim incrementally with MacVim that he successfully switched. Of course, GUIs like MacVim could still supply their own easy mode, so it's not a significant problem, but I thought it was worth pointing out anyway.

Contributor

oakes commented Dec 17, 2014

@justinmk,

Calling it a "mode" at this point is a bit grandiose, since it is only two lines.

Perhaps, but it's in the title of this PR, and to a beginner there really is no difference between a two line script and 200 line script. Both require the same setup process prior to use.

@fmoralesc,

It is certainly hard to find data on beginner users, and I doubt one would find them on /r/vim. I agree that switching to normal mode with <C-l> is pretty wonky, but the goal of easy mode should be to make normal mode unnecessary. If it were possible to save and quit using nano-style Ctrl commands, that would be ideal.

I recommend you read wycat's experiences learning Vim for the first time. He pointed out that immersion led to frustration. It was only by learning Vim incrementally with MacVim that he successfully switched. Of course, GUIs like MacVim could still supply their own easy mode, so it's not a significant problem, but I thought it was worth pointing out anyway.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 17, 2014

Contributor

If it were possible to save and quit using nano-style Ctrl commands, that would be ideal.

We can add those to mswin.vim, which provided win-style mappings for easy mode. It is actually weird <C-s> and <C-q> are not already mapped there for that. Does anyone know the reason?

Now, to "make normal mode unnecessary" seems unfeasible (normal mode is the core of vim for me!), but why don't we try to define what that would entail? What should be remapped, how would that work? I suggest we move that discussion to a new issue, though.

I recommend you read wycat's experiences learning Vim for the first time.

I've read that article, and I think it is not contrary to what I meant. When I say "immersion", I don't mean the full-on "let's unmap the arrow keys" things one sometimes hears, which is bonkers (I actually still use the arrow keys ;)) But learning to move between modes, some commands and other mappings is not unreasonable; I would love to make it easier to learn that. What I really mean is you learn vim by practicing those things, and you should be exposed to that interface as much as possible to gain fluency. I recently read this article on that topic, you might like it.

Contributor

fmoralesc commented Dec 17, 2014

If it were possible to save and quit using nano-style Ctrl commands, that would be ideal.

We can add those to mswin.vim, which provided win-style mappings for easy mode. It is actually weird <C-s> and <C-q> are not already mapped there for that. Does anyone know the reason?

Now, to "make normal mode unnecessary" seems unfeasible (normal mode is the core of vim for me!), but why don't we try to define what that would entail? What should be remapped, how would that work? I suggest we move that discussion to a new issue, though.

I recommend you read wycat's experiences learning Vim for the first time.

I've read that article, and I think it is not contrary to what I meant. When I say "immersion", I don't mean the full-on "let's unmap the arrow keys" things one sometimes hears, which is bonkers (I actually still use the arrow keys ;)) But learning to move between modes, some commands and other mappings is not unreasonable; I would love to make it easier to learn that. What I really mean is you learn vim by practicing those things, and you should be exposed to that interface as much as possible to gain fluency. I recently read this article on that topic, you might like it.

@fmoralesc fmoralesc referenced this pull request Dec 17, 2014

Closed

[RFC] Set some defaults early #1667

4 of 4 tasks complete
@oakes

This comment has been minimized.

Show comment
Hide comment
@oakes

oakes Dec 17, 2014

Contributor

@fmoralesc On second thought, making easy mode behave like nano would probably be going too far, as there would be no impetus to learn normal mode commands. It's beside the point, anyway. I don't want to add any more noise to thise PR so I'll leave it at that.

Contributor

oakes commented Dec 17, 2014

@fmoralesc On second thought, making easy mode behave like nano would probably be going too far, as there would be no impetus to learn normal mode commands. It's beside the point, anyway. I don't want to add any more noise to thise PR so I'll leave it at that.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 17, 2014

Contributor

@oakes Let's still discuss how to make learning vim easier in a different issue, though. I want to know what you have thought about it, in regards to the GUI and UX ;)

Contributor

fmoralesc commented Dec 17, 2014

@oakes Let's still discuss how to make learning vim easier in a different issue, though. I want to know what you have thought about it, in regards to the GUI and UX ;)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 15, 2015

It's been just under a month since the last comment, so does anyone think more discussion is needed?

ghost commented Jan 15, 2015

It's been just under a month since the last comment, so does anyone think more discussion is needed?

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jan 15, 2015

Member

I will review this thread again tonight.

Member

justinmk commented Jan 15, 2015

I will review this thread again tonight.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Jan 15, 2015

Contributor

I'll rebase ASAP. I'm currently working on the other set of patches at #1793 .

Contributor

fmoralesc commented Jan 15, 2015

I'll rebase ASAP. I'm currently working on the other set of patches at #1793 .

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost commented Jan 15, 2015

Thanks.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 15, 2015

Is there any reason you're not touching evim.vim?

ghost commented Jan 15, 2015

Is there any reason you're not touching evim.vim?

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Jan 15, 2015

Contributor

Must have slipped through.

Contributor

fmoralesc commented Jan 15, 2015

Must have slipped through.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Jan 21, 2015

Contributor

Any comments on this, then, @justinmk, @Pyrohh? This is ready on my end.

Contributor

fmoralesc commented Jan 21, 2015

Any comments on this, then, @justinmk, @Pyrohh? This is ready on my end.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 21, 2015

Assuming you haven't changed anything recently, then LGTM

ghost commented Jan 21, 2015

Assuming you haven't changed anything recently, then LGTM

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Jan 21, 2015

Contributor

No, I haven't. I've been pretty busy digging myself out of the pit of #1793. :/

Contributor

fmoralesc commented Jan 21, 2015

No, I haven't. I've been pretty busy digging myself out of the pit of #1793. :/

justinmk added a commit that referenced this pull request Jan 21, 2015

@justinmk justinmk merged commit c3028e4 into neovim:master Jan 21, 2015

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@justinmk justinmk removed the RFC label Jan 21, 2015

@ghost ghost referenced this pull request Feb 21, 2015

Merged

Upcoming Newsletter #82

22 of 22 tasks complete

@fmoralesc fmoralesc deleted the fmoralesc:remove-easy-mode branch Feb 22, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment