Am Donnerstag, 10. September 2015, 14:33:37 schrieb Manuel Ortega:
> In the case of mercurial, there's no need to make branches or merges in
> order to solve this problem. Just add the following to $REPO/.hg/hgrc:
>
> [hooks]
> pre-status = hg revert runtime/doc/tags
> pre-update = hg revert
Am Dienstag, 25. August 2015, 17:42:26 schrieb Christian Brabandt:
Did the .gitignore file change between the old googlecode repository and
the new github repository? I get a modification here:
diff --git a/.gitignore b/.gitignore
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,3 @@
-#
Am Donnerstag, 20. August 2015, 10:09:39 schrieb Manuel Ortega:
On Thu, Aug 20, 2015 at 4:55 AM, Bram Moolenaar b...@moolenaar.net wrote:
Markus Heidelberg wrote:
Am Mittwoch, 19. August 2015, 23:15:14 schrieb Markus Heidelberg:
Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram
Am Donnerstag, 20. August 2015, 10:55:23 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
Am Mittwoch, 19. August 2015, 23:15:14 schrieb Markus Heidelberg:
Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram Moolenaar:
I have removed the Ubuntu package for hg-fast-export
Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram Moolenaar:
I have removed the Ubuntu package for hg-fast-export and downloaded the
individual files from repo.or.cz. The conversion now runs without any
errors or warnings.
The result is now available at
Am Mittwoch, 19. August 2015, 23:15:14 schrieb Markus Heidelberg:
Am Mittwoch, 19. August 2015, 21:35:52 schrieb Bram Moolenaar:
I have removed the Ubuntu package for hg-fast-export and downloaded the
individual files from repo.or.cz. The conversion now runs without any
errors
Am Mittwoch, 19. August 2015, 19:00:36 schrieb Justin M. Keyes:
On Aug 19, 2015 5:57 PM, Markus Heidelberg markus.heidelb...@web.de
wrote:
Am Mittwoch, 19. August 2015, 15:03:38 schrieb Olaf Dabrunz:
On 19-Aug-15, Bram Moolenaar wrote:
Justin M. Keyes wrote:
On 8/18/15
Am Mittwoch, 19. August 2015, 15:03:38 schrieb Olaf Dabrunz:
On 19-Aug-15, Bram Moolenaar wrote:
Justin M. Keyes wrote:
On 8/18/15, Bram Moolenaar b...@moolenaar.net wrote:
There were a couple of hiccups, but the repository has moved to GitHub
now. It's in the destination
Am Mittwoch, 19. August 2015, 11:59:12 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
Am Dienstag, 18. August 2015, 18:42:50 schrieb Bram Moolenaar:
I let the script continue, ignoring the errors. Then I pushed the
result to github. I got some errors, I think my sequence
Am Sonntag, 16. August 2015, 15:23:15 schrieb Bram Moolenaar:
OK, if there is a chance you still find some improvements for the
Mercurial cleanup, we better wait a bit before doing that.
Once you have it all figured out, I hope you can send me the final
scripts. I wouldn't want some small
I hope I don't brake the mail chain, I'm not at home at my mail client.
Wonderful! And just in time, I'm working on Vim today.
Then staying up late was worth it :)
So, these are the steps to be taken:
1. Stop making changes: freeze; announce on Google code project page.
Announce on the
Am Dienstag, 18. August 2015, 18:42:50 schrieb Bram Moolenaar:
I wrote:
Applying your git cleanup script after the conversion from hg to git
produces lots of these errors:
fatal: ambiguous argument 'v7.2.434~4': unknown revision or path not in the
working tree.
Use '--' to
Am Sonntag, 16. August 2015, 15:23:15 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
BTW: you are working on the git cleanup, but is the Mercurial cleanup
now ready to be committed? AFAIK it all looks OK, so I could apply this
to my local repository and push it to Google code
Am Montag, 17. August 2015, 14:49:51 schrieb Marius Gedminas:
On Fri, Aug 14, 2015 at 01:39:18AM +0200, Markus Heidelberg wrote:
Am Donnerstag, 13. August 2015, 13:14:34 schrieb Bram Moolenaar:
You mentioned the size of the repository after export to github was
much larger than the one
Am Freitag, 14. August 2015, 09:42:34 schrieb Christian Brabandt:
Hi Markus!
On Fr, 14 Aug 2015, Markus Heidelberg wrote:
I'd also prefer to just removing the .hgignore from the history and
replacing it with .gitignore. What would that mean for the HG mirror,
Christian?
Hm, I don't
Am Samstag, 15. August 2015, 15:33:54 schrieb Bram Moolenaar:
Christian Brabandt wrote:
On Do, 13 Aug 2015, Bram Moolenaar wrote:
Then, I want to check in a change to Google code only, that produces
an
error when trying to build that version. This is because there is
Am Samstag, 15. August 2015, 15:33:54 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
Oh, I just noticed, of course we cannot just use a new git
repository/project on GitHub, otherwise the issues are gone.
The final official repository has to be pushed to one created
Am Freitag, 14. August 2015, 15:05:41 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
Am Freitag, 14. August 2015, 01:39:18 schrieb Markus Heidelberg:
Am Donnerstag, 13. August 2015, 13:14:34 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
[...]
2
Am Freitag, 14. August 2015, 20:38:49 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
Oh, I just noticed, of course we cannot just use a new git
repository/project on GitHub, otherwise the issues are gone.
The final official repository has to be pushed to one created
Am Donnerstag, 13. August 2015, 13:14:34 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
[...]
2. Conversion from HG to Git
So, what we would need to do is use the export to github for whatever
functionality it provides, but then wipe
Am Donnerstag, 13. August 2015, 23:01:07 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
OK, then I would document a procedure for local HG to Git conversion and
create a script for Git repository cleanup.
I did:
% mkdir vim-git
% cd vim-git
% git init
% hg
Am Mittwoch, 12. August 2015, 23:20:21 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
1. Cleanup in the HG repository
***
a check whether the rebase extension is enabled.
I think I already have it enabled, my .hgrc contains:
[extensions
Hi Bram,
sorry for the late reply. I'm pretty busy and also needed a bit to find
the proper words. It also takes some time to get into this topic again
after several months of silence.
Am Samstag, 8. August 2015, 21:43:13 schrieb Bram Moolenaar:
Markus Heidelberg wrote:
For me, a proper
Am Mittwoch, 12. August 2015, 08:50:55 schrieb Nazri Ramliy:
On Wed, Aug 12, 2015 at 6:51 AM, Markus Heidelberg #!/bin/sh
# Vim HG repository cleanup
hg config extensions.rebase || (echo -e Rebase extension has to be enabled
in ~/.hgrc:\n[extensions]\nrebase = exit 1)
The exit 1
Am Donnerstag, 23. April 2015, 14:20:06 schrieb Daniel Hahler:
Bram Moolenaar wrote:
Daniel Hahler wrote:
As Christian asked: How does the cleanup script fit in?
It's best to have a step-by-step description of what should happen to
avoid ending up with something that isn't what we
Am Donnerstag, 23. April 2015, 22:27:03 schrieb James McCoy:
On Thu, Apr 23, 2015 at 11:14:25AM -0700, Daniel Hahler wrote:
James McCoy wrote:
On Thu, Apr 23, 2015 at 9:19 AM, Christian Brabandt wrote:
On Do, 23 Apr 2015, Daniel Hahler wrote:
Using that export mangles the history
Am Donnerstag, 23. April 2015, 20:03:51 schrieb James McCoy:
On Thu, Apr 23, 2015 at 08:43:00PM +0200, Christian Brabandt wrote:
Hi James!
On Do, 23 Apr 2015, James McCoy wrote:
Using that export mangles the history of the repository by, at
the very least, removing all traces of
Am Donnerstag, 23. April 2015, 11:14:25 schrieb Daniel Hahler:
James McCoy wrote:
If people are just going to rebase their patches, then there's no
problem. If instead they want to merge future Vim development into
their existing branches, then the lack of a shared history is a
problem.
Hello Christian and Nikolay
Am Dienstag, 14. April 2015, 20:02:17 schrieb Christian Brabandt:
On Di, 14 Apr 2015, Nikolay Pavlov wrote:
2015-04-14 20:45 GMT+03:00 Christian Brabandt cbli...@256bit.org:
Hi Markus!
On Mo, 13 Apr 2015, Markus Heidelberg wrote:
[...]
hg rebase
Hello Bram,
currently I'm pretty busy aside from computer, so it all takes a while.
But here it is, the first part of cleanup in HG. A Git cleanup process
will follow after having finished this step.
Am Mittwoch, 1. April 2015, 21:52:41 schrieb Bram Moolenaar:
I generally like cleaning up,
Hi,
if switching to Git, we could seriously consider cleaning up the
repository, now it might be the last chance for quite a while.
I have collected some possibilities for improvement - some simple, some
a bit more complicated, but if found the proper commands/scripts, the
automated tasks should
/runtime/syntax/hex.vimMon Mar 02 20:26:23 2015 +0100
@@ -1,7 +1,28 @@
Vim syntax file
- Language:Intel hex MCS51
- Maintainer: Sams Ricahrd s...@ping.at
- Last Change: 2003 Apr 25
+ Language:Intel HEX
+ Maintainer: Markus Heidelberg markus.heidelb...@web.de
+ Last Change: 2015 Feb 24
Tony Mechelynck, 2010-05-28 02:59:
On 28/05/10 01:54, Markus Heidelberg wrote:
You can still add something like .*.swp to .hgignore for the swap files.
I would add not only .*.swp but even .*.sw? (to ignore .swo .swn etc.),
Yes, that would make sense.
src/auto/config.mk (which
Bram Moolenaar, 2010-05-26 22:59:
Tony Mechelynck wrote:
On 25/05/10 22:37, Bram Moolenaar wrote:
[...]
The undo files are hidden, all version control systems I know will
ignore them. E.g. swap files are normally not a problem.
[...]
For a counterexample, Mercurial tracks
Tony Mechelynck, 2010-05-16 18:09:
for instance on my local
repository there's one additional revision every time I fetch the
source (if there is a change in one or more of src/version.c,
src/Makefile, src/eval.c or src/feature.h)
A few days ago I told you that it has *nothing* to do with
Tony Mechelynck, 2010-05-14 05:11:
However, I have a few home
patches, one of which adds an Extra patch near the end of version.c
-- with the patches distributed by ftp this was no problem, as this
change is after the added patches: patch doesn't even notice it. But
with Mercurial as
Hello,
I have reviewed the patch for relative line numbers and while going
through the changes again, from the point of regressions I think it is
hard to introduce any in this patch, because most of the changes for the
'relativenumber' option are pretty parallel to the 'number' option.
Bram
Just a short notification.
The feature branches in vim_extended are now based on 'vim-with-runtime'
instead of plain 'vim'. Since the official Mercurial repository also
includes the latest runtime files, this makes sense now.
(Inspired by the Lech's new feature branch feat/tagfunc, which he based
Bram Moolenaar, 2010-02-24 15:08:
Patch 7.2.372 (extra)
Problem:Cross-compiling GvimExt and xxd doesn't work.
Solution: Change the build files. (Markus Heidelberg)
Files:src/INSTALLpc.txt, src/GvimExt/Make_ming.mak,
src/Make_cyg.mak,
src/Make_ming.mak, src/xxd
Bram Moolenaar, 2010-01-07:
Let me know if something looks wrong. Once this is approved by
vim-dev I'll publish it to a larger audience.
Is this the final Vim repository now or do you plan to rewrite it before
announcing it officially? Why don't you include the history (patch
descriptions)
James Vega, 2010-01-29:
On Fri, Jan 29, 2010 at 12:06:15AM +0100, Markus Heidelberg wrote:
Bram Moolenaar, 2010-01-07:
Let me know if something looks wrong. Once this is approved by
vim-dev I'll publish it to a larger audience.
Is this the final Vim repository now or do you plan
Bram Moolenaar, 2010-01-17:
Markus Heidelberg wrote:
Bram Moolenaar, 2010-01-07:
I have setup a Mercurial repository. It contains the same files that
are in CVS, plus the updated runtime files.
What about these files, available via ftp, but not via hg?
runtime/spell
sc, 2010-01-16:
On Saturday 16 January 2010 10:54:13 am Markus Heidelberg wrote:
vim_extended.git is based on vim_mainline so it will not be
continued in the same way. One solution would be to use a
tool like hg-to-git to import the official repo into a git
branch, but I guess
Bram Moolenaar, 2010-01-07:
I have setup a Mercurial repository. It contains the same files that
are in CVS, plus the updated runtime files.
What about these files, available via ftp, but not via hg?
runtime/getdos.aap
runtime/getunix.aap
runtime/main.aap
runtime/README.txt
Chris Sutcliffe, 2010-01-16:
I have setup a Mercurial repository. It contains the same files that
are in CVS, plus the updated runtime files.
What about these files, available via ftp, but not via hg?
The .aap files are a bit redundant given that all the code is in the
Mercurial
Lech Lorens, 30.10.2009:
On 29-10-2009 Bram Moolenaar b...@moolenaar.net wrote:
When I try this I get:
window 1 window 2
/dev/null file.txt
+++
|filler |last - 2|
|filler |last - 1|
|_ |last line
Lech Lorens, 30.10.2009:
On 30-Oct-2009 Markus Heidelberg markus.heidelb...@web.de wrote:
I have no problem reproducing it. I just wanted to send this as a
reproduction recipe:
$ vim -u NONE -U NONE -c normal itext -c diffsplit /dev/null
But yours from above works just as fine
Hello,
during some discussion with an Arch Linux user about the Arch Vim
package, we noticed the following:
These files have been removed from the vim tarballs in June/July 2008,
but are still present on the ftp server and should be removed:
/usr/share/vim/vim72/keymap/bulgarian.vim
John Little, 30.08.2009:
I was trying to check out the vim git repository, but my browser can't
resolve repo.or.cz.
Is it still available?
Yes, don't panic :)
Just a DNS problem or so.
Markus
--~--~-~--~~~---~--~~
You received this message from the
mobi phil, 30.06.2009:
Before continuing to invest time on this dirrection, I wonder if it would
make more sense to write QT windowing for vim, and that could be built both
on windows ce and the linux based phones (like QT on openmoko etc.). I would
like to ask the community:
1. do you
_sc_, 25.06.2009:
when you say
Maybe you can change your script to choose which branch to merge
first.
you put yourself at risk of being asked how one might go about
doing such an ambitious thing
you may consider yourself asked, but asked with no pressure -- my
current two script
Chris Sutcliffe, 11.06.2009:
The compiler is currently hard coded to use gcc in xxd/Make_cyg.mak,
the attached patch allows it to be overridden using the standard
'CC=compiler' mechanism.
This un-hardcoding is part of my patch for cross-compiling with mingw
from 2009-03-18, which is still on
_sc_, 04.06.2009:
i update with my update script:
http://home.swbell.net/toothpik/.build/vim/u
it started out with with the same M... message i've been getting
for a week, showed me it was pulling stuff down, then ended with
the scary fatal message -- i will temporarily put the
_sc_, 05.06.2009:
On Friday 05 June 2009 4:11 am, Markus Heidelberg wrote:
I didn't notice this myself, because I always do
git checkout -- runtime/doc/tags
in my update/build script.
i have added it to mine, right before the merge of vim-with-runtime
http
Hi, nice to see you're still happy with git :)
_sc_, 04.06.2009:
markus (or anybody)--
for a week now (exactly a week: it started may 28) i've been
getting an 'M runtime/doc/tags' warning with my updates
didn't seem too earth-shattering, but today there were updates,
bringing me up
Bram Moolenaar, 17.05.2009:
Markus Heidelberg wrote:
The autocommand exists in these files:
runtime/doc/eval.txt
runtime/doc/usr_05.txt
runtime/vimrc_example.vim
eval.txt contains the most up-to-date autocommand, so adjust the others
to it:
* don't jump when the mark
The autocommand exists in these files:
runtime/doc/eval.txt
runtime/doc/usr_05.txt
runtime/vimrc_example.vim
eval.txt contains the most up-to-date autocommand, so adjust the others
to it:
* don't jump when the mark is in the first line
* use :normal! instead of :normal to avoid mappings
*
Bram Moolenaar, 17.05.2009:
Markus Heidelberg wrote:
The autocommand exists in these files:
runtime/doc/eval.txt
runtime/doc/usr_05.txt
runtime/vimrc_example.vim
eval.txt contains the most up-to-date autocommand, so adjust the others
to it:
* don't jump when the mark
Hello Nazri,
Nazri Ramliy, 31.03.2009:
The relative numbers are not updated properly when a scrollbinded
window is scrolled down due to the cursor being moved down in another
scrollbinded window.
I'm aware of it. That's because the global variable lnum becomes
invalid, when the current
Hisashi T Fujinaka, 25.03.2009:
I think I switched from CVS to subversion when I noticed that the
runtime files were up-to-date in svn but not CVS.
Neither of them contains the latest runtime files.
Ah, well, there's probably an easier way but I don't know what it is.
Dennis Benzinger, 23.03.2009:
Hi!
Is there a repository with the history of the runtime files?
Not officially, unfortunately. But since December the Vim extended git
repository contains a branch with the runtime files.
http://repo.or.cz/w/vim_extended.git
If I browse the CVS repository
Tony Mechelynck, 21.03.2009:
On 21/03/09 00:02, StarWing wrote:
[...]
i want to join in the develop of Vim! now i'm reading the source code,
feel very difficult, has some guide-line to source code? such as the
main flow, or the skeleton of the whole program?
There is :help
StarWing, 20.03.2009:
On 3月20日, 下午9时42分, Tony Mechelynck antoine.mechely...@gmail.com
Bram has now uploaded the patch and the other files that go with it on
the FTP server. Anyone interested can now go ahead and download them,
either to compile Vim or to update secondary repositories if
Bram Moolenaar, 19.03.2009:
There still is a needs to be verified note.
This note refers to this:
1) Install the mingw32 cross-compiler. See
http://www.libsdl.org/extras/win32/cross/README.txt
I can't say anything about this, I created the mingw toolchain with
Bram Moolenaar, 18.03.2009:
Markus Heidelberg wrote:
in :help a there is written
Any trailing or leading white space is included.
Ah, exclusive-or, of course. Why did I only used test cases with both
leading and trailing white space?
but only the trailing white space
Bram Moolenaar, 18.03.2009:
Markus Heidelberg wrote:
Before for xxd and GvimExt the normal compiler was invoked.
Also introduce the CROSS_COMPILE variable for the cross-compiler prefix,
now you don't have to set CC, CXX and WINDRES separately any more, if it
differs from
Vince Negri, 17.03.2009:
Morning all:
patch updated to 7.2.141 here:
http://vince.negri.googlepages.com/conceal-ownsyntax.diff
The link to tex2.vim [1] doesn't work any more, have you removed the file?
Markus
[1] http://vince.negri.googlepages.com/tex2.vim
Hello,
in :help a there is written
Any trailing or leading white space is included.
but only the trailing white space is included. Which one is correct, Vim
or the documentation?
The same applies to ' and `
Markus
--~--~-~--~~~---~--~~
You received
---
src/INSTALLpc.txt |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/INSTALLpc.txt b/src/INSTALLpc.txt
index 755ea3b..9f57070 100644
--- a/src/INSTALLpc.txt
+++ b/src/INSTALLpc.txt
@@ -215,8 +215,9 @@ directory.
You should not need to do *any* editing of any
John Beckett, 09.03.2009:
Bram Moolenaar wrote:
It's perhaps a bit strange to use :diffthis! to start diff
mode in other windows. :diffall would be more obvious.
It's not symmetric with :diffoff vs :diffoff!, but that
one doesn't say this.
What do you all think about using
Hi,
patch 7.2.137 has rewritten half of the function shift_block() in
src/ops.c. This is the part, which was heavily modified by the variable
tabstops patch, so that I ended up with a merge conflict. I will at
first remove the feature from the branch, so that I can update the
master branch.
If
Conditions:
* diff mode
* visual selection (characterwise or blockwise) started on a line with
DiffAdd, DiffChange or DiffText highlighting
* cursor column = start column of the visual selection
* console Vim, GUI not in use (reproduced on Linux and Windows)
- character of the cursor should
Markus Heidelberg, 03.03.2009:
Hello,
when searching for the EOL ($) and 'hlsearch' is set, it doesn't get
properly highlighted, if the EOL is in the same column as the cursor is
placed after the first match.
To reproduce:
vim -u NONE -U NONE -c set hlsearch -c normal 3ix^Mxx
Bram Moolenaar, 08.03.2009:
Markus Heidelberg wrote:
Bram Moolenaar, 06.03.2009:
Markus Heidelberg wrote:
Lech Lorens, 05.03.2009:
Perfectly fine with me - I hardly ever use :diffoff without !, anyway.
Is there a reason to not support the corresponding
Bram Moolenaar, 06.03.2009:
Markus Heidelberg wrote:
Lech Lorens, 05.03.2009:
Perfectly fine with me - I hardly ever use :diffoff without !, anyway.
Is there a reason to not support the corresponding :diffthis! command?
For consistency it seems like a good idea, instead of using
Ben Fritz, 06.03.2009:
On Mar 6, 3:41 am, Markus Heidelberg markus.heidelb...@web.de wrote:
What do you think, should the :diffthis! command set a special window
into diffmode, if it is the current window or should it never adjust
special windows?
I think, if a user executes
Tony Mechelynck, 03.03.2009:
On 02/03/09 13:48, Milan Vancura wrote:
But even people using ftp+rsync method can achieve the same just using
different method (in a more complicated way, my opinion, but this is a
different story and not my decision) as everyone still gets a patch through
Dennis Benzinger, 03.03.2009:
Hi!
Am 03.03.2009 06:40, James Vega schrieb:
[...]
2) Vim compiled with the --disable-multibyte configure option cannot use
UTF-8, or any other multibyte encoding; in fact it doesn't even accept
the 'encoding' option as valid.
Is there a reason
Tony Mechelynck, 03.03.2009:
On 03/03/09 06:40, James Vega wrote:
On Tue, Mar 03, 2009 at 03:32:45AM +0100, Tony Mechelynck wrote:
2) Vim compiled with the --disable-multibyte configure option cannot use
UTF-8, or any other multibyte encoding; in fact it doesn't even accept
the
Dennis Benzinger, 03.03.2009:
Hi Markus!
Am 03.03.2009 11:14, Markus Heidelberg schrieb:
Dennis Benzinger, 03.03.2009:
Hi!
Am 03.03.2009 06:40, James Vega schrieb:
[...]
2) Vim compiled with the --disable-multibyte configure option cannot
use
UTF-8, or any other
Milan Vancura, 02.03.2009:
Similarly, if I need to check something in the vim history, another
repository,
made by Christian Michon, is very helpful (http://github.com/cmichon/vim).
Indeed! I used it, when I recently used git-bisect, since vim_extended
doesn't have much useful history for
Hello,
when searching for the EOL ($) and 'hlsearch' is set, it doesn't get
properly highlighted, if the EOL is in the same column as the cursor is
placed after the first match.
To reproduce:
vim -u NONE -U NONE -c set hlsearch -c normal 3ix^Mxx^Mxxx^M^[/$^M
^M = Ctrl-vEnter
^[ =
Markus Heidelberg, 03.03.2009:
Hello,
when searching for the EOL ($) and 'hlsearch' is set, it doesn't get
properly highlighted, if the EOL is in the same column as the cursor is
placed after the first match.
To reproduce:
vim -u NONE -U NONE -c set hlsearch -c normal 3ix^Mxx
Tony Mechelynck, 28.02.2009:
On 28/02/09 04:54, Markus Heidelberg wrote:
Tony Mechelynck, 28.02.2009:
On 28/02/09 03:44, Markus Heidelberg wrote:
Tony Mechelynck, 27.02.2009:
On 27/02/09 04:04, Bram Moolenaar wrote:
How about some documentation? So that we know how it's supposed
Tony Mechelynck, 28.02.2009:
On 28/02/09 11:34, Markus Heidelberg wrote:
[...]
This debate is going nowhere. You won't change your mind, and neither
shall I, so I'm shutting up.
OK, do so, without having responded to the main argument a single time,
although I've reminded you. It seems
Tony Mechelynck, 28.02.2009:
On 28/02/09 12:06, Markus Heidelberg wrote:
Tony Mechelynck, 28.02.2009:
On 28/02/09 11:34, Markus Heidelberg wrote:
[...]
This debate is going nowhere. You won't change your mind, and neither
shall I, so I'm shutting up.
OK, do so, without having
Larson, DavidX S, 27.02.2009:
It is recommended to send the updates to the script's maintainer (listed in
the
script's header), too, so that he can quickly incorporate them into his
development version.
Hi Ingo,
Yea, I've already submitted these changes to Dr. Chip, but I haven't
Tony Mechelynck, 27.02.2009:
On 27/02/09 04:04, Bram Moolenaar wrote:
How about some documentation? So that we know how it's supposed to
work.
Yes: the announced eval.txt diff was not included. That's actually a
good point, because as long as your patch doesn't make it into
Tony Mechelynck, 28.02.2009:
On 28/02/09 03:44, Markus Heidelberg wrote:
Tony Mechelynck, 27.02.2009:
On 27/02/09 04:04, Bram Moolenaar wrote:
How about some documentation? So that we know how it's supposed to
work.
Yes: the announced eval.txt diff was not included. That's actually
Nikolai Weibull, 23.02.2009:
On Sun, Feb 22, 2009 at 23:16, Bram Moolenaar b...@moolenaar.net wrote:
Markus Heidelberg wrote:
Bram, can you include this? I got no response from the maintainer.
Hmm, Nikolai is usually responsive. Perhaps he just missed this
message.
I'll get
When in the pager because the :map output is to long for the screen,
leaving it with the possible keys (q : Esc Ctrl-C) sometimes doesn't
work immediately. It is depended on the size of Vim's screen. I tested
it with vim on the KDE Konsole and with gvim.
Maybe it is also dependent on the output
Markus Heidelberg, 22.02.2009:
Some test cases:
vim on Konsole maximized, lines=50 columns=155
:mapCRq
:mapCRddq
vim on Konsole standard, lines=24 columns=80
:mapCRq
:mapCRq
:mapCRddq
gvim, lines=30, columns=80
:mapCRdq
:mapCRdddq
:mapCRq
Bram Moolenaar, 22.02.2009:
Markus Heidelberg wrote:
When in the pager because the :map output is to long for the screen,
leaving it with the possible keys (q : Esc Ctrl-C) sometimes doesn't
work immediately. It is depended on the size of Vim's screen. I tested
it with vim on the KDE
Bram Moolenaar, 22.02.2009:
Patch 7.2.123
Problem:Typing 'q' at more prompt for :map output still displays another
line, causing another more prompt. (Markus Heidelberg)
Solution: Quit listing maps when 'q' typed.
Files: src/getchar.c
This only fixes a few
Bram Moolenaar, 23.02.2009:
Markus Heidelberg wrote:
Bram Moolenaar, 22.02.2009:
Patch 7.2.123
Problem:Typing 'q' at more prompt for :map output still displays
another
line, causing another more prompt. (Markus Heidelberg)
Solution: Quit listing maps
Markus Heidelberg, 23.02.2009:
Bram Moolenaar, 23.02.2009:
Markus Heidelberg wrote:
Bram Moolenaar, 22.02.2009:
Patch 7.2.123
Problem:Typing 'q' at more prompt for :map output still displays
another
line, causing another more prompt. (Markus
Bram Moolenaar, 23.02.2009:
Markus Heidelberg wrote:
Markus Heidelberg, 23.02.2009:
Bram Moolenaar, 23.02.2009:
Markus Heidelberg wrote:
Bram Moolenaar, 22.02.2009:
Patch 7.2.123
Problem:Typing 'q' at more prompt for :map output still
After reaching the end of the more prompt, hitting SPACE jumps out of
it. Add 'f' to avoid this problem and for consistency with 'b' in
scroll back a screen.
The first patch was bad, it did jump out of the more prompt when
pressing 'f' at the end of it, this is fixed now.
---
---
src/message.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/message.c b/src/message.c
index e0f2897..1cb7344 100644
--- a/src/message.c
+++ b/src/message.c
@@ -2504,7 +2504,6 @@ do_more_prompt(typed_char)
break;
case 'u': /*
After reaching the end of the more prompt, hitting SPACE jumps out of
it. Add 'f' to avoid this problem and for consistency with 'b' in
scroll down a screen.
This also changes the help message to contain f instead of SPACE,
I'm not sure about this.
This change also adds a missing leading Space
1 - 100 din 204 matches
Mail list logo
