Re: [vim/vim] Update usr_51.txt (PR #13496)

[JohnBeckett]

The question of whether singular "they" is acceptable English was settled 
many decades ago. It's true that there are hold-outs who don't like "they" 
but the term has been part of English for a long time. Documentation which 
uses "he" or "he/she" is archaic.

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6ac08d05-cd9a-4e74-9bc3-c5dea74dbfb4n%40googlegroups.com.

Re: Moving the Vim Homepage on 26.09.2023

[JohnBeckett]

I expect there is some simple problem in the new PHP because no links to 
scripts appear to be working. For example, I believe the most recent script 
is 6078 and its link currently shows a blank page (and view source shows 
there was no output):
https://www.vim.org/scripts/script.php?script_id=6078

And script  does not exist but there is no error:
https://www.vim.org/scripts/script.php?script_id=

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6d1cee55-4fdb-4993-8fd3-8f28bab22f97n%40googlegroups.com.

Re: [vim/vim] Make object/class member variables public by default (PR #12932)

[JohnBeckett]

On Thursday, August 31, 2023 at 2:40:37 AM UTC+10 Yegappan Lakshmanan wrote:

To summarize, we have the following ways to declare and control access to 
object and class member variables currently (without the changes from this 
PR):
vim9script class A # object member: read-only access this.val1 = 10 # 
object member: read/write access public this.val2 = 20 # object member: 
private (no access) this._val3 = 30 # class member: read-only access static 
val4 = 40 # class member: read/write access public static val5 = 50 # class 
member: private (no access) static _val6 = 60 endclass

Please implement the above.  Vim script should be simple so do not require 
getters. Vim script should help coders so require "public" to explicitly 
show when data might be externally changed.

Message ID: 

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/cbf2e646-81e9-420f-a218-81009e015100n%40googlegroups.com.

Re: [vim/vim] vim.org should redirect to www.vim.org (Issue #11259)

[JohnBeckett]

The issue is that a volunteer handles all DNS issues at no cost or hassle 
for Bram. It keeps working year after year. That volunteer takes the 
technically correct view that vim.org is a domain name and it would be a 
mistake to expect a domain name to function as a host (a web server).

John


On Monday, October 3, 2022 at 4:52:57 AM UTC+11 Martin Tournoij wrote:

> This has been mentioned several times, but the maintainer of the DNS 
> records says it doesn't work. I forgot the details.
> Fortunately several browsers handle this if you type "vim.org".
>
> Neither Firefox not Chromium on my system do this.
>
> I'm pretty sure this can be made to work, one way or the other, even if 
> it's just pointing vim.org to a simple HTML page with a meta refresh tag.
>
> —
> Reply to this email directly, view it on GitHub 
> .
>
> You are receiving this because you are subscribed to this thread.Message 
> ID: 
>

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/bca977fc-3e30-42e9-be3b-0a125466aa7bn%40googlegroups.com.

Re: [vim/vim] win32: Drop support for XP and Vista (PR #11089)

[JohnBeckett]

> I don't see any thumbs-up or thumbs-down on this PR

My opinion is that anyone using (or who has to use) an unsupported and 
insecure operating system should not expect indefinite upgrades for 
programs like Vim. It's likely that someone using XP or Vista wouldn't even 
look for new Vim versions. That is, I think that support for the old 
systems should be dropped.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/3f9a3ead-4bb8-455e-83c7-60d993abda2en%40googlegroups.com.

Re: [vim/vim] :help vim9-scopes is outdated (Issue #9724)

[JohnBeckett]

>
> On Friday, February 11, 2022 at 10:09:08 PM UTC+11 Bram Moolenaar wrote:
> > This is what we would have then:
> >
> >  - Vim9 script at script level: "s:" NOT allowed.
> >  - Vim9 script in :def function: "s:" NOT allowed.
> >  - Vim9 script in legacy function: "s:" required for script items.
> >  - legacy script at script level: "s:" required for script items.
> >  - legacy script in :def function: "s:" required for script items that 
> are not defined yet, "s:" optional for existing script items.
> >  - legacy script in legacy function: "s:" required for script items
>
> I am not familiar enough with the details to make a meaningful 
> recommendation. However, the above list mentions "legacy" in the last four 
> items and it would make sense for s: to be required/optional there. The 
> first two items (Vim9 script at script level, Vim9 script in :def function) 
> should not permit s:.
>
> John
>

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/3cfe832d-4c44-4e66-b5d4-cc9b04724313n%40googlegroups.com.

Re: [vim/vim] :help vim9-scopes is outdated (Issue #9724)

[JohnBeckett]

On Thursday, February 10, 2022 at 12:27:18 AM UTC+11 Bram Moolenaar wrote:

> This comes from converting a legacy script to Vim9. So the question is
> whether it is good to force removing the "s:" prefix or is it more
> convenient to let it there?

If s: is never needed in vim9script, it should be an error to include it. 
As someone learning to use the new system, I want firm guidance—should I 
include s: or not? If I see it in someone's script, I'm going to wonder if 
it should be in mine (perhaps there is a performance advantage or something 
else I don't know about). It wastes everyone's time if arcane syntax is 
sometimes used.

There will never be another opportunity to decide how vim9script should 
work.

John

> Message ID: 
>

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/b3ad01f5-26e0-4e16-adf9-562974069b42n%40googlegroups.com.

vim9 :0put puts after the first line

[JohnBeckett]

I think this is a Vim 8.2.4293 bug but as it's from my first vim9script it 
might be me. Save the following to a file and source it (:so %).

vim9script
def Main(): void
  @a = "one\ntwo\nthree"
  new
  put =@a
  :1d
  :0put ='This should be the first line.'
enddef
Main()

The result is:

one
This should be the first line.
two
three

Using :1put! instead of :0put gives the same result.

Sourcing the following shows the correct order.

function Main()
  let @a = "one\ntwo\nthree"
  new
  put =@a
  :1d
  :0put ='This should be the first line.'
endfunction
call Main()

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/57358a35-0abf-45af-985f-b6e1c5207233n%40googlegroups.com.

Command :version should show major.minor.patch

[JohnBeckett]

It is convenient to say that Vim version 8.2.x is needed for a particular 
feature, but someone not familiar with Vim conventions may not know what 
the "x" means. I propose that, if "Included patches" is a range such as 
"1-3273", :version should show:

VIM - Vi IMproved 8.2.3273 (...)
...
Included patches: 1-3273

instead of:

VIM - Vi IMproved 8.2 (...)
...
Included patches: 1-3273

If included patches is not a contiguous range, just show 8.2 as is done 
currently.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/32d1418f-5fe3-4c7c-8b10-e1ac7f8b89d5n%40googlegroups.com.

Re: [vim/vim] Add diacritic-insensitive search (#8026)

[JohnBeckett]

If something like ignorediacritics is implemented, please make it work for 
:sort as well.

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/161749c5-0bbe-41fb-9d1d-67ea5a99e476n%40googlegroups.com.

Re: [vim/vim] Vim Stuck on Large file size when All the data is on single line (#7403)

[JohnBeckett]

> It only happens with large file (single line) only.

I have found that it is syntax highlighting which is very slow on long 
lines.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ee69e60d-589e-4be7-b6a1-2e6e8fe40cf3n%40googlegroups.com.

Re: [vim/vim] feature request: scroll through soft wrapped lines (#3188)

[JohnBeckett]

On Tuesday, July 10, 2018 at 7:26:03 PM UTC+10, GianniGi wrote:
> Can we please add an option that makes vim consider equal
> the soft wrapped (visual) lines and the hard wrapped lines?

Editing text where a single physical line is a long paragraph
is incredibly frustrating in Vim. Viewing diffs is a nightmare
because you can't scroll to see the changed text. A fix would
be very welcome.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.1.0105

[JohnBeckett]

On Sunday, June 24, 2018 at 3:23:31 AM UTC+10, Bram Moolenaar wrote:
> Patch 8.1.0105
> Problem:All tab stops are the same.
> Solution:   Add the variable tabstop feature. (Christian Brabandt,
> closes #2711)

Thanks Christian and Bram!

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How about a release?

[JohnBeckett]

On March 12, 2018 at 2:04:34 AM UTC+11, Bram Moolenaar wrote:
> First of all, I'm sorry to disappoint you.  This patch has
> been floating around for a long time and has never made it in.
> It's not urgent, and not a small thing to include, with the
> result I have been postponing it for a long time.

Re the variable tabs patch, I routinely edit tab-separated value
files and they would greatly benefit from variable tabs because
some columns are narrow while others are wide.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] In help documents, we should unify the spelling “Vim” or ”VIM". (#1732)

[JohnBeckett]

On Monday, May 29, 2017 at 7:03:51 PM UTC+10, Tatsuki wrote:
> There are 2 kinds spelling, “Vim” and “VIM” in the help documents.
> 
> For example, arabic.txt unified by “VIM"(but only L230 spelled "Vim”).
> 
> But autocmd.txt unified by “VIM”.
> 
> I think we should unify the spelling. But I don’t know which spelling should 
> be chosen.

Yes please! The documentation has evolved over many years and the style of how 
Vim/VIM/vim appears should be cleaned up. Also, let's fix 
gvim/Gvim/GVim/GVIM/gVim.

At the sadly neglected Vim wiki, we chose "Vim" and "gvim" despite the 
inconsistency. The "Vim" spelling fits modern usage such as in "Python" and 
many other packages. But then "Gvim" is rather weird, and "gVim" is very weird.

It would be nice to clean up the text shown by :version which starts with:

VIM - Vi IMproved 8.0

That might be better as:

Vim - vi improved 8.0.123

The patch level should be included. The above would mean patches 1 to 123 
inclusive have been applied.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Right-click pasting from PuTTY on Windows 10 (#1188)

[JohnBeckett]

On Friday, October 21, 2016 at 8:38:47 AM UTC+11, Trevor Sullivan wrote:
> Unfortunately, when I right-click in the PuTTY session, rather
> than pasting clipboard contents, what's actually happening is
> that Vim is going from INSERT mode to (insert) VISUAL mode.

Doing a right-click in Putty causes it to send the contents of the clipboard to 
the remote server, that is, to Vim which is in insert mode because you used 
"i". It sounds like a Putty config problem, or something weird in the clipboard.

In Putty, rather than doing a right-click, try typing Shift-Insert which should 
have the same effect. What happens?

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

E315 ml_get invalid lnum

[JohnBeckett]

Vim 8 deploys $VIMRUNTIME/defaults.vim which includes an autocmd
to "jump to the last known cursor position".
That can generate E315.

Execute the following to create two files and exit.
At exit, the cursor is on the last line of each file.

gvim -N -u NONE
:tabe test1.tmp
:put =range(1,90)
:w
:tabe test2.tmp
:put =range(1,100)
:xa

Execute the following to generate internal error E315:

gvim -N -u NONE
:source $VIMRUNTIME/defaults.vim
:tabe test2.tmp
:vert diffs test1.tmp

Result:

"test1.tmp" 91L, 353C
E315: ml_get: invalid lnum: 92
Press ENTER or type command to continue

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2J vs JJ

[JohnBeckett]

On Monday, October 10, 2016 at 6:19:35 PM UTC+11, Nazri wrote:
> So in order to get what can be done with JJ, I have to hit 3J
> instead, which feels weird.

I noticed that recently. However, ":help J" says "Join [count] lines, with a 
minimum of two lines" so the behaviour agrees with the documentation.

J means 1J which means join 1 line. However, the minimum is 2, so it joins 2 
lines.

2J means join 2 lines, and so is the same as J and 1J.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Diff should indicate if no differences detected

[JohnBeckett]

On Tuesday, August 30, 2016 at 5:56:01 AM UTC+10, Bram Moolenaar wrote:
>> gvim -N -u NONE
>>
>> :let lines = range(1, 999)
>> :call writefile(lines, 'old.tmp')
>> :call writefile(['inserted'] + lines, 'new.tmp')
>> :e new.tmp
>> :vert diffs old.tmp
>>
>> One way to execute the commands is to copy the lines to the
>> clipboard. In Vim, type @+
>>
>> Result: See two windows side-by-side. They appear to be
>> identical, with each window showing:
>>
>> 1
>> 2
>> 3
>> 4
>> 5
>> 6
>> +--993 lines: 7--
>>
>> The cursor is on "1" at the top of the left-hand window.
>> Pressing [c does nothing other than ring the bell. The only way
>> I know to see that the two files are different is to switch to
>> the right-hand window and scroll up ([c works).
>>
>> I'm never confident any more that a diff is showing everything.
>
> For me, when the files are identical I would not see any lines
> of text, only the closed fold.  Perhaps your setting is to
> always open the fold under the cursor?
>
> That filler lines may hide above the window is hard to avoid.
> We can't disallow scrolling the window into that position.
> Scrolling one line down to reveal one filler line is not so
> easy in general, would only work in some situations.  E.g.
> when the line wraps in the other window it may completely fill
> the window and the cursor line can't be displayed.

Thanks, you are right and that works for me. The fact that I can
see some lines open (after the recent patch) means there is a
difference.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Diff should indicate if no differences detected

[JohnBeckett]

On Sunday, August 28, 2016 at 10:40:05 PM UTC+10, Bram Moolenaar wrote:
> John Beckett wrote:
>> It is a real problem that Vim can mislead the user into thinking there
>> is no difference, when in fact a new line has been inserted at the top
>> of the other window. Just scrolling one window to the top is not
>> enough because unless you gg in *both* windows, you have no idea
>> whether the files are identical or not.
>
> It's strange that in this case we get lots of useless "~" lines.
> I wonder why that happens.  Probably the top line in the window is
> computed before the fold is closed.
>
> At least it helps a bit to set 'scrolloff' to 5 or more.
> Hmm, perhaps we should add that to the defaults.

Thanks Bram for patch 7.4.2279, that's much better.
However, the following shows there is still a frustration.

Using gvim.exe 7.4.2290

Start Vim then execute the commands shown.

gvim -N -u NONE

:let lines = range(1, 999)
:call writefile(lines, 'old.tmp')
:call writefile(['inserted'] + lines, 'new.tmp')
:e new.tmp
:vert diffs old.tmp

One way to execute the commands is to copy the lines to the
clipboard. In Vim, type @+

Result: See two windows side-by-side. They appear to be
identical, with each window showing:

1
2
3
4
5
6
+--993 lines: 7--

The cursor is on "1" at the top of the left-hand window.
Pressing [c does nothing other than ring the bell. The only way
I know to see that the two files are different is to switch to
the right-hand window and scroll up ([c works).

I'm never confident any more that a diff is showing everything.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Diff should indicate if no differences detected

[JohnBeckett]

On Sunday, August 28, 2016 at 11:26:51 PM UTC+10, Christian Brabandt wrote:
> Would a message, if both files are the same, be sufficient? I think diff
> always returns 0 if there are no differences found, so we could simply
> show a message in that case.

Hi Christian,

Thanks for the suggestion but Bram made a patch:

Patch 7.4.2279
Problem:Starting diff mode with the cursor in the last line
might end up only showing one closed fold.
Solution:   Scroll the window to show the same relative cursor position.
https://groups.google.com/forum/#!topic/vim_dev/1aZydRHu-rk

I'll try that soon.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Diff should indicate if no differences detected

[JohnBeckett]

On Sunday, August 28, 2016 at 8:05:29 PM UTC+10, toothpik wrote:
>> :tabe expected.txt
>> :vert diffs output.txt
>
>> When I last viewed those files, I may have exited with the cursor
>> on the last line. I use the code from ":help restore-cursor" to
>> restore the cursor position, so the diff shows the cursor at the
>> bottom.
>
> there's your problem right there

What are you saying? That I should never exit a file with the cursor at the 
end? Or I should not use the documented restore-cursor code?

It is a real problem that Vim can mislead the user into thinking there is no 
difference, when in fact a new line has been inserted at the top of the other 
window. Just scrolling one window to the top is not enough because unless you 
gg in *both* windows, you have no idea whether the files are identical or not.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Diff should indicate if no differences detected

[JohnBeckett]

Bram recently fixed :diffoff!
https://groups.google.com/forum/#!topic/vim_dev/h1nREhhF7mY

That reminds me of a diff frustration.

Suppose I have two files expected.txt and output.txt, each over 1000 lines. 
Running a test program creates the second file, and it should be the same as 
the first. I use something like the following to diff:

:tabe expected.txt
:vert diffs output.txt

When I last viewed those files, I may have exited with the cursor on the last 
line. I use the code from ":help restore-cursor" to restore the cursor 
position, so the diff shows the cursor at the bottom.

Problem: If the only difference is near the top, all I see in the left and 
right windows is a single line representing the folded "no difference" text. To 
be sure there is no difference, I have to gg in *both* windows.

I could use [c in just one window and take the fact that nothing happens as an 
indication that the two files are identical, but that is not satisfying. It 
also fails to show the diff if the only difference is that the file in the 
other window has had a new line inserted at the top.

Using zb is the same: it does not show the diff if the only difference is that 
the file in the other window has had a new line inserted at the top.

Can something be done to give a more convincing display of whether the two 
buffers have a difference? The problem is that Vim's logic for positioning the 
top line of the window shows the minimum amount of text in the above scenario 
(possibly just a single fold line). It would be nice if some extra logic said 
"this is a diff, so if there is a difference, scroll *both* windows down as 
much as possible".

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.1926

[JohnBeckett]

On Monday, June 13, 2016 at 8:52:25 PM UTC+10, Christian Brabandt wrote:
> ..\gvim -u dos.vim -U NONE --noplugin --not-a-term -s dotest.in test58.in
> NMAKE : fatal error U1077: '..\gvim.EXE' : return code '0xc005'
> Stop.
> 
> I rebuild that commit 3 times and it always breaks at that step for the
> 32bit build. Does anybody know, what that means?

You know that 0xc005 is an access violation error code? Something caused 
gvim to try to access unallocated memory?

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating runtime files without version control

[JohnBeckett]

Ken Takata wrote:
> Maybe, adding a link to http://ftp.vim.org/pub/vim/patches/7.4/README

On a page dedicated to discussing installing Vim, that link would be useful. 
However it is of no use for someone wanting to install Vim. Anyone wanting an 
old version will know what they have to do. Your download page needs to tell 
someone new what to do.

> If you send me a full text, I will merge it.

Here is my suggested wording. It's a bit verbose and would be painful if it has 
to be repeated for each version. However, something like this would be needed 
for someone who wants to be told what to do.

I don't know what the exe does. Does it offer to install 64-bit Vim on a 64-bit 
system? If yes, replace "32-bit" with "32-bit or 64-bit". Do we know what 
version of Windows is required? If it is XP, the first line might say "Nightly 
Vim build snapshots for Windows XP or later."

---start---

Nightly Vim Windows build snapshots.

Download file gvim_7.m.n.exe with the highest m and n version numbers. Run the 
exe to install 32-bit Vim, both GUI (gvim.exe) and console (vim.exe). The zip 
files contain the files that are installed by running the exe.

Vim will work without the following. However, if the specified version for a 
language is also installed, Vim can use it to provide extra features.

ActivePerl 5.22
(etc)

---end---

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating runtime files without version control

[JohnBeckett]

An alternative would be to use brief text like the following. We can put 
information on the wiki page which would be rewritten.

In the following "more information" would be a link to 
http://vim.wikia.com/wiki/Where_to_download_Vim

---start---

Nightly Vim Windows build snapshots (more information).

Run the most recent gvim_7.x.x.exe file to install Vim.

If any of the following are installed, they can be used by Vim to provide extra 
features.

ActivePerl 5.22
(etc)

---end---

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating runtime files without version control

[JohnBeckett]

Ken Takata wrote:
> OK, I added a note:
> https://github.com/k-takata/vim-win32-installer/releases
>
> I think it's ready to set up the official installer repository.

Thanks for setting that up. It will be of great benefit. However, can the 
explanatory text be improved? If each release has to have the same text for 
simplicity, can it contain a link to a page that briefly explains what is 
available. The page could be at vim.org or vim.wikia.com and it could have some 
brief text saying what each download is. Presumably each .exe is an installer 
that will offer to install Vim, both console vim.exe and GUI gvim.exe versions?

"Note:" does not help and should be omitted.

"in case you don't have a preference" is too mysterious. Just say that the .exe 
files are installers which will install the files required to run Vim, and the 
.zip files have all the Vim files which the user would need to manually handle.

Text "current dependencies" suggests the user MUST have those packages 
installed. However, I think it wants to say that the user MAY have one or more 
of the installed packages in which case extra features within Vim will be 
available. For example, if someone wants to use Python 2 from within Vim, they 
need Python 2.7 installed.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.1027

[JohnBeckett]

Bram Moolenaar wrote:
> Thinca wrote:
>
>> The description of "bin" is not added to :help 'nrformats'
>
> How about this:
>
>  bin  If included, numbers starting with "0b" or "0B" will be
>   considered to be binary.  Example: Using CTRL-X on
>   "0b1000" results in "0x0111".

Typo in last word: "0x" should be "0b".

Perhaps it is too wordy, but consider a new last line:

"0b1000" decrements it with result "0b0111".

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[JohnBeckett]

Thanks all. Bram's patch 7.4.975 fixes the problem here.

In case this ever arises again, I suspect the "au LargeFile BufLeave" line in 
my commands to demonstrate the problem was required. Executing the BufLeave 
event when leaving the big file window seemed to be necessary to produce the 
conditions that led to the problem.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[JohnBeckett]

Mike Williams:
> I'll look some more into it to make the defaults on Windows
> more sensible and if the code can be simplified.

Thanks all for the interesting progress. I'm trying to set up a test system 
where I might be able to join in but it's a long time since I worked in C. I 
don't know anything about the HAVE_xxx settings, but it appears there is a 
condition where Vim's data can be corrupted and that condition is being exposed 
by the particular tests being run. However, the problem is potentially more 
general, and conceivably corruptions could occur in other circumstances.

Have you reached a conclusion about whether the problem is related to a 
compiler optimisation bug? My guess would be that it is not since I don't think 
Steve Hall uses Visual Studio to build the Vim-without-Cream that I mentioned, 
and it also shows the corruption.

There has to be a clue in the fact that I have only ever seen corrupted text 
after executing :sort. Presumably Vim makes an array of pointers and sorts 
them. That array is being clobbered, or Vim's pointer to the array is being 
overwritten. Are any unchecked memory allocations done in Vim's sort?

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[JohnBeckett]

Dominique Pelle wrote:
>> Sorry, I forgot to check for plugins. I get no corruption when no plugins 
>> are loaded.
>>
>> The following shows how to reproduce the corruption from scratch.
>>
>> In a temp directory, make file auto.vim as follows.
>>
>> --- Start of auto.vim ---
>>
>> " Simplified LargeFile.vim
>> augroup LargeFile
>>   au BufReadPre *
>>   \ let f=expand("") |
>>   \  if getfsize(f) >= 100*1024*1024 |
>>   \  let b:eikeep=  |
>>   \  let b:ulkeep=  |
>>   \  set ei=FileType |
>>   \  setlocal noswf bh=unload |
>>   \  let f=escape(substitute(f,'\','/','g'),' ') |
>>   \  exe "au LargeFile BufEnter ".f." set ul=-1" |
>>   \  exe "au LargeFile BufLeave ".f." let =".b:ulkeep."|set ei=".b:eikeep 
>> |
>>   \  exe "au LargeFile BufUnload ".f." au! LargeFile * ". f |
>>   \  echomsg "***note*** handling a large file" |
>>   \ endif
>> augroup END
>>
>> --- end ---
>>
>> Execute the following two lines in Vim to create the big file in the temp 
>> directory:
>>
>> :let x = [repeat('a',20), repeat('b',25), repeat('c',30), repeat('d',35), 
>> repeat('e',40)]
>> :call writefile(repeat(x, 100), 'big.tmp')
>>
>> In the temp directory, start Vim with no plugins:
>>
>> vim -N -u NONE -i NONE
>>
>> Execute the following commands:
>>
>> :source auto.vim
>> :e big.tmp
>> :1,2y
>> :vnew
>> :put
>> :%s/.*/\=strlen(submatch(0)) . "\t" . submatch(0)/
>> :nohlsearch
>>
>> Sorting the buffer shows obvious corruption (many blank lines and junk):
>>
>> :sort
>>
>> John
>
>
> Hi John
>
> I tried to reproduce the corruption as you described,
> but I did not see any problem on Linux x86_64.
> I tried with both asan and valgrind.  Your bug might
> be Win32 specific.
>
> I don't have Windows, but I wonder whether someone
> could try Vim with DrMemory. See http://www.drmemory.org/
>
> asan may also work on Windows, but I'm not 100% sure.
> See:
> http://stackoverflow.com/questions/11806469/clang-with-faddress-sanitizer-on-windows
>
> Using those tools on Windows would obviously be useful
> to test Vim beyond this particular sort corruption bug.
>
> Regards
> Dominique

Thanks for investigating, and for the good ideas which I'll try to follow. I 
skipped the obvious stuff because it seemed unlikely to be an issue with the 
platform-specific code.

Here are my results on different systems I could find:

- Vim 7.4.972 win32 on 64-bit Windows 7 (my build): shows bug.
- Vim 7.4.827 on Windows XP (from cream): shows bug.
- Vim 7.3.266 on Windows XP (my build): no problem.
- Vim 7.3.415 on 32-bit Linux (my build): no problem.

The "cream" was from installing gvim-7-4-827.exe (Vim-without-Cream):
http://sourceforge.net/projects/cream/files/Vim/

It would be nice if others could report findings.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[JohnBeckett]

Christian Brabandt wrote:
> I have never seen something like this. 

I have tried again and seem to have a way to reproduce the problem.

In Vim, execute the following two lines (they may wrap here, each line starts 
with a colon). This creates file big.tmp which is 155 MB with 5 million lines.

:let x = [repeat('a',20), repeat('b',25), repeat('c',30), repeat('d',35), 
repeat('e',40)]
:call writefile(repeat(x, 100), 'big.tmp')

Close Vim and start it again. Then execute the following. It edits the big file 
and copies 20,000 lines to a new window, then does a substitute to insert the 
length of each line.

:e big.tmp
:1,2y
:vnew
:put
:%s/.*/\=strlen(submatch(0)) . "\t" . submatch(0)/
:nohlsearch

Now sort the 20,000 lines. The result reliably shows obvious corruption on my 
Vim 7.4.972.

:sort

I was planning to also execute the following to mimic the sort of things I do 
before the problem appears, but they are not necessary at the moment. The above 
is sufficient.

:undo
:redo
:sort n

To state the obvious, if you see the corruption, Vim is now unstable and while 
it may work for a while, it may crash. Close Vim and start a new instance 
before doing any work.

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[JohnBeckett]

Sorry, I forgot to check for plugins. I get no corruption when no plugins are 
loaded.

The following shows how to reproduce the corruption from scratch.

In a temp directory, make file auto.vim as follows.

--- Start of auto.vim ---

" Simplified LargeFile.vim
augroup LargeFile
  au BufReadPre *
  \ let f=expand("") |
  \  if getfsize(f) >= 100*1024*1024 |
  \  let b:eikeep=  |
  \  let b:ulkeep=  |
  \  set ei=FileType |
  \  setlocal noswf bh=unload |
  \  let f=escape(substitute(f,'\','/','g'),' ') |
  \  exe "au LargeFile BufEnter ".f." set ul=-1" |
  \  exe "au LargeFile BufLeave ".f." let =".b:ulkeep."|set ei=".b:eikeep |
  \  exe "au LargeFile BufUnload ".f." au! LargeFile * ". f |
  \  echomsg "***note*** handling a large file" |
  \ endif
augroup END

--- end ---

Execute the following two lines in Vim to create the big file in the temp 
directory:

:let x = [repeat('a',20), repeat('b',25), repeat('c',30), repeat('d',35), 
repeat('e',40)]
:call writefile(repeat(x, 100), 'big.tmp')

In the temp directory, start Vim with no plugins:

vim -N -u NONE -i NONE

Execute the following commands:

:source auto.vim
:e big.tmp
:1,2y
:vnew
:put
:%s/.*/\=strlen(submatch(0)) . "\t" . submatch(0)/
:nohlsearch

Sorting the buffer shows obvious corruption (many blank lines and junk):

:sort

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sort corruption

[JohnBeckett]

For many months I have noticed a bug whereby a sort results in corrupted text. 
I've been using a rather outdated Vim and the conditions for the corruption are 
not reproducible. I have recently upgraded to Vim 7.4.972 and just saw the bug 
again. I'm running 32-bit Vim with gigabytes of memory.

Here is an outline of what sometimes shows the corruption.

- Edit a big file (say 150 MB with two million lines).
- Copy some of the file (say 20,000 lines) to another buffer.
- Edit the copied text including some complex :s commands.
- Enter :sort to sort the result.
- Repeat last two steps a few times, possibly in other buffers.

The big file activates plugin/LargeFile.vim which is the original Mar 30, 2006 
release on my system. It just changes some settings so should not be relevant.

The result often works, but sometimes it is corrupted. The result is the 
correct number of lines, but most of them are empty. Lines that aren't empty 
contain snippets of the old text (for example, one line was the last three 
characters of a twenty-character line in the original).

This is a pretty useless report because whenever I've tried to reproduce the 
problem I fail. Is anyone else seeing this? Does anyone have a stress testing 
system?

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem using cgn to change a search hit when replacement includes hit

[JohnBeckett]

Christian Brabandt wrote:
> ...
> A fix is attached, but it is ugly.

Thanks! I applied the patch and did some tests trying to break
it, but it works well.

I don't understand the code, but I can see that:

flag + SEARCH_KEEP + SEARCH_END

works because of the possible values in flag, and '+' is how it
was done earlier in "SEARCH_KEEP + flag", but why not replace
each '+' with '|'?

John

-- 
-- 
You received this message from the "vim_dev" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Any spam from ad...@139.com at vim_dev?

[JohnBeckett]

Does anyone in vim_dev get junk mail from ad...@139.com?

The vim_use mailing list has an irritating problem whereby when
someone posts a message to vim_use, they receive a confusing
response from ad...@139.com 24 hours later. More at:
http://groups.google.com/group/vim_use/browse_thread/thread/32064f12c6f76d78

Does anyone posting to vim_dev receive similar spam?
If so, can you tell me when the most recent was?

Would one of the regular posters here please let me know if
you do NOT get the spam.

John

-- 
You received this message from the vim_dev 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