5 ms·

I use a bunch of plugins and I've never had trouble remembering the defaults in the odd case I'm unable to use my own config. I don't get why the top comment o

by cgag 7y ago

I use a bunch of plugins and I've never had trouble remembering the defaults in the odd case I'm unable to use my own config. I don't get why the top comment on all vim threads is always recommending using poor defaults your whole life so you can avoid learning to configure it or avoid a second of confusion when you're ssh'd somewhere. Maybe everyone else besides me spends all their time ssh'd into random servers.

carterehsmith 7y ago
Nah, I've seen people downloading their preferred configs right to the production server, because they, understandably, feel more comfy with that. But, it may not be for everyone. Where I work, we are in the process of reaching some compliance targets, and all this downloading unknown stuff from unknown servers is out the window. For the best, I think.
- trcollinson 7y ago
  It's unfortunate that in this day and age we still have people who directly access and touch a production server at all, ever. There is zero need.
  - alasdair_ 7y ago
    This sounds nice until you have to debug a crazy error that only happens in production.
    - michaelmrose 7y ago
      Wouldn't this represent 0.1% of your usage? Meanwhile the thinking portion is 99% of the job and the act of using the UI to enact the changes on any editor is the other 1%. Making 1% of 1/10 of 1% more effecient seems like a curious optimization.
    - trcollinson 7y ago
      Honestly, if you have to hop on production to debug a crazy error, you have two bugs. The infrastructure being so different on production compared to development or local is a fixable issue. As are any other differences between production and local that make difficult to debug in these special cases. It takes a long time. It's a substantial effort. But it is worth while.
  - airnomad 7y ago
    You're quite green, aren't you?
    - trcollinson 7y ago
      It may seem that way, but no I've crossed that chasm long ago. I've debugged on production more than I would ever care to remember. But in all honesty it is easier than ever to stay completely off of production. It's also extremely cost effective. It's not simple and it is work, but it has never been easier to actually be successful at staying off if production.
      - airnomad 7y ago
        Easier then ever maybe but still probably impossible to avoid. It's not that anyone wants to mess up with live, it's more like you don't have a choice.
        trcollinson 7y ago
        Really? I haven't allowed people to log directly only a production environment in almost 10 years. There is definitely a choice.
- clinta 7y ago
  People need to stop editing directly on servers. Vim's netrw can write out over scp, use your configured vim on your desktop to edit the files on the server.
  - lunchables 7y ago
    The problem is browsing files, for me. I can't use fzf, nerdtree, nnn.vim, whatever. I much prefer sshfs and treating the remote file system like a local one. But I'm not really familiar with netrw other than just: :e scp://host/path/file
    - clinta 7y ago
      I've never used any of those plugins, but the built in netrw has a directory browser that works. On vanilla vim if you :e scp://host// you should get the built in netrw browser working over scp.
    - kqr 7y ago
      This is one of the reasons my preferred implementation of Vi is Evil -- the TRAMP network layer in Emacs does exactly what you want: let you treat any remote file system as local. It even does multi-hop access through e.g. bastion machines. It is great.
- michaelmrose 7y ago
  How much editing do people need to do on the production server in the context of developing software? Incidentally one can mount a remote filesystem via ssh and edit the files as if they were local with any editor. With Emacs you can skip a step and directly point your editor to the remote file via tramp.
bin0 7y ago
It's not a serious issue for me. I can't download my configs to random devices either. Working on embedded stuff I've usually only got vi, and honestly, the most annoying thing is no `F` binding (which is a default in vim).
- rhizome 7y ago
  Poor undo is my main bugaboo in vi, but I'm usually OK with just :e! and starting over.

by cgag 7y ago

carterehsmith 7y ago

Nah, I've seen people downloading their preferred configs right to the production server, because they, understandably, feel more comfy with that. But, it may not be for everyone. Where I work, we are in the process of reaching some compliance targets, and all this downloading unknown stuff from unknown servers is out the window. For the best, I think.

trcollinson 7y ago
It's unfortunate that in this day and age we still have people who directly access and touch a production server at all, ever. There is zero need.
- alasdair_ 7y ago
  This sounds nice until you have to debug a crazy error that only happens in production.
  - michaelmrose 7y ago
    Wouldn't this represent 0.1% of your usage? Meanwhile the thinking portion is 99% of the job and the act of using the UI to enact the changes on any editor is the other 1%. Making 1% of 1/10 of 1% more effecient seems like a curious optimization.
  - trcollinson 7y ago
    Honestly, if you have to hop on production to debug a crazy error, you have two bugs. The infrastructure being so different on production compared to development or local is a fixable issue. As are any other differences between production and local that make difficult to debug in these special cases. It takes a long time. It's a substantial effort. But it is worth while.
- airnomad 7y ago
  You're quite green, aren't you?
  - trcollinson 7y ago
    It may seem that way, but no I've crossed that chasm long ago. I've debugged on production more than I would ever care to remember. But in all honesty it is easier than ever to stay completely off of production. It's also extremely cost effective. It's not simple and it is work, but it has never been easier to actually be successful at staying off if production.
    - airnomad 7y ago
      Easier then ever maybe but still probably impossible to avoid. It's not that anyone wants to mess up with live, it's more like you don't have a choice.
      - trcollinson 7y ago
        Really? I haven't allowed people to log directly only a production environment in almost 10 years. There is definitely a choice.
clinta 7y ago
People need to stop editing directly on servers. Vim's netrw can write out over scp, use your configured vim on your desktop to edit the files on the server.
- lunchables 7y ago
  The problem is browsing files, for me. I can't use fzf, nerdtree, nnn.vim, whatever. I much prefer sshfs and treating the remote file system like a local one. But I'm not really familiar with netrw other than just: :e scp://host/path/file
  - clinta 7y ago
    I've never used any of those plugins, but the built in netrw has a directory browser that works. On vanilla vim if you :e scp://host// you should get the built in netrw browser working over scp.
  - kqr 7y ago
    This is one of the reasons my preferred implementation of Vi is Evil -- the TRAMP network layer in Emacs does exactly what you want: let you treat any remote file system as local. It even does multi-hop access through e.g. bastion machines. It is great.
michaelmrose 7y ago
How much editing do people need to do on the production server in the context of developing software? Incidentally one can mount a remote filesystem via ssh and edit the files as if they were local with any editor. With Emacs you can skip a step and directly point your editor to the remote file via tramp.

bin0 7y ago

It's not a serious issue for me. I can't download my configs to random devices either. Working on embedded stuff I've usually only got vi, and honestly, the most annoying thing is no `F` binding (which is a default in vim).

rhizome 7y ago
Poor undo is my main bugaboo in vi, but I'm usually OK with just :e! and starting over.