I was an Eclipse user, now I have to use Vim in my machine.
I used to "compare" a file I edited with a CVS repository to do merges an commit the files, using a context menu and my mouse.
Is this possible in Vim? Opening a vimdiff for a file before commiting, and commit it from vim itself?
And how is that supposed to work?
I'm supposing I would be editing a file. Then, I want to see the modifications. I run vimdiff in gvim, and a new window (or buffer) is opened. I run the modifications, save what is applicable (using vimdiff commands), and commit running another command.
Is this all transparent in vim? Do I have to keep getting out of vim to my terminal, or can all be done inside it?
Do I need to use some plugins, or just really simple functions inside my vimrc?
There is a couple plugins to integrate VCS to vim.
I personnally use vcscommand. It does at least the 2 things you're asking for: comparing from repository using vimdiff and commiting from within vim.
I personally just switch between vim and the terminal.
Usually I'd have several console tabs open at the same time (if you're on windows, Console can do that).
It depends on the VCS used, but you can linked that VCS with vimdiff (see git, for instance)
You could also try and integrate directly Vim into your Eclipse session with eclim.
(should you still be using eclipse. If not, I leave the following for others)
It does support the Eclipse local History.
Related
Suppose that I have a map on my init.vim that I want to change the behaviour depending on the folder that I am. How could you do that?
A more concrete example: I have a map on my F12 that runs the project that I am. So if I am on a python project, this F12 will run an ipython on a floaternew window, with the current file already imported. Though, if I am on a cpp project, the same F12 will build using Make and running the binary on a floaternew window as well.
Nowadays, I have these two behaviours mapped on different key bindings. But It is going to very nice if I have only one binding to "run the project". Even if I need to open neovim with some parameter in each project, like neovim --local-config mylocalconfig.vim (extending init.vim with some behaviour)
I am kind inspired by a behaviour like direnv but with .vim files.
Any ideas?
There is an option in vim set exrc which enables reading vim config files from current directory, it also works in neovim.
From docs (:h exrc)
Enables the reading of .vimrc, .exrc and .gvimrc in the current
directory. If you switch this option on you should also consider
setting the 'secure' option (see |initialization|). Using a local
.exrc, .vimrc or .gvimrc is a potential security leak, use with care!
also see |.vimrc| and |gui-init|.
This option cannot be set from a |modeline| or in the |sandbox|, for
security reasons.
I have emacs24 and emacs25 on my machine. I want to use spacemacs with emacs24 and keep emacs25...well...as emacs. When I install spacemacs my ~/.emacs and ~/.emacs.d are changed. Both emacs start using spacemacs, which I do not want. Is there a way to have a spacemacs and an emacs at the same time. Tried looking for a solution and came across a solution to keep separate config files. But how to make emacs look for a specific config file. By the way if you still haven't guessed...I'm a noob.
At one level, this is quite easy to do. However, at another, there can be some
complications, depending on what you really want to do.
Emacs supports a command line switch -l to tell emacs where to find the config
file. So, from a very simple perspective, you could just create two wrapper
scripts my-spacemacs.sh and my-plainemacs.sh and inside them have the scripts
call emacs with a specific -l /path/to/config. You can pass $* to pick up other
command line arguments if you want.
The potential problem with this approach is that emacs will still use .emacs.d
to store all sorts of other information, including possibly elpa packages and
this could cause problems. To be safer, it is better to keep things completely
separate.
If you don't need to run both versions at the same time, the easy solution is to
have to separate directories, such as ~/.spacemacs-emacs.d and ~/plain-emacs.d
and then have a sym link called .emacs.d which points to whichever of the
versions you want to run. The two main problems with this approach is that you
need to reset the symbolic link whenever you want to change emacs flavors and
this won't work if you want to run both versions at the same time.
I guess we really need to know about your actual use case - why do you need two
different configurations? Knowing this could help identify a better approach.
As an example, I use org mode and babel to manage my emacs config. I have a
number of different versions and a simple script which I can run to generate
whichever init.el file I want from the different org files. I have a minimal.org
file, which has the most minimal emacs configuration I can bare and I have my
standard init.org which generates my working init.el and then I have an
experimental.org which is used to generate an init.el file which I use for
experimenting with new configurations or packages. It is trivial to switch
configurations, but I never need to run two different configurations at the same
time.
I often like to check out some of the other pre-cooked emacs setups, like
spacemacs, prelude, etc. for these, I just grab the current git version and use
a symbolic link to point .emacs.d at the root fo the git repo I want to
experiment with.
you can also use the following approach:
create a directory ~/spacemacs.
extract/copy the spacemacs .emacs.d into ~/spacemacs (so that it is ~/spacemacs/.emacs.d).
create a desktop link called Spacemacs (or menu entry) and enter the following command:
HOME=$HOME/spacemacs emacs
You can also start spacemacs from the shell with this command.
This way, you can run vanilla emacs and spacemacs simultaneously, each with its own configuration directory and elpa repository. The only disadvantage might be that you need to change a directory level upward to reach your real home directory, not the „fake” one set via the variable.
btw, this is how I run several emacs versions and configurations, as needed for diverse stuff.
The best solution seems to be using chemacs: https://github.com/plexus/chemacs
I'm using vim in cygwin writing javascript code, using eclipse tomcat as web server. I checked the preference refresh using native hooks or polling. But after I write the buffer in vim, the project won't get refreshed, so the hosted application won't get republished neither. Only after I press F5 on the project manually, then everything works fine. Can someone help here? What am I doing wrong?
By default, Vim writes the file contents to a temporary file and then moves that over the original, see :help backup. Since this is now a different file (handle), the hooks set up by Eclipse may stop working.
You can make Vim override the original file by setting
:set backupcopy=yes
OK< I know I can use Eclipse for Java programming and such but I work using WAMP for editing PHP, XHTML, JavaScript files... what IDE is best to edit the files and use GitHub? Because I don't know want to go to localhost and then copy my files to my local GitHub repo...
Cloud9 IDE might be what you are looking for! It's an online IDE with out-of-the-box intergration with GitHub, heroku etc. and gives you the ability to share workspaces as well.
Eclipse has the egit plugin that is really nice. You can use aptana which is based around eclipse but includes all the web views. It can basically edit everything you mentioned and really well, while providing a nice wrapper for your git repos
http://aptana.org/products/studio3
http://eclipse.org/egit/
well is not an IDE but vim with some git plugins is the best for me.
Eclipse should have some git plugins also, I think.
The best way to learn git is yo use it from command line!
Emacs + tramp + the command line ?
Update: magit is reported to support tramp
Update:
My experience: I have a distant linux server running a rails app. and private git repositories / apache (using several VirtualHosts with or without ssl). That server runs a ssh server. I use bare ssh session for command line usage (git, nominal admin.) and emacs + tramp to remotely edit the files presents on that server. I you are not rebuked by anti-eye candies tools (as for not-at-all drag'n'drop stuff), I would suggest you to give emacs a try (see EmacsW32 and nXhtml if you are under Windows). I assume you can install a ssh server on your WAMP machine… If this is the case, you could open your file from emacs just by using the following syntax (assuming you would edit the /home/renaud/.bashrc on the distant server):
/ssh:user#obf.uscatedmachine.org:/home/user/.bashrc
With putty on windows: see that and this posts.
It works the same for directories. You shall be prompted for your password once, and then edit the file/directory as if it is just on your machine. For the git part, I have verified myself since I do the git stuff directly from a ssh terminal, but latest magit
is reported to support tramp (i.e. remote git plumbering from my understanding).
If you have never used emacs before, it will not be easy. You will have to learn emacs basics first and customize it to fit you needs. My opinion is that's worth to give it a try. I could help you with basic configuration if needed.
(I use myself emacs almost for everything on my linux box from simple text editing to Java programming.)
Update:
After some testing, magit works very well remotely (tested on linux)! A new mode added to my configuration thanks to your question!
I've been spending a lot of time utilizing Mercurial. On windows, I've been using TortoiseHg and on Linux and Mac OS X, I've been (forced) to use the console interface.
After spending time with the console utilities, I find (to my surprise) that I do like them.
But, most of my usage has been superficial. I've been doing basic clones, pulls and merges with the rare but occasional commit. I've not done any heavy lifting with it.
What I'm curious about is if regular users use the console interface of tools like Mercurial, SVN and/or git for real world, day-to-day development? Until now, I've never given the console program of SVN much thought -- I've always used TortoiseSVN.
I realize that there is no real answer to this question (Hence, it's community wiki) but I thought other real-world insight would be beneficial. If others have successfully used these console programs, perhaps it's worth using them more.
So, do you use the console programs on a regular day-to-day basis or do you only use them when you need to?
Note: I do realize that people use the console programs. It is ridiculous to think they are not used. This question is focused on day-to-day use for average developers for average development. Average being that you generally use GUI interfaces and/or you are developing GUI applications.
I develop primary on OS X, frequently on Linux, and occasionally on Windows. The only place I don't use the console utilities is in Windows, where I'm not as familiar (and thus not as productive) with the console. On OS X and Linux, I exclusively use the command-line utilities for Git, Mercurial, and Subversion. I find the command-line utilities to be more powerful (especially in the case of Git), and I feel more "at home" with them.
I do use gitk and GitX (a gitk-like program for OS X) to visualize Git histories, but that's the only GUI tool I use.
I use the svn binary regularly on Unix, doing "svn up", "svn diff", "svn commit", "svn ann", and "svn log" most of the time. I prefer the command line, because I have a shell window open in the source anyway (to run builds and tests), and along with file name completion, using the keyboard is faster than using the mouse for me.
I use Mac and I love git to be used in command line.
I use the following utilities & tools to make productive & intuitive.
Git aware prompt to show the currently checkout branch all the time
Iterm2 as a replacement for the default Mac terminal
Meld as git diff & mergetool
Both Iterm2 & Meld can be installed via homebrew (brew cask install meld)
My terminal screen looks like:
Source Tree is a must have GUI tool if you don't love CLI so much.