Re: Patch patch 9.0.1679: Cleanup Tests from leftover files

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 8, 2023 at 12:57 PM Christian Brabandt  wrote:
>
>
> On Di, 08 Aug 2023, Christian Brabandt wrote:
>
> > patch 9.0.1679: Cleanup Tests from leftover files
>
> Sorry, trying to get the patch mails working.
>
> While this seems to fix the recent CI test failures about the file
> Xcrypt_sodium_v2.txt now I am seeing sodium_mlock() failures. I don't
> know yet why this happens :(
>

The git log commit message for this patch has a lot of details.  Bram
used to mention
a short description of the problem and the solution in the commit log.
Should we follow
that model going forward?

Regards,
Yegappan

-- 
-- 
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/CAAW7x7mx8NrvNeY5qYB%3D_BzMW5SCv%2BF5x8BDKWOiAjrBkKs12Q%40mail.gmail.com.

Re: Patch patch 9.0.1679: Cleanup Tests from leftover files

[Christian Brabandt]

On Di, 08 Aug 2023, Christian Brabandt wrote:

> patch 9.0.1679: Cleanup Tests from leftover files

Sorry, trying to get the patch mails working.

While this seems to fix the recent CI test failures about the file 
Xcrypt_sodium_v2.txt now I am seeing sodium_mlock() failures. I don't 
know yet why this happens :(

Best,
Christian
-- 
Hat man eine kleine Bitte: muß man mit dem Allgemeinen anfangen, man
habe was zu bitten, weil der andere dann froh ist, daß es nichts
Größeres ist. Eine große Bitte aber tue man ohne dies.
-- Jean Paul

-- 
-- 
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/ZNKeFySJ/TgXANp%2B%40256bit.org.

Patch patch 9.0.1679: Cleanup Tests from leftover files

[Christian Brabandt]

patch 9.0.1679: Cleanup Tests from leftover files

Commit: 
https://github.com/vim/vim/commit/84bc00e9b52b1174888f2f696f8b628a83c49988
Author: Christian Brabandt 
Date:   Thu Jul 13 11:45:54 2023 +0200

patch 9.0.1679: Cleanup Tests from leftover files

Problem:Tests may leave leftover files around
Solution:   Clean up tests and remove files

There were a few failures in 'linux (huge, gcc, testgui, true, true)'
e.g. here: 
https://github.com/vim/vim/actions/runs/5497376153/jobs/10018060156

,
| Error detected while processing command line..script 
/home/runner/work/vim/vim/src/testdir/runtest.vim[585]..function 
RunTheTest[54]..Test_lvimgrep_crash[16]..TestTimeout[12]..VimLeavePre 
Autocommands for "*"..function EarlyExit[7]..FinishTesting:
| line   70:
| E445: Other window contains changes
| E937: Attempt to delete a buffer that is in use: Xtest_stable_xxd.txt
| E937: Attempt to delete a buffer that is in use: Xtest_stable_xxd.txt
| E937: Attempt to delete a buffer that is in use: 
Xtest_stable_xxd.txtmalloc(): unsorted double linked list corrupted
`

Which is puzzling, because the Xtest_stable_xxd file should have been
long gone after test_crypt.vim is run (and definitely no longer be
staying around in test_quickfix.vim).

So try to clean up properly after a test script is run, just in case any
X is still around. During testing, a found a few leftover files,
which I also fixed in the relevant test-file.

Unfortunately, the test workflow 'linux (huge, gcc, testgui, true,
true)' now seems to fail with 'E1230: Encryption: sodium_mlock()' in
test_crypt.vim. Hopefully this is only temporary.

diff --git a/src/testdir/runtest.vim b/src/testdir/runtest.vim
index e2bc28d37..0d79bef3b 100644
--- a/src/testdir/runtest.vim
+++ b/src/testdir/runtest.vim
@@ -411,6 +411,24 @@ func RunTheTest(test)
   endif
 endfunc
 
+function Delete_Xtest_Files()
+  for file in glob('X*', v:false, v:true)
+if file ==? 'XfakeHOME'
+  " Clean up files created by setup.vim
+  call delete('XfakeHOME', 'rf')
+  continue
+endif
+" call add(v:errors, file .. " exists when it shouldn't, trying to delete 
it!")
+call delete(file)
+if !empty(glob(file, v:false, v:true))
+  " call add(v:errors, file .. " still exists after trying to delete it!")
+  if has('unix')
+call system('rm -rf  ' .. file)
+  endif
+endif
+  endfor
+endfunc
+
 func AfterTheTest(func_name)
   if len(v:errors) > 0
 if match(s:may_fail_list, '^' .. a:func_name) >= 0
@@ -439,13 +457,11 @@ endfunc
 " This function can be called by a test if it wants to abort testing.
 func FinishTesting()
   call AfterTheTest('')
+  call Delete_Xtest_Files()
 
   " Don't write viminfo on exit.
   set viminfo=
 
-  " Clean up files created by setup.vim
-  call delete('XfakeHOME', 'rf')
-
   if s:fail == 0 && s:fail_expected == 0
 " Success, create the .res file so that make knows it's done.
 exe 'split ' . fnamemodify(g:testname, ':r') . '.res'
diff --git a/src/testdir/test_mksession.vim b/src/testdir/test_mksession.vim
index aa291821e..5485e144f 100644
--- a/src/testdir/test_mksession.vim
+++ b/src/testdir/test_mksession.vim
@@ -973,6 +973,7 @@ func Test_mksession_foldopt()
   close
   %bwipe
   set sessionoptions&
+  call delete('Xtest_mks.out')
 endfunc
 
 " Test for mksession with "help" but not "options" in 'sessionoptions'
@@ -1105,6 +1106,7 @@ func Test_mksession_shortmess_with_A()
   set shortmess&
   set sessionoptions&
   call delete('Xtestsession')
+  call delete('Xtestfile')
 endfunc
 
 " Test for mksession with 'compatible' option
diff --git a/src/testdir/test_terminal.vim b/src/testdir/test_terminal.vim
index da263f455..bb6fca3ac 100644
--- a/src/testdir/test_terminal.vim
+++ b/src/testdir/test_terminal.vim
@@ -309,6 +309,7 @@ func Test_terminal_rename_buffer()
   call assert_equal('bar', bufname())
   call assert_match('bar.*finished', execute('ls'))
   exe 'bwipe! ' .. buf
+  call delete('Xtext')
 endfunc
 
 func s:Nasty_exit_cb(job, st)
@@ -1045,6 +1046,8 @@ func Test_terminal_redir_file()
 call WaitForAssert({-> assert_equal('dead', job_status(g:job))})
 bwipe
   endif
+
+  call delete('Xtext')
 endfunc
 
 func TerminalTmap(remap)
diff --git a/src/version.c b/src/version.c
index e5b484485..f2e714ca4 100644
--- a/src/version.c
+++ b/src/version.c
@@ -695,6 +695,8 @@ static char *(features[]) =
 
 static int included_patches[] =
 {   /* Add new patch number below this line */
+/**/
+1679,
 /**/
 1678,
 /**/

-- 
-- 
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 

Patch

[Christian Brabandt]

-- 
-- 
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/E1qTSiz-00Abmx-Mj%40256bit.org.

Re: Where is Bram?

[Doug Kearns]

On Wed, 9 Aug 2023 at 04:52, Christian Brabandt  wrote:

>
> On Mi, 09 Aug 2023, Doug Kearns wrote:
>
> > Runtime file updates often include test updates (e.g., filetype
> detection tests) and changes to runtime infrastructure (e.g.,
> runtime/ftplugin.vim) are also arguably worth a version bump.
> >
> > Bram's distinction here actually makes a lot of sense but may, I
> understand, not be tenable.
>
> Yes indeed. So https://github.com/vim/vim/issues/12722 shall increase the
> minor or not?


In an ideal world I think file type detection improvements like this should
get a bump.  It feels like core functionality and is tested by the main
test suite.

Regards,
Doug

-- 
-- 
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/CAJ1uvoBO%2BaYYaTUvPuirxxZ_q_TFrrN32xBgxyYOk9HutNMwew%40mail.gmail.com.

Re: [PATCH 2/2] Update the vimscript code in ":h restore-cursor"

[Christian Brabandt]

On Di, 08 Aug 2023, Dragan Simic wrote:

> On 2023-08-08 20:15, Christian Brabandt wrote:
> > On Di, 08 Aug 2023, 'Dragan Simic' via vim_dev wrote:
> > 
> > > diff --git a/runtime/doc/usr_05.txt b/runtime/doc/usr_05.txt
> > > index bc68e61b8..acc0f0c6b 100644
> > > --- a/runtime/doc/usr_05.txt
> > > +++ b/runtime/doc/usr_05.txt
> > > @@ -308,10 +308,14 @@ This switches on three very clever mechanisms:
> > > 
> > > 
> > >   *restore-cursor* *last-position-jump*  >
> > > -autocmd BufReadPost *
> > > -  \ if line("'\"") >= 1 && line("'\"") <= line("$") &&  !~#
> > > 'commit'
> > > -  \ |   exe "normal! g`\""
> > > -  \ | endif
> > > +augroup RestoreCursor
> > > +  autocmd!
> > > +  autocmd BufReadPost *
> > > +\ let line = line("'\"")
> > > +\ | if line >= 1 && line <= line("$") &&  !~# 'commit'
> > > &&  !=# 'xxd'
> > > +\ |   execute "normal! g`\""
> > > +\ | endif
> > > +augroup END
> > 
> > How about this version instead? This should make it easier to add more
> > filetypes to it.
> > 
> > > +\ | if line >= 1 && line <= line("$") && index(['commit',
> > > 'xxd'], ) = -1
> > > +\ |   execute "normal! g`\""
> > > +\ | endif
> 
> This looks great, but I'm afraid it won't work as expected.  AFAICT, the
> " !~# 'commit'" part is there as a negative regexp match to catch the
> "gitcommit" file type and any other similar file type names.

Ah yes that is true. I remember when I added it :)

Actually, I remember I had a similar issue where a certain filetype did 
not make sense for jumping to that last position, but do no longer 
remember which one :/

> > Shall we also change this in runtime/defaults.vim accordingly?
> 
> Perhaps it would be a good idea.

Best
Christian
-- 
Das wahrhaft größte Geschenk ist es, wenn man sein eigenes
Herz verschenken will.
-- Benjamin Stramke

-- 
-- 
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/ZNKPrt082SdxBVvC%40256bit.org.

Re: Where is Bram?

[Christian Brabandt]

On Mi, 09 Aug 2023, Doug Kearns wrote:

> Runtime file updates often include test updates (e.g., filetype detection 
> tests) and changes to runtime infrastructure (e.g., runtime/ftplugin.vim) are 
> also arguably worth a version bump.
> 
> Bram's distinction here actually makes a lot of sense but may, I understand, 
> not be tenable.

Yes indeed. So https://github.com/vim/vim/issues/12722 shall increase the minor 
or not?

Best,
Christian
-- 
Das Glück des Genies: Wenn es zuzeiten des Ernstes geboren wird.
-- Goethe, Maximen und Reflektionen, Nr. 764

-- 
-- 
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/ZNKPAXpo54SoEnkw%40256bit.org.

Re: [vim/vim] I'm sad to hear the news. (Discussion #12737)

['Dragan Simic' via vim_dev]

May you rest peacefully, Bram.  You started and continued doing a 
monumental thing for the humanity.


No matter how sad this moment is, let it remind us that the good things 
we do in our lives are important.  Human lives are extremely fragile, so 
let's do our best while we all are able to.


--
--
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/41fc0d4373f36262d584273d683a64c9%40manjaro.org.

Re: Where is Bram?

[Doug Kearns]

On Wed, 9 Aug 2023 at 03:56, Christian Brabandt  wrote:

>
> On Di, 08 Aug 2023, Yegappan Lakshmanan wrote:
>
> > I am not suggesting a separate minor release for each runtime file
> update here.
> > Otherwise, we will have too many minor releases.  Can we make a minor
> release
> > only for PRs that change the C code and not the runtime files (still
> > merge the runtime changes as separate PRs)?
>
> Yes, that should be possible. We can merge runtime files directly,
> without incrementing the minor patch number and only increment the minor
> patch number for changes to the source (including diff, libvterm, xxd or
> the test suite)
>

Runtime file updates often include test updates (e.g., filetype detection
tests) and changes to runtime infrastructure (e.g., runtime/ftplugin.vim)
are also arguably worth a version bump.

Bram's distinction here actually makes a lot of sense but may, I
understand, not be tenable.

Regards,
Doug

-- 
-- 
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/CAJ1uvoC5POrwToUac18EcfsBfgPa9Nu9BuF%2B955fMDXq1x8QgA%40mail.gmail.com.

Re: [PATCH 2/2] Update the vimscript code in ":h restore-cursor"

['Dragan Simic' via vim_dev]

On 2023-08-08 20:15, Christian Brabandt wrote:

On Di, 08 Aug 2023, 'Dragan Simic' via vim_dev wrote:


diff --git a/runtime/doc/usr_05.txt b/runtime/doc/usr_05.txt
index bc68e61b8..acc0f0c6b 100644
--- a/runtime/doc/usr_05.txt
+++ b/runtime/doc/usr_05.txt
@@ -308,10 +308,14 @@ This switches on three very clever mechanisms:


*restore-cursor* *last-position-jump*  >
-autocmd BufReadPost *
-  \ if line("'\"") >= 1 && line("'\"") <= line("$") &&  !~# 
'commit'

-  \ |   exe "normal! g`\""
-  \ | endif
+augroup RestoreCursor
+  autocmd!
+  autocmd BufReadPost *
+\ let line = line("'\"")
+\ | if line >= 1 && line <= line("$") &&  !~# 'commit' && 
 !=# 'xxd'

+\ |   execute "normal! g`\""
+\ | endif
+augroup END


How about this version instead? This should make it easier to add more
filetypes to it.

+\ | if line >= 1 && line <= line("$") && index(['commit', 
'xxd'], ) = -1

+\ |   execute "normal! g`\""
+\ | endif


This looks great, but I'm afraid it won't work as expected.  AFAICT, the 
" !~# 'commit'" part is there as a negative regexp match to catch the 
"gitcommit" file type and any other similar file type names.



Shall we also change this in runtime/defaults.vim accordingly?


Perhaps it would be a good idea.



Best,
Christian
--
Es hat in der ganzen Geschichte noch keinen Krieg zwischen zwei Ländern
gegeben, in deren beider Hauptstädte sich McDonald's Filialen befinden.
-- Frank Lüdecke (Zum Krieg in Afghanistan 2002)

--


--
--
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/4582eb182e491e1c4e97e47bbd1b9412%40manjaro.org.

Re: [PATCH 2/2] Update the vimscript code in ":h restore-cursor"

[Christian Brabandt]

On Di, 08 Aug 2023, 'Dragan Simic' via vim_dev wrote:

> diff --git a/runtime/doc/usr_05.txt b/runtime/doc/usr_05.txt
> index bc68e61b8..acc0f0c6b 100644
> --- a/runtime/doc/usr_05.txt
> +++ b/runtime/doc/usr_05.txt
> @@ -308,10 +308,14 @@ This switches on three very clever mechanisms:
>  
>  
>   *restore-cursor* *last-position-jump*  >
> -autocmd BufReadPost *
> -  \ if line("'\"") >= 1 && line("'\"") <= line("$") &&  !~# 'commit'
> -  \ |   exe "normal! g`\""
> -  \ | endif
> +augroup RestoreCursor
> +  autocmd!
> +  autocmd BufReadPost *
> +\ let line = line("'\"")
> +\ | if line >= 1 && line <= line("$") &&  !~# 'commit' &&  !=# 
> 'xxd'
> +\ |   execute "normal! g`\""
> +\ | endif
> +augroup END

How about this version instead? This should make it easier to add more 
filetypes to it.

> +\ | if line >= 1 && line <= line("$") && index(['commit', 'xxd'], 
> ) = -1
> +\ |   execute "normal! g`\""
> +\ | endif


Shall we also change this in runtime/defaults.vim accordingly?


Best,
Christian
-- 
Es hat in der ganzen Geschichte noch keinen Krieg zwischen zwei Ländern
gegeben, in deren beider Hauptstädte sich McDonald's Filialen befinden.
-- Frank Lüdecke (Zum Krieg in Afghanistan 2002)

-- 
-- 
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/ZNKGVmPILgS3bDXg%40256bit.org.

Re: [PATCH 1/2] Update the vimscript code in ":h hex-editing"

[Christian Brabandt]

On Di, 08 Aug 2023, 'Dragan Simic' via vim_dev wrote:

> 
> This version saves and restores the view position while saving the
> buffer, to keep the current view unchanged after doing ":w", which
> previously caused the window to scroll back to the very beginning of
> the buffer.  I believe it's needles to say how annoying and actually
> counterproductive that was.
> 
> This version also eliminates the "Press ENTER or type command to
> continue" message, which was previously displayed after opening larger
> binary files.  The use of "silent" and "redraw!" commands is also
> tailored specifically to avoid screen flickering, e.g. when doing
> ":w", caused by the buffer being filtered by an external command.
> 
> While there, reformat the code to make it more readable, and use longer
> versions of the commands, to make it slightly more consistent and more
> understandable to newcomers.
> ---
>  runtime/doc/tips.txt | 28 
>  1 file changed, 20 insertions(+), 8 deletions(-)
> 

> diff --git a/runtime/doc/tips.txt b/runtime/doc/tips.txt
> index ea8d538bf..79b1574e2 100644
> --- a/runtime/doc/tips.txt
> +++ b/runtime/doc/tips.txt
> @@ -431,14 +431,26 @@ comma-separated list of extension(s) you find yourself 
> wanting to edit: >
>  
>   " vim -b : edit binary using xxd-format!
>   augroup Binary
> -   au!
> -   au BufReadPre  *.bin let =1
> -   au BufReadPost *.bin if  | %!xxd
> -   au BufReadPost *.bin set ft=xxd | endif
> -   au BufWritePre *.bin if  | %!xxd -r
> -   au BufWritePre *.bin endif
> -   au BufWritePost *.bin if  | %!xxd
> -   au BufWritePost *.bin set nomod | endif
> +   autocmd!
> +   autocmd BufReadPre  *.bin set binary
> +   autocmd BufReadPost *.bin
> + \ if 
> + \ |   execute "silent %!xxd -c 32"
> + \ |   set filetype=xxd
> + \ |   redraw
> + \ | endif
> +   autocmd BufWritePre *.bin
> + \ if 
> + \ |   let s:view = winsaveview()
> + \ |   execute "silent %!xxd -r -c 32"
> + \ | endif
> +   autocmd BufWritePost *.bin
> + \ if 
> + \ |   execute "silent %!xxd -c 32"
> + \ |   set nomodified
> + \ |   call winrestview(s:view)
> + \ |   redraw
> + \ | endif
>   augroup END
>  
>  
> ==

Thanks, I think using the long command form makes sense.



Best,
Christian
-- 
angeln:
  stundenlang geduldig an einem Fleck lauern, bis man nichts gefangen hat.

-- 
-- 
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/ZNKFVdFYCjzLUYjj%40256bit.org.

Re: Where is Bram?

[Christian Brabandt]

On Di, 08 Aug 2023, Yegappan Lakshmanan wrote:

> I am not suggesting a separate minor release for each runtime file update 
> here.
> Otherwise, we will have too many minor releases.  Can we make a minor release
> only for PRs that change the C code and not the runtime files (still
> merge the runtime changes as separate PRs)?

Yes, that should be possible. We can merge runtime files directly, 
without incrementing the minor patch number and only increment the minor 
patch number for changes to the source (including diff, libvterm, xxd or 
the test suite)

Best,
Christian
-- 
Es ist schwer, das Glück in uns zu finden, und es ist ganz unmöglich,
es anderswo zu finden.
-- Nicolas Sébastien de Chamfort

-- 
-- 
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/ZNKB0QMWog9/NF/F%40256bit.org.

Re: Where is Bram?

[Christian Brabandt]

On Di, 08 Aug 2023, Dominique Pellé wrote:

> I can see some bugs at https://huntr.dev/repos/vim/vim/
> but I have the impression that I only see those that are
> fixed, which then become public. The most recent one
> I see is from June 15, 2023. I'll look at this in more details
> later.

There are some bugs, that are not marked self-closed or not/applicable 
(but rather medium or high). I believe, those are still open.

I think the hardest part will be to simplify and understand the provided 
POC files.

Best,
Christian
-- 
Richter: "Angeklagter, wann arbeiten Sie eigentlich?"
"Dann und wann."
"Und was?"
"Dies und das."
"Und wo?"
"Hier und dort."
"Gut, Sie kommen ins Gefängnis."
"Und wann werde ich wieder entlassen?"
"Früher oder später."

-- 
-- 
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/ZNKBXo/sOF06BnFM%40256bit.org.

Re: Where is Bram?

[Christian Brabandt]

On Di, 08 Aug 2023, Marvin Renich wrote:

> Christian, just a suggestion for a minor grammatical correction:
> 
> > ,
> > | [2023-08-09] The Vim project is deeply shocked and sad by the sudden
>^ saddened

Thanks, fixed.

> I would like to take this opportunity to express my appreciation to
> Christian, Ken, Yegappan, and Dr. Chip for all the work they have done
> in the past, and now in this very difficult time, for the work they are
> doing to keep this project as strong as it was under Bram's care.

Best,
Christian
-- 
Die Wissenschaft ist der Verstand der Welt, die Kunst ihre Seele.
-- Maxim Gorkij

-- 
-- 
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/ZNKAtG3yWQXk5M3U%40256bit.org.

Re: Where is Bram?

[Dominique Pellé]

Yegappan Lakshmanan wrote:

> > About point #2 i.e. "Addressing reported security
> > vulnerabilities including those reported in https://huntr.dev/repos/vim/vim;
> > I never looked at this, as I thought only Bram had
> > access to bug reported there for security reasons.
> > But if I can have access (?) I would be interested in:
> > - minimizing crash fuzzing POC
> > - and attempting to fix them
> >
>
> I am able to view all the reports and the discussions.  Are you able
> to view them?

I can see some bugs at https://huntr.dev/repos/vim/vim/
but I have the impression that I only see those that are
fixed, which then become public. The most recent one
I see is from June 15, 2023. I'll look at this in more details
later.

Regards
Dominique

-- 
-- 
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/CAON-T_jbyE7qWhKPVHN07sra1PvHPVZm0cRNGjLuDCiR%3D%3D_AMg%40mail.gmail.com.

Re: Where is Bram?

[Marvin Renich]

* Christian Brabandt  [230808 12:37]:
> 
> After fighting with mysql for a while, this should be done now: 
> https://www.vim.org/news/news.php sharing here:

Christian, just a suggestion for a minor grammatical correction:

> ,
> | [2023-08-09] The Vim project is deeply shocked and sad by the sudden
   ^ saddened

> | passing of Bram. We certainly will miss him, his guidance and his
> | humour.
> | 
> | The Vim project wouldn't exist without his ongoing passion to lead and
> | develop Vim and the community for more than 30 years.
> | 
> | Our deepest condolences to all his family and may they have enough
> | strengths to come through these sad times. We lost a great guy way too
> | early, who should have had the chance to enjoy and live for at least
> | several more years!
> | 
> | In addition he was well-known for collecting donations for the ICCF
> | foundation and helping many children in Uganda. And despite the sad
> | news, during the last 7 days an incredible amount of EURO 60,000 was
> | donated. That is so awesome. Thank you all contributors!
> | 
> | An incredible amount of people have been giving respect and saying
> | goodby at here and you'll find obituary articles and links here.
> | 
> | It is in Brams interest to continue the Vim project even if development
> | now will slow down, but hopefully the community is being able to step up
> | and continue the work in the next years. (Christian Brabandt) 
> `

I would like to take this opportunity to express my appreciation to
Christian, Ken, Yegappan, and Dr. Chip for all the work they have done
in the past, and now in this very difficult time, for the work they are
doing to keep this project as strong as it was under Bram's care.

...Marvin

-- 
-- 
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/ZNJ9gi5ks4ZjDtop%40basil.wdw.

Re: Where is Bram?

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 8, 2023 at 8:39 AM Yegappan Lakshmanan  wrote:
>
> Hi Dominique,
>
> On Mon, Aug 7, 2023 at 1:12 PM Dominique Pellé
>  wrote:
> >
> > Yegappan Lakshmanan wrote:
> >
> > > Hi all,
> > >
> > > I am listing the tasks that Bram used to do for developing and maintaining
> > > Vim below (as far I can remember):
> > >
> > > 1. Developing fixes for Vim crash reports including the analysis of
> > >fuzzy test files.
> > > 2. Addressing reported security vulnerabilities including those reported
> > >in https://huntr.dev/repos/vim/vim.  I think various Linux
> > >distribution maintainers report these issues directly to Bram.
> > > 3. Fixing Coverity warnings reported in
> > >https://scan.coverity.com/projects/vim
> > > 4. Fixing CI build breakages including ASAN errors.
> > > 5. Create patches based on pull requests from Vim contributors
> > >(including updating the patches to match the Vim coding style and
> > >perform minor refactoring).
> > > 6. Developing major new features (e.g. Vim9 script, virtual text, etc.)
> > > 7. Reproducing the reported issues and developing fixes for those
> > >issues.
> > > 8. Improving the test infrastructure.  For example, he recently
> > >incorporated coding style checks and the support for syntax
> > >highlighting checks.
> > > 9. Incorporating the runtime file updates (e.g. syntax files, file
> > >types, etc.)
> > > 10. Updating the Vim documentation based on discussions and pull
> > > requests.
> > > 11. Maintaining the todo.txt file to track the roadmap for features and
> > > fixes.
> > > 12. Responding to questions and discussions in the Vim-dev mailing list.
> > > 13. Updating the vim.org website with news.
> > > 14. Preparing and making Vim releases (maybe once a year).
> > >
> > > Regards,
> > > Yegappan
> >
> > Thanks Yegappan for this list.
> >
> > About point #2 i.e. "Addressing reported security
> > vulnerabilities including those reported in https://huntr.dev/repos/vim/vim;
> > I never looked at this, as I thought only Bram had
> > access to bug reported there for security reasons.
> > But if I can have access (?) I would be interested in:
> > - minimizing crash fuzzing POC
> > - and attempting to fix them
> >
>
> I am able to view all the reports and the discussions.  Are you able
> to view them?
>
> >
> > About point #9 i.e. "Incorporating the runtime file updates"
> > I've always found it odd that some changes were split into
> > a commit in src and another commit later in runtime. It
> > often caused confusion, with PR author asking "part of
> > my change was not included?!" and the response being
> > "it will be in the next runtime update". Perhaps that's
> > something worth revisiting?
> >
>
> Yes. I think we should move the PR model for the runtime file updates.
>

I am not suggesting a separate minor release for each runtime file update here.
Otherwise, we will have too many minor releases.  Can we make a minor release
only for PRs that change the C code and not the runtime files (still
merge the runtime
changes as separate PRs)?

Regards,
Yegappan

>
> > In fact, this happened to my last PR at
> > https://github.com/vim/vim/pull/12544/files
> > where only part of it was merged and the
> > remaining part was meant to be in the next
> > runtime update, which sadly never happened.
> > I'll create a PR when I have time for what went
> > missing.
> >
> > There might also be other unrelated changes
> > which were pending in the next runtime update
> > that never happened. Often Bram responded
> > with "I'll include it" when people reported
> > corrections to the docs for example.
> >
> > Regards
> > Dominique
> >

-- 
-- 
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/CAAW7x7kct3BmGbJYkM290dfFYvf-CFkv5BP0f-kuSMzn%3DDGB6Q%40mail.gmail.com.

Re: Where is Bram?

[Christian Brabandt]

On Di, 08 Aug 2023, Yegappan Lakshmanan wrote:

> 
> Yes.  Also, there are references in the todo.txt file about many
> patches sent directly
> to Bram in the past.  All these patches are lost now.

Yes + Brams check scripts, to verify there were no obvious errors in the 
provided runtime files. Oh well...

I'll probably send out a reminder to all known Maintainers to resend any 
updates soon.

Best,
Christian
-- 
Eines Tages werden Maschinen vielleicht denken, aber sie werden
niemals Phantasie haben.
-- Theodor Heuss

-- 
-- 
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/ZNJw3awZat9NgdY9%40256bit.org.

Re: Where is Bram?

[Christian Brabandt]

On Mo, 07 Aug 2023, Christian Brabandt wrote:

> Yes, it is on my agenad, once I return from vacation. I don't have currently
> SSH access on my vacation place (only HTTPs unfortunately).

After fighting with mysql for a while, this should be done now: 
https://www.vim.org/news/news.php sharing here:

,
| [2023-08-09] The Vim project is deeply shocked and sad by the sudden
| passing of Bram. We certainly will miss him, his guidance and his
| humour.
| 
| The Vim project wouldn't exist without his ongoing passion to lead and
| develop Vim and the community for more than 30 years.
| 
| Our deepest condolences to all his family and may they have enough
| strengths to come through these sad times. We lost a great guy way too
| early, who should have had the chance to enjoy and live for at least
| several more years!
| 
| In addition he was well-known for collecting donations for the ICCF
| foundation and helping many children in Uganda. And despite the sad
| news, during the last 7 days an incredible amount of EURO 60,000 was
| donated. That is so awesome. Thank you all contributors!
| 
| An incredible amount of people have been giving respect and saying
| goodby at here and you'll find obituary articles and links here.
| 
| It is in Brams interest to continue the Vim project even if development
| now will slow down, but hopefully the community is being able to step up
| and continue the work in the next years. (Christian Brabandt) 
`

Also I have been told (and mentioned above), that in the past 7 days 
ICCF has received € 60,000 which is quite amazing!

Best,
Christian
-- 
Ein Narr ist nie so lächerlich, als man ihn macht.
-- Jean Paul

-- 
-- 
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/ZNJvREGfCdX5LUl4%40256bit.org.

Re: Where is Bram?

[Christian Brabandt]

On Di, 08 Aug 2023, Yegappan Lakshmanan wrote:

> Yes. I think we should move the PR model for the runtime file updates.

Yes, we should go ahead with this mode as of now. I am not sure, if this 
will however cause problems with e.g. the vim-win32-installer 
repository, if there are many changes without a proper minor patch 
number at the same time. But I think this should be fixed over there.

Best,
Christian
-- 
Am besten, Du kaufst Dir einen Strick und erschießt Dich, wo das Wasser am
tiefsten ist.

-- 
-- 
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/ZNJua%2BumHaE3Jj%2B9%40256bit.org.

Re: Where is Bram?

[Yegappan Lakshmanan]

Hi Dominique,

On Mon, Aug 7, 2023 at 1:12 PM Dominique Pellé
 wrote:
>
> Yegappan Lakshmanan wrote:
>
> > Hi all,
> >
> > I am listing the tasks that Bram used to do for developing and maintaining
> > Vim below (as far I can remember):
> >
> > 1. Developing fixes for Vim crash reports including the analysis of
> >fuzzy test files.
> > 2. Addressing reported security vulnerabilities including those reported
> >in https://huntr.dev/repos/vim/vim.  I think various Linux
> >distribution maintainers report these issues directly to Bram.
> > 3. Fixing Coverity warnings reported in
> >https://scan.coverity.com/projects/vim
> > 4. Fixing CI build breakages including ASAN errors.
> > 5. Create patches based on pull requests from Vim contributors
> >(including updating the patches to match the Vim coding style and
> >perform minor refactoring).
> > 6. Developing major new features (e.g. Vim9 script, virtual text, etc.)
> > 7. Reproducing the reported issues and developing fixes for those
> >issues.
> > 8. Improving the test infrastructure.  For example, he recently
> >incorporated coding style checks and the support for syntax
> >highlighting checks.
> > 9. Incorporating the runtime file updates (e.g. syntax files, file
> >types, etc.)
> > 10. Updating the Vim documentation based on discussions and pull
> > requests.
> > 11. Maintaining the todo.txt file to track the roadmap for features and
> > fixes.
> > 12. Responding to questions and discussions in the Vim-dev mailing list.
> > 13. Updating the vim.org website with news.
> > 14. Preparing and making Vim releases (maybe once a year).
> >
> > Regards,
> > Yegappan
>
> Thanks Yegappan for this list.
>
> About point #2 i.e. "Addressing reported security
> vulnerabilities including those reported in https://huntr.dev/repos/vim/vim;
> I never looked at this, as I thought only Bram had
> access to bug reported there for security reasons.
> But if I can have access (?) I would be interested in:
> - minimizing crash fuzzing POC
> - and attempting to fix them
>

I am able to view all the reports and the discussions.  Are you able
to view them?

>
> About point #9 i.e. "Incorporating the runtime file updates"
> I've always found it odd that some changes were split into
> a commit in src and another commit later in runtime. It
> often caused confusion, with PR author asking "part of
> my change was not included?!" and the response being
> "it will be in the next runtime update". Perhaps that's
> something worth revisiting?
>

Yes. I think we should move the PR model for the runtime file updates.

Regards,
Yegappan

> In fact, this happened to my last PR at
> https://github.com/vim/vim/pull/12544/files
> where only part of it was merged and the
> remaining part was meant to be in the next
> runtime update, which sadly never happened.
> I'll create a PR when I have time for what went
> missing.
>
> There might also be other unrelated changes
> which were pending in the next runtime update
> that never happened. Often Bram responded
> with "I'll include it" when people reported
> corrections to the docs for example.
>
> Regards
> Dominique
>

-- 
-- 
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/CAAW7x7kxatPYJDCCo4wE2LW8PTSUjcbEZWX2_FDuC6bR4nfKKA%40mail.gmail.com.

Re: Where is Bram?

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 8, 2023 at 8:18 AM Doug Kearns  wrote:
>
> On Tue, 8 Aug 2023 at 06:12, Dominique Pellé  
> wrote:
>
> 
>
>> About point #9 i.e. "Incorporating the runtime file updates"
>> I've always found it odd that some changes were split into
>> a commit in src and another commit later in runtime. It
>> often caused confusion, with PR author asking "part of
>> my change was not included?!" and the response being
>> "it will be in the next runtime update". Perhaps that's
>> something worth revisiting?
>
>
> I assume you're aware of how it worked but for others, user-maintained
> runtime file additions and updates didn't receive a patch number and
> were batched in a periodic "Update runtime files" commit.  However,
> any related changes to the core runtime like filetype detection were
> committed separately with priority as these did receive a patch
> number.
>
> I discussed this with Bram a couple of times over the years and the
> distinction was intentional.  I don't have a strong view on it but I
> agree that it's quite confusing for new and casual contributors.
>

I think Bram followed this approach to minimize the number of commits with
small changes to the runtime files.  This was the model followed before the
Vim source moved to github.

I think we can move to the PR model for runtime file changes to attribute
the changes to the proper author and to encourage more participation.
This is one of the points that was frequently brought up in the past in many
forums.

> 
>
>> There might also be other unrelated changes
>> which were pending in the next runtime update
>> that never happened. Often Bram responded
>> with "I'll include it" when people reported
>> corrections to the docs for example.
>
>
> It seems that there hasn't been an update of the user maintained
> runtime files since June 11[1] so there's likely to be a significant
> number of submissions that have been dropped.  For example, Bram
> didn't respond to my last emailed update on July 6.  Perhaps we should
> make a request for these to be resubmitted by PR at some stage.
>

Yes.  Also, there are references in the todo.txt file about many
patches sent directly
to Bram in the past.  All these patches are lost now.

Regards,
Yegappan

> Regards,
> Doug
>
> 1. https://github.com/vim/vim/commit/10e8ff9b26078994cae57c2422b145d37aaf714e
>

-- 
-- 
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/CAAW7x7kZe5cDs9-Giin5dN-AinchQa2oXK_AA8TGHho8AaRisQ%40mail.gmail.com.

Re: Where is Bram?

[Doug Kearns]

On Tue, 8 Aug 2023 at 06:12, Dominique Pellé 
wrote:



About point #9 i.e. "Incorporating the runtime file updates"
> I've always found it odd that some changes were split into
> a commit in src and another commit later in runtime. It
> often caused confusion, with PR author asking "part of
> my change was not included?!" and the response being
> "it will be in the next runtime update". Perhaps that's
> something worth revisiting?
>

I assume you're aware of how it worked but for others, user-maintained
runtime file additions and updates didn't receive a patch number and were
batched in a periodic "Update runtime files" commit.  However, any related
changes to the core runtime like filetype detection were committed
separately with priority as these did receive a patch number.

I discussed this with Bram a couple of times over the years and the
distinction was intentional.  I don't have a strong view on it but I agree
that it's quite confusing for new and casual contributors.



There might also be other unrelated changes
> which were pending in the next runtime update
> that never happened. Often Bram responded
> with "I'll include it" when people reported
> corrections to the docs for example.
>

It seems that there hasn't been an update of the user maintained runtime
files since June 11[1] so there's likely to be a significant number of
submissions that have been dropped.  For example, Bram didn't respond to my
last emailed update on July 6.  Perhaps we should make a request for these
to be resubmitted by PR at some stage.

Regards,
Doug

1.
https://github.com/vim/vim/commit/10e8ff9b26078994cae57c2422b145d37aaf714e

-- 
-- 
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/CAJ1uvoBUMUf6mXLCd6euqBYm2-jzvRCjHT1AyY_5LL%2Bfw_dpSQ%40mail.gmail.com.

[PATCH 1/2] Update the vimscript code in ":h hex-editing"

['Dragan Simic' via vim_dev]

This version saves and restores the view position while saving the
buffer, to keep the current view unchanged after doing ":w", which
previously caused the window to scroll back to the very beginning of
the buffer.  I believe it's needles to say how annoying and actually
counterproductive that was.

This version also eliminates the "Press ENTER or type command to
continue" message, which was previously displayed after opening larger
binary files.  The use of "silent" and "redraw!" commands is also
tailored specifically to avoid screen flickering, e.g. when doing
":w", caused by the buffer being filtered by an external command.

While there, reformat the code to make it more readable, and use longer
versions of the commands, to make it slightly more consistent and more
understandable to newcomers.
---
 runtime/doc/tips.txt | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

-- 
-- 
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/3d5c6f3fb9d55bb68f25f8b7b2ace8fc7a4128ef.1691476159.git.dsimic%40manjaro.org.
diff --git a/runtime/doc/tips.txt b/runtime/doc/tips.txt
index ea8d538bf..79b1574e2 100644
--- a/runtime/doc/tips.txt
+++ b/runtime/doc/tips.txt
@@ -431,14 +431,26 @@ comma-separated list of extension(s) you find yourself wanting to edit: >
 
 	" vim -b : edit binary using xxd-format!
 	augroup Binary
-	  au!
-	  au BufReadPre  *.bin let =1
-	  au BufReadPost *.bin if  | %!xxd
-	  au BufReadPost *.bin set ft=xxd | endif
-	  au BufWritePre *.bin if  | %!xxd -r
-	  au BufWritePre *.bin endif
-	  au BufWritePost *.bin if  | %!xxd
-	  au BufWritePost *.bin set nomod | endif
+	  autocmd!
+	  autocmd BufReadPre  *.bin set binary
+	  autocmd BufReadPost *.bin
+	\ if 
+	\ |   execute "silent %!xxd -c 32"
+	\ |   set filetype=xxd
+	\ |   redraw
+	\ | endif
+	  autocmd BufWritePre *.bin
+	\ if 
+	\ |   let s:view = winsaveview()
+	\ |   execute "silent %!xxd -r -c 32"
+	\ | endif
+	  autocmd BufWritePost *.bin
+	\ if 
+	\ |   execute "silent %!xxd -c 32"
+	\ |   set nomodified
+	\ |   call winrestview(s:view)
+	\ |   redraw
+	\ | endif
 	augroup END
 
 ==

[PATCH 2/2] Update the vimscript code in ":h restore-cursor"

['Dragan Simic' via vim_dev]

Thanks to the input file's dual nature, so to speak, using xxd(1)
to filter and edit binary files makes restoring the cursor position
broken.  Fix that by ignoring the appropriate file type in the code
that restores the cursor position.

While there, refactor the code a bit to save a few CPU cycles and
to keep the line lengths in check, and use longer versions of some
of the commands, to make it slightly more consistent and more
understandable to newcomers.
---
 runtime/doc/usr_05.txt | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

-- 
-- 
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/ff9a5f6f18ed343236cab42c204780fc08377e5d.1691476159.git.dsimic%40manjaro.org.
diff --git a/runtime/doc/usr_05.txt b/runtime/doc/usr_05.txt
index bc68e61b8..acc0f0c6b 100644
--- a/runtime/doc/usr_05.txt
+++ b/runtime/doc/usr_05.txt
@@ -308,10 +308,14 @@ This switches on three very clever mechanisms:
 
 
 *restore-cursor* *last-position-jump*  >
-autocmd BufReadPost *
-  \ if line("'\"") >= 1 && line("'\"") <= line("$") &&  !~# 'commit'
-  \ |   exe "normal! g`\""
-  \ | endif
+augroup RestoreCursor
+  autocmd!
+  autocmd BufReadPost *
+\ let line = line("'\"")
+\ | if line >= 1 && line <= line("$") &&  !~# 'commit' &&  !=# 'xxd'
+\ |   execute "normal! g`\""
+\ | endif
+augroup END
 
 Another autocommand.  This time it is used after reading any file.  The
 complicated stuff after it checks if the '" mark is defined, and jumps to it

Re: [vim/vim] Please share condolence articles on Bram and his work (Discussion #12742)

[George V. Reilly]

I wrote a post about Bram at my 
blog: https://www.georgevreilly.com/blog/2023/08/07/BramMoolenaarRIP.html

On Monday, August 7, 2023 at 3:00:04 PM UTC-7 Yegappan Lakshmanan wrote:

Some more articles:

https://thenewstack.io/bram-moolenaar-author-of-the-open-source-vim-code-editor-has-died/
https://fagenwasanni.com/ai/bram-moolenaar-creator-of-the-open-source-vim-code-editor-passes-away/160833/
https://thenextweb.com/news/dev-world-mourns-loss-of-vim-creator-bram-moolenaar
https://news.itsfoss.com/vim-creator-passed-away/
https://www.hackread.com/vim-text-editor-linux-bram-moolenaar-passes-away/

—
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/d52a57d8-66be-420b-9277-2b3ae1bf0427n%40googlegroups.com.