I use both the text editor separate from compile and launch for most languages however for Java I use an IDE because the language can is very verbose and an IDE can catch most of the minor errors. Also auto complete when using multiple open files simultaneously which have package level methods or variables is helpful.
I do agree there are cases when shit doesn't work when it should, this happened mostly in Eclipse when I would be writing in a competitive programming competition and writing stuff quick and dirty. Serves me right for not writing in something else but no one else on the team knows how to write or read in anything else.
As far as IDEA vs Eclipse - IDEA will detect what you want to do and make an appropriate guess as you type and is far more accurate and easy to auto complete with while error checking. I can write an entire class and it will auto import things from the appropriate libraries as I type. Both are really good at finding problems. IDEA is better at resolving them.
Integration with git and other services is far better in IDEA, night and day. Eclipse can't even change colours or zoom without plugins while IDEA has it integrated as it should be.
I've been using vim on and off lately to write shell, perl and bash scripts. It's a great tool, but I always thought it would scale poorly when you got into larger projects where management becomes more of an issue, but I suppose I'll just have to use it more
I've been using vim on and off lately to write shell, perl and bash scripts. It's a great tool, but I always thought it would scale poorly when you got into larger projects where management becomes more of an issue, but I suppose I'll just have to use it more
You can put plugins and stuff in it, but I only do that as little as possible.
It's a fundamental difference in philosophy. The idea of UNIX is that you have a lot of very small programs that each do one thing, and only one thing, very very well. Then those programs can interoperate with each other. So vim is a text editor. It ONLY edits text. If you want to do something else, like build, compile, analyze, etc. you get a separate tool that does that thing very well.
The Windows/OSX philosophy is that you open one application full screen and that one application does everything.
Instead of getting a vim plugin for something that isn't text-editing related, go back to your terminal and just apt-get install a separate program that does the thing you need.
Like, in XCode people are all using Git integration. I use Git on its own in the command line. What is the benefit of integrating it with vim somehow?
I use magit-mode for git in emacs. It's pretty fantastic for picking and choosing files (or hunks) to add, seeing what's changed, and going to back to work in progress. It's speedier and less typing than the command line would be.
So to become a more old man respectable programmer I am going to try and do this entire semester at University in VIM. I've never tried it but I'm going to learn. I'll write all my programs in C to increase the difficulty.
I'll be running Linux in a Virtualbox in Windows 10. I'll go with BASH because I know it better than KSH, ZSH or CSH.
Maybe download like a cheat sheet and just go for it. I've used VIM a few times when working with Linux but then always just open stuff in gedit because I would get frustrated.
Finally figured out alpha masking using GLSL and a couple month hiatus of just working on other things. Pretty motivated to keep working on my roguelike now. FOV is still a work in progress since I want to tune the visibility to show the edges of tiles.
Maybe download like a cheat sheet and just go for it. I've used VIM a few times when working with Linux but then always just open stuff in gedit because I would get frustrated.
Yeah I got a bit of that, why the fuck is escape the default command switch button, it seems so silly considering you have to switch so often. VIM is really punishing on new users making mistakes or typographical errors. You really need the muscle memory to be efficient (especially the HJKL movement and not being able to copy to clipboard without saving the file), I'll do some actual programming with it today rather than messing around with it.
Also my professor got mad when I insinuated that VIM wasn't a modern day text editor like Sublime Text or Notepad++.
Force yourself to use Vim for a while and you'll switch to internally screaming every time you use a graphical IDE and have to take your fingers off home row in order to move through a file.
Still trying to figure out the best way to display the wall tiles. Do I do partial visibility? How do I handle edge cases such as looking around corners? Apart from some obvious bugs, I still cannot get it to look right.
One is that you have complete knowledge of the structure of the environment. The second is that the FOV algorithm doesn't to show partial coverage of the level structure (wall faces/etc) because of this knowledge. My game's asthetic is one of partial/fake isometric view so it's important to see the wall faces. I actually implemented the Monaco algorithm exactly as seen here
What I'm doing is using the white portion as an alpha mask so anything that it touches is illuminated by the shader during the rendering process. However, with this method you can see that none of the walls are illuminated. This is a problem if you have doors/walls or other types of tiles that you want the player to see.
Perhaps make light penetrate and reflect off them? If a path through a wall is short enough and the player is close enough to the wall the light could pass through the wall along that vector and dimly light the area on the other side. That would let you see around corners and offer wall detail as the light could penetrate the wall but not pass through it completely, but would also introduce a lot of extra calculations and potential slow-down if you aren't clever about it and from what I can tell might not be compatible with the technique you are currently using.
Force yourself to use Vim for a while and you'll switch to internally screaming every time you use a graphical IDE and have to take your fingers off home row in order to move through a file.
I'm devoted to doing this for the next 6 months. Might need someone else in the competitive programming team to type for the first few competitions while I get comfortable with VIM.
not being able to copy to clipboard without saving the file
You should figure out how to do this without saving the file.
What? I've never heard of not being able to copy to clipboard without saving. WTF?
Hmm, I guess my script to copy to the system clipboard is incorrect. Inside VIM I just "yank" stuff, my next thing is getting my formatting to be less daunting than working out how to solve the problem .
I've restricted myself to using the H,J,K,L movement so far, is it cheating if I use the arrow keys?
Also been using it just in Terminal (without colours), I might switch to gvim for the colours as even in simple 200 line programs I get lost in reviewing the code. Also need to become diligent about closing brackets, literally all the errors that popped up today were unclosed round brackets.
To copy to the system clipboard you want to use the commands
"+ or "*
" copies the current selection to a buffer. + and * are clipboard buffers. On Windows they are both the same thing since Windows has only one clipboard. X11 based systems have two clipboard buffers, so that's why there is both + and *.
Nothing is cheating in vim. But using arrow keys is much slower since you move your fingers far away from the keys that do the rest of the commands. Getting hjkl into your muscle memory also makes it easier to play Nethack.
You can easily get colors in vim in any modern terminal emulator. That said, I still use gvim so that I can have vim in a separate window, and not constantly having terminals eaten up by text editors.
For closing brackets, there are a few strategies you can use. First, you can always write your opening and closing brackets together, and then fill in the space between them.
You can also modify your vimrc, maybe with a plugin, that will highlight mismatched brackets. You could even set it to make a closing bracket when you make a starting one.
Another thing I recommend is to have a linter run on save. For python I use flake8. So in vim whenever I write a .py file to disk, it checks it over and alerts me of any issues. This includes things like variables that get assigned and never used, blatant syntax errors, mismatched indenting, lines that are too long, etc. Similar static analysis tools exist for every language, and are very good.
I usually do the type both brackets initially method but I produce errors when I go back in and rewrite or tweak functions.
Thanks for the tips I'll implement the ones that suit me over the weekend. I'm predominantly going to be writing in C (on Linux) so indenting will be mainly for readability. However when I become very comfortable with using tabs appropriately I'll have less problems when writing in Python.
I'm getting more comfortable, main hurdle now is efficient use of Visual mode.
Force yourself to use Vim for a while and you'll switch to internally screaming every time you use a graphical IDE and have to take your fingers off home row in order to move through a file.
The late Dennis Richie, as well as fellow Unix inventor Ken Thompson, disagree with you there.
Comments
I do agree there are cases when shit doesn't work when it should, this happened mostly in Eclipse when I would be writing in a competitive programming competition and writing stuff quick and dirty. Serves me right for not writing in something else but no one else on the team knows how to write or read in anything else.
As far as IDEA vs Eclipse -
IDEA will detect what you want to do and make an appropriate guess as you type and is far more accurate and easy to auto complete with while error checking. I can write an entire class and it will auto import things from the appropriate libraries as I type. Both are really good at finding problems. IDEA is better at resolving them.
Integration with git and other services is far better in IDEA, night and day. Eclipse can't even change colours or zoom without plugins while IDEA has it integrated as it should be.
It's a fundamental difference in philosophy. The idea of UNIX is that you have a lot of very small programs that each do one thing, and only one thing, very very well. Then those programs can interoperate with each other. So vim is a text editor. It ONLY edits text. If you want to do something else, like build, compile, analyze, etc. you get a separate tool that does that thing very well.
The Windows/OSX philosophy is that you open one application full screen and that one application does everything.
Instead of getting a vim plugin for something that isn't text-editing related, go back to your terminal and just apt-get install a separate program that does the thing you need.
Like, in XCode people are all using Git integration. I use Git on its own in the command line. What is the benefit of integrating it with vim somehow?
I'll be running Linux in a Virtualbox in Windows 10.
I'll go with BASH because I know it better than KSH, ZSH or CSH.
Any recommendations or just go HAM?
Finally figured out alpha masking using GLSL and a couple month hiatus of just working on other things. Pretty motivated to keep working on my roguelike now. FOV is still a work in progress since I want to tune the visibility to show the edges of tiles.
VIM is really punishing on new users making mistakes or typographical errors. You really need the muscle memory to be efficient (especially the HJKL movement and not being able to copy to clipboard without saving the file), I'll do some actual programming with it today rather than messing around with it.
Also my professor got mad when I insinuated that VIM wasn't a modern day text editor like Sublime Text or Notepad++.
Still trying to figure out the best way to display the wall tiles. Do I do partial visibility? How do I handle edge cases such as looking around corners? Apart from some obvious bugs, I still cannot get it to look right.
One is that you have complete knowledge of the structure of the environment. The second is that the FOV algorithm doesn't to show partial coverage of the level structure (wall faces/etc) because of this knowledge. My game's asthetic is one of partial/fake isometric view so it's important to see the wall faces. I actually implemented the Monaco algorithm exactly as seen here
What I'm doing is using the white portion as an alpha mask so anything that it touches is illuminated by the shader during the rendering process. However, with this method you can see that none of the walls are illuminated. This is a problem if you have doors/walls or other types of tiles that you want the player to see.
This may be Rogue heresy, but have you considered an illogical top-down perspective like Zelda1 dungeons?
You can always see all the walls on all sides.
Might need someone else in the competitive programming team to type for the first few competitions while I get comfortable with VIM. Hmm, I guess my script to copy to the system clipboard is incorrect. Inside VIM I just "yank" stuff, my next thing is getting my formatting to be less daunting than working out how to solve the problem
I've restricted myself to using the H,J,K,L movement so far, is it cheating if I use the arrow keys?
Also been using it just in Terminal (without colours), I might switch to gvim for the colours as even in simple 200 line programs I get lost in reviewing the code.
Also need to become diligent about closing brackets, literally all the errors that popped up today were unclosed round brackets.
To copy to the system clipboard you want to use the commands
"+ or "*
" copies the current selection to a buffer. + and * are clipboard buffers. On Windows they are both the same thing since Windows has only one clipboard. X11 based systems have two clipboard buffers, so that's why there is both + and *.
Nothing is cheating in vim. But using arrow keys is much slower since you move your fingers far away from the keys that do the rest of the commands. Getting hjkl into your muscle memory also makes it easier to play Nethack.
You can easily get colors in vim in any modern terminal emulator. That said, I still use gvim so that I can have vim in a separate window, and not constantly having terminals eaten up by text editors.
For closing brackets, there are a few strategies you can use. First, you can always write your opening and closing brackets together, and then fill in the space between them.
You can also modify your vimrc, maybe with a plugin, that will highlight mismatched brackets. You could even set it to make a closing bracket when you make a starting one.
Another thing I recommend is to have a linter run on save. For python I use flake8. So in vim whenever I write a .py file to disk, it checks it over and alerts me of any issues. This includes things like variables that get assigned and never used, blatant syntax errors, mismatched indenting, lines that are too long, etc. Similar static analysis tools exist for every language, and are very good.
Thanks for the tips I'll implement the ones that suit me over the weekend. I'm predominantly going to be writing in C (on Linux) so indenting will be mainly for readability.
However when I become very comfortable with using tabs appropriately I'll have less problems when writing in Python.
I'm getting more comfortable, main hurdle now is efficient use of Visual mode.