Jens Paulus wrote:

> alright, maybe my description was wrong. Try the commands `ay<C-V>`c and
> `ad<C-V>`c and you should see that the character at mark c is not
> included.

I can reproduce this one.  I'll fix it.

--
hundred-and-one symptoms of being an internet addict:
200. You really believe in the concept of a "paperless" office.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///

Johnny Blaze wrote:

> I have attached a patch to Make_mvc.mak.  It adds another CPUNR option
> and removes some debug options from CFLAGS, PDB, and LINK_PDB.
>
> CPUNR: Adds "P4" to the list.  It uses the options /G7 and /arch:SSE2.
>  This causes CL to optimize the code specifically for P4 and AMD
> processors that implement SSE2 instructions.  /arch:SSE2 is a new
> option as of VC7.0.

Looks OK.  P4 also needs to be added to the comments at line 58.

> CFLAGS: Removed /Zi in the no-debug block.  According to Microsoft, if
> you use this, it adds debug information to the assemblies and marks
> them as debug.  This slows down execution.

OK.

> PDB: Removed all options in the no-debug block.   If there is no PDB
> created, why give this option?
>
> LINK_PDB: same as above

OK.

> On PDB and LINK_PDB, Microsoft indicates that these options take a
> file name, but the makefile gives a directory.  Is this correct?

Perhaps this is for an older version of MSVC?

I notice you also changed "-MD" to "/MD".  Specific reason?

> VIM 7.0026 fails these tests:
>
> test54 - test.out has double-quotes around the text, while test54.ok does not.
> test11 - It looks like line-endings problems
> test30 - this still gives line-endings problems
>
> These tests were ran from a CVS working directory.  I restored
> test30.in and test30.ok from the snapshot zip and the problem went
> away.  I know you had test30.ok marked as binary, does it need to be
> checked in again?  I tried restoring test11.in and test11.ok, but it
> failed both ways.
>
> These tests were performed using the options in the in included
> makefile patch as well as a standard makeflie with CPUNR=i686.

I only see the problem with test54.  The others must be caused by
unix/dos fileformat trouble.  I use the files copied from Unix and then
change 'fileformat' in all files to dos.

Test 54 can be fixed by removing the quotes from test54.in.  Also remove
the space before ">>".

I would think that for CVS all test files should actually NOT be marked
binary, so that the line endings are adjusted.  Problem is that this
process apparently fails to work properly, not adding a CR to a line
that already ends in a CR.  I don't know how to solve that...

Otherwise, we would need to run a script that fixes the fileformats
before running the actual tests.  It seems using this in
src/testdir/Make_dos.mak works:


nongui: fixff $(SCRIPTS16) $(SCRIPTS)
         echo ALL DONE

small:  fixff $(SCRIPTS16)
         echo ALL DONE

gui:    fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS_GUI)
         echo ALL DONE

win32:  fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS32)
         echo ALL DONE

fixff:
         -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok


If this works properly then ALL files in src/testdir can be marked binary.

--
hundred-and-one symptoms of being an internet addict:
196. Your computer costs more than your car.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///

On Sat, 01 Jan 2005 14:23:06 +0100, Bram Moolenaar <Bram@...> wrote:
>
> Johnny Blaze wrote:
>
> > I have attached a patch to Make_mvc.mak.  It adds another CPUNR option
> > and removes some debug options from CFLAGS, PDB, and LINK_PDB.
> >
> > CPUNR: Adds "P4" to the list.  It uses the options /G7 and /arch:SSE2.
> >  This causes CL to optimize the code specifically for P4 and AMD
> > processors that implement SSE2 instructions.  /arch:SSE2 is a new
> > option as of VC7.0.
>
> Looks OK.  P4 also needs to be added to the comments at line 58.

got it.

> I notice you also changed "-MD" to "/MD".  Specific reason?

sorry, I meant to change that back.  I looked it up, cl and link
should both take either - or / without differences.

I have attached an updated patch.

--

.  o O pyromancer O o  .

On Sat, 01 Jan 2005 14:23:06 +0100, Bram Moolenaar <Bram@...> wrote:

> I would think that for CVS all test files should actually NOT be marked
> binary, so that the line endings are adjusted.  Problem is that this
> process apparently fails to work properly, not adding a CR to a line
> that already ends in a CR.  I don't know how to solve that...
>
> Otherwise, we would need to run a script that fixes the fileformats
> before running the actual tests.  It seems using this in
> src/testdir/Make_dos.mak works:
>
> nongui: fixff $(SCRIPTS16) $(SCRIPTS)
>         echo ALL DONE
>
> small:  fixff $(SCRIPTS16)
>         echo ALL DONE
>
> gui:    fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS_GUI)
>         echo ALL DONE
>
> win32:  fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS32)
>         echo ALL DONE
>
> fixff:
>         -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok
>
> If this works properly then ALL files in src/testdir can be marked binary.

test30 and test11 still fail with fixff added.  I could only get
test11 to be successful if I change the line in test11.in:"set nobin
ff&" to "set nobin ff=unix". test30 is only successful if I restore
test30.ok from the snapshot (and keep fixff from changing it).


--

.  o O pyromancer O o  .

Johnny Blaze wrote:

> On Sat, 01 Jan 2005 14:23:06 +0100, Bram Moolenaar <Bram@...> wrote:
>
> > I would think that for CVS all test files should actually NOT be marked
> > binary, so that the line endings are adjusted.  Problem is that this
> > process apparently fails to work properly, not adding a CR to a line
> > that already ends in a CR.  I don't know how to solve that...
> >
> > Otherwise, we would need to run a script that fixes the fileformats
> > before running the actual tests.  It seems using this in
> > src/testdir/Make_dos.mak works:
> >
> > nongui: fixff $(SCRIPTS16) $(SCRIPTS)
> >         echo ALL DONE
> >
> > small:  fixff $(SCRIPTS16)
> >         echo ALL DONE
> >
> > gui:    fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS_GUI)
> >         echo ALL DONE
> >
> > win32:  fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS32)
> >         echo ALL DONE
> >
> > fixff:
> >         -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in
*.ok
> >
> > If this works properly then ALL files in src/testdir can be marked binary.
>
> test30 and test11 still fail with fixff added.  I could only get
> test11 to be successful if I change the line in test11.in:"set nobin
> ff&" to "set nobin ff=unix". test30 is only successful if I restore
> test30.ok from the snapshot (and keep fixff from changing it).

Did you check out the files in Unix mode, thus without CVS doing any CR
adding?  I suspect it only adds a CR when there isn't one already, that
breaks the tests.  Vim adds a CR to every line, then it should be OK.

--
$ echo pizza > /dev/oven

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///

In message <804f592d04123117177ef4e581@...> of Sat, 1 Jan
2005 07:17:02 in , Johnny Blaze <pyromancer@...> writes
>On Fri, 31 Dec 2004 13:24:28 -0800, George V. Reilly <george@...> wrote:
>> Does Vim actually generate code that uses SSE2 instructions or does it
>> notably benefit from P4-specific optimizations? Vim is fast on modern
>> hardware.
>
>I runs faster for me with the optimizations.

Scenario? Numbers?
--
Walter Briscoe

test11 and test30 still fail.  I used "cvs co -kb vim7/src/testdir"
after removing testdir.  -kb is supposed to use the same line endings
as stored in CVS.

On a related note, have you considered switching the repository to
subversion? (http://subversion.tigris.org)  There are scripts to
convert a CVS repository to a Subversion repository.... :-)



On Sat, 01 Jan 2005 17:37:57 +0100, Bram Moolenaar <Bram@...> wrote:
>
> Johnny Blaze wrote:
>
> > On Sat, 01 Jan 2005 14:23:06 +0100, Bram Moolenaar <Bram@...>
wrote:
> >
> > > I would think that for CVS all test files should actually NOT be marked
> > > binary, so that the line endings are adjusted.  Problem is that this
> > > process apparently fails to work properly, not adding a CR to a line
> > > that already ends in a CR.  I don't know how to solve that...
> > >
> > > Otherwise, we would need to run a script that fixes the fileformats
> > > before running the actual tests.  It seems using this in
> > > src/testdir/Make_dos.mak works:
> > >
> > > nongui: fixff $(SCRIPTS16) $(SCRIPTS)
> > >         echo ALL DONE
> > >
> > > small:  fixff $(SCRIPTS16)
> > >         echo ALL DONE
> > >
> > > gui:    fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS_GUI)
> > >         echo ALL DONE
> > >
> > > win32:  fixff $(SCRIPTS16) $(SCRIPTS) $(SCRIPTS32)
> > >         echo ALL DONE
> > >
> > > fixff:
> > >         -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in
*.ok
> > >
> > > If this works properly then ALL files in src/testdir can be marked binary.
> >
> > test30 and test11 still fail with fixff added.  I could only get
> > test11 to be successful if I change the line in test11.in:"set nobin
> > ff&" to "set nobin ff=unix". test30 is only successful if I restore
> > test30.ok from the snapshot (and keep fixff from changing it).
>
> Did you check out the files in Unix mode, thus without CVS doing any CR
> adding?  I suspect it only adds a CR when there isn't one already, that
> breaks the tests.  Vim adds a CR to every line, then it should be OK.
>
> --
> $ echo pizza > /dev/oven
>
>  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
> ///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
>  \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
>


--

.  o O pyromancer O o  .

On Fri 31-Dec-04 2:47pm -0600, Jens Paulus wrote:

> alright, maybe my description was wrong. Try the commands `ay<C-V>`c and
> `ad<C-V>`c and you should see that the character at mark c is not
> included.

I'm surprised that Bram sees a problem.  I tried this
from 6.3.53 and don't see the problem.  When I paste
the yank, I see the whole first column.  When I try
delete, the whole first column is deleted.  This is
what I expect.

Although I prefer the default sel=inclusive when
working with blocks, I get too much bad behavior in
Windows when the EOL can't included.

For example, reading news where the subjects are all at
top and repeated with the full stories below, I use
'Alt-V' to get me to the stories and 'n' to get back to
the index.  My mappings for Alt-V are as follows:

=======================================================
" Search for visually selected text and position to top
vnoremap / y/<C-R>"<CR>zt

" Mark full line and do above
nmap <M-v> 0v$/
=======================================================

The problem is the inclusive grabs the EOL and the
search string becomes: text^M
which can't be found :-(

I've set up a "toggle" for 'sel' to easily switch
modes:

nmap <M-F3> :if &sel == 'inclusive'
         \ \| set sel=exclusive
         \ \| else
         \ \| set sel=inclusive
         \ \| endif
         \ \| set sel?<CR>

--
Best regards,
Bill

Johnny Blaze wrote:

> test11 and test30 still fail.  I used "cvs co -kb vim7/src/testdir"
> after removing testdir.  -kb is supposed to use the same line endings
> as stored in CVS.

test11 fails if gzip is not available.  Perhaps that's the problem you
are encountering?

It appears the test[11|30].[in|ok] files in CVS are identical to what I
have.  Another cause for problems is a diff program that can't handle
the different line endings.

> On a related note, have you considered switching the repository to
> subversion? (http://subversion.tigris.org)  There are scripts to
> convert a CVS repository to a Subversion repository.... :-)

It has been considered.  There are two problems:
(1) we don't have a reliable repository for subversion (SourceForge
doesn't support it).
(2) Not many people have it, thus we would have to keep the CVS
repository as well.

Since we are using CVS for distribution and keeping old versions, not
for actual development, it's not much use to switch to subversion.

--
hundred-and-one symptoms of being an internet addict:
211. Your husband leaves you...taking the computer with him and you
      call him crying, and beg him to bring the computer back.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///

Hello Vim Developers,

What is that?  I'm trying Vim 7.0aa Alpha but that
doesn't appear to have any patch levels.

BTW, the latest alpha is VERY unstable - unlike any of
the others.  Every session is ended with an AV and an
invitation to send data to Microsoft.

The specific message starts with:

Vi Improved - A Text Editor has encountered a problem
and needs to close.  We are sorry for the inconvenience.

--
Best regards,
Bill

On Sun, 02 Jan 2005 22:33:08 +0100, Bram Moolenaar <Bram@...> wrote:
>
> Johnny Blaze wrote:
>
> > test11 and test30 still fail.  I used "cvs co -kb vim7/src/testdir"
> > after removing testdir.  -kb is supposed to use the same line endings
> > as stored in CVS.
>
> test11 fails if gzip is not available.  Perhaps that's the problem you
> are encountering?
>
> It appears the test[11|30].[in|ok] files in CVS are identical to what I
> have.  Another cause for problems is a diff program that can't handle
> the different line endings.

hmm... I am using the current versions of both diff and gzip from
gnuwin32.sf.net ... I'll check into diff and see if they have fiddled
with it.  Thanks Bram.

> > On a related note, have you considered switching the repository to
> > subversion? (http://subversion.tigris.org)  There are scripts to
> > convert a CVS repository to a Subversion repository.... :-)
>
> It has been considered.  There are two problems:
> (1) we don't have a reliable repository for subversion (SourceForge
> doesn't support it).
> (2) Not many people have it, thus we would have to keep the CVS
> repository as well.

1: ww.tigris.org (for project hosting) and svn.collab.net (for the
subverison repository hosting)

> Since we are using CVS for distribution and keeping old versions, not
> for actual development, it's not much use to switch to subversion.

okay... Subversion is my new favorite toy (okay, second favorite
behind vim :-)... just thought I would share :-)

--

.  o O pyromancer O o  .

On Sun, 2 Jan 2005 15:30:27 -0600, Bill McCarthy <WJMc@...> wrote:
> BTW, the latest alpha is VERY unstable - unlike any of
> the others.  Every session is ended with an AV and an
> invitation to send data to Microsoft.

I'm seeing the same.  As of 9:39 PM CST the code got superbuggy..
Lots of crashes.  I have a fairly complex statusline (that shows
ff,ft,modified, line position, etc) and everything but the filename is
a bunch of graphical symbols.

WinXP/VC7.1/CPUNR=i686 and P4/FEATURES=HUGE/dynamic perl/no ruby/no python/no mx


--

.  o O pyromancer O o  .

[Adding vim-dev back, since I inadvertently dropped them]
[!#@!@# qmail bounced the first copy of this since it was in HTML]

Johnny Blaze wrote:
  >George V. Reilly <george@...> wrote:
  >>According to
 
>>http://msdn.microsoft.com/library/en-us/vccore/html/_core_.2f.z7.2c_2f.zd.2c_2\
f.zi.asp
  >>it does no such thing.
  >>
  >>/Zi can affect the runtime performance of *managed* code, but Vim is
native
  >>code. The /clr flag is not present in the compiler flags. Generating
  >>debugger information can also make the compilation a little slower.
  >
  >From the link you gave:
  >
  >"This attribute can affect the runtime performance of the application.
  >For more information about how the Debuggable attribute affects
  >performance and how you can modify the performance impact, see Making
  >an Image Easier to Debug."
  >
  >Its unclear to me as to whether this is talking about the combination
  >of /Zi and /clr ("This attribute" not "these attributes"). or /Zi
  >alone.

It's talking about the "Debuggable" attribute from the preceding
sentence, which you omitted. /Zi and /clr are _options_ to the compiler.
Debuggable is an _attribute_ in the the assembly metadata. There are no
assemblies in the unmanaged world.

Compare the language in the description for the VC6 compiler, which was
the last compiler before .NET:
http://msdn.microsoft.com/library/en-us/vccore98/html/_core_.2f.z7.2c_2f.zd.2c_2\
f.zi.asp

/Zi     Produces a program database (PDB) that contains type
         information and symbolic debugging information for use with
         the debugger. The symbolic debugging information includes
         the names and types of variables, as well as functions
         and line numbers.

It doesn't say anything about performance, for the good reason that /Zi
doesn't affect performance.

I used to be the Performance Lead for IIS. Here are some performance
articles that I wrote, which may convince you that I know something
about the subject:
http://msdn.microsoft.com/workshop/server/asp/asptips.asp
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/ma\
intain/optimize/iis5tune.mspx
http://msdn.microsoft.com/workshop/server/iis/tencom.asp

But here's an even better way to convince yourself. Use the /FAcs option
to generate a .cod (combined machine, source, and assembly listing)
file. Try this on several Vim source files, both with and without /Zi.
Let us know if you find a real difference in code generation.

  >> I don't know about you, but I often need to debug optimized code, and
  >>without symbols, it's a pain. You don't have to ship the symbols. Just
  >>archive them for major releases.
  >
  >Why can't this be a separate option? (PDB=yes)  Does the vast majority
  >of people compiling a SSE2 optimized, no-debug version of vim with
  >MSVC need debugging information?

The debugging information is essentially free, because almost all of it
ends up in the PDB symbols file. You just get a small amount of
metainformation in the EXE, which makes it slightly larger, but no slower.

Microsoft builds all binaries with debugging information and archives
the PDBs on symbol servers. This helps enormously when crashes happen in
the field. These symbols are available for developers to use with
Windbg/ntsd/kd: see
http://www.microsoft.com/whdc/devtools/debugging/symbols.mspx

One other thing. I'd recommend using the /GS flag, which inserts stack
canaries to detect stack buffer overruns. All the binaries in Windows XP
SP2 and in Windows Server 2003 are compiled with this flag.
http://msdn.microsoft.com/library/en-us/vccore/html/vclrfGSBufferSecurity.asp
http://blogs.msdn.com/branbray/archive/2003/11/11/51012.aspx
--
1) The project is on schedule.
2) I just fixed the last bug.
3) I only changed one little thing.
4) This will take just a minute.
     -- The four great lies of computing
(Get Witty Auto-Generated Signatures from http://SmartBee.org)
George V. Reilly   george@...
http://george.reilly.org/
Read my blog: http://weblogs.asp.net/george_v_reilly/

Johnny Blaze wrote:

> On Sun, 2 Jan 2005 15:30:27 -0600, Bill McCarthy <WJMc@...> wrote:
> > BTW, the latest alpha is VERY unstable - unlike any of
> > the others.  Every session is ended with an AV and an
> > invitation to send data to Microsoft.
>
> I'm seeing the same.  As of 9:39 PM CST the code got superbuggy..
> Lots of crashes.  I have a fairly complex statusline (that shows
> ff,ft,modified, line position, etc) and everything but the filename is
> a bunch of graphical symbols.

That's why it is an alpha version.  I'm now messing up the expression
evaluation to add new data types.  It's very likely to introduce a few
problems.

There is one patch that will help for 7.0028.  Change the end of
set_var() in src/eval.c to look like this:

	 copy_var(varp, v);
     else
     {
	 v->tv.var_type = varp->tv.var_type;
	 v->tv.var_val.var_string = varp->tv.var_val.var_string;
	 varp->tv.var_val.var_string = NULL;
     }

That last assignment is new.  Hopefully that solves these crashes.

--
hundred-and-one symptoms of being an internet addict:
213. Your kids start referring to you as "that guy in front of the monitor."

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///

On Mon, 03 Jan 2005 09:47:39 +0100, Bram Moolenaar <Bram@...> wrote:
>
> Johnny Blaze wrote:
>
> > On Sun, 2 Jan 2005 15:30:27 -0600, Bill McCarthy <WJMc@...> wrote:
> > > BTW, the latest alpha is VERY unstable - unlike any of
> > > the others.  Every session is ended with an AV and an
> > > invitation to send data to Microsoft.
> >
> > I'm seeing the same.  As of 9:39 PM CST the code got superbuggy..
> > Lots of crashes.  I have a fairly complex statusline (that shows
> > ff,ft,modified, line position, etc) and everything but the filename is
> > a bunch of graphical symbols.
>
> That's why it is an alpha version.  I'm now messing up the expression
> evaluation to add new data types.  It's very likely to introduce a few
> problems.

Just a clarification... Mine wasn't a complaint, it was a report.
Bring on the new data types!

--

.  o O pyromancer O o  .

On Sun, 02 Jan 2005 22:08:19 -0800, George V. Reilly <george@...> wrote:
> I used to be the Performance Lead for IIS. Here are some performance
> articles that I wrote, which may convince you that I know something
> about the subject:
> http://msdn.microsoft.com/workshop/server/asp/asptips.asp
>
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/ma\
intain/optimize/iis5tune.mspx
> http://msdn.microsoft.com/workshop/server/iis/tencom.asp

oh, I didn't mean to imply that you weren't who you said you are, or
to indicate that you didn't know what you were talking about, I was
just going off of my understanding of the Microsoft Docs.  I
appreciate the information.

--

.  o O pyromancer O o  .

are available at

deb http://www.lxtec.de/debarchiv binary-powerpc/
deb http://www.lxtec.de/debarchiv binary-i386/
deb-src http://www.lxtec.de/debarchiv sources/

The packages are created with cvs head updates.

Ciao

Elimar

--
   The path to source is always uphill!
                                 -unknown-
    <I'm not subscribed to vim@..., so please include my address
    at replies>

>-----Original Message-----
>From: Jens Paulus [mailto:jpaulus@...]
>Sent: Thursday, December 30, 2004 8:02 AM
>To: vim-dev@...
>Subject: Re: Empty registers
>
>Hi Bram,
>
>On Thu, Dec 30, 2004 at 16:44:08 +0100, Bram Moolenaar wrote:
>> > 10. Empty registers
>> > Empty registers should not be saved in viminfo file and not be
>> > displayed in the :reg output.
>>
>> Why not?
>>
>> It's actually quite difficult to make a register empty, they hardly
>> ever appear.
>
>register can easily made empty, use qaq to make the a register
>empty. Or do :let @a="" which does the same. For a better
>overview which registers are used I think it is good to make
>registers with old content empty every now and then. When
>starting from an empty viminfo file or when creating a new one
>only those registers are stored and shown in the :reg output
>which are not empty. Thus making registers empty should also
>delete their entry in the viminfo file and should make them
>not show up in the :reg output.
>
>Best regards
>
>Jens

I agree that there should be a way to make a register "disappear".  This
would be useful for shortening the list of registers you have to look
thru for something meaningful.  OTOH, :let @a="" is an easy workaround.

But *much* more important to me would be a way to *unmark* a mark.
Right now the best you can do is to change it to point to line 1, where
marks aren't shown (eg, :0ma {mark}).  However, it still clutters up the
listing of marks for the buffer, obscuring what you really want to see.

I inadvertently had CapsLock on when I wanted to set mark z, so I got 'Z
instead.i  I use sessions, so the mark is perpetually remembered!  I've
just realized that the only way to get rid of it is to close my gvim
instance, edit the session file in another instance, then reactivate the
original instance/session.  Pain in the @$$, folks!!  How difficult
would it be to create an :unmark {mark} command?!?  Seems to me it
shouldn't be more than a couple hours work for someone who knows the
code ...

[but I suppose I'm an optimist :) ]

-Keith

Keith Roberts wrote:

> I agree that there should be a way to make a register "disappear".  This
> would be useful for shortening the list of registers you have to look
> thru for something meaningful.  OTOH, :let @a="" is an easy
> workaround.

I'll make Vim 7 not store empty registers in the viminfo file.  Note
that a register containing an empty line is not empty: "p" would insert
an empty line.

> But *much* more important to me would be a way to *unmark* a mark.
> Right now the best you can do is to change it to point to line 1, where
> marks aren't shown (eg, :0ma {mark}).  However, it still clutters up the
> listing of marks for the buffer, obscuring what you really want to see.
>
> I inadvertently had CapsLock on when I wanted to set mark z, so I got 'Z
> instead.i  I use sessions, so the mark is perpetually remembered!  I've
> just realized that the only way to get rid of it is to close my gvim
> instance, edit the session file in another instance, then reactivate the
> original instance/session.  Pain in the @$$, folks!!  How difficult
> would it be to create an :unmark {mark} command?!?  Seems to me it
> shouldn't be more than a couple hours work for someone who knows the
> code ...

Vim 7 has the ":delmarks" command for this:

:delm[arks] {marks}  Delete the specified marks.  Marks that can be deleted
			 include A-Z and 0-9.  You cannot delete the ' mark.

--
From the classified section of a city newspaper:
Dog for sale: eats anything and is fond of children.


  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///

On Mon, 03 Jan 2005 the mental interface of
Elimar Riesebieter told:

> are available at
>
> deb http://www.lxtec.de/debarchiv binary-powerpc/
> deb http://www.lxtec.de/debarchiv binary-i386/
> deb-src http://www.lxtec.de/debarchiv sources/

The packages are still removed. Please ask the Debian Maintainer for
further info's about his repository containing same packages.

Ciao

Elimar

--
   Do you smell something burning or ist it me?

On Sun, 02 Jan 2005 22:33:08 +0100, Bram Moolenaar <Bram@...> wrote:
>
> Johnny Blaze wrote:
>
> > test11 and test30 still fail.  I used "cvs co -kb vim7/src/testdir"
> > after removing testdir.  -kb is supposed to use the same line endings
> > as stored in CVS.
>
> test11 fails if gzip is not available.  Perhaps that's the problem you
> are encountering?
>
> It appears the test[11|30].[in|ok] files in CVS are identical to what I
> have.  Another cause for problems is a diff program that can't handle
> the different line endings.

Bram,

The problem with test11 appears to be the gnuwin32 port of sed.  This
version of sed operates in text mode by default, which changes
line-endings to the native system (only if sed changes something, if
you run a cat-like sed script, it appears to put out what you put in).
  If you run it in binary mode, it leaves line-endings alone.

I  changed the sed command in test11.in to sed -B s/e/E ... and it works fine.

Again on test30, If I put the snapshot-zip version of test30.ok in the
working directory and cvs update test30.ok it shows that it was
locally modified.  If I cvs update -kb test30.ok (-kb is supposed to
use the same line-endings as stored in the repos.) it still shows
modified.  Vim sees test30.ok as ff=unix, so fixff will cause test30
to fail if you put the snapshot version in.

--

.  o O pyromancer O o  .

Johnny Blaze wrote:

> The problem with test11 appears to be the gnuwin32 port of sed.  This
> version of sed operates in text mode by default, which changes
> line-endings to the native system (only if sed changes something, if
> you run a cat-like sed script, it appears to put out what you put in).
>  If you run it in binary mode, it leaves line-endings alone.
>
> I  changed the sed command in test11.in to sed -B s/e/E ... and it
> works fine.

Ah, that explains the problems.  The -B argument is not available
elsewhere, thus we can't use that.  You can try adding a command to
remove the extra CR characters:

*** testdir/test11.in~ Sun Jul 18 21:46:21 2004
--- testdir/test11.in Tue Jan  4 09:55:07 2005
***************
*** 44,49 ****
--- 44,50 ----
   :au FilterReadPost  *.out  '[,']s/x/X/g
   :e! test.out                    " Edit the output file
   :23,$!cat
+ :23,$s/\r$//                 " remove CR for when sed adds them
   :au! FileReadPre    *.gz   !gzip -d <afile>
   :au  FileReadPre    *.gz   call rename(expand("<afile>:r"), expand("<afile>"))
   :au! FileReadPost   *.gz   '[,']s/l/L/

> Again on test30, If I put the snapshot-zip version of test30.ok in the
> working directory and cvs update test30.ok it shows that it was
> locally modified.  If I cvs update -kb test30.ok (-kb is supposed to
> use the same line-endings as stored in the repos.) it still shows
> modified.  Vim sees test30.ok as ff=unix, so fixff will cause test30
> to fail if you put the snapshot version in.

I don't understand this.  It works fine for me, thus the version of
test30.ok in the snapshot should be OK.  Note that it is in unix format,
thus fixff must change it to dos format.  If you compare the files after
that they will differ.

I just checked again that the current files (snapshot 29) work fine for
me.  That is using Make_mvc.mak.

--
hundred-and-one symptoms of being an internet addict:
218. Your spouse hands you a gift wrapped magnet with your PC's name
      on it and you accuse him or her of genocide.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///

On Tue, 04 Jan 2005 11:18:31 +0100, Bram Moolenaar <Bram@...> wrote:
>
> Johnny Blaze wrote:
>
> > The problem with test11 appears to be the gnuwin32 port of sed.  This
> > version of sed operates in text mode by default, which changes
> > line-endings to the native system (only if sed changes something, if
> > you run a cat-like sed script, it appears to put out what you put in).
> >  If you run it in binary mode, it leaves line-endings alone.
> >
> > I  changed the sed command in test11.in to sed -B s/e/E ... and it
> > works fine.
>
> Ah, that explains the problems.  The -B argument is not available
> elsewhere, thus we can't use that.  You can try adding a command to
> remove the extra CR characters:
>
> *** testdir/test11.in~  Sun Jul 18 21:46:21 2004
> --- testdir/test11.in   Tue Jan  4 09:55:07 2005
> ***************
> *** 44,49 ****
> --- 44,50 ----
>   :au FilterReadPost  *.out  '[,']s/x/X/g
>   :e! test.out                    " Edit the output file
>   :23,$!cat
> + :23,$s/\r$//                 " remove CR for when sed adds them
>   :au! FileReadPre    *.gz   !gzip -d <afile>
>   :au  FileReadPre    *.gz   call rename(expand("<afile>:r"),
expand("<afile>"))
>   :au! FileReadPost   *.gz   '[,']s/l/L/

This works excellently.

> I don't understand this.  It works fine for me, thus the version of
> test30.ok in the snapshot should be OK.  Note that it is in unix format,
> thus fixff must change it to dos format.  If you compare the files after
> that they will differ.
>
> I just checked again that the current files (snapshot 29) work fine for
> me.  That is using Make_mvc.mak.

I found something that does work.  (I have attached a patch for
src/testdir/Make_dos.mak.  Basically duplicate fixff's only action and
change ff=dos to ff=unix and make it only for test30.ok.

@@ -46,6 +45,7 @@

  fixff:
 	 -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok
+ -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=unix|upd" +q test30.ok

-------------

That seems to work everytime even after deleting the file (test30.ok)
and pulling another from CVS.

Its kinda kludgy, but it works.

--

.  o O pyromancer O o  .

Johnny Blaze wrote:

> > I don't understand this.  It works fine for me, thus the version of
> > test30.ok in the snapshot should be OK.  Note that it is in unix
> > format, thus fixff must change it to dos format.  If you compare the
> > files after that they will differ.
> >
> > I just checked again that the current files (snapshot 29) work fine for
> > me.  That is using Make_mvc.mak.
>
> I found something that does work.  (I have attached a patch for
> src/testdir/Make_dos.mak.  Basically duplicate fixff's only action and
> change ff=dos to ff=unix and make it only for test30.ok.

I don't like this solution, because it makes an exception for one file.
It does point in the right direction: Apparently it worked for me
because my "diff" ignored differences in dos/unix file formats.
test30.ok would be dos and test30.out will be unix format.

For DOS I prefer all file formats to be dos (after fixff), so that there
are no exceptions.

Besides this, using the "cat" command will break the test for people
that don't have it.  I'll change the test to avoid it.  Makes it
portable and faster too.

--
hundred-and-one symptoms of being an internet addict:
225. You sign up for free subscriptions for all the computer magazines

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///

>-----Original Message-----
>From: Bram@... [mailto:Bram@...]
>Sent: Monday, January 03, 2005 12:39 PM
>To: Keith Roberts
>Cc: Jens Paulus; vim-dev@...
>Subject: RE: Empty registers
>
>
>Keith Roberts wrote:
>> I agree that there should be a way to make a register "disappear".
>
>I'll make Vim 7 not store empty registers in the viminfo file.
> Note that a register containing an empty line is not empty:
>"p" would insert an empty line.

Excellent!

>> But *much* more important to me would be a way to *unmark* a mark.
>
>Vim 7 has the ":delmarks" command for this:
>
>:delm[arks] {marks}  Delete the specified marks.  Marks that
>can be deleted
> 	 include A-Z and 0-9.  You cannot delete
>the ' mark.

This is good, but why not a-z as well?  As I said, a bunch of a-z marks
all at "1 0" location just obfuscate the listing.  More importantly, if
you tend to use specific letters for locating specific areas of the
code, it is more useful [to me] to get a "Mark not defined" error than
to get moved to line 1.

-Keith

Your document is attached.

> >> But *much* more important to me would be a way to *unmark* a mark.
> >
> >Vim 7 has the ":delmarks" command for this:
> >
> >:delm[arks] {marks}  Delete the specified marks.  Marks that
> >can be deleted
> > 	 include A-Z and 0-9.  You cannot delete
> >the ' mark.
>
> This is good, but why not a-z as well?

You can.  The docs only mention the ones that may be unexpected.

--
A computer without Windows is like a fish without a bicycle.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///

Please read the attached file.

Hi Bram,

On Thu, Dec 30, 2004 at 14:18:54 +0100, Jens Paulus wrote:
> > > what I do not understand is why the ruler cursor position gets updated
> > > after a timeoutlen delay when leaving Insert mode in vim but in gvim it
> > > there is no such delay. The same is also when for example doing
> > > 4iabcd<Esc> and the repeated text is inserted after this delay. In gvim
> > > there are the same settings for timeoutlen, timeout, ttimeout but it
> > > happens immediately. Starting vim with -u NONE or setting it to
> > > nocompatible makes it work immediately and without delay. But with same
> > > settings gvim has no delay but vim has this delay.
> >
> > The reason is that in a terminal there are key codes that start with
> > Esc.  When Vim receives an Esc in Insert mode it can't be sure if it is
> > the Esc key or the start of a key code (e.g., for a cursor key).  Vim
> > then pretents to go out of Insert mode, but only really does so after
> > 'ttimeoutlen'.
> >
> > You can fix this by using a terminal that uses CSI for special keys.
>
> maybe you can provide me with some suggestions for such terminals. Now I
> tried the following mapping
> imap <Esc> <C-C>
> and the result is that there is no delay anymore and it happens
> immediately. The disadvantage of this is that an abbreviation is not
> expanded anymore when leaving Insert mode and pressing the cursor keys
> is just like if the mappings
> ino <Up> <CR><Up>A
> ino <Down> <CR><Up>B
> ino <Right> <CR><Up>C
> ino <Left> <CR><Up>D
> were active.

what I also tried is this.
imap <Esc> <C-]><C-C>
The idea is to expand the abbreviation and then leave Insert mode.
However, this only works after entering an abbreviation. If <C-]> would
be a <Nop> if normal text and no abbreviation is entered then the
problem with the <Esc> delay could easily be solved with this mapping.
Then if someone wants to insert CTRL-] into the text, this person would use
CTRL-V instead.

Best regards

Jens

Hi Bram,

On Tue, Jan 04, 2005 at 20:29:16 +0100, Jens Paulus wrote:
> > > The reason is that in a terminal there are key codes that start with
> > > Esc.  When Vim receives an Esc in Insert mode it can't be sure if it is
> > > the Esc key or the start of a key code (e.g., for a cursor key).  Vim
> > > then pretents to go out of Insert mode, but only really does so after
> > > 'ttimeoutlen'.
> > >
> > > You can fix this by using a terminal that uses CSI for special keys.

by the way I think it would be useful to add a paragraph like this to
the descriptian of the timout or ttimeout option because there may be
lots of people that suffer from this delay.

Best regards

Jens