Re: Vim 7.3e ready for beta testing
Pan Shizhu wrote: We need a Big icon for Windows 7. During the Vim 7.3 development, Windows 7 releases, in Windows 7 desktop we can choose small Icon, normal Icon, and big Icon. The Icon for Vim 7.3 works for Normal Icon and Small Icon, but when I choose Big icon on Windows 7 desktop, it still shows a Normal Icon. Now it is time to give Vim 7.3 Windows Installer a Big Icon. Thanks. OK, so can someone tell me how to do that? How big is a Big Icon? -- hundred-and-one symptoms of being an internet addict: 44. Your friends no longer send you e-mail...they just log on to your IRC channel. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_use maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3e ready for beta testing
On Thu, Aug 12, 2010 at 1:43 PM, Bram Moolenaar b...@moolenaar.net wrote: Pan Shizhu wrote: We need a Big icon for Windows 7. During the Vim 7.3 development, Windows 7 releases, in Windows 7 desktop we can choose small Icon, normal Icon, and big Icon. The Icon for Vim 7.3 works for Normal Icon and Small Icon, but when I choose Big icon on Windows 7 desktop, it still shows a Normal Icon. Now it is time to give Vim 7.3 Windows Installer a Big Icon. Thanks. OK, so can someone tell me how to do that? How big is a Big Icon? 256x256, which then gets scaled automatically by Vista and Windows 7. 24-bit color. More 3D. * http://msdn.microsoft.com/en-us/library/aa511280.aspx * http://www.axialis.com/tutorials/tutorial-vistaicons.html http://www.axialis.com/tutorials/tutorial-vistaicons.htmlPerhaps we could use the icon from MacVim as a starting point? -- /George V. Reilly geo...@reilly.org Twitter: @georgevreilly http://www.georgevreilly.com/blog http://blogs.cozi.com/tech -- You received this message from the vim_use maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3e ready for beta testing
Bram Moolenaar b...@moolenaar.net wrote:
- it's not a new problem in 7.3
Isn't a/the purpose of a new release resolving known issues?
Specifically, the manifest bug that I described in ==3== and the
first part of ==4== has been known for at least two years now.
- it is going to be incompatible with previous versions, some scripts
may need to be adjusted
If the behaviour under discussion is ever going to change, then the
sooner this happens the better. Neither writing more scripts to the
current interface nor abstaining from writing such would make things
any easier in the future.
- knowing how Vim does this it's possible to make it work
I for one am not sure that I understand all the intricacies involved,
even after your explanations. Neither are those complicacies described
in the documentation. And even where it is known what to do, the
resulting code tends to get contrived and prone to error.
Anyway, I see I cannot change your mind.
The following is only a clarification of (my opinion on) the essence
and importance of issues being discussed.
for s in ['abc', '', 'def'] | echo s | endfor
...
It only starts a new line if you have output something. Change the
empty string to ' ' and it works.
Provided that I know it is indeed empty. If it were
for s in ss … endfor
then I'd have to add an ‘if’ statement to check each string if it's
empty, and if it is, print something else instead of it. I see it
much simpler to use echon and explicit ‘\n’s all the way … but then
what is the use of having echo at all?
There is a deeper, and more serious problem here: echo's outcome
appears to be history-dependent rather than self-contained, which is
an especially bad case of non-orthogonality. Obviously, there are
situations where history is unknown, hence the outcome of echo is
unpredictable. (Imagine a history-dependent printf() in C.)
echo abc\n | echo def
...
This works:
echo abc\n | echo def
Same as above holds. Normally two calls of echo do not textually
follow each other, so you do not actually know whether adding that
space makes sense. What if the second echo were to be echon?
(c) after a call of input(), e.g. in
let x = input('') | echo 'ABC'
the ABC string goes to the same line as the input; similarly,
let x = input('') | echo \nABC
prints ABC on the line immediately following the input(), while
it should really leave an empty line between that of input() and
that with the ABC.
This is intentional, it avoids having to press Enter at the more-prompt.
You can echo the result of input() if you want to see it.
The issue here is not whether we want to see the result of input(),
but, once more, the echo not starting on a new line.
And I don't really understand how the more-prompt gets into the
picture; we are discussing echo and input() which I understand as
general-purpose programming facilities.
(Besides, the echo is again erroneous as described in (c) above.)
Please don't call things an error when it might actually be intended
behavior.
I called it erroneous because it did seem so, in the absence of self-
consistency as well as consistency with the documentation. There was
no reason to suspect it was intentional.
The behavior of messages is very complicated. It's a compromise between
keeping the text the user might want to read and avoiding an annoying
hit-enter prompt. These things can't be solved by looking at only one
side of the problem.
But they are solvable, as many examples out there demonstrate.
I believe solutions to be achievable through streamlining rather than
the opposite. If any compromise is needed, it'd better not affect
simplicity, dependability, consistency, and composability.
Best regards,
Boyko
--
You received this message from the vim_use maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3e ready for beta testing
Boyko Bantchev wrote:
Bram Moolenaar b...@moolenaar.net wrote:
- it's not a new problem in 7.3
Isn't a/the purpose of a new release resolving known issues?
Specifically, the manifest bug that I described in ==3== and the
first part of ==4== has been known for at least two years now.
Yes, but we are too close to a release to make changes that might cause
more trouble than they fix. There is not sufficient time for testing
and discussing alternative solutions.
- it is going to be incompatible with previous versions, some scripts
may need to be adjusted
If the behaviour under discussion is ever going to change, then the
sooner this happens the better. Neither writing more scripts to the
current interface nor abstaining from writing such would make things
any easier in the future.
- knowing how Vim does this it's possible to make it work
I for one am not sure that I understand all the intricacies involved,
even after your explanations. Neither are those complicacies described
in the documentation. And even where it is known what to do, the
resulting code tends to get contrived and prone to error.
Anyway, I see I cannot change your mind.
The following is only a clarification of (my opinion on) the essence
and importance of issues being discussed.
for s in ['abc', '', 'def'] | echo s | endfor
...
It only starts a new line if you have output something. Change the
empty string to ' ' and it works.
Provided that I know it is indeed empty. If it were
for s in ss … endfor
then I'd have to add an ‘if’ statement to check each string if it's
empty, and if it is, print something else instead of it. I see it
much simpler to use echon and explicit ‘\n’s all the way … but then
what is the use of having echo at all?
There is a deeper, and more serious problem here: echo's outcome
appears to be history-dependent rather than self-contained, which is
an especially bad case of non-orthogonality. Obviously, there are
situations where history is unknown, hence the outcome of echo is
unpredictable. (Imagine a history-dependent printf() in C.)
echo abc\n | echo def
...
This works:
echo abc\n | echo def
Same as above holds. Normally two calls of echo do not textually
follow each other, so you do not actually know whether adding that
space makes sense. What if the second echo were to be echon?
(c) after a call of input(), e.g. in
let x = input('') | echo 'ABC'
the ABC string goes to the same line as the input; similarly,
let x = input('') | echo \nABC
prints ABC on the line immediately following the input(), while
it should really leave an empty line between that of input() and
that with the ABC.
This is intentional, it avoids having to press Enter at the more-prompt.
You can echo the result of input() if you want to see it.
The issue here is not whether we want to see the result of input(),
but, once more, the echo not starting on a new line.
And I don't really understand how the more-prompt gets into the
picture; we are discussing echo and input() which I understand as
general-purpose programming facilities.
(Besides, the echo is again erroneous as described in (c) above.)
Please don't call things an error when it might actually be intended
behavior.
I called it erroneous because it did seem so, in the absence of self-
consistency as well as consistency with the documentation. There was
no reason to suspect it was intentional.
The behavior of messages is very complicated. It's a compromise between
keeping the text the user might want to read and avoiding an annoying
hit-enter prompt. These things can't be solved by looking at only one
side of the problem.
But they are solvable, as many examples out there demonstrate.
I believe solutions to be achievable through streamlining rather than
the opposite. If any compromise is needed, it'd better not affect
simplicity, dependability, consistency, and composability.
Best regards,
Boyko
--
hundred-and-one symptoms of being an internet addict:
32. You don't know what sex three of your closest friends are, because they
have neutral nicknames and you never bothered to ask.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the vim_use maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3e ready for beta testing
On 8 August 2010 23:01, Bram Moolenaar b...@moolenaar.net wrote:
...
We are getting close to the 7.3 release! If nothing goes wrong I will
release 7.3 in less than a week. Last chance to report problems!
...
Bram,
Great thanks to you for doing all this huge work on keeping Vim the
best text editor. This work of yours helps so many people in the
world, and in so many ways, to do their own work.
The upcoming 7.3 release will no doubt improve on our experience
with Vim, as all previous have done. However, I am concerned that
the problems with Vim language's basic input and output about which
I wrote several times, are, it seems, going to remain in 7.3 – and
that means for at least another couple of years or more.
Please reconsider this!
One way to use Vimscript is to write and execute simple REPLs in the
editor. A number of useful utilities, as well as educational programs
can be written this way. Simple and reliable I/O primitives are
essential to this, but, alas, Vim's :echo and input() have serious
bugs each, and are even more problematic when used together. Said
problems can be circumvented, I guess, but at the expense of ugliness
and inconvenience reproduced in every single script. This would
continually repel especially potential new users of Vim.
I am once again describing the bugs and incosistencies I know of, in
the hope that this would help to change your mind w.r.t. them. I am
mostly repeating my previous posts but exposing the issues a bit more
systematically.
Thank you for your attention, best regards,
Boyko
~
==1==
The documentation says that echo “… starts on a new line” but this
is broken in at least several cases:
(a) empty strings, e.g.
for s in ['abc', '', 'def'] | echo s | endfor
prints
abc
def
rather than
abc
def
(b) this doesn't look like empty strings but still:
echo abc\n | echo def
is supposed to output
abc
def
but instead prints
abc
def
(c) after a call of input(), e.g. in
let x = input('') | echo 'ABC'
the ABC string goes to the same line as the input; similarly,
let x = input('') | echo \nABC
prints ABC on the line immediately following the input(), while
it should really leave an empty line between that of input() and
that with the ABC.
==2==
The documentation says nothing about whether input() always starts
on a new line or not. Simple tests such as e.g.
echo | let x = input('')
lead one to concluding that it does. However, then,
while 1 | let x = input('A') | echo R\n | endw
should be expected to print empty lines between each R\n and the
subsequent input('A') but it does not – that contradicts the
assumption that input() always moves to a new line at start.
(Besides, the echo is again erroneous as described in (c) above.)
==3==
Reducing the R\n in the above example to just R:
while 1 | let s = input('A') | echo 'R' | endw
exhibits an even stranger behaviour. For a start, just enter several
empty lines to each input() before breaking the loop: not only is the
'R' printed on the same line as 'A' (which it shouldn't) but each new
'R' is displaced more and more to the right.
==4==
Once input() finishes, both the prompt and the entered string are
being removed from display. Apart from this being, I believe, a
wrong behaviour in itself, it, again, is not consistently manifested.
This is easily seen by trying the last example above, this time
entering non-empty lines. One can see that the implicitly echoed
input is fully or partially (depending on its length) retained –
which is probably a particular manifestation of some of the other
bugs I mentioned (or perhaps a remnant of a correct behaviour).
Also, the input()'s display, both the prompt and the entered text,
is not removed if a single command such as
:let x = input('PROMPT: ')
is executed.
I believe that input() should *never* remove the entered text, as well
as the prompt, if any. Provided that it ends without moving to a new
line, it shoild still be possible, if that is wanted, to erase the
said text by ‘echon’-ing \r or \b. If removal is the default and
one wants to keep the input, one would have to re-echo what he just
typed in, which I think is much less natural.
--
You received this message from the vim_use maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3e ready for beta testing
Boyko Bantchev wrote:
On 8 August 2010 23:01, Bram Moolenaar b...@moolenaar.net wrote:
...
We are getting close to the 7.3 release! If nothing goes wrong I will
release 7.3 in less than a week. Last chance to report problems!
...
Bram,
Great thanks to you for doing all this huge work on keeping Vim the
best text editor. This work of yours helps so many people in the
world, and in so many ways, to do their own work.
The upcoming 7.3 release will no doubt improve on our experience
with Vim, as all previous have done. However, I am concerned that
the problems with Vim language's basic input and output about which
I wrote several times, are, it seems, going to remain in 7.3 – and
that means for at least another couple of years or more.
Please reconsider this!
One way to use Vimscript is to write and execute simple REPLs in the
editor. A number of useful utilities, as well as educational programs
can be written this way. Simple and reliable I/O primitives are
essential to this, but, alas, Vim's :echo and input() have serious
bugs each, and are even more problematic when used together. Said
problems can be circumvented, I guess, but at the expense of ugliness
and inconvenience reproduced in every single script. This would
continually repel especially potential new users of Vim.
I am once again describing the bugs and incosistencies I know of, in
the hope that this would help to change your mind w.r.t. them. I am
mostly repeating my previous posts but exposing the issues a bit more
systematically.
I am not going to change this now, because:
- it's not a new problem in 7.3
- it is going to be incompatible with previous versions, some scripts
may need to be adjusted
- knowing how Vim does this it's possible to make it work
Thank you for your attention, best regards,
Boyko
~
==1==
The documentation says that echo “… starts on a new line” but this
is broken in at least several cases:
(a) empty strings, e.g.
for s in ['abc', '', 'def'] | echo s | endfor
prints
abc
def
rather than
abc
def
It only starts a new line if you have output something. Change the
empty string to ' ' and it works.
(b) this doesn't look like empty strings but still:
echo abc\n | echo def
is supposed to output
abc
def
but instead prints
abc
def
This works:
echo abc\n | echo def
abc
def
(c) after a call of input(), e.g. in
let x = input('') | echo 'ABC'
the ABC string goes to the same line as the input; similarly,
let x = input('') | echo \nABC
prints ABC on the line immediately following the input(), while
it should really leave an empty line between that of input() and
that with the ABC.
This is intentional, it avoids having to press Enter at the more-prompt.
You can echo the result of input() if you want to see it.
==2==
The documentation says nothing about whether input() always starts
on a new line or not. Simple tests such as e.g.
echo | let x = input('')
lead one to concluding that it does. However, then,
while 1 | let x = input('A') | echo R\n | endw
should be expected to print empty lines between each R\n and the
subsequent input('A') but it does not – that contradicts the
assumption that input() always moves to a new line at start.
It's difficult to explain how this works and probably also depends on
options settings, such as 'shortmess'. You can see what happens.
(Besides, the echo is again erroneous as described in (c) above.)
Please don't call things an error when it might actually be intended
behavior.
==3==
Reducing the R\n in the above example to just R:
while 1 | let s = input('A') | echo 'R' | endw
exhibits an even stranger behaviour. For a start, just enter several
empty lines to each input() before breaking the loop: not only is the
'R' printed on the same line as 'A' (which it shouldn't) but each new
'R' is displaced more and more to the right.
That looks like a bug.
==4==
Once input() finishes, both the prompt and the entered string are
being removed from display. Apart from this being, I believe, a
wrong behaviour in itself, it, again, is not consistently manifested.
This is easily seen by trying the last example above, this time
entering non-empty lines. One can see that the implicitly echoed
input is fully or partially (depending on its length) retained –
which is probably a particular manifestation of some of the other
bugs I mentioned (or perhaps a remnant of a correct behaviour).
Also, the input()'s display, both the prompt and the entered text,
is not removed if a single command such as
:let x = input('PROMPT: ')
is executed.
I believe that input() should *never* remove the entered text, as well
as the prompt, if any. Provided that it ends without
Re: Vim 7.3e ready for beta testing
Although I'm not certain that I understand the full set of use cases
that would benefit from a resolution of these inconsistencies, it
seems plausible to me that most or all of the use cases could be
implemented in a buffer with some insightful mappings (of, for
example, `i_^M`) and/or autocommands. There are at least a couple of
full-blown shells that run in a buffer this way: [vimshell] and
[conque]. Maybe their techniques could be useful to you.
As a tentative suggestion for resolving the inconsistencies with
`:echo`: perhaps there could be an option which would enable full
echoing, including empty lines, set by default to the current
behaviour?
Cheers
-Ted
[conque]: http://www.vim.org/scripts/script.php?script_id=2771
[vimshell]: http://github.com/Shougo/vimshell
On Aug 9, 5:02 pm, Bram Moolenaar b...@moolenaar.net wrote:
Boyko Bantchev wrote:
On 8 August 2010 23:01, Bram Moolenaar b...@moolenaar.net wrote:
...
We are getting close to the 7.3 release! If nothing goes wrong I will
release 7.3 in less than a week. Last chance to report problems!
...
Bram,
Great thanks to you for doing all this huge work on keeping Vim the
best text editor. This work of yours helps so many people in the
world, and in so many ways, to do their own work.
The upcoming 7.3 release will no doubt improve on our experience
with Vim, as all previous have done. However, I am concerned that
the problems with Vim language's basic input and output about which
I wrote several times, are, it seems, going to remain in 7.3 – and
that means for at least another couple of years or more.
Please reconsider this!
One way to use Vimscript is to write and execute simple REPLs in the
editor. A number of useful utilities, as well as educational programs
can be written this way. Simple and reliable I/O primitives are
essential to this, but, alas, Vim's :echo and input() have serious
bugs each, and are even more problematic when used together. Said
problems can be circumvented, I guess, but at the expense of ugliness
and inconvenience reproduced in every single script. This would
continually repel especially potential new users of Vim.
I am once again describing the bugs and incosistencies I know of, in
the hope that this would help to change your mind w.r.t. them. I am
mostly repeating my previous posts but exposing the issues a bit more
systematically.
I am not going to change this now, because:
- it's not a new problem in 7.3
- it is going to be incompatible with previous versions, some scripts
may need to be adjusted
- knowing how Vim does this it's possible to make it work
Thank you for your attention, best regards,
Boyko
~
==1==
The documentation says that echo “… starts on a new line” but this
is broken in at least several cases:
(a) empty strings, e.g.
for s in ['abc', '', 'def'] | echo s | endfor
prints
abc
def
rather than
abc
def
It only starts a new line if you have output something. Change the
empty string to ' ' and it works.
(b) this doesn't look like empty strings but still:
echo abc\n | echo def
is supposed to output
abc
def
but instead prints
abc
def
This works:
echo abc\n | echo def
abc
def
(c) after a call of input(), e.g. in
let x = input('') | echo 'ABC'
the ABC string goes to the same line as the input; similarly,
let x = input('') | echo \nABC
prints ABC on the line immediately following the input(), while
it should really leave an empty line between that of input() and
that with the ABC.
This is intentional, it avoids having to press Enter at the more-prompt.
You can echo the result of input() if you want to see it.
==2==
The documentation says nothing about whether input() always starts
on a new line or not. Simple tests such as e.g.
echo | let x = input('')
lead one to concluding that it does. However, then,
while 1 | let x = input('A') | echo R\n | endw
should be expected to print empty lines between each R\n and the
subsequent input('A') but it does not – that contradicts the
assumption that input() always moves to a new line at start.
It's difficult to explain how this works and probably also depends on
options settings, such as 'shortmess'. You can see what happens.
(Besides, the echo is again erroneous as described in (c) above.)
Please don't call things an error when it might actually be intended
behavior.
==3==
Reducing the R\n in the above example to just R:
while 1 | let s = input('A') | echo 'R' | endw
exhibits an even stranger behaviour. For a start, just enter several
empty lines to each input() before breaking the loop: not only is the
'R' printed on the same line as 'A' (which it
Vim 7.3e ready for beta testing
Hello Vim users, Announcing: Vim (Vi IMproved) version 7.3e BETA This is a BETA release of Vim 7.3. It consists of Vim 7.2 plus all patches, updated runtime files and some more. We are getting close to the 7.3 release! If nothing goes wrong I will release 7.3 in less than a week. Last chance to report problems! The biggest additions since 7.2: - Persistent undo and undo for reload - Blowfish encryption, encryption of the swap file - Conceal text (note: since 7.3a 'conc' was renamed to 'cole') - Lua interface - Python 3 interface I will no longer include new features in 7.3, it's only testing now. Once you have installed Vim 7.3e BETA you can find details about the changes since Vim 7.2 with: :help version-7.3 Testing --- Please especially test the persistent undo and encryption. These need to work reliably. Report anything that isn't right. That includes a crash but also a typo in the documentation and a missing file. Gratitude - If you like Vim, this is the way to say thanks: http://iccf-holland.org/clinic.html Where to get it --- The best way to obtain the latest Vim 7.3 is using Mercurial. Summary: hg clone https://vim.googlecode.com/hg/ vim cd vim hg update vim73 More information here: http://www.vim.org/mercurial.php All downloadable files can be found below this directory: ftp://ftp.vim.org/pub/vim/unstable/ Direct link to the MS-Windows self-installing executable: ftp://ftp.vim.org/pub/vim/unstable/pc/gvim73e.exe Information about which files to download for what system (don't use the links, they are still for Vim 7.2): http://www.vim.org/download.php A list of mirror sites can be found here: http://www.vim.org/mirrors.php An overview of the files below unstable: UNIX: unix/vim-7.3e.tar.bz2 sources + runtime files, bzip2 compressed MS-WINDOWS one-size-fits-all: pc/gvim73e.exe self-installing, includes all runtime files VARIOUS: doc/vim73ehtml.zip help files converted to HTML MS-WINDOWS separate files: pc/vim73ert.zip runtime files pc/gvim73e.zip GUI binary for Windows 95/98/NT/2000/XP pc/gvim73eole.zip GUI binary with OLE support pc/gvim73e_s.zipGUI binary for Windows 3.1 (untested) pc/vim73ed32.zipconsole version for MS-DOS/Windows 95/98 pc/vim73ew32.zipconsole version for Windows NT/2000/XP pc/vim73esrc.zipsources for PC (with CR-LF) DIFFS TO PREVIOUS RELEASE: unix/vim-7.3d-7.3e.diff.gz sources + runtime files Omitted in this version are: - Extra and lang archives, these are now included in the main source and runtime archives. - The 16-bit DOS, OS/2 and Amiga versions, these are obsolete. Mailing lists - For user questions you can turn to the Vim mailing list. There are a lot of tips, scripts and solutions. You can ask your Vim questions, but only if you subscribe. See http://www.vim.org/maillist.php#vim If you want to help Vim development, discuss new features or get the latest patches, subscribe to the vim-dev mailing list. See http://www.vim.org/maillist.php#vim-dev Subject specific lists: Multi-byte issues: http://www.vim.org/maillist.php#vim-multibyte Macintosh issues: http://www.vim.org/maillist.php#vim-mac Before you ask a question you should search the archives, someone may already have given the answer. Reporting bugs -- Send them to vim-...@vim.org. Please describe the problem precisely. All the time spent on answering mail is subtracted from the time that is spent on improving Vim! Always give a reproducible example and try to find out which settings or other things influence the appearance of the bug. Try starting without your own vimrc file: vim -u NONE. Try different machines if possible. See :help bugs in Vim. Send me a patch if you can! Happy Vimming! -- How To Keep A Healthy Level Of Insanity: 17. When the money comes out the ATM, scream I won!, I won! 3rd time this week! /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_use maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
