29981Re: What a to-do!
- Oct 3, 2002Walter Briscoe wrote:
> I quote from the vim 6.1.1-100 todo.txt:I suppose this is actually for gvim.
> > Win32 console:
> > 9 When editing a file by its short file name, it should be expanded into its
> > long file name, to avoid problems like these: (Mccollister)
> > 1) Create a file called ".bashrc" using some other editor.
> > 2) Drag that file onto a shortcut or the actual executable.
> > 3) Note that the file name is something like BASHRC~1
> > 4) Go to File->Save As menu item and type ".bashrc" as the file name.
> > 5) Press "Yes" to indicate that I want to overwrite the file.
> > 6) Note that the message "File exists (use ! to override)" is displayed
> > and the file is not saved.
> > Use FindFirstFile() to expand a file name and directory in the path to its
> > long name.
> I built a console vim with Make_ivc.mak.
> I tried vim -u NONE -U NONE shrtname. vim started as if I had done
> vim -u NONE -U NONE "long file name". This happened in both WME and W95.
> I shall try the precise problem reported on W95.
> 1) done (echo hello > .bashrc)
> 2) Dragged
> 3) File name is .bashrc rather than BASHRC~1 or similar
> 4) No file menu. I think this MIGHT refer to gvim
> 3a) File name is C:\TEMP\BASHRC~1Either it depends on the version of MS-Windows or it was already fixed.
> 4a) File-Save default name is .bashrc. No override needed.
> Is there any problem?
In win98 I do get a message about editing BASHRC~1, but the buffer name
is .bashrc. That means the conversion to a long filename was already
> > 8 ":winpos" doesn't work. Patch from Vipin Aravind.It also works for an xterm. If there is a way to make it work in a
> It works for me in gvim. It does not work in vim. Why should it do so?
> It is documented as:
> > :winp[os]
> > Display current position of the top left corner of the GUI vim
> > window in pixels. Does not work in all versions.
console window, why not do it?
> I shall look at:It would be good if you can fix this. I did an attempt once, but
> > 9 When using libcall() for a function that returns an invalid pointer, Vim
> > crashes. Check for a bad pointer with isBadReadPtr() doesn't appear to
> > work well.
> Steve Oualline's book does not mention libcall. I see it is mentioned in
> version5.txt as a contribution from Negri. Perhaps Vince can get me up
> to speed with a demonstration of the feature. It must be useful as it
> was originally implemented only in Win32 and is now also done in UNIX.
couldn't find a way to avoid a crash. Best is if any use of libcall()
detects that a pointer is not valid and gives an error message instead
Nobody will ever need more than 640 kB RAM.
-- Bill Gates, 1983
Windows 98 requires 16 MB RAM.
-- Bill Gates, 1999
Logical conclusion: Nobody will ever need Windows 98.
/// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
/// Creator of Vim - Vi IMproved -- http://www.vim.org \\\
\\\ Project leader for A-A-P -- http://www.a-a-p.org ///
\\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
- << Previous post in topic Next post in topic >>