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

30 views
Skip to first unread message

Dragan Simic

unread,
Aug 9, 2023, 11:24:11 AM8/9/23
to vim...@vim.org

Save and restore the view position before and after saving the buffer,
respectively, to keep the current view of the xxd(1)'s hex dump
unchanged after doing ":w", which previously caused the window to
scroll back to the very beginning of the buffer. I believe it's
needless to say how annoying and counterproductive that was.

Get rid of 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 tailored specifically to avoid
screen flickering, e.g. when doing ":w", which is caused by the buffer
being filtered by an external command.

Increase the number of octets per line, produced by xxd(1), from the
default value of 16 to 32. This puts bigger chunks of the hex dump
on the screen and makes the whole thing much more usable.

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

0001-Improve-the-vimscript-code-in-h-hex-editing.patch

Dragan Simic

unread,
Aug 9, 2023, 11:24:11 AM8/9/23
to vim...@vim.org

Using xxd(1) to filter and edit binary files causes the input files
to have dual nature, so to speak, which effectively makes restoring
the cursor position broken. Fix that by ignoring the "xxd" file type
in the code that restores the cursor position.

Interactive rebasing in git causes files to be edited in vim, which,
similarly to commit messages, are rarely the same as the last one
edited. Thus, also add "gitrebase" to the list of file types for
which the cursor position isn't restored.

While there, refactor the code a bit to possibly save a few CPU cycles
and to keep the line lengths in check, and use the long form of the
commands and variables, to make the code slightly more consistent and
more understandable to newcomers.

Update the relevant comments in the code and the associated parts of
the documentation, to keep them in sync with the updated code.

Remove some redundant trailing whitespace as well, as spotted.
---
runtime/defaults.vim | 16 ++++++++++------
runtime/doc/usr_05.txt | 26 ++++++++++++++++++--------
2 files changed, 28 insertions(+), 14 deletions(-)

0002-Update-the-vimscript-code-for-restoring-cursor-position.patch

Christian Brabandt

unread,
Aug 10, 2023, 12:49:47 AM8/10/23
to vim...@googlegroups.com
[...]

Thanks, applied both.

BTW: like your commit message, it makes understanding why this change
has been done so much better.


Best,
Christian
--
"Every morning, I get up and look through the 'Forbes' list of the
richest people in America. If I'm not there, I go to work"
-- Robert Orben

Christian Brabandt

unread,
Aug 10, 2023, 1:00:09 AM8/10/23
to vim...@googlegroups.com
Improve the vimscript code in ":h hex-editing"

Commit: https://github.com/vim/vim/commit/6a500661a9cb7b57093cf1095aa67e9c4aabc709
Author: Dragan Simic' via vim_dev <vim...@googlegroups.com>
Date: Wed Aug 9 17:23:57 2023 +0200

Improve the vimscript code in ":h hex-editing"

Save and restore the view position before and after saving the buffer,
respectively, to keep the current view of the xxd(1)'s hex dump
unchanged after doing ":w", which previously caused the window to
scroll back to the very beginning of the buffer. I believe it's
needless to say how annoying and counterproductive that was.

Get rid of 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 tailored specifically to avoid
screen flickering, e.g. when doing ":w", which is caused by the buffer
being filtered by an external command.

Increase the number of octets per line, produced by xxd(1), from the
default value of 16 to 32. This puts bigger chunks of the hex dump
on the screen and makes the whole thing much more usable.

While there, reformat the code to make it more readable, and use the
long form of the commands and variables to make the code slightly more
consistent and more understandable to newcomers.

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 &bin=1
- au BufReadPost *.bin if &bin | %!xxd
- au BufReadPost *.bin set ft=xxd | endif
- au BufWritePre *.bin if &bin | %!xxd -r
- au BufWritePre *.bin endif
- au BufWritePost *.bin if &bin | %!xxd
- au BufWritePost *.bin set nomod | endif
+ autocmd!
+ autocmd BufReadPre *.bin set binary
+ autocmd BufReadPost *.bin
+ \ if &binary
+ \ | execute "silent %!xxd -c 32"
+ \ | set filetype=xxd
+ \ | redraw
+ \ | endif
+ autocmd BufWritePre *.bin
+ \ if &binary
+ \ | let s:view = winsaveview()
+ \ | execute "silent %!xxd -r -c 32"
+ \ | endif
+ autocmd BufWritePost *.bin
+ \ if &binary
+ \ | execute "silent %!xxd -c 32"
+ \ | set nomodified
+ \ | call winrestview(s:view)
+ \ | redraw
+ \ | endif
augroup END

==============================================================================

Christian Brabandt

unread,
Aug 10, 2023, 1:00:10 AM8/10/23
to vim...@googlegroups.com
Update the vimscript code for restoring cursor position

Commit: https://github.com/vim/vim/commit/81b8bf5b4a33552c610dc2ea743ac2698a16aef7
Author: Dragan Simic' via vim_dev <vim...@googlegroups.com>
Date: Wed Aug 9 17:23:58 2023 +0200

Update the vimscript code for restoring cursor position

Using xxd(1) to filter and edit binary files causes the input files
to have dual nature, so to speak, which effectively makes restoring
the cursor position broken. Fix that by ignoring the "xxd" file type
in the code that restores the cursor position.

Interactive rebasing in git causes files to be edited in vim, which,
similarly to commit messages, are rarely the same as the last one
edited. Thus, also add "gitrebase" to the list of file types for
which the cursor position isn't restored.

While there, refactor the code a bit to possibly save a few CPU cycles
and to keep the line lengths in check, and use the long form of the
commands and variables, to make the code slightly more consistent and
more understandable to newcomers.

Update the relevant comments in the code and the associated parts of
the documentation, to keep them in sync with the updated code.

Remove some redundant trailing whitespace as well, as spotted.

diff --git a/runtime/defaults.vim b/runtime/defaults.vim
index 67659895f..6f8deb06b 100644
--- a/runtime/defaults.vim
+++ b/runtime/defaults.vim
@@ -99,15 +99,19 @@ if 1
" Put these in an autocmd group, so that you can revert them with:
" ":autocmd! vimStartup"
augroup vimStartup
- au!
+ autocmd!

" When editing a file, always jump to the last known cursor position.
" Don't do it when the position is invalid, when inside an event handler
- " (happens when dropping a file on gvim) and for a commit message (it's
- " likely a different one than last time).
+ " (happens when dropping a file on gvim), for a commit or rebase message
+ " (likely a different one than last time), and when using xxd(1) to filter
+ " and edit binary files (it transforms input files back and forth, causing
+ " them to have dual nature, so to speak)
autocmd BufReadPost *
- \ if line("'\"") >= 1 && line("'\"") <= line("$") && &ft !~# 'commit'
- \ | exe "normal! g`\""
+ \ let line = line("'\"")
+ \ | if line >= 1 && line <= line("$") && &filetype !~# 'commit'
+ \ && index(['xxd', 'gitrebase'], &filetype) == -1
+ \ | execute "normal! g`\""
\ | endif

augroup END
@@ -119,7 +123,7 @@ if 1
augroup vimHints
au!
autocmd CmdwinEnter *
- \ echohl Todo |
+ \ echohl Todo |
\ echo gettext('You discovered the command-line window! You can close it with ":q".') |
\ echohl None
augroup END
diff --git a/runtime/doc/usr_05.txt b/runtime/doc/usr_05.txt
index bc68e61b8..f43b23956 100644
--- a/runtime/doc/usr_05.txt
+++ b/runtime/doc/usr_05.txt
@@ -308,17 +308,27 @@ This switches on three very clever mechanisms:


*restore-cursor* *last-position-jump* >
- autocmd BufReadPost *
- \ if line("'\"") >= 1 && line("'\"") <= line("$") && &ft !~# 'commit'
- \ | exe "normal! g`\""
- \ | endif
+ augroup RestoreCursor
+ autocmd!
+ autocmd BufReadPost *
+ \ let line = line("'\"")
+ \ | if line >= 1 && line <= line("$") && &filetype !~# 'commit'
+ \ && index(['xxd', 'gitrebase'], &filetype) == -1
+ \ | 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
-if so. The backslash at the start of a line is used to continue the command
-from the previous line. That avoids a line getting very long.
-See |line-continuation|. This only works in a Vim script file, not when
-typing commands at the command-line.
+if so. It doesn't do that for a commit or rebase message, which are likely
+a different one than last time, and when using xxd(1) to filter and edit
+binary files, which transforms input files back and forth, causing them to
+have dual nature, so to speak. See also |using-xxd|.
+
+The backslash at the start of a line is used to continue the command from the
+previous line. That avoids a line getting very long. See |line-continuation|.
+This only works in a Vim script file, not when typing commands at the
+command line.

>
command DiffOrig vert new | set bt=nofile | r ++edit # | 0d_ | diffthis

Dragan Simic

unread,
Aug 10, 2023, 1:14:26 AM8/10/23
to vim...@vim.org
On 2023-08-10 06:49, Christian Brabandt wrote:
> On Mi, 09 Aug 2023, 'Dragan Simic' via vim_dev wrote:
>>
>> Save and restore the view position before and after saving the buffer,
>> respectively, to keep the current view of the xxd(1)'s hex dump
>> unchanged after doing ":w", which previously caused the window to
>> scroll back to the very beginning of the buffer. I believe it's
>> needless to say how annoying and counterproductive that was.
>>
>> Get rid of 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 tailored specifically to avoid
>> screen flickering, e.g. when doing ":w", which is caused by the buffer
>> being filtered by an external command.
>>
>> Increase the number of octets per line, produced by xxd(1), from the
>> default value of 16 to 32. This puts bigger chunks of the hex dump
>> on the screen and makes the whole thing much more usable.
>>
>> While there, reformat the code to make it more readable, and use the
>> long form of the commands and variables to make the code slightly more
>> consistent and more understandable to newcomers.
>
> [...]
>
> Thanks, applied both.

Great, thanks!

> BTW: like your commit message, it makes understanding why this change
> has been done so much better.

I'm glad you like it. :) It does take a fair amount of time to write
such detailed commit messages, but they're well worth it later, either
to help anyone going through the repository history understand the
changes, or in case any regressions are discovered later.

Dragan Simic

unread,
Aug 10, 2023, 1:52:43 AM8/10/23
to vim...@vim.org
BTW, as a suggestion, it might be a good idea to employ the rather
standard "Signed-off-by" scheme in the commit messages. For example,
the headers of my patches were garbled a bit by the Google mailing list,
rendering my true identity invisible, i.e. hiding my email address,
which would've been prevented by having a "Signed-off-by" line. I
believe that all patches should be properly attributed.

Christian Brabandt

unread,
Aug 10, 2023, 11:30:54 AM8/10/23
to vim...@googlegroups.com

On Do, 10 Aug 2023, 'Dragan Simic' via vim_dev wrote:

> BTW, as a suggestion, it might be a good idea to employ the rather standard
> "Signed-off-by" scheme in the commit messages. For example, the headers of
> my patches were garbled a bit by the Google mailing list, rendering my true
> identity invisible, i.e. hiding my email address, which would've been
> prevented by having a "Signed-off-by" line. I believe that all patches
> should be properly attributed.

Yes, I know this is used and several projects. I may as well do it, but
don't want to enforce it.

Best,
Christian
--
Stability itself is nothing else than a more sluggish motion.
Reply all
Reply to author
Forward
0 new messages