Using GVim instead of Vim on Windows
Peter Salzman
I installed Vim for Windows on Windows XP. I'd like to open a text
file with GVim, not Vim.
* I double click an icon. It opens up in Vim.
* I right click an icon and choose "Edit with Vim". I opens in GVim.
* I right click an icon and choose "Open With" and select "Vim". It
opens in Vim.
* I right click an icon and choose "Open With | Choose Program...".
Then I click on Vim. It opens up in Vim.
* I right click an icon and choose "Open With | Choose Program...".
Then I click on Browse and select "D:\Program
Files\vim\vim72\gvim.exe". Windows doesn't seem to like this because
it throws me back into the "Open With" window as if gvim.exe wasn't a
proper executable.
* From the Windows explorer, I choose "Tools | File Types | Txt |
Advanced". I choose "Open | Edit". I see this in the "Application
used to perform action":
"D:\Program Files\vim\vim72\gvim.exe" "%1"
which looks ok to me.
How do I coax Windows to use GVim, not Vim?
Thanks!
John Beckett
> I installed Vim for Windows on Windows XP. I'd like to open
> a text file with GVim, not Vim.
There probably is a way to fix whatever is wrong, but frankly a better
idea might be to start again. At the following, choose "Windows Vim
installers without Cream" and install the latest (7.2.101 at the moment,
vim.exe and gvim.exe):
http://cream.sourceforge.net/download.html
You should uninstall what you have now (assuming it's not the above). I
always start Vim from the command line, so I'm not sure about the file
associations, but uninstalling should remove the registry settings you
have now.
John
Tony Mechelynck
Method I
--------
Create (or modify) your own desktop icon with "Gvim" as the name and
"D:\Program Files\vim\vim72\gvim.exe" "%1" as the command. The icon will
probably be OK but if (after setting the Command) it isn't, you can get
the right one from the gvim.exe binary.
Method II
---------
1. Make sure that "D:\Program Files\vim\vim72" (without the quotes) is
part of your PATH, which IIRC is a semicolon-separated list. How to set
the PATH varies between versions of Windows; on XP it is (IIRC) in
"Control Panel => System => Advanced => Environment variables" (or, if I
didn't RC, somewhere not too far from that).
2. Start a Dos Box (for instance by invoking cmd.exe in the Execute item
of your Start Menu). You may keep that Dos Box constantly open, it is
very useful. Start gvim from the command-line, as (e.g.)
gvim.exe filename.ext
or even without a filename if you want it to open on its "splash screen"
without editing an existing file.
Best regards,
Tony.
--
The basic idea behind malls is that they are more convenient than
cities. Cities contain streets, which are dangerous and crowded and
difficult to park in. Malls, on the other hand, have parking lots,
which are also dangerous and crowded and difficult to park in, but --
here is the big difference -- in mall parking lots, THERE ARE NO
RULES. You're allowed to do anything. You can drive as fast as you
want in any direction you want. I was once driving in a mall parking
lot when my car was struck by a pickup truck being driven backward by a
squat man with a tattoo that said "Charlie" on his forearm, who got out
and explained to me, in great detail, why the accident was my fault,
his reasoning being that he was violent and muscular, whereas I was
neither. This kind of reasoning is legally valid in mall parking
lots.
-- Dave Barry, "Christmas Shopping: A Survivor's Guide"
Ben Fritz
On Feb 15, 3:29 am, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
> Method II
> ---------
> 1. Make sure that "D:\Program Files\vim\vim72" (without the quotes) is
> part of your PATH, which IIRC is a semicolon-separated list. How to set
> the PATH varies between versions of Windows; on XP it is (IIRC) in
> "Control Panel => System => Advanced => Environment variables" (or, if I
> didn't RC, somewhere not too far from that).
will automatically place batch files in C:\WINDOWS\system32 (already
in your path) with names like gvim.bat, vim.bat, etc.
> 2. Start a Dos Box (for instance by invoking cmd.exe in the Execute item
> of your Start Menu). You may keep that Dos Box constantly open, it is
> very useful. Start gvim from the command-line, as (e.g.)
>
> gvim.exe filename.ext
>
> or even without a filename if you want it to open on its "splash screen"
> without editing an existing file.
>
automatically placed batch files do their thing.
Tony Mechelynck
When I was on Windows, I always directly invoked the binary, with no
noticeable ill effects.
Best regards,
Tony.
--
There's nothing wrong with America that a good erection wouldn't cure.
-- David Mairowitz
Ben Fritz
On Feb 17, 2:17 am, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
>
> noticeable ill effects.
>
you'll need to go through the hassle of setting your path to the new
Vim install directory instead of the old. I've been meaning to change
all my file associations to the batch files as well to get around the
upgrade issue there too, but have never gotten around to it.
Tony Mechelynck
>
>
> On Feb 17, 2:17 am, Tony Mechelynck<antoine.mechely...@gmail.com>
> wrote:
>
>> When I was on Windows, I always directly invoked the binary, with no
>> noticeable ill effects.
>>
>
> Right, nothing wrong with that...it's just that when you upgrade Vim,
Only for a new minor release, which isn't often enough to bother me, and
requires extra work anyway with my workflow, to get the source and make
it ready for compilation.
Not for a new patchlevel.
> you'll need to go through the hassle of setting your path to the new
> Vim install directory instead of the old. I've been meaning to change
> all my file associations to the batch files as well to get around the
> upgrade issue there too, but have never gotten around to it.
Of course, on Linux (where I am now), "make install" (or "make
installvimbin" which I use for my "tiny" version named vi) takes care of
placing the binary in the $PATH; and my existing softlinks (in
/usr/local/bin/ : view -> vim, vimdiff -> vim, gvim -> vim, gview ->
vim, etc. etc. etc.) don't need any change.
Best regards,
Tony.
--
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense.
-- E. W. Dijkstra
Oh, yeah? "Against oppression, insurrection is for the people the most
imprescriptible of rights and the holiest of duties" (Declaration of the
Rights of Man and Citizen, 1789). If someone, be he named Dijkstra or
anything else, tries to tell me in what languages I "may" program and to
put his "laws" to execution, I shall treat him as an oppressor. You
Vimmers be the judges of whether the years I spent programming mostly in
COBOL (and some in assembly language) crippled my mind.
John Little
On Feb 18, 4:48 am, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
> If someone, be he named Dijkstra or
> anything else, tries to tell me in what languages I "may" program and to
> put his "laws" to execution, I shall treat him as an oppressor. You
> Vimmers be the judges of whether the years I spent programming mostly in
> COBOL (and some in assembly language) crippled my mind.
effects on others, I must allow that he (Dijkstra) has, or had, a
point. Perhaps I have a "that which did not kill me, made me stronger"
attitude, but "crippling" is not too string a word for some former
colleagues, particularly cobol-74.
Regards, John
Tony Mechelynck
My "political opinion" is that you're free to cripple your _own_ mind as
much as you want, as long as you don't do harm to _others_. So the
criminal offence, if any (which remains to be seen), might be _teaching_
COBOL or _requiring_ its use, but not _using_ it. BTW, I didn't notice
any crippling effect of COBOL-60 (or of whatever standard we were
following in 69 or so) on my colleagues' minds. I'd say Dijkstra had the
parochial view of a C-only programmer, and when I want to produce
nice-looking reports, I'd say COBOL wins hands down over C every time.
If you say COBOL-74 was different from "my" COBOL in crippling terms, I
have to defer to you. Was COBOL-74 freeform already? Or was it only the
result of the "structured programming" fashion wave which tended to
eliminate all GO TO statements from COBOL, even those targeting the EXIT
paragraph at the end of a called subroutine? "My" COBOL was fixed-form
and with-GO-TO, but we had a head programmer who strongly disliked
"spaghetti style" and enforced a "house style" which was quite readable
IMHO.
Best regards,
Tony.
--
You need no longer worry about the future. This time tomorrow you'll
be dead.
John Little
On Feb 21, 12:02 am, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
> criminal offence, if any (which remains to be seen), might be _teaching_
> COBOL or _requiring_ its use, but not _using_ it.
with whoever gets to maintain the code.
> If you say COBOL-74 was different from "my" COBOL in crippling terms, I
> have to defer to you. Was COBOL-74 freeform already?
all-variables-global data division. Cobol-85 cleaned things up a lot,
enabling logic to coded straightforwardly. But the cripples I
referred to were so enamoured of their copy books with GO TO paragraph-
exit they enshrined it in the coding standards. go tos are bad, but
when they're in copy books (included code), going to places in other
copy books, I find the notion of brain damage inescapable. That might
have been one shop going off on a tangent, but I encountered the same
practice (among other heinousness) on another unrelated project.
(That included something that was arguably criminally negligent,
because it concealed a back door that could be used to affect money
transfers.)
This may seem off-topic, but IMO is relevant to vim-dev at least.
Vim's developers might be aware of some aspects of the "house-style".
Regards, John
_sc_
this sounds like a fun rant -- i can't not jump in, forgive me
you haven't lived until you've been required to modify an old cobol
program that made liberal use of altered gotos
eg: ALTER A210 TO GO TO B103.
that is what the paragraph names were like -- a letter and a number
-- they came from the flow charts on which the programs were
initially designed, made no sense whatsoever without the flow
charts, and of course the flow charts were nowhere to be found
now, while trying to wrap your mind around that, imagine the
program processes lab results in a hospital, and you either get the
modification right or people could wind up dying because the result
of their lab test came from some other patient
i was never quite so glad as when i got out of that hospital and
into a nice safe insurance company doing new c++ development
oh wait -- yes i was -- when my financial advisor told me i could
retire any time now -- tee hee
sorry for the bandwidth,
sc
Tony Mechelynck
Hm. When I learnt programming, "structured programming" wasn't yet "the
only way to go". Of course we called subroutines using PERFORM, but
nothing prevented using GO TO within a single routine, especially to go
to the EXIT paragraph at the end of the subroutine (a "return" in the
middle of a function, or a "break" in the middle of a while-loop, do the
same in C or in vim-script under another guise, don't they?). And since
the DEPENDING clause could only be used with GO TO, another GO TO might
be necessary when coming back. Self-modifying code (the ALTER statement)
was used only in very special and well-documented cases.
As for money transfers, I never worked for a bank. At first I was in a
servicebureau, where we programmers made programs for various clients
(mostly accounting OT1H and payrolls OTOH), but code from any programmer
belonged to the firm and could be seen and worked on by any other
programmer if necessary (for instance, if the original "author" went ill
or left the firm). Later I worked for a subsidiary of Electrolux, where
I converted an existing production database to an SQL-based system from
some outside software maker. Here, money transfers didn't even enter the
program's workings IIRC.
As for the CALL statement, it wasn't invented when I first learnt COBOL
(subroutines were called using PERFORM, which, whatever you might think,
was perfectly usable). Later, CALL was added as a non-ANSI extension to
call assembly-language subprograms as in
ENTER COMMUNICATION-MODE.
CALL external-name [USING data-name-1 ... data-name-n].
ENTER COBOL.
which an even later ANSI standard would simplify to
ENTER language-name external-name [USING data-name-1 ... data-name-n].
(where, on the system where I worked then, language-name was required
but documentary only, couldn't be COBOL, and didn't influence the
generated code). This was one of the reasons I got an interest in
assembly language: to do some things which weren't reasonably feasible
in COBOL, such as translating input from 9-track tapes, read by the
hardware into two characters per byte, to the 6-bit characters of that
processor; or later to improve the performance of the critical parts of
some programs which did what they had to do, but much too slowly. Also
to circumvent the fact that the INDEXED BY clause hadn't yet been
invented, which meant that subscripts had to be in decimal while the
hardware (which couldn't do binary multiplication) addressed memory in
binary.
Best regards,
Tony.
--
No man may purchase alcohol without written consent from his wife.
[real standing law in Pennsylvania, United States of America]
Tony Mechelynck
almost:
ALTER procedure-name-1 TO [PROCEED TO] procedure-name-2.
where PROCEED and the second TO were (IIRC) not required by the language
but we always used them, if only because (in those times) COBOL source
was supposed to be "better" if it resembled English language, so some
verbosity was preferred over hardly-understandable terseness.
procedure-name-1 had to be a paragraph with nothing else than a GO TO
statement in it.
>
> that is what the paragraph names were like -- a letter and a number
> -- they came from the flow charts on which the programs were
> initially designed, made no sense whatsoever without the flow
> charts, and of course the flow charts were nowhere to be found
Where I worked, flow charts had to be religiously kept with the
program's documentation, and anyway, any of us programmers was quite
adept at reconstituting a missing flowchart from the source code. But
finding that a flowchart was missing was a good reason for a serious
look at the AUTHOR paragraph of the IDENTIFICATION DIVISION --
well-fleshed-out IDENTIFICATION DIVISIONs were part of the "house style"
which our senior programmers insisted on when teaching newbies --
programming degrees didn't exist when I started, and most of the
learning was done on the job. Another part of that house style was fixed
columns in the DATA DIVISION, such as VALUE, OCCURS, REDEFINES and
similar clauses in column 40 and the word PICTURE written in full
starting in column 52 (so that the "picture" itself always started in
column 60). (This was fixed-form COBOL on 80-character Hollerith cards,
remember? It could be saved onto tape, and usually was, but still with
80-character fixed-length lines.)
However, what often happened was that bugfixes to the source code
weren't always mentioned in the flowcharts: if the code and the
flowcharts don't agree, the code tells you what the program is doing
now, the analyst's specs (usually) tell you what it ought to do, and the
flowchart on file usually tells you how the original programmer thought
the specs should be implemented. When trying to find a bug, all three
are complementary, plus (for instance in case of a crash) the memory
dump we got from the operator when a UEP error (Unusual End of Program)
happened, usually for out-of-range subscript, which in turn most often
was a symptom of an off-by-one error in the bounds of a PERFORM VARYING
statement. (No stack trace, we didn't use that, recursive subroutines
were an unknown thing on those OSes.)
>
> now, while trying to wrap your mind around that, imagine the
> program processes lab results in a hospital, and you either get the
> modification right or people could wind up dying because the result
> of their lab test came from some other patient
:-) Happily for me, maybe, I never worked for a hospital. What I did
work on was one program for a simulation of a marshalling yard for the
International Railways Union, various accounting jobs within
(well-documented) software packages written by other people of the firm,
some job over a production database, and also (but not in COBOL) keeping
an eye on the system software (which, in those times, was distributed
with its source) and writing some assembly-language modules to be called
from COBOL.
>
> i was never quite so glad as when i got out of that hospital and
> into a nice safe insurance company doing new c++ development
>
> oh wait -- yes i was -- when my financial advisor told me i could
> retire any time now -- tee hee
>
> sorry for the bandwidth,
well, I guess I used much more than you did over the whole of this thread.
>
> sc
Best regards,
Tony.
--
Never let your sense of morals prevent you from doing what is right.
-- Salvor Hardin, "Foundation"