Double Commander is an open source file manager in the likeness of the venerable Norton Commander. By default its View (F3) and Edit (F4) options open the file for viewing or editing with its own internal viewer and editor. On Windows 7, I like to set the viewer and editor as GViM, which can be set in the Configuration → Options → Tools. However, this setting does not work, since View (F3) or Edit (F4) does not do anything.
This is due to a bug in Double Commander, which cannot handle a path with spaces. On Windows 7, ViM is typically installed to
C:\Program Files (x86)\Vim\vim72, which is a path with spaces. To make Double Commander handle this, open the Tools dialog (like above) and enclose the path to gvim.exe (or any executable) in double quotes. View (F3) and Edit (F3) should work after this.
Tried with: Double Commander 0.4.5.1 Beta
xplorer2 Lite is a fantastic 2-pane file manager that I use on Windows. After moving to Windows 7, I noticed that xplorer2 Lite was not displaying the icon overlays applied by Explorer extensions like TortoiseSVN and TortoiseHg. Also, their right-click context menus were not displayed on right-clicking files or folders in xplorer2 Lite.
The problem is that I was using xplorer2 Lite, a 32-bit program on 64-bit Windows. So, it cannot display the icon overlays or context menus of 64-bit Windows Explorer. Until a 64-bit version of xplorer2 Lite is released, there seems to be no solution to this problem.
Tried with: xplorer2 Lite 220.127.116.11
How was I not aware of this useful shortcut?! :-)
After changing Python installations on Windows, you may find that Python is ignoring the commandline parameters passed to a Python script.
To fix this, open regedit.exe, head over to
HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command and make sure the value field is
"C:\PYTHON_PATH\python.exe" "%1" %*. If the
%* is missing, then the Python script will not have access to the commandline parameters passed to it.
convert.exe from the installation of
ImageMagick-6.6.3-3-Q16-windows-x64-dll.exe gives this error:
The program can’t start because CORE_RL_wand_.dll is missing from your computer. Try reinstalling the program to fix this problem.
The packagers have forgotten this DLL. The solution is to install the statically linked
ImageMagick-6.6.3-4-Q16-windows-x64-static.exe or try a x64-dll.exe installer of an older version.
You might feel the need to publish Mercurial repositories in a central location and collaborate using that. This is really useful when:
- You are working from 2 or more workstations or laptops.
- You are in a small team and there are 2 or more people working on the project.
Publishing a Mercurial repository in a central location enables different people or computers to push and pull from it. There are a few common ways to do this:
- hg serve: Real easy and quick to setup with simple features.
- SSH: Not as easy on Windows as on Linux. OpenSSH server is the most common option, but it comes with Cygwin and all its problems.
- HTTP: Requires quite a lot of configuration on Windows.
- SMB: If you are on a Windows network, your computers or team is small in number and your needs are simple, then using a Windows share is very compelling!
You can start publishing Mercurial repositories using Windows shares in just a few minutes:
- Designate one computer as the central repository server. Let us call it A. It can be the workstation of the one of the team members, it does not really matter. Other computers, B and C, should be in the same Windows network as A.
- Create a directory on A, say
D:\HgReps and move all your current repositories to it. New repositories in the future should also be created here.
- Share the directory on A, so it becomes
\\A\HgReps. Give only the team members who use A, B and C access to read and write to this share. You could also give read access to other users who you wish only pull from A. These access permissions should be very easy to configure if you are in a well set up Windows domain.
- Point all the current working directories on A, B and C to push and pull from
\\A\HgReps. To do this, open the
.hg/hgrc file in each working directory and edit it so it points to A. For a project named Foobar, the
.hg/hgrc file looks like:
default = \\A\HgReps\Foobar
All this setup is ridiculously easy to do for a small team and everything just works without much configuration. Another nice side-effect is that you can backup the
D:\HgReps on computer A easily and grab all the team’s commits.
Mercurial users keep insisting that you do not really need to create actual branches to work. But, if you are one of the few who likes to do this, merging branches is just as easy too. I use TortoiseHg, but the equivalent command-line options are just as obvious.
- Consider branches A and B. You wish to merge B to A, so that work on A can continue. Typically, A might be the default branch and B can be a feature branch.
- Finish, test and commit all the files on both branches A and B.
- Open Repository Explorer. Update the working directory to branch A. This can be done by choosing the head of branch A, right-click and choose Update.
- Choose the head of branch B, right-click and choose Merge with. Tip of branch A will automatically be chosen as the target for the merge. Click Merge.
- Mercurial will try to merge the files automatically as much as possible. For the files with merge conflicts, it will pop up KDiff3 windows so you can pick the changes you want merged. The conflict windows are displayed sequentially, finish one and the next one is displayed.
- Settle all the conflicts and your merge is done! Branch B should be connected to branch A nicely in the graph displayed in Repository Explorer now.