I think this is probably far too nice, but what about pkill vim
That just types ll vim
[deleted]
How to Exit Vim
401–409 of 409 posts
Re: How to Exit Vim
#402One of my Computer Science lecturers had a rule: use Vim for all development for his class whilst on campus, and if caught using any other editor/IDE – or committing any artifacts showing evidence of such – we would lose several percentage points from our final mark for his class. Harsh? Perhaps. But I can’t thank that lecturer enough for that rule. He converted a mostly IDE-wielding class into one that actually appr…
I used to be a vim evangelist before, but after seeing some of the people at my lab writing code as fast as me in Sublime Text, I’ve decided not to participate in editor wars anymore.
Re: How to Exit Vim
#403Earlier quoted context omitted.
Scrum has a built in self destruct method - the retrospective. With a little maneuvering, the team should be able to remove most of the annoying things about scrum by using the retrospective. Obviously you can't go scorched earth and drop all the annoying bits at once. But, if scrum is really being followed (I know this is also part of the problem), the retro should allow the team to change the process over time.
You can't remove a professional scrum-master who does nothing else in the retrospective as the scrum-master is running the retrospective.
Disagree: the team owns the retrospective, not the Scrum master. If team members aren't happy with what the Scrum master is doing, that should be addressed in the retrospective.
Re: How to Exit Vim
#404Earlier quoted context omitted.
It saddens me to say, but this is so familiar. Especially working in a big corporate company where they hire scrum masters who just follow the scrum guide.
Scrum has a built in self destruct method - the retrospective. With a little maneuvering, the team should be able to remove most of the annoying things about scrum by using the retrospective. Obviously you can't go scorched earth and drop all the annoying bits at once. But, if scrum is really being followed (I know this is also part of the problem), the retro should allow the team to change the process over time.
I would not call it self destruct, rather reconstruct or adjust. If the way the team uses Scrum isn't effective, then the retrospective can be used to explore issues and adjust the way of working.
Re: How to Exit Vim
#405Earlier quoted context omitted.
Scrum has a built in self destruct method - the retrospective. With a little maneuvering, the team should be able to remove most of the annoying things about scrum by using the retrospective. Obviously you can't go scorched earth and drop all the annoying bits at once. But, if scrum is really being followed (I know this is also part of the problem), the retro should allow the team to change the process over time.
This obviously only works when your scrum master is willing to take feedback on scrum processes. Which, with most scrum masters is not the case, you’re essentially telling them they’re doing a bad job, and it usually hurts their ego.
Something is seriously wrong if the Scrum master doesn't take feedback. That goes against the Agile values and principles.
Re: How to Exit Vim
#406Earlier quoted context omitted.
This obviously only works when your scrum master is willing to take feedback on scrum processes. Which, with most scrum masters is not the case, you’re essentially telling them they’re doing a bad job, and it usually hurts their ego.
Something is seriously wrong if the Scrum master doesn't take feedback. That goes against the Agile values and principles.
I honestly haven't met many scrum masters who don't just preach the scrum guide. Even if the team is struggling with the way we do Agile, the scrum master will just continue to force the scrum guide onto the team.
What I currently see is that our scrum master has sold the business on the agile way, so if a developer complains about it, there's something wrong with the developer. It's probably just a bad scrum master, but I've met multiple of those.
Re: How to Exit Vim
#407Earlier quoted context omitted.
You can't remove a professional scrum-master who does nothing else in the retrospective as the scrum-master is running the retrospective.
Disagree: the team owns the retrospective, not the Scrum master. If team members aren't happy with what the Scrum master is doing, that should be addressed in the retrospective.
And this is coming from your own personal experience? I've never been in a scrum team where we as developers had any say in what the scrum master was doing. The most we could do was retrospectives with other developers, and try to improve there. However that's rarely enough to make a business work.
Re: How to Exit Vim
#408Earlier quoted context omitted.
I’ve seen Java developers completely lost with no idea where to start debugging an installation in a lab environment because they had no IDE, JDK only. Sure, you might argue that it’s an unlikely scenario, but never say never. CS is one of many fields where having a basic understanding of how things work at least a couple of layers of abstraction down is a good thing, and at least could save potential embarrassment.
You're not wrong, but I don't see how forcing people to use vim solves this problem. If anything, you risk having a whole class of students who can only do things the vim way. I'll grant you that you're much more likely in a lab environment to have access to a POSIX system so you can use vi or whatever, but you could also wind up in a shop that dictates its devs use a specific IDE. I'm in full-agreement that it's a g…
I should have been clear that I lean toward your side of the issue in that a blanket policy for the entire term does seem a bit extreme but completely without value. If I were pushed to defend the instructor’s policy of a particular editor, vi is nearly certain to be on any Unix installation. Not necessarily how I would (or have) done it, but the approach is not without value.
My preferred Unix editor is the vi family. I wonder whether emacs people are less sympathetic.
Re: How to Exit Vim
#409In the opposing vein, as an Emacs user the best configuration I ever made was to rebind C-x C-c to execute-extended-command instead of kill-emacs. It was way too easy to (even accidentally!) kill emacs with a sweep of a finger. And I probably use a few hundred execute-extended-command calls for each kill-emacs (which I now have to type manually as 'C-x C-c kill-emacs' - no problemo). A similar optimisation was with t…
| However, I've been toying around with the idea | of eventually writing a minimal 'vi' clone that | you cannot exit. I'm sure there's pent-up demand | just waiting for one! If a user space program can be truly unexitable without restarting (including the possibility of killing it through another shell, of course), then would you consider it to be a bug in the operating system? Seems a reasonable conclusion to me.
Alt+SysRq+k
(read linux/Documentation/admin-guide/sysrq.rst before you try this)