On 2021-10-30, meine <trialero@gmx.com> wrote:
> When starting Goyo, artifacts of the previous screen-wide display of the
> text stay. Scrolling though the text doesn't remove them (as opposed to
> Goyo in a GUI, where resizing the window removes the artifacts).
I do not have a solution, but I use Goyo and I cannot reproduce your
issue in my terminal (Apple's Terminal.app). You should provide more
details about your environment: Vim version, OS, terminal.
And have you searched for similar issues at
https://github.com/junegunn/goyo.vim/issues? You may have more luck
reporting your problem there.
Life.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/slkcrd%24ucf%241%40ciao.gmane.io.
Saturday, October 30, 2021
goyo plugin and artifacts in TTY
Hi,
for distraction free writing I like working in TTY -- terminal, no
graphical environment. I also like using the Goyo plugin to make the
lines ons screen shorter.
When starting Goyo, artifacts of the previous screen-wide display of the
text stay. Scrolling though the text doesn't remove them (as opposed to
Goyo in a GUI, where resizing the window removes the artifacts).
Does anyone know a solution to this?
Maybe it is in the plugin code, but I'm not (yet) that skilled to find
possible solutions.
TIA,
//meine
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YX2vk14g/yqwnsXs%40trackstand.
for distraction free writing I like working in TTY -- terminal, no
graphical environment. I also like using the Goyo plugin to make the
lines ons screen shorter.
When starting Goyo, artifacts of the previous screen-wide display of the
text stay. Scrolling though the text doesn't remove them (as opposed to
Goyo in a GUI, where resizing the window removes the artifacts).
Does anyone know a solution to this?
Maybe it is in the plugin code, but I'm not (yet) that skilled to find
possible solutions.
TIA,
//meine
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YX2vk14g/yqwnsXs%40trackstand.
Friday, October 29, 2021
Re: upgrading past 8.2.2918 loses access to /dev/tty from athena gvim
On Sun, Oct 17, 2021 at 01:37:34PM +0100, Bram Moolenaar <Bram@moolenaar.net> wrote:
>
> > On Thu, Oct 14, 2021 at 04:28:14PM +0100, Bram Moolenaar <Bram@moolenaar.net> wrote:
> >
> > > > > Since more than one person complained about this, and it still doesn't
> > > > > fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
> > > > > different solution.
> > > >
> > > > Thanks. Maybe blocking SIGHUP would fix the original problem with
> > > > background processes?
> > >
> > > Hopefully someone can find out what the actualy problem is and find a
> > > solution that works and does not cause new problems.
> >
> > Hmm, SIGHUP is already ignored in the gui.
>
> Thanks for taking time to look into this.
>
> > My guess is that the original problem is that most
> > shells inherit gvim's ignoring of SIGHUP, but zsh
> > doesn't. So the command being executed doesn't ignore
> > SIGHUP either, and it dies when zsh terminates, rather
> > than when it's finished. But that is just a guess.
> >
> > It's strange. The original bug report was for Arch Linux.
> > But it works fine on Debian Linux. It doesn't work on macOS.
>
> Thus we don't fully understand the cause of the problem. Perhaps it's a
> specific zsh version or how it was configured?
I thought that too, i.e., maybe macOS (via macports)
and arch have a recent zsh that no longer works, but
debian stable might have an older version which still
works. But macports and debian stable both have zsh-5.8
which is the latest version. Arch should have the same.
Hmm, the system /bin/zsh on my macOS is zsh-5.3 and
that works fine. So it's still a mystery.
> > I tried the following things on macOS:
> >
> > - Append "; wait" to the command
> > - Prepend "setopt NO_HUP; " to the command
> > - Prepend "trap '' HUP; " to the command
> > - Prepend "setopt NO_HUP; trap '' HUP; " to the command
> > - set shellcmdflag=-o\ nohup\ -c
> >
> > The only thing that "fixed" it was appending "; wait"
> > to the command. Below is a patch that does that,
> > only when the gui is running and the shell is zsh and
> > there's an ampersand in the command (so "&&" will be a
> > false positive).
> >
> > [...]
> >
> > But it's awful and hacky. It "fixes" the problem by
> > effectively disabling the ability to background a
> > process in zsh. And since it isn't a problem on Debian
> > Linux, it would make things slightly worse on some
> > systems, but only for commands that actually take a
> > long time to execute.
> >
> > Unfortunately, dtruss on macOS isn't working well
> > enough for me to trace what's happening. Perhaps
> > someone with Arch Linux can use strace to investigate.
> >
> > Until then, the most practical solution is to just:
> >
> > set shell=/bin/bash
> >
> > That fixes it on macOS.
>
> Well, more a workaround than a fix. But indeed, just setting 'shell' to
> something else than zsh should be a workable solution for most users.
>
> I rather recommend using another shell than to include a hacky solution
> with side effects.
Indeed.
> --
> If Microsoft would build a car...
> ... Occasionally your car would die on the freeway for no
> reason. You would have to pull over to the side of the road,
> close all of the car windows, shut it off, restart it, and
> reopen the windows before you could continue. For some reason
> you would simply accept this.
>
> /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
> /// \\\
> \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
cheers,
raf
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YXuzl5uK31sad0qC%40raf.org.
>
> > On Thu, Oct 14, 2021 at 04:28:14PM +0100, Bram Moolenaar <Bram@moolenaar.net> wrote:
> >
> > > > > Since more than one person complained about this, and it still doesn't
> > > > > fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
> > > > > different solution.
> > > >
> > > > Thanks. Maybe blocking SIGHUP would fix the original problem with
> > > > background processes?
> > >
> > > Hopefully someone can find out what the actualy problem is and find a
> > > solution that works and does not cause new problems.
> >
> > Hmm, SIGHUP is already ignored in the gui.
>
> Thanks for taking time to look into this.
>
> > My guess is that the original problem is that most
> > shells inherit gvim's ignoring of SIGHUP, but zsh
> > doesn't. So the command being executed doesn't ignore
> > SIGHUP either, and it dies when zsh terminates, rather
> > than when it's finished. But that is just a guess.
> >
> > It's strange. The original bug report was for Arch Linux.
> > But it works fine on Debian Linux. It doesn't work on macOS.
>
> Thus we don't fully understand the cause of the problem. Perhaps it's a
> specific zsh version or how it was configured?
I thought that too, i.e., maybe macOS (via macports)
and arch have a recent zsh that no longer works, but
debian stable might have an older version which still
works. But macports and debian stable both have zsh-5.8
which is the latest version. Arch should have the same.
Hmm, the system /bin/zsh on my macOS is zsh-5.3 and
that works fine. So it's still a mystery.
> > I tried the following things on macOS:
> >
> > - Append "; wait" to the command
> > - Prepend "setopt NO_HUP; " to the command
> > - Prepend "trap '' HUP; " to the command
> > - Prepend "setopt NO_HUP; trap '' HUP; " to the command
> > - set shellcmdflag=-o\ nohup\ -c
> >
> > The only thing that "fixed" it was appending "; wait"
> > to the command. Below is a patch that does that,
> > only when the gui is running and the shell is zsh and
> > there's an ampersand in the command (so "&&" will be a
> > false positive).
> >
> > [...]
> >
> > But it's awful and hacky. It "fixes" the problem by
> > effectively disabling the ability to background a
> > process in zsh. And since it isn't a problem on Debian
> > Linux, it would make things slightly worse on some
> > systems, but only for commands that actually take a
> > long time to execute.
> >
> > Unfortunately, dtruss on macOS isn't working well
> > enough for me to trace what's happening. Perhaps
> > someone with Arch Linux can use strace to investigate.
> >
> > Until then, the most practical solution is to just:
> >
> > set shell=/bin/bash
> >
> > That fixes it on macOS.
>
> Well, more a workaround than a fix. But indeed, just setting 'shell' to
> something else than zsh should be a workable solution for most users.
>
> I rather recommend using another shell than to include a hacky solution
> with side effects.
Indeed.
> --
> If Microsoft would build a car...
> ... Occasionally your car would die on the freeway for no
> reason. You would have to pull over to the side of the road,
> close all of the car windows, shut it off, restart it, and
> reopen the windows before you could continue. For some reason
> you would simply accept this.
>
> /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
> /// \\\
> \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
cheers,
raf
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YXuzl5uK31sad0qC%40raf.org.
Wednesday, October 27, 2021
Re: [vim/vim] [question] How to remap ctrl + Left/Right (Issue #9059)
On 2021-10-27, Julio Guerrero wrote:
> Hi Gary, I have applied those changes in my vimrc but the problem remains,
> after I ran the verbose command maps are pointing to my vimrc (same lines I
> added). I'm sorry I did not know this is the dev repo, will move my question to
> the other repo.
>
> Hi lacygoill, as per your questions:
>
> • $TERM: screen-256color
> • E846: Key code not set:
> • Ctrl-V then Ctrl-Right, delete lines
> • I use tmux
> • TERM out multiplexer: same as inside VIM - screen-256color
I'm using a different terminal now than I was this morning. Running
vim within tmux, I now see the problem.
In insert mode Ctrl-V Ctrl-Left inserts:
^[[1;5D
Ctrl-V Ctrl-Right inserts:
^[[1;5C
See
:help i_CTRL-V
Pressing Ctrl-Left in either normal or insert modes deletes the next
5 lines. Pressing Ctrl-Right also deletes 5 lines but goes to
insert mode.
That makes sense. Vim doesn't recognize those escape sequences so
it processes them as normal keystrokes. In normal mode, Vim ignores
that first <Esc> (^[). In insert mode, that first <Esc> puts Vim
into normal mode. Vim does not recognize the sequence [1 and
appears to ignore it. The ; will repeat the latest f, t, F or
T command. That may or may not move the cursor and affect the next
command. 5D deletes 5 lines. 5C deletes from the cursor to the end
of the line 4 more lines and starts insert mode.
I don't know the right solution at the moment, but a workaround
would be to put this in your vimrc.
if &term == "screen-256color"
nnoremap <Esc>[1;5C <C-Right>
nnoremap <Esc>[1;5D <C-Left>
inoremap <Esc>[1;5C <C-Right>
inoremap <Esc>[1;5D <C-Left>
endif
Regards,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211027201947.GC2195%40phoenix.
> Hi Gary, I have applied those changes in my vimrc but the problem remains,
> after I ran the verbose command maps are pointing to my vimrc (same lines I
> added). I'm sorry I did not know this is the dev repo, will move my question to
> the other repo.
>
> Hi lacygoill, as per your questions:
>
> • $TERM: screen-256color
> • E846: Key code not set:
> • Ctrl-V then Ctrl-Right, delete lines
> • I use tmux
> • TERM out multiplexer: same as inside VIM - screen-256color
I'm using a different terminal now than I was this morning. Running
vim within tmux, I now see the problem.
In insert mode Ctrl-V Ctrl-Left inserts:
^[[1;5D
Ctrl-V Ctrl-Right inserts:
^[[1;5C
See
:help i_CTRL-V
Pressing Ctrl-Left in either normal or insert modes deletes the next
5 lines. Pressing Ctrl-Right also deletes 5 lines but goes to
insert mode.
That makes sense. Vim doesn't recognize those escape sequences so
it processes them as normal keystrokes. In normal mode, Vim ignores
that first <Esc> (^[). In insert mode, that first <Esc> puts Vim
into normal mode. Vim does not recognize the sequence [1 and
appears to ignore it. The ; will repeat the latest f, t, F or
T command. That may or may not move the cursor and affect the next
command. 5D deletes 5 lines. 5C deletes from the cursor to the end
of the line 4 more lines and starts insert mode.
I don't know the right solution at the moment, but a workaround
would be to put this in your vimrc.
if &term == "screen-256color"
nnoremap <Esc>[1;5C <C-Right>
nnoremap <Esc>[1;5D <C-Left>
inoremap <Esc>[1;5C <C-Right>
inoremap <Esc>[1;5D <C-Left>
endif
Regards,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211027201947.GC2195%40phoenix.
Python 311 call fails
Hi,
Got this error on pyhton3 print('foo')
E370: Could not load library python311.dll: Le module sp<e9>cifi<e9> est introuvable.
E263: Sorry, this command is disabled, the Python library could not be loaded.
This is my configuration
1) redir @a | echomsg system('where python311.dll') | redir END | put=@a
C:\Python311\python311.dll^@S:\path\Vim\to\python\x86\python311.dll^@
2) echomsg filereadable('S:\path\Vim\to\python\x86\python311.dll')
3) VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 27 2021 15:23:19)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-3565
Compiled by ni.va@
Huge version with GUI. Features included (+) or not (-):
+cmdline_compl +file_in_path +lua/dyn -python -termguicolors +windows
+cmdline_hist +find_in_path +menu +python3/dyn +terminal +writebackup
Compilation: gcc -I. -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DHAVE_INET_NTOP -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DFEAT_DIRECTX_COLOR_EMOJI -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=i686 -Wall -I./lua-5.3.5/src/include -I./lua-5.3.5/src -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL="lua53.dll" -DFEAT_RUBY -I C:/Ruby30/include/ruby-3.0.0 -I C:/Ruby30/include/ruby-3.0.0/i386-mingw32 -DDYNAMIC_RUBY -DDYNAMIC_RUBY_DLL="msvcrt-ruby300.dll" -DRUBY_VERSION=30 -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL="python311.dll" -O3 -fomit-frame-pointer -freg-struct-return
Linking: g++ -I. -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DHAVE_INET_NTOP -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DFEAT_DIRECTX_COLOR_EMOJI -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=i686 -Wall -I./lua-5.3.5/src/include -I./lua-5.3.5/src -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL="lua53.dll" -DFEAT_RUBY -I C:/Ruby30/include/ruby-3.0.0 -I C:/Ruby30/include/ruby-3.0.0/i386-mingw32 -DDYNAMIC_RUBY -DDYNAMIC_RUBY_DLL="msvcrt-ruby300.dll" -DRUBY_VERSION=30 -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL="python311.dll" -O3 -fomit-frame-pointer -freg-struct-return -s -municode -mwindows -o gvim.exe -lkernel32 -luser32 -lgdi32 -ladvapi32 -lcomdlg32 -lcomctl32 -lnetapi32 -lversion -lwsock32 -lws2_32 -ld2d1 -ldwrite -loleaut32 -lwinmm -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lgcc_eh -Wl,-Bstatic -lwinpthread -Wl,-Bdynamic -lole32 -luuid
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/eb85ab4b-a113-49e8-925b-8d4c52b20f52n%40googlegroups.com.
Tuesday, October 26, 2021
Gvim drag-n-drop feature broken ?
Hi,
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/1b4a8e24-7935-48b5-b3c6-8480b153b871n%40googlegroups.com.
Maybe is my distribution but it seems that dropping files and dirs are no longer possible with GVim Buildx868.2.3564 on windows 10.
Meanwhile I have `has('drop_file') that returns 1 and tried a starting GVIM without loading plugins with -u NONE. Even with a test without $MYVIMRC.
Thanks
NiVa
-- --
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/1b4a8e24-7935-48b5-b3c6-8480b153b871n%40googlegroups.com.
Saturday, October 23, 2021
ch_open failed to connect to server
In neovim we can use sockconnect() to connect to a server. for example: sockconnect('tcp', 'imap.163.com:143'). I just test ch_open('imap.163.com:143'), it always failed.
TagBar 2.7 and ctags 5.9 exception closed GVim win32 x86 8.2.3558
Hi,
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/3f2a1c0e-0783-49d2-ae9d-934e9935ca10n%40googlegroups.com.
I daily use Gvim reading source code or other with TagBar plugin under Win10 OS under GVim 32bits x86 8.2.3558 build with ming under MSYS2.
It appears that TagBarToogle it works perfectly on my physical laptop Win10 64bits meanwhile an exception seems closing Gvim under Virtual MAchine under same OS.
Thanks for helping.
NiVa
Gvim
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 23 2021 12:24:35)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-3558
TagBar
*tagbar.txt* Display tags of a file ordered by scope
Author: Jan Larres
Licence: Vim licence, see |license|
Homepage: https://preservim.github.io/tagbar
Version: 2.7
Ctags
Universal Ctags 5.9.0(c0b04ae1), Copyright (C) 2015 Universal Ctags Team
Universal Ctags is derived from Exuberant Ctags.
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
Compiled: Oct 13 2021, 16:48:46
URL: https://ctags.io/
Optional compiled features: +win32, +wildcards, +regex, +gnulib_regex, +unix-path-separator, +iconv, +option-directory, +case-insensitive-filenames, +packcc, +optscript
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/3f2a1c0e-0783-49d2-ae9d-934e9935ca10n%40googlegroups.com.
Monday, October 18, 2021
Re: Vim backup files
There are options to change the location and to disable backup files for certain filetypes. My .vimrc file has:
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6d042fdf-91fa-4a0f-9e5e-5748c49f6fban%40googlegroups.com.
autocmd BufNewFile,BufRead /tmp/crontab* set nobackup nowritebackup
set backupdir=~/Library/Caches/vim/backup//
set backup
On Monday, October 18, 2021 at 5:31:34 AM UTC-4 Bram Moolenaar wrote:
Steve Litt wrote:
> I've used Vim since the 20th century, and of course things keep getting
> better, which means change. As I remember, back in the day, the Vim
> backup files that began with a dot and ended with .swp were text files
> containing what was in the window, and were automatically updated every
> X number of seconds. This appears to no longer be the case.
> .test.pl.swp appeared to be a binary file, so I couldn't just diff it
> with the original.
The backup file of file.txt is .file.txt~.
The .swp file is a binary format, although it does contain the text in
some way.
> In the past, after a crash, when I ran Vim on the file again, it gave
> me a dialog box in which to choose to recover, ignore, quit, whatever.
> This didn't happen in today's crash.
>
> I tried using :rec in the main file, it said there was no recovery
> file, and maybe changed the recovery file to .test.pl.swp.swp. I tried
> a few other things, but I was always just one step behind and
> eventually lost the swap files completely. Only one of them was
> important, and I have a paper copy, so I should be OK.
>
> After a crash, I'd like a way to know whether a swap file exists, and
> whether it indicates any differences from what's in my buffer. Is there
> a program that can do this for me, now that the dialog box doesn't
> happen anymore?
You can use "vim -r" to list swap files. If you see the one you need
then use "vim -r .file.txt.swp" to recover it.
--
hundred-and-one symptoms of being an internet addict:
184. You no longer ask prospective dates what their sign is, instead
your line is "Hi, what's your URL?"
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6d042fdf-91fa-4a0f-9e5e-5748c49f6fban%40googlegroups.com.
Re: Vim backup files
Steve Litt wrote:
> I've used Vim since the 20th century, and of course things keep getting
> better, which means change. As I remember, back in the day, the Vim
> backup files that began with a dot and ended with .swp were text files
> containing what was in the window, and were automatically updated every
> X number of seconds. This appears to no longer be the case.
> .test.pl.swp appeared to be a binary file, so I couldn't just diff it
> with the original.
The backup file of file.txt is .file.txt~.
The .swp file is a binary format, although it does contain the text in
some way.
> In the past, after a crash, when I ran Vim on the file again, it gave
> me a dialog box in which to choose to recover, ignore, quit, whatever.
> This didn't happen in today's crash.
>
> I tried using :rec in the main file, it said there was no recovery
> file, and maybe changed the recovery file to .test.pl.swp.swp. I tried
> a few other things, but I was always just one step behind and
> eventually lost the swap files completely. Only one of them was
> important, and I have a paper copy, so I should be OK.
>
> After a crash, I'd like a way to know whether a swap file exists, and
> whether it indicates any differences from what's in my buffer. Is there
> a program that can do this for me, now that the dialog box doesn't
> happen anymore?
You can use "vim -r" to list swap files. If you see the one you need
then use "vim -r .file.txt.swp" to recover it.
--
hundred-and-one symptoms of being an internet addict:
184. You no longer ask prospective dates what their sign is, instead
your line is "Hi, what's your URL?"
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211018093121.D0E21C80054%40moolenaar.net.
> I've used Vim since the 20th century, and of course things keep getting
> better, which means change. As I remember, back in the day, the Vim
> backup files that began with a dot and ended with .swp were text files
> containing what was in the window, and were automatically updated every
> X number of seconds. This appears to no longer be the case.
> .test.pl.swp appeared to be a binary file, so I couldn't just diff it
> with the original.
The backup file of file.txt is .file.txt~.
The .swp file is a binary format, although it does contain the text in
some way.
> In the past, after a crash, when I ran Vim on the file again, it gave
> me a dialog box in which to choose to recover, ignore, quit, whatever.
> This didn't happen in today's crash.
>
> I tried using :rec in the main file, it said there was no recovery
> file, and maybe changed the recovery file to .test.pl.swp.swp. I tried
> a few other things, but I was always just one step behind and
> eventually lost the swap files completely. Only one of them was
> important, and I have a paper copy, so I should be OK.
>
> After a crash, I'd like a way to know whether a swap file exists, and
> whether it indicates any differences from what's in my buffer. Is there
> a program that can do this for me, now that the dialog box doesn't
> happen anymore?
You can use "vim -r" to list swap files. If you see the one you need
then use "vim -r .file.txt.swp" to recover it.
--
hundred-and-one symptoms of being an internet addict:
184. You no longer ask prospective dates what their sign is, instead
your line is "Hi, what's your URL?"
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211018093121.D0E21C80054%40moolenaar.net.
Sunday, October 17, 2021
Re: Vim backup files
On 10/18/21 01:29, Shlomi Fish wrote:
> Hi Steve!
>
how did you get past my spam filters
> On Sun, 17 Oct 2021 18:18:46 -0400
> Steve Litt <slitt@troubleshooters.com> wrote:
>
>> Hi all,
>>
>> I've used Vim since the 20th century, and of course things keep getting
>> better, which means change. As I remember, back in the day, the Vim
>> backup files that began with a dot and ended with .swp were text files
>> containing what was in the window, and were automatically updated every
>> X number of seconds. This appears to no longer be the case.
>> .test.pl.swp appeared to be a binary file, so I couldn't just diff it
>> with the original.
>>
>> In the past, after a crash, when I ran Vim on the file again, it gave
>> me a dialog box in which to choose to recover, ignore, quit, whatever.
>> This didn't happen in today's crash.
>>
>> I tried using :rec in the main file, it said there was no recovery
>> file, and maybe changed the recovery file to .test.pl.swp.swp. I tried
>> a few other things, but I was always just one step behind and
>> eventually lost the swap files completely. Only one of them was
>> important, and I have a paper copy, so I should be OK.
>>
>> After a crash, I'd like a way to know whether a swap file exists, and
>> whether it indicates any differences from what's in my buffer. Is there
>> a program that can do this for me, now that the dialog box doesn't
>> happen anymore?
>>
>
> I tried it now:
>
> ```
> [shlomif@telaviv1 ~]$ -t dotfiles
> shlomif[dotfiles]:$trunk$ git i
> ⇒ On branch master
> ⇒ Your branch is up to date with 'origin/master'.
> ⇒ Remotes:
> origin git@github.com:shlomif/shlomif-computer-settings.git (fetch)
> origin git@github.com:shlomif/shlomif-computer-settings.git (push)
> shlomif[dotfiles]:$trunk$ ls
> LICENSE README.asciidoc README.asciidoc~ shlomif-settings
> shlomif[dotfiles]:$trunk$ gvim README.asciidoc
> shlomif[dotfiles]:$trunk$ pkill gvim
> Vim: Caught deadly signal TERM
> Vim: preserving files...
> shlomif[dotfiles]:$trunk$ Vim: Finished.
>
> shlomif[dotfiles]:$trunk$ git i
> ⇒ On branch master
> ⇒ Your branch is up to date with 'origin/master'.
> ⇒ Remotes:
> origin git@github.com:shlomif/shlomif-computer-settings.git (fetch)
> origin git@github.com:shlomif/shlomif-computer-settings.git (push)
> shlomif[dotfiles]:$trunk$ la
> total 68K
> drwxr-xr-x 8 shlomif shlomif 4.0K Oct 18 08:15 .git
> -rw-r--r-- 1 shlomif shlomif 4.8K Apr 21 08:23 .gitignore
> -rw-r--r-- 1 shlomif shlomif 4.7K Jul 27 2020 .gitignore~
> -rw-r--r-- 1 shlomif shlomif 2.3K Oct 6 2018 .hgignore
> -rw-r--r-- 1 shlomif shlomif 9 Oct 6 2018 LICENSE
> -rw-r--r-- 1 shlomif shlomif 17 Oct 6 2018 .perltidyrc
> -rw-r--r-- 1 shlomif shlomif 866 Jul 21 19:28 README.asciidoc
> -rw-r--r-- 1 shlomif shlomif 866 Jul 21 19:27 README.asciidoc~
> -rw-r--r-- 1 shlomif shlomif 12K Oct 18 08:14 .README.asciidoc.swp
> drwxr-xr-x 41 shlomif shlomif 4.0K Oct 2 2020 shlomif-settings
> drwxr-xr-x 4 shlomif shlomif 4.0K Sep 8 2020 .tidyall.d
> -rw-r--r-- 1 shlomif shlomif 523 Sep 29 2020 .tidyallrc
> -rw-r--r-- 1 shlomif shlomif 2.2K Jul 17 2020 .travis.yml
> shlomif[dotfiles]:$trunk$
>
> ```
>
> After I edited README.asciidoc again, I got this dialog:
> https://www.shlomifish.org/Files/files/images/gvim-recover-Screenshot_2021-10-18_08-16-50.png
> . Pressing "Recover" restored my unsaved changes.
>
> So "works for me" with my vim config (
> https://github.com/shlomif/shlomif-computer-settings/tree/master/shlomif-settings/vim-conf
> ).
>
>
>
>> Thanks,
>>
>> SteveT
>>
>> Steve Litt
>> Spring 2021 featured book: Troubleshooting Techniques of the Successful
>> Technologist http://www.troubleshooters.com/techniques
>>
>
>
>
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/0d7d962b-b87d-faf0-da9f-4b57dc4953fd%40my.liu.edu.
> Hi Steve!
>
how did you get past my spam filters
> On Sun, 17 Oct 2021 18:18:46 -0400
> Steve Litt <slitt@troubleshooters.com> wrote:
>
>> Hi all,
>>
>> I've used Vim since the 20th century, and of course things keep getting
>> better, which means change. As I remember, back in the day, the Vim
>> backup files that began with a dot and ended with .swp were text files
>> containing what was in the window, and were automatically updated every
>> X number of seconds. This appears to no longer be the case.
>> .test.pl.swp appeared to be a binary file, so I couldn't just diff it
>> with the original.
>>
>> In the past, after a crash, when I ran Vim on the file again, it gave
>> me a dialog box in which to choose to recover, ignore, quit, whatever.
>> This didn't happen in today's crash.
>>
>> I tried using :rec in the main file, it said there was no recovery
>> file, and maybe changed the recovery file to .test.pl.swp.swp. I tried
>> a few other things, but I was always just one step behind and
>> eventually lost the swap files completely. Only one of them was
>> important, and I have a paper copy, so I should be OK.
>>
>> After a crash, I'd like a way to know whether a swap file exists, and
>> whether it indicates any differences from what's in my buffer. Is there
>> a program that can do this for me, now that the dialog box doesn't
>> happen anymore?
>>
>
> I tried it now:
>
> ```
> [shlomif@telaviv1 ~]$ -t dotfiles
> shlomif[dotfiles]:$trunk$ git i
> ⇒ On branch master
> ⇒ Your branch is up to date with 'origin/master'.
> ⇒ Remotes:
> origin git@github.com:shlomif/shlomif-computer-settings.git (fetch)
> origin git@github.com:shlomif/shlomif-computer-settings.git (push)
> shlomif[dotfiles]:$trunk$ ls
> LICENSE README.asciidoc README.asciidoc~ shlomif-settings
> shlomif[dotfiles]:$trunk$ gvim README.asciidoc
> shlomif[dotfiles]:$trunk$ pkill gvim
> Vim: Caught deadly signal TERM
> Vim: preserving files...
> shlomif[dotfiles]:$trunk$ Vim: Finished.
>
> shlomif[dotfiles]:$trunk$ git i
> ⇒ On branch master
> ⇒ Your branch is up to date with 'origin/master'.
> ⇒ Remotes:
> origin git@github.com:shlomif/shlomif-computer-settings.git (fetch)
> origin git@github.com:shlomif/shlomif-computer-settings.git (push)
> shlomif[dotfiles]:$trunk$ la
> total 68K
> drwxr-xr-x 8 shlomif shlomif 4.0K Oct 18 08:15 .git
> -rw-r--r-- 1 shlomif shlomif 4.8K Apr 21 08:23 .gitignore
> -rw-r--r-- 1 shlomif shlomif 4.7K Jul 27 2020 .gitignore~
> -rw-r--r-- 1 shlomif shlomif 2.3K Oct 6 2018 .hgignore
> -rw-r--r-- 1 shlomif shlomif 9 Oct 6 2018 LICENSE
> -rw-r--r-- 1 shlomif shlomif 17 Oct 6 2018 .perltidyrc
> -rw-r--r-- 1 shlomif shlomif 866 Jul 21 19:28 README.asciidoc
> -rw-r--r-- 1 shlomif shlomif 866 Jul 21 19:27 README.asciidoc~
> -rw-r--r-- 1 shlomif shlomif 12K Oct 18 08:14 .README.asciidoc.swp
> drwxr-xr-x 41 shlomif shlomif 4.0K Oct 2 2020 shlomif-settings
> drwxr-xr-x 4 shlomif shlomif 4.0K Sep 8 2020 .tidyall.d
> -rw-r--r-- 1 shlomif shlomif 523 Sep 29 2020 .tidyallrc
> -rw-r--r-- 1 shlomif shlomif 2.2K Jul 17 2020 .travis.yml
> shlomif[dotfiles]:$trunk$
>
> ```
>
> After I edited README.asciidoc again, I got this dialog:
> https://www.shlomifish.org/Files/files/images/gvim-recover-Screenshot_2021-10-18_08-16-50.png
> . Pressing "Recover" restored my unsaved changes.
>
> So "works for me" with my vim config (
> https://github.com/shlomif/shlomif-computer-settings/tree/master/shlomif-settings/vim-conf
> ).
>
>
>
>> Thanks,
>>
>> SteveT
>>
>> Steve Litt
>> Spring 2021 featured book: Troubleshooting Techniques of the Successful
>> Technologist http://www.troubleshooters.com/techniques
>>
>
>
>
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/0d7d962b-b87d-faf0-da9f-4b57dc4953fd%40my.liu.edu.
Re: Vim backup files
Hi Steve!
On Sun, 17 Oct 2021 18:18:46 -0400
Steve Litt <slitt@troubleshooters.com> wrote:
> Hi all,
>
> I've used Vim since the 20th century, and of course things keep getting
> better, which means change. As I remember, back in the day, the Vim
> backup files that began with a dot and ended with .swp were text files
> containing what was in the window, and were automatically updated every
> X number of seconds. This appears to no longer be the case.
> .test.pl.swp appeared to be a binary file, so I couldn't just diff it
> with the original.
>
> In the past, after a crash, when I ran Vim on the file again, it gave
> me a dialog box in which to choose to recover, ignore, quit, whatever.
> This didn't happen in today's crash.
>
> I tried using :rec in the main file, it said there was no recovery
> file, and maybe changed the recovery file to .test.pl.swp.swp. I tried
> a few other things, but I was always just one step behind and
> eventually lost the swap files completely. Only one of them was
> important, and I have a paper copy, so I should be OK.
>
> After a crash, I'd like a way to know whether a swap file exists, and
> whether it indicates any differences from what's in my buffer. Is there
> a program that can do this for me, now that the dialog box doesn't
> happen anymore?
>
I tried it now:
```
[shlomif@telaviv1 ~]$ -t dotfiles
shlomif[dotfiles]:$trunk$ git i
⇒ On branch master
⇒ Your branch is up to date with 'origin/master'.
⇒ Remotes:
origin git@github.com:shlomif/shlomif-computer-settings.git (fetch)
origin git@github.com:shlomif/shlomif-computer-settings.git (push)
shlomif[dotfiles]:$trunk$ ls
LICENSE README.asciidoc README.asciidoc~ shlomif-settings
shlomif[dotfiles]:$trunk$ gvim README.asciidoc
shlomif[dotfiles]:$trunk$ pkill gvim
Vim: Caught deadly signal TERM
Vim: preserving files...
shlomif[dotfiles]:$trunk$ Vim: Finished.
shlomif[dotfiles]:$trunk$ git i
⇒ On branch master
⇒ Your branch is up to date with 'origin/master'.
⇒ Remotes:
origin git@github.com:shlomif/shlomif-computer-settings.git (fetch)
origin git@github.com:shlomif/shlomif-computer-settings.git (push)
shlomif[dotfiles]:$trunk$ la
total 68K
drwxr-xr-x 8 shlomif shlomif 4.0K Oct 18 08:15 .git
-rw-r--r-- 1 shlomif shlomif 4.8K Apr 21 08:23 .gitignore
-rw-r--r-- 1 shlomif shlomif 4.7K Jul 27 2020 .gitignore~
-rw-r--r-- 1 shlomif shlomif 2.3K Oct 6 2018 .hgignore
-rw-r--r-- 1 shlomif shlomif 9 Oct 6 2018 LICENSE
-rw-r--r-- 1 shlomif shlomif 17 Oct 6 2018 .perltidyrc
-rw-r--r-- 1 shlomif shlomif 866 Jul 21 19:28 README.asciidoc
-rw-r--r-- 1 shlomif shlomif 866 Jul 21 19:27 README.asciidoc~
-rw-r--r-- 1 shlomif shlomif 12K Oct 18 08:14 .README.asciidoc.swp
drwxr-xr-x 41 shlomif shlomif 4.0K Oct 2 2020 shlomif-settings
drwxr-xr-x 4 shlomif shlomif 4.0K Sep 8 2020 .tidyall.d
-rw-r--r-- 1 shlomif shlomif 523 Sep 29 2020 .tidyallrc
-rw-r--r-- 1 shlomif shlomif 2.2K Jul 17 2020 .travis.yml
shlomif[dotfiles]:$trunk$
```
After I edited README.asciidoc again, I got this dialog:
https://www.shlomifish.org/Files/files/images/gvim-recover-Screenshot_2021-10-18_08-16-50.png
. Pressing "Recover" restored my unsaved changes.
So "works for me" with my vim config (
https://github.com/shlomif/shlomif-computer-settings/tree/master/shlomif-settings/vim-conf
).
> Thanks,
>
> SteveT
>
> Steve Litt
> Spring 2021 featured book: Troubleshooting Techniques of the Successful
> Technologist http://www.troubleshooters.com/techniques
>
--
Shlomi Fish https://www.shlomifish.org/
https://youtu.be/GoEn1YfYTBM - Tiffany Alvord - "Fall Together"
If Chuck Norris is disappointed by you not following his advice, he'll survive.
On the other hand, you will not.
— https://www.shlomifish.org/humour/bits/facts/Chuck-Norris/
Please reply to list if it's a mailing list post - https://shlom.in/reply .
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211018082916.66e2d76d%40shlomifish.org.
On Sun, 17 Oct 2021 18:18:46 -0400
Steve Litt <slitt@troubleshooters.com> wrote:
> Hi all,
>
> I've used Vim since the 20th century, and of course things keep getting
> better, which means change. As I remember, back in the day, the Vim
> backup files that began with a dot and ended with .swp were text files
> containing what was in the window, and were automatically updated every
> X number of seconds. This appears to no longer be the case.
> .test.pl.swp appeared to be a binary file, so I couldn't just diff it
> with the original.
>
> In the past, after a crash, when I ran Vim on the file again, it gave
> me a dialog box in which to choose to recover, ignore, quit, whatever.
> This didn't happen in today's crash.
>
> I tried using :rec in the main file, it said there was no recovery
> file, and maybe changed the recovery file to .test.pl.swp.swp. I tried
> a few other things, but I was always just one step behind and
> eventually lost the swap files completely. Only one of them was
> important, and I have a paper copy, so I should be OK.
>
> After a crash, I'd like a way to know whether a swap file exists, and
> whether it indicates any differences from what's in my buffer. Is there
> a program that can do this for me, now that the dialog box doesn't
> happen anymore?
>
I tried it now:
```
[shlomif@telaviv1 ~]$ -t dotfiles
shlomif[dotfiles]:$trunk$ git i
⇒ On branch master
⇒ Your branch is up to date with 'origin/master'.
⇒ Remotes:
origin git@github.com:shlomif/shlomif-computer-settings.git (fetch)
origin git@github.com:shlomif/shlomif-computer-settings.git (push)
shlomif[dotfiles]:$trunk$ ls
LICENSE README.asciidoc README.asciidoc~ shlomif-settings
shlomif[dotfiles]:$trunk$ gvim README.asciidoc
shlomif[dotfiles]:$trunk$ pkill gvim
Vim: Caught deadly signal TERM
Vim: preserving files...
shlomif[dotfiles]:$trunk$ Vim: Finished.
shlomif[dotfiles]:$trunk$ git i
⇒ On branch master
⇒ Your branch is up to date with 'origin/master'.
⇒ Remotes:
origin git@github.com:shlomif/shlomif-computer-settings.git (fetch)
origin git@github.com:shlomif/shlomif-computer-settings.git (push)
shlomif[dotfiles]:$trunk$ la
total 68K
drwxr-xr-x 8 shlomif shlomif 4.0K Oct 18 08:15 .git
-rw-r--r-- 1 shlomif shlomif 4.8K Apr 21 08:23 .gitignore
-rw-r--r-- 1 shlomif shlomif 4.7K Jul 27 2020 .gitignore~
-rw-r--r-- 1 shlomif shlomif 2.3K Oct 6 2018 .hgignore
-rw-r--r-- 1 shlomif shlomif 9 Oct 6 2018 LICENSE
-rw-r--r-- 1 shlomif shlomif 17 Oct 6 2018 .perltidyrc
-rw-r--r-- 1 shlomif shlomif 866 Jul 21 19:28 README.asciidoc
-rw-r--r-- 1 shlomif shlomif 866 Jul 21 19:27 README.asciidoc~
-rw-r--r-- 1 shlomif shlomif 12K Oct 18 08:14 .README.asciidoc.swp
drwxr-xr-x 41 shlomif shlomif 4.0K Oct 2 2020 shlomif-settings
drwxr-xr-x 4 shlomif shlomif 4.0K Sep 8 2020 .tidyall.d
-rw-r--r-- 1 shlomif shlomif 523 Sep 29 2020 .tidyallrc
-rw-r--r-- 1 shlomif shlomif 2.2K Jul 17 2020 .travis.yml
shlomif[dotfiles]:$trunk$
```
After I edited README.asciidoc again, I got this dialog:
https://www.shlomifish.org/Files/files/images/gvim-recover-Screenshot_2021-10-18_08-16-50.png
. Pressing "Recover" restored my unsaved changes.
So "works for me" with my vim config (
https://github.com/shlomif/shlomif-computer-settings/tree/master/shlomif-settings/vim-conf
).
> Thanks,
>
> SteveT
>
> Steve Litt
> Spring 2021 featured book: Troubleshooting Techniques of the Successful
> Technologist http://www.troubleshooters.com/techniques
>
--
Shlomi Fish https://www.shlomifish.org/
https://youtu.be/GoEn1YfYTBM - Tiffany Alvord - "Fall Together"
If Chuck Norris is disappointed by you not following his advice, he'll survive.
On the other hand, you will not.
— https://www.shlomifish.org/humour/bits/facts/Chuck-Norris/
Please reply to list if it's a mailing list post - https://shlom.in/reply .
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211018082916.66e2d76d%40shlomifish.org.
Vim backup files
Hi all,
I've used Vim since the 20th century, and of course things keep getting
better, which means change. As I remember, back in the day, the Vim
backup files that began with a dot and ended with .swp were text files
containing what was in the window, and were automatically updated every
X number of seconds. This appears to no longer be the case.
.test.pl.swp appeared to be a binary file, so I couldn't just diff it
with the original.
In the past, after a crash, when I ran Vim on the file again, it gave
me a dialog box in which to choose to recover, ignore, quit, whatever.
This didn't happen in today's crash.
I tried using :rec in the main file, it said there was no recovery
file, and maybe changed the recovery file to .test.pl.swp.swp. I tried
a few other things, but I was always just one step behind and
eventually lost the swap files completely. Only one of them was
important, and I have a paper copy, so I should be OK.
After a crash, I'd like a way to know whether a swap file exists, and
whether it indicates any differences from what's in my buffer. Is there
a program that can do this for me, now that the dialog box doesn't
happen anymore?
Thanks,
SteveT
Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist
http://www.troubleshooters.com/techniques
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211017181834.3289c725%40mydesk.domain.cxm.
I've used Vim since the 20th century, and of course things keep getting
better, which means change. As I remember, back in the day, the Vim
backup files that began with a dot and ended with .swp were text files
containing what was in the window, and were automatically updated every
X number of seconds. This appears to no longer be the case.
.test.pl.swp appeared to be a binary file, so I couldn't just diff it
with the original.
In the past, after a crash, when I ran Vim on the file again, it gave
me a dialog box in which to choose to recover, ignore, quit, whatever.
This didn't happen in today's crash.
I tried using :rec in the main file, it said there was no recovery
file, and maybe changed the recovery file to .test.pl.swp.swp. I tried
a few other things, but I was always just one step behind and
eventually lost the swap files completely. Only one of them was
important, and I have a paper copy, so I should be OK.
After a crash, I'd like a way to know whether a swap file exists, and
whether it indicates any differences from what's in my buffer. Is there
a program that can do this for me, now that the dialog box doesn't
happen anymore?
Thanks,
SteveT
Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist
http://www.troubleshooters.com/techniques
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211017181834.3289c725%40mydesk.domain.cxm.
Re: upgrading past 8.2.2918 loses access to /dev/tty from athena gvim
> On Thu, Oct 14, 2021 at 04:28:14PM +0100, Bram Moolenaar <Bram@moolenaar.net> wrote:
>
> > > > Since more than one person complained about this, and it still doesn't
> > > > fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
> > > > different solution.
> > >
> > > Thanks. Maybe blocking SIGHUP would fix the original problem with
> > > background processes?
> >
> > Hopefully someone can find out what the actualy problem is and find a
> > solution that works and does not cause new problems.
>
> Hmm, SIGHUP is already ignored in the gui.
Thanks for taking time to look into this.
> My guess is that the original problem is that most
> shells inherit gvim's ignoring of SIGHUP, but zsh
> doesn't. So the command being executed doesn't ignore
> SIGHUP either, and it dies when zsh terminates, rather
> than when it's finished. But that is just a guess.
>
> It's strange. The original bug report was for Arch Linux.
> But it works fine on Debian Linux. It doesn't work on macOS.
Thus we don't fully understand the cause of the problem. Perhaps it's a
specific zsh version or how it was configured?
> I tried the following things on macOS:
>
> - Append "; wait" to the command
> - Prepend "setopt NO_HUP; " to the command
> - Prepend "trap '' HUP; " to the command
> - Prepend "setopt NO_HUP; trap '' HUP; " to the command
> - set shellcmdflag=-o\ nohup\ -c
>
> The only thing that "fixed" it was appending "; wait"
> to the command. Below is a patch that does that,
> only when the gui is running and the shell is zsh and
> there's an ampersand in the command (so "&&" will be a
> false positive).
>
> diff --git a/src/misc2.c b/src/misc2.c
> index 8e01434ea..20c56edde 100644
> --- a/src/misc2.c
> +++ b/src/misc2.c
> @@ -1766,6 +1766,29 @@ call_shell(char_u *cmd, int opt)
> proftime_T wait_time;
>
>
> > > > Since more than one person complained about this, and it still doesn't
> > > > fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
> > > > different solution.
> > >
> > > Thanks. Maybe blocking SIGHUP would fix the original problem with
> > > background processes?
> >
> > Hopefully someone can find out what the actualy problem is and find a
> > solution that works and does not cause new problems.
>
> Hmm, SIGHUP is already ignored in the gui.
Thanks for taking time to look into this.
> My guess is that the original problem is that most
> shells inherit gvim's ignoring of SIGHUP, but zsh
> doesn't. So the command being executed doesn't ignore
> SIGHUP either, and it dies when zsh terminates, rather
> than when it's finished. But that is just a guess.
>
> It's strange. The original bug report was for Arch Linux.
> But it works fine on Debian Linux. It doesn't work on macOS.
Thus we don't fully understand the cause of the problem. Perhaps it's a
specific zsh version or how it was configured?
> I tried the following things on macOS:
>
> - Append "; wait" to the command
> - Prepend "setopt NO_HUP; " to the command
> - Prepend "trap '' HUP; " to the command
> - Prepend "setopt NO_HUP; trap '' HUP; " to the command
> - set shellcmdflag=-o\ nohup\ -c
>
> The only thing that "fixed" it was appending "; wait"
> to the command. Below is a patch that does that,
> only when the gui is running and the shell is zsh and
> there's an ampersand in the command (so "&&" will be a
> false positive).
>
> diff --git a/src/misc2.c b/src/misc2.c
> index 8e01434ea..20c56edde 100644
> --- a/src/misc2.c
> +++ b/src/misc2.c
> @@ -1766,6 +1766,29 @@ call_shell(char_u *cmd, int opt)
> proftime_T wait_time;
>
Saturday, October 16, 2021
Re: upgrading past 8.2.2918 loses access to /dev/tty from athena gvim
On Thu, Oct 14, 2021 at 04:28:14PM +0100, Bram Moolenaar <Bram@moolenaar.net> wrote:
> > > Since more than one person complained about this, and it still doesn't
> > > fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
> > > different solution.
> >
> > Thanks. Maybe blocking SIGHUP would fix the original problem with
> > background processes?
>
> Hopefully someone can find out what the actualy problem is and find a
> solution that works and does not cause new problems.
Hmm, SIGHUP is already ignored in the gui.
My guess is that the original problem is that most
shells inherit gvim's ignoring of SIGHUP, but zsh
doesn't. So the command being executed doesn't ignore
SIGHUP either, and it dies when zsh terminates, rather
than when it's finished. But that is just a guess.
It's strange. The original bug report was for Arch Linux.
But it works fine on Debian Linux. It doesn't work on macOS.
I tried the following things on macOS:
- Append "; wait" to the command
- Prepend "setopt NO_HUP; " to the command
- Prepend "trap '' HUP; " to the command
- Prepend "setopt NO_HUP; trap '' HUP; " to the command
- set shellcmdflag=-o\ nohup\ -c
The only thing that "fixed" it was appending "; wait"
to the command. Below is a patch that does that,
only when the gui is running and the shell is zsh and
there's an ampersand in the command (so "&&" will be a
false positive).
diff --git a/src/misc2.c b/src/misc2.c
index 8e01434ea..20c56edde 100644
--- a/src/misc2.c
+++ b/src/misc2.c
@@ -1766,6 +1766,29 @@ call_shell(char_u *cmd, int opt)
proftime_T wait_time;
> > > Since more than one person complained about this, and it still doesn't
> > > fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
> > > different solution.
> >
> > Thanks. Maybe blocking SIGHUP would fix the original problem with
> > background processes?
>
> Hopefully someone can find out what the actualy problem is and find a
> solution that works and does not cause new problems.
Hmm, SIGHUP is already ignored in the gui.
My guess is that the original problem is that most
shells inherit gvim's ignoring of SIGHUP, but zsh
doesn't. So the command being executed doesn't ignore
SIGHUP either, and it dies when zsh terminates, rather
than when it's finished. But that is just a guess.
It's strange. The original bug report was for Arch Linux.
But it works fine on Debian Linux. It doesn't work on macOS.
I tried the following things on macOS:
- Append "; wait" to the command
- Prepend "setopt NO_HUP; " to the command
- Prepend "trap '' HUP; " to the command
- Prepend "setopt NO_HUP; trap '' HUP; " to the command
- set shellcmdflag=-o\ nohup\ -c
The only thing that "fixed" it was appending "; wait"
to the command. Below is a patch that does that,
only when the gui is running and the shell is zsh and
there's an ampersand in the command (so "&&" will be a
false positive).
diff --git a/src/misc2.c b/src/misc2.c
index 8e01434ea..20c56edde 100644
--- a/src/misc2.c
+++ b/src/misc2.c
@@ -1766,6 +1766,29 @@ call_shell(char_u *cmd, int opt)
proftime_T wait_time;
Thursday, October 14, 2021
Re: Matching a non-match
On 2021-10-14 17:34, A. Wik wrote:
> Yes, I think so. Is it because \@! is zero-width that it must be
> paired with something (eg. ".") that does have width?
>
> And it matches an empty line because of the \%( ... \)*?
Exactly, on both fronts. 👍
-tim
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211014124046.01d79d09%40bigbox.attlocal.net.
> Yes, I think so. Is it because \@! is zero-width that it must be
> paired with something (eg. ".") that does have width?
>
> And it matches an empty line because of the \%( ... \)*?
Exactly, on both fronts. 👍
-tim
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211014124046.01d79d09%40bigbox.attlocal.net.
Re: Matching a non-match
Hi all,
On Wed, 13 Oct 2021 at 14:36, Tim Chase <vim@tim.thechases.com> wrote:
>
> On 2021-10-11 23:45, A. Wik wrote:
> > > or if you want to match the entire line, you can use:
> > >
> > > /^\%(\%(exim.input\)\@!.\)*$/
> > >
> > > That breaks down to
> > >
> > > ^ from the start of the line
> > > \%(…\)* zero or more of these things
> > > \%(exim.match\)\@! at each of these places, this can't match
> > > . accept a character here
> > > $ all the way to the end of the line
> > > (no partial line matches, or it would find
> > > ".spool/exim/inpu" (because "exim.input" doesn't yet
> > > match)
> >
> > Can you clarify the function of the dot? It appears that without
> > it, it finds only empty lines. With it, it finds any line not
> > matching "exim.input", including empty lines.
>
> Sorry for the late reply. The "." is what lets the regex move
> forward, roughly stating ".*" but at each of those "." locations,
> before we accept that location, we assert that "exim.match" can't
> match at that particular character.
>
> this line contains exim match here
>
> when the regex engine gets to the "e" in "exim match", the \@!
> assertion fails, so the regex doesn't match that line, but on a line
> like
>
> hello
>
> it starts at the beginning. /exim.match/ doesn't match there so the
> "." accepts the "h", moving to the next char. /exim.match/ doesn't
> match there either, so the "." accepts the "e". Repeat until it gets
> to the end, having asserted that each ".", no /exim.match/ exists.
>
> Hope that helps make a bit of sense of it?
Yes, I think so. Is it because \@! is zero-width that it must be
paired with something (eg. ".") that does have width?
And it matches an empty line because of the \%( ... \)*?
-aw
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CALPW7mTVWaRd026iULVbQXbnPbhBKOtymcz_NiHP4NPPbk_ptA%40mail.gmail.com.
On Wed, 13 Oct 2021 at 14:36, Tim Chase <vim@tim.thechases.com> wrote:
>
> On 2021-10-11 23:45, A. Wik wrote:
> > > or if you want to match the entire line, you can use:
> > >
> > > /^\%(\%(exim.input\)\@!.\)*$/
> > >
> > > That breaks down to
> > >
> > > ^ from the start of the line
> > > \%(…\)* zero or more of these things
> > > \%(exim.match\)\@! at each of these places, this can't match
> > > . accept a character here
> > > $ all the way to the end of the line
> > > (no partial line matches, or it would find
> > > ".spool/exim/inpu" (because "exim.input" doesn't yet
> > > match)
> >
> > Can you clarify the function of the dot? It appears that without
> > it, it finds only empty lines. With it, it finds any line not
> > matching "exim.input", including empty lines.
>
> Sorry for the late reply. The "." is what lets the regex move
> forward, roughly stating ".*" but at each of those "." locations,
> before we accept that location, we assert that "exim.match" can't
> match at that particular character.
>
> this line contains exim match here
>
> when the regex engine gets to the "e" in "exim match", the \@!
> assertion fails, so the regex doesn't match that line, but on a line
> like
>
> hello
>
> it starts at the beginning. /exim.match/ doesn't match there so the
> "." accepts the "h", moving to the next char. /exim.match/ doesn't
> match there either, so the "." accepts the "e". Repeat until it gets
> to the end, having asserted that each ".", no /exim.match/ exists.
>
> Hope that helps make a bit of sense of it?
Yes, I think so. Is it because \@! is zero-width that it must be
paired with something (eg. ".") that does have width?
And it matches an empty line because of the \%( ... \)*?
-aw
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CALPW7mTVWaRd026iULVbQXbnPbhBKOtymcz_NiHP4NPPbk_ptA%40mail.gmail.com.
Re: upgrading past 8.2.2918 loses access to /dev/tty from athena gvim
> > Since more than one person complained about this, and it still doesn't
> > fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
> > different solution.
>
> Thanks. Maybe blocking SIGHUP would fix the original problem with
> background processes?
Hopefully someone can find out what the actualy problem is and find a
solution that works and does not cause new problems.
--
hundred-and-one symptoms of being an internet addict:
150. You find yourself counting emoticons to get to sleep.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211014152814.B79ABC80053%40moolenaar.net.
> > fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
> > different solution.
>
> Thanks. Maybe blocking SIGHUP would fix the original problem with
> background processes?
Hopefully someone can find out what the actualy problem is and find a
solution that works and does not cause new problems.
--
hundred-and-one symptoms of being an internet addict:
150. You find yourself counting emoticons to get to sleep.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211014152814.B79ABC80053%40moolenaar.net.
Wednesday, October 13, 2021
Re: upgrading past 8.2.2918 loses access to /dev/tty from athena gvim
On Wed, Oct 13, 2021 at 10:06:17AM +0100, Bram Moolenaar <Bram@moolenaar.net> wrote:
> > macos-10.14.6
> > ./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
> >
> > I just upgraded vim from approximately 8.2.2550 to 8.2.3501
> > and something important has stopped working (from gvim).
> >
> > I have an autocommand group for editing gpg1-encrypted files.
> > It executes gpg1 via a shell and that requires access to /dev/tty.
> >
> > Before the upgrade, it worked in vim and (athena) gvim (i.e.
> > it would ask me for the passphrase). After the upgrade, it no
> > longer works in athena gvim. gpg reports:
> >
> > gpg: cannot open tty `/dev/tty': Device not configured
> >
> > The last version where this works is 8.2.2918.
> > The first version that doesn't work is:
> >
> > 8.2.2919: using ":!command" does not work if it uses posix_spawn()
> >
> > That patch removed this:
> >
> > diff --git a/src/os_unix.c b/src/os_unix.c
> > index 20c61106f..0a4f0e698 100644
> > --- a/src/os_unix.c
> > +++ b/src/os_unix.c
> > @@ -4775,11 +4775,6 @@ mch_call_shell_fork(
> > // push stream discipline modules
> > if (options & SHELL_COOKED)
> > setup_slavepty(pty_slave_fd);
> > -# ifdef TIOCSCTTY
> > - // Try to become controlling tty (probably doesn't work,
> > - // unless run by root)
> > - ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
> > -# endif
> > }
> > # endif
> > set_default_child_environment(FALSE);
> >
> > If I run :!tty, it outputs /dev/ttys007, so I tried
> > replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
> > in the latest version, but that didn't work.
> >
> > Any idea what I need to do to restore access to /dev/tty
> > from the athena gui? Or do I have to downgrade to 8.2.2918
> > and stay there?
>
> Since more than one person complained about this, and it still doesn't
> fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
> different solution.
Thanks. Maybe blocking SIGHUP would fix the original problem with
background processes?
cheers,
raf
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YWehbP3yYzYcdVpB%40raf.org.
> > macos-10.14.6
> > ./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
> >
> > I just upgraded vim from approximately 8.2.2550 to 8.2.3501
> > and something important has stopped working (from gvim).
> >
> > I have an autocommand group for editing gpg1-encrypted files.
> > It executes gpg1 via a shell and that requires access to /dev/tty.
> >
> > Before the upgrade, it worked in vim and (athena) gvim (i.e.
> > it would ask me for the passphrase). After the upgrade, it no
> > longer works in athena gvim. gpg reports:
> >
> > gpg: cannot open tty `/dev/tty': Device not configured
> >
> > The last version where this works is 8.2.2918.
> > The first version that doesn't work is:
> >
> > 8.2.2919: using ":!command" does not work if it uses posix_spawn()
> >
> > That patch removed this:
> >
> > diff --git a/src/os_unix.c b/src/os_unix.c
> > index 20c61106f..0a4f0e698 100644
> > --- a/src/os_unix.c
> > +++ b/src/os_unix.c
> > @@ -4775,11 +4775,6 @@ mch_call_shell_fork(
> > // push stream discipline modules
> > if (options & SHELL_COOKED)
> > setup_slavepty(pty_slave_fd);
> > -# ifdef TIOCSCTTY
> > - // Try to become controlling tty (probably doesn't work,
> > - // unless run by root)
> > - ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
> > -# endif
> > }
> > # endif
> > set_default_child_environment(FALSE);
> >
> > If I run :!tty, it outputs /dev/ttys007, so I tried
> > replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
> > in the latest version, but that didn't work.
> >
> > Any idea what I need to do to restore access to /dev/tty
> > from the athena gui? Or do I have to downgrade to 8.2.2918
> > and stay there?
>
> Since more than one person complained about this, and it still doesn't
> fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
> different solution.
Thanks. Maybe blocking SIGHUP would fix the original problem with
background processes?
cheers,
raf
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YWehbP3yYzYcdVpB%40raf.org.
Re: upgrading past 8.2.2918 loses access to /dev/tty from athena gvim
On Wed, Oct 13, 2021 at 08:57:13AM +0200, Christian Brabandt <cblists@256bit.org> wrote:
>
> On Mi, 13 Okt 2021, raf wrote:
>
> > Hi,
> >
> > macos-10.14.6
> > ./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
> >
> > I just upgraded vim from approximately 8.2.2550 to 8.2.3501
> > and something important has stopped working (from gvim).
> >
> > I have an autocommand group for editing gpg1-encrypted files.
> > It executes gpg1 via a shell and that requires access to /dev/tty.
> >
> > Before the upgrade, it worked in vim and (athena) gvim (i.e.
> > it would ask me for the passphrase). After the upgrade, it no
> > longer works in athena gvim. gpg reports:
> >
> > gpg: cannot open tty `/dev/tty': Device not configured
> >
> > The last version where this works is 8.2.2918.
> > The first version that doesn't work is:
> >
> > 8.2.2919: using ":!command" does not work if it uses posix_spawn()
> >
> > That patch removed this:
> >
> > diff --git a/src/os_unix.c b/src/os_unix.c
> > index 20c61106f..0a4f0e698 100644
> > --- a/src/os_unix.c
> > +++ b/src/os_unix.c
> > @@ -4775,11 +4775,6 @@ mch_call_shell_fork(
> > // push stream discipline modules
> > if (options & SHELL_COOKED)
> > setup_slavepty(pty_slave_fd);
> > -# ifdef TIOCSCTTY
> > - // Try to become controlling tty (probably doesn't work,
> > - // unless run by root)
> > - ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
> > -# endif
> > }
> > # endif
> > set_default_child_environment(FALSE);
> >
> > If I run :!tty, it outputs /dev/ttys007, so I tried
> > replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
> > in the latest version, but that didn't work.
> >
> > Any idea what I need to do to restore access to /dev/tty
> > from the athena gui? Or do I have to downgrade to 8.2.2918
> > and stay there?
>
> This may depend on the shell you use. So what shell are you using? See
> also https://github.com/vim/vim/issues/8951
>
> Best,
> Christian
Thanks. Yes, I'm using zsh as well. If I prefix the vim
command with "SHELL=/bin/sh", the latest version works.
cheers,
raf
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YWegvXle7CVF42qy%40raf.org.
>
> On Mi, 13 Okt 2021, raf wrote:
>
> > Hi,
> >
> > macos-10.14.6
> > ./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
> >
> > I just upgraded vim from approximately 8.2.2550 to 8.2.3501
> > and something important has stopped working (from gvim).
> >
> > I have an autocommand group for editing gpg1-encrypted files.
> > It executes gpg1 via a shell and that requires access to /dev/tty.
> >
> > Before the upgrade, it worked in vim and (athena) gvim (i.e.
> > it would ask me for the passphrase). After the upgrade, it no
> > longer works in athena gvim. gpg reports:
> >
> > gpg: cannot open tty `/dev/tty': Device not configured
> >
> > The last version where this works is 8.2.2918.
> > The first version that doesn't work is:
> >
> > 8.2.2919: using ":!command" does not work if it uses posix_spawn()
> >
> > That patch removed this:
> >
> > diff --git a/src/os_unix.c b/src/os_unix.c
> > index 20c61106f..0a4f0e698 100644
> > --- a/src/os_unix.c
> > +++ b/src/os_unix.c
> > @@ -4775,11 +4775,6 @@ mch_call_shell_fork(
> > // push stream discipline modules
> > if (options & SHELL_COOKED)
> > setup_slavepty(pty_slave_fd);
> > -# ifdef TIOCSCTTY
> > - // Try to become controlling tty (probably doesn't work,
> > - // unless run by root)
> > - ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
> > -# endif
> > }
> > # endif
> > set_default_child_environment(FALSE);
> >
> > If I run :!tty, it outputs /dev/ttys007, so I tried
> > replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
> > in the latest version, but that didn't work.
> >
> > Any idea what I need to do to restore access to /dev/tty
> > from the athena gui? Or do I have to downgrade to 8.2.2918
> > and stay there?
>
> This may depend on the shell you use. So what shell are you using? See
> also https://github.com/vim/vim/issues/8951
>
> Best,
> Christian
Thanks. Yes, I'm using zsh as well. If I prefix the vim
command with "SHELL=/bin/sh", the latest version works.
cheers,
raf
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YWegvXle7CVF42qy%40raf.org.
Re: Matching a non-match
On 2021-10-11 23:45, A. Wik wrote:
> > or if you want to match the entire line, you can use:
> >
> > /^\%(\%(exim.input\)\@!.\)*$/
> >
> > That breaks down to
> >
> > ^ from the start of the line
> > \%(…\)* zero or more of these things
> > \%(exim.match\)\@! at each of these places, this can't match
> > . accept a character here
> > $ all the way to the end of the line
> > (no partial line matches, or it would find
> > ".spool/exim/inpu" (because "exim.input" doesn't yet
> > match)
>
> Can you clarify the function of the dot? It appears that without
> it, it finds only empty lines. With it, it finds any line not
> matching "exim.input", including empty lines.
Sorry for the late reply. The "." is what lets the regex move
forward, roughly stating ".*" but at each of those "." locations,
before we accept that location, we assert that "exim.match" can't
match at that particular character.
this line contains exim match here
when the regex engine gets to the "e" in "exim match", the \@!
assertion fails, so the regex doesn't match that line, but on a line
like
hello
it starts at the beginning. /exim.match/ doesn't match there so the
"." accepts the "h", moving to the next char. /exim.match/ doesn't
match there either, so the "." accepts the "e". Repeat until it gets
to the end, having asserted that each ".", no /exim.match/ exists.
Hope that helps make a bit of sense of it?
-tim
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211013093623.413af4c8%40bigbox.attlocal.net.
> > or if you want to match the entire line, you can use:
> >
> > /^\%(\%(exim.input\)\@!.\)*$/
> >
> > That breaks down to
> >
> > ^ from the start of the line
> > \%(…\)* zero or more of these things
> > \%(exim.match\)\@! at each of these places, this can't match
> > . accept a character here
> > $ all the way to the end of the line
> > (no partial line matches, or it would find
> > ".spool/exim/inpu" (because "exim.input" doesn't yet
> > match)
>
> Can you clarify the function of the dot? It appears that without
> it, it finds only empty lines. With it, it finds any line not
> matching "exim.input", including empty lines.
Sorry for the late reply. The "." is what lets the regex move
forward, roughly stating ".*" but at each of those "." locations,
before we accept that location, we assert that "exim.match" can't
match at that particular character.
this line contains exim match here
when the regex engine gets to the "e" in "exim match", the \@!
assertion fails, so the regex doesn't match that line, but on a line
like
hello
it starts at the beginning. /exim.match/ doesn't match there so the
"." accepts the "h", moving to the next char. /exim.match/ doesn't
match there either, so the "." accepts the "e". Repeat until it gets
to the end, having asserted that each ".", no /exim.match/ exists.
Hope that helps make a bit of sense of it?
-tim
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211013093623.413af4c8%40bigbox.attlocal.net.
Re: upgrading past 8.2.2918 loses access to /dev/tty from athena gvim
> macos-10.14.6
> ./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
>
> I just upgraded vim from approximately 8.2.2550 to 8.2.3501
> and something important has stopped working (from gvim).
>
> I have an autocommand group for editing gpg1-encrypted files.
> It executes gpg1 via a shell and that requires access to /dev/tty.
>
> Before the upgrade, it worked in vim and (athena) gvim (i.e.
> it would ask me for the passphrase). After the upgrade, it no
> longer works in athena gvim. gpg reports:
>
> gpg: cannot open tty `/dev/tty': Device not configured
>
> The last version where this works is 8.2.2918.
> The first version that doesn't work is:
>
> 8.2.2919: using ":!command" does not work if it uses posix_spawn()
>
> That patch removed this:
>
> diff --git a/src/os_unix.c b/src/os_unix.c
> index 20c61106f..0a4f0e698 100644
> --- a/src/os_unix.c
> +++ b/src/os_unix.c
> @@ -4775,11 +4775,6 @@ mch_call_shell_fork(
> // push stream discipline modules
> if (options & SHELL_COOKED)
> setup_slavepty(pty_slave_fd);
> -# ifdef TIOCSCTTY
> - // Try to become controlling tty (probably doesn't work,
> - // unless run by root)
> - ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
> -# endif
> }
> # endif
> set_default_child_environment(FALSE);
>
> If I run :!tty, it outputs /dev/ttys007, so I tried
> replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
> in the latest version, but that didn't work.
>
> Any idea what I need to do to restore access to /dev/tty
> from the athena gui? Or do I have to downgrade to 8.2.2918
> and stay there?
Since more than one person complained about this, and it still doesn't
fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
different solution.
--
hundred-and-one symptoms of being an internet addict:
140. You'd rather catch a score on the web than watch the game as
it is being played on tv.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211013090617.86F74C80053%40moolenaar.net.
> ./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
>
> I just upgraded vim from approximately 8.2.2550 to 8.2.3501
> and something important has stopped working (from gvim).
>
> I have an autocommand group for editing gpg1-encrypted files.
> It executes gpg1 via a shell and that requires access to /dev/tty.
>
> Before the upgrade, it worked in vim and (athena) gvim (i.e.
> it would ask me for the passphrase). After the upgrade, it no
> longer works in athena gvim. gpg reports:
>
> gpg: cannot open tty `/dev/tty': Device not configured
>
> The last version where this works is 8.2.2918.
> The first version that doesn't work is:
>
> 8.2.2919: using ":!command" does not work if it uses posix_spawn()
>
> That patch removed this:
>
> diff --git a/src/os_unix.c b/src/os_unix.c
> index 20c61106f..0a4f0e698 100644
> --- a/src/os_unix.c
> +++ b/src/os_unix.c
> @@ -4775,11 +4775,6 @@ mch_call_shell_fork(
> // push stream discipline modules
> if (options & SHELL_COOKED)
> setup_slavepty(pty_slave_fd);
> -# ifdef TIOCSCTTY
> - // Try to become controlling tty (probably doesn't work,
> - // unless run by root)
> - ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
> -# endif
> }
> # endif
> set_default_child_environment(FALSE);
>
> If I run :!tty, it outputs /dev/ttys007, so I tried
> replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
> in the latest version, but that didn't work.
>
> Any idea what I need to do to restore access to /dev/tty
> from the athena gui? Or do I have to downgrade to 8.2.2918
> and stay there?
Since more than one person complained about this, and it still doesn't
fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a
different solution.
--
hundred-and-one symptoms of being an internet addict:
140. You'd rather catch a score on the web than watch the game as
it is being played on tv.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211013090617.86F74C80053%40moolenaar.net.
Re: upgrading past 8.2.2918 loses access to /dev/tty from athena gvim
On Wed, Oct 13, 2021 at 8:54 AM raf <raf@raf.org> wrote:
>
> Hi,
>
> macos-10.14.6
> ./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
>
> I just upgraded vim from approximately 8.2.2550 to 8.2.3501
> and something important has stopped working (from gvim).
>
> I have an autocommand group for editing gpg1-encrypted files.
> It executes gpg1 via a shell and that requires access to /dev/tty.
>
> Before the upgrade, it worked in vim and (athena) gvim (i.e.
> it would ask me for the passphrase). After the upgrade, it no
> longer works in athena gvim. gpg reports:
>
> gpg: cannot open tty `/dev/tty': Device not configured
>
> The last version where this works is 8.2.2918.
> The first version that doesn't work is:
>
> 8.2.2919: using ":!command" does not work if it uses posix_spawn()
>
> That patch removed this:
>
> diff --git a/src/os_unix.c b/src/os_unix.c
> index 20c61106f..0a4f0e698 100644
> --- a/src/os_unix.c
> +++ b/src/os_unix.c
> @@ -4775,11 +4775,6 @@ mch_call_shell_fork(
> // push stream discipline modules
> if (options & SHELL_COOKED)
> setup_slavepty(pty_slave_fd);
> -# ifdef TIOCSCTTY
> - // Try to become controlling tty (probably doesn't work,
> - // unless run by root)
> - ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
> -# endif
> }
> # endif
> set_default_child_environment(FALSE);
>
> If I run :!tty, it outputs /dev/ttys007, so I tried
> replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
> in the latest version, but that didn't work.
>
> Any idea what I need to do to restore access to /dev/tty
> from the athena gui? Or do I have to downgrade to 8.2.2918
> and stay there?
>
> cheers,
> raf
Since you wrote:
> The last version where this works is 8.2.2918.
> The first version that doesn't work is:
Then the regression is introduced by:
commit 6a43b37b760347b9a1bedf12e41b458000922969 (tag: v8.2.2919)
Author: Bram Moolenaar <Bram@vim.org>
Date: Tue Jun 1 20:48:40 2021 +0200
patch 8.2.2919: using ":!command" does not work if it uses posix_spawn()
Problem: Using ":!command" does not work if the command uses
posix_spawn().
Solution: Do not call ioctl() with TIOCSCTTY. (Felipe Contreras)
Perhaps Felipe Contreras (added in copy) can check your patch.
Regards
Dominique
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAON-T_gE8PPR-LdVBgLs4KtYrZviemJM1rdd0xHdSX0Bn6v_Jw%40mail.gmail.com.
>
> Hi,
>
> macos-10.14.6
> ./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
>
> I just upgraded vim from approximately 8.2.2550 to 8.2.3501
> and something important has stopped working (from gvim).
>
> I have an autocommand group for editing gpg1-encrypted files.
> It executes gpg1 via a shell and that requires access to /dev/tty.
>
> Before the upgrade, it worked in vim and (athena) gvim (i.e.
> it would ask me for the passphrase). After the upgrade, it no
> longer works in athena gvim. gpg reports:
>
> gpg: cannot open tty `/dev/tty': Device not configured
>
> The last version where this works is 8.2.2918.
> The first version that doesn't work is:
>
> 8.2.2919: using ":!command" does not work if it uses posix_spawn()
>
> That patch removed this:
>
> diff --git a/src/os_unix.c b/src/os_unix.c
> index 20c61106f..0a4f0e698 100644
> --- a/src/os_unix.c
> +++ b/src/os_unix.c
> @@ -4775,11 +4775,6 @@ mch_call_shell_fork(
> // push stream discipline modules
> if (options & SHELL_COOKED)
> setup_slavepty(pty_slave_fd);
> -# ifdef TIOCSCTTY
> - // Try to become controlling tty (probably doesn't work,
> - // unless run by root)
> - ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
> -# endif
> }
> # endif
> set_default_child_environment(FALSE);
>
> If I run :!tty, it outputs /dev/ttys007, so I tried
> replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
> in the latest version, but that didn't work.
>
> Any idea what I need to do to restore access to /dev/tty
> from the athena gui? Or do I have to downgrade to 8.2.2918
> and stay there?
>
> cheers,
> raf
Since you wrote:
> The last version where this works is 8.2.2918.
> The first version that doesn't work is:
Then the regression is introduced by:
commit 6a43b37b760347b9a1bedf12e41b458000922969 (tag: v8.2.2919)
Author: Bram Moolenaar <Bram@vim.org>
Date: Tue Jun 1 20:48:40 2021 +0200
patch 8.2.2919: using ":!command" does not work if it uses posix_spawn()
Problem: Using ":!command" does not work if the command uses
posix_spawn().
Solution: Do not call ioctl() with TIOCSCTTY. (Felipe Contreras)
Perhaps Felipe Contreras (added in copy) can check your patch.
Regards
Dominique
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAON-T_gE8PPR-LdVBgLs4KtYrZviemJM1rdd0xHdSX0Bn6v_Jw%40mail.gmail.com.
Tuesday, October 12, 2021
Re: upgrading past 8.2.2918 loses access to /dev/tty from athena gvim
On Mi, 13 Okt 2021, raf wrote:
> Hi,
>
> macos-10.14.6
> ./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
>
> I just upgraded vim from approximately 8.2.2550 to 8.2.3501
> and something important has stopped working (from gvim).
>
> I have an autocommand group for editing gpg1-encrypted files.
> It executes gpg1 via a shell and that requires access to /dev/tty.
>
> Before the upgrade, it worked in vim and (athena) gvim (i.e.
> it would ask me for the passphrase). After the upgrade, it no
> longer works in athena gvim. gpg reports:
>
> gpg: cannot open tty `/dev/tty': Device not configured
>
> The last version where this works is 8.2.2918.
> The first version that doesn't work is:
>
> 8.2.2919: using ":!command" does not work if it uses posix_spawn()
>
> That patch removed this:
>
> diff --git a/src/os_unix.c b/src/os_unix.c
> index 20c61106f..0a4f0e698 100644
> --- a/src/os_unix.c
> +++ b/src/os_unix.c
> @@ -4775,11 +4775,6 @@ mch_call_shell_fork(
> // push stream discipline modules
> if (options & SHELL_COOKED)
> setup_slavepty(pty_slave_fd);
> -# ifdef TIOCSCTTY
> - // Try to become controlling tty (probably doesn't work,
> - // unless run by root)
> - ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
> -# endif
> }
> # endif
> set_default_child_environment(FALSE);
>
> If I run :!tty, it outputs /dev/ttys007, so I tried
> replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
> in the latest version, but that didn't work.
>
> Any idea what I need to do to restore access to /dev/tty
> from the athena gui? Or do I have to downgrade to 8.2.2918
> and stay there?
This may depend on the shell you use. So what shell are you using? See
also https://github.com/vim/vim/issues/8951
Best,
Christian
--
Was mich ein bischen tröstet ist, daß auch Politiker von BSE betroffen sind.
-- Heinz Rudolf Kunze
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211013065713.GE3083214%40256bit.org.
> Hi,
>
> macos-10.14.6
> ./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
>
> I just upgraded vim from approximately 8.2.2550 to 8.2.3501
> and something important has stopped working (from gvim).
>
> I have an autocommand group for editing gpg1-encrypted files.
> It executes gpg1 via a shell and that requires access to /dev/tty.
>
> Before the upgrade, it worked in vim and (athena) gvim (i.e.
> it would ask me for the passphrase). After the upgrade, it no
> longer works in athena gvim. gpg reports:
>
> gpg: cannot open tty `/dev/tty': Device not configured
>
> The last version where this works is 8.2.2918.
> The first version that doesn't work is:
>
> 8.2.2919: using ":!command" does not work if it uses posix_spawn()
>
> That patch removed this:
>
> diff --git a/src/os_unix.c b/src/os_unix.c
> index 20c61106f..0a4f0e698 100644
> --- a/src/os_unix.c
> +++ b/src/os_unix.c
> @@ -4775,11 +4775,6 @@ mch_call_shell_fork(
> // push stream discipline modules
> if (options & SHELL_COOKED)
> setup_slavepty(pty_slave_fd);
> -# ifdef TIOCSCTTY
> - // Try to become controlling tty (probably doesn't work,
> - // unless run by root)
> - ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
> -# endif
> }
> # endif
> set_default_child_environment(FALSE);
>
> If I run :!tty, it outputs /dev/ttys007, so I tried
> replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
> in the latest version, but that didn't work.
>
> Any idea what I need to do to restore access to /dev/tty
> from the athena gui? Or do I have to downgrade to 8.2.2918
> and stay there?
This may depend on the shell you use. So what shell are you using? See
also https://github.com/vim/vim/issues/8951
Best,
Christian
--
Was mich ein bischen tröstet ist, daß auch Politiker von BSE betroffen sind.
-- Heinz Rudolf Kunze
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211013065713.GE3083214%40256bit.org.
upgrading past 8.2.2918 loses access to /dev/tty from athena gvim
Hi,
macos-10.14.6
./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
I just upgraded vim from approximately 8.2.2550 to 8.2.3501
and something important has stopped working (from gvim).
I have an autocommand group for editing gpg1-encrypted files.
It executes gpg1 via a shell and that requires access to /dev/tty.
Before the upgrade, it worked in vim and (athena) gvim (i.e.
it would ask me for the passphrase). After the upgrade, it no
longer works in athena gvim. gpg reports:
gpg: cannot open tty `/dev/tty': Device not configured
The last version where this works is 8.2.2918.
The first version that doesn't work is:
8.2.2919: using ":!command" does not work if it uses posix_spawn()
That patch removed this:
diff --git a/src/os_unix.c b/src/os_unix.c
index 20c61106f..0a4f0e698 100644
--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -4775,11 +4775,6 @@ mch_call_shell_fork(
// push stream discipline modules
if (options & SHELL_COOKED)
setup_slavepty(pty_slave_fd);
-# ifdef TIOCSCTTY
- // Try to become controlling tty (probably doesn't work,
- // unless run by root)
- ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
-# endif
}
# endif
set_default_child_environment(FALSE);
If I run :!tty, it outputs /dev/ttys007, so I tried
replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
in the latest version, but that didn't work.
Any idea what I need to do to restore access to /dev/tty
from the athena gui? Or do I have to downgrade to 8.2.2918
and stay there?
cheers,
raf
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YWaCiRdgEJg3TGOG%40raf.org.
macos-10.14.6
./configure --disable-darwin --with-x --enable-gui=athena --with-features=huge
I just upgraded vim from approximately 8.2.2550 to 8.2.3501
and something important has stopped working (from gvim).
I have an autocommand group for editing gpg1-encrypted files.
It executes gpg1 via a shell and that requires access to /dev/tty.
Before the upgrade, it worked in vim and (athena) gvim (i.e.
it would ask me for the passphrase). After the upgrade, it no
longer works in athena gvim. gpg reports:
gpg: cannot open tty `/dev/tty': Device not configured
The last version where this works is 8.2.2918.
The first version that doesn't work is:
8.2.2919: using ":!command" does not work if it uses posix_spawn()
That patch removed this:
diff --git a/src/os_unix.c b/src/os_unix.c
index 20c61106f..0a4f0e698 100644
--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -4775,11 +4775,6 @@ mch_call_shell_fork(
// push stream discipline modules
if (options & SHELL_COOKED)
setup_slavepty(pty_slave_fd);
-# ifdef TIOCSCTTY
- // Try to become controlling tty (probably doesn't work,
- // unless run by root)
- ioctl(pty_slave_fd, TIOCSCTTY, (char *)NULL);
-# endif
}
# endif
set_default_child_environment(FALSE);
If I run :!tty, it outputs /dev/ttys007, so I tried
replacing "!gpg1" in the commands with "!GPG_TTY=`tty` gpg1"
in the latest version, but that didn't work.
Any idea what I need to do to restore access to /dev/tty
from the athena gui? Or do I have to downgrade to 8.2.2918
and stay there?
cheers,
raf
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YWaCiRdgEJg3TGOG%40raf.org.
Monday, October 11, 2021
Re: Matching a non-match
Thanks to all who replied to my thread!
On Sun, 20 Dec 2020 at 17:30, Tim Chase <vim@tim.thechases.com> wrote:
>
> On 2020-12-20 11:09, A. Wik wrote:
> > Browsing a directory listing, sometimes I hit lines like these:
> > ./spool/exim/input/1FM8sl-00004n-Ix-H
> > ./spool/exim/input/1FM8sn-00004u-OF-D
> > ./spool/exim/input/1E9dsQ-00004f-MO-D
> > [... thousands of similar lines ...]
> >
> > How can I use "/" to find the next line not matching the above
> > pattern? I've tried the following (and several variations):
> > /\(.*exim.input\)\@<!.*
>
> you can use which only finds the start of the line:
>
> /^\%(.*exim.input\)\@!
>
> or if you want to match the entire line, you can use:
>
> /^\%(\%(exim.input\)\@!.\)*$/
>
> That breaks down to
>
> ^ from the start of the line
> \%(…\)* zero or more of these things
> \%(exim.match\)\@! at each of these places, this can't match
> . accept a character here
> $ all the way to the end of the line
> (no partial line matches, or it would find
> ".spool/exim/inpu" (because "exim.input" doesn't yet
> match)
Can you clarify the function of the dot? It appears that without it,
it finds only empty lines. With it, it finds any line not matching
"exim.input", including empty lines.
-aw
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CALPW7mQjfOSkRpMzOWB0Na2SO5E33E5XAqQ2zwGOQn3e%2BMYzCQ%40mail.gmail.com.
On Sun, 20 Dec 2020 at 17:30, Tim Chase <vim@tim.thechases.com> wrote:
>
> On 2020-12-20 11:09, A. Wik wrote:
> > Browsing a directory listing, sometimes I hit lines like these:
> > ./spool/exim/input/1FM8sl-00004n-Ix-H
> > ./spool/exim/input/1FM8sn-00004u-OF-D
> > ./spool/exim/input/1E9dsQ-00004f-MO-D
> > [... thousands of similar lines ...]
> >
> > How can I use "/" to find the next line not matching the above
> > pattern? I've tried the following (and several variations):
> > /\(.*exim.input\)\@<!.*
>
> you can use which only finds the start of the line:
>
> /^\%(.*exim.input\)\@!
>
> or if you want to match the entire line, you can use:
>
> /^\%(\%(exim.input\)\@!.\)*$/
>
> That breaks down to
>
> ^ from the start of the line
> \%(…\)* zero or more of these things
> \%(exim.match\)\@! at each of these places, this can't match
> . accept a character here
> $ all the way to the end of the line
> (no partial line matches, or it would find
> ".spool/exim/inpu" (because "exim.input" doesn't yet
> match)
Can you clarify the function of the dot? It appears that without it,
it finds only empty lines. With it, it finds any line not matching
"exim.input", including empty lines.
-aw
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CALPW7mQjfOSkRpMzOWB0Na2SO5E33E5XAqQ2zwGOQn3e%2BMYzCQ%40mail.gmail.com.
Sunday, October 10, 2021
Re: Sort lines, then tag, then unsort
Julius Hamilton said on Tue, 14 Sep 2021 13:57:34 +0200
>I would like to sort lines in a text document and then tag them, and
>then revert the file to its original order.
>
>First of all, is there a way to tag a line, so that lines with a given
>tag can be quickly referred to, but the tag is not in the actual text?
>
>Secondly, I noticed with my sort command ":sort \^[A-Z].*[^\.]$\ r"
>(sort all lines beginning with a capital letter and not ending in a
>period) it sends the matches in alphabetical order to the bottom of
>the file. Is there a way to specify a second-order sort by which all
>the matches are sub-sorted, rather than the default alphabetical? And,
>is there a way to send them to the top of the document rather than the
>bottom?
I think you're using the wrong tool. Also, you haven't said why you
need Vim tags on lines. If I'm not mistaken, there are only a limited
number of tags, and if you have that few lines, you're better off doing
this all manually.
Anyway, the tool I'd use is AWK. Not one liners, but real AWK programs.
My first step would be to put every about 3 underscores followed by
the line number at the end of every line, but add one million to
the line number so all line numbers have the same length. This is
trivial in AWK. Now you have a record of the original sort order.
Next, I'd perform whatever kind of two stage or branched sorting you
need to do, once again with AWK.
Next, do whatever you need to do in order to simulate Vim tags. Because
you haven't told us what the tags are used for, I can't comment further.
Next, do whatever you need to do with those simulated tags.
Finally, within Vim, move the ending line numbers to the front of each
line, and re-sort again, to put it in the original order. Finally, use
Vim to get rid of those line numbers.
SteveT
Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211010042520.5103b5c2%40mydesk.domain.cxm.
>I would like to sort lines in a text document and then tag them, and
>then revert the file to its original order.
>
>First of all, is there a way to tag a line, so that lines with a given
>tag can be quickly referred to, but the tag is not in the actual text?
>
>Secondly, I noticed with my sort command ":sort \^[A-Z].*[^\.]$\ r"
>(sort all lines beginning with a capital letter and not ending in a
>period) it sends the matches in alphabetical order to the bottom of
>the file. Is there a way to specify a second-order sort by which all
>the matches are sub-sorted, rather than the default alphabetical? And,
>is there a way to send them to the top of the document rather than the
>bottom?
I think you're using the wrong tool. Also, you haven't said why you
need Vim tags on lines. If I'm not mistaken, there are only a limited
number of tags, and if you have that few lines, you're better off doing
this all manually.
Anyway, the tool I'd use is AWK. Not one liners, but real AWK programs.
My first step would be to put every about 3 underscores followed by
the line number at the end of every line, but add one million to
the line number so all line numbers have the same length. This is
trivial in AWK. Now you have a record of the original sort order.
Next, I'd perform whatever kind of two stage or branched sorting you
need to do, once again with AWK.
Next, do whatever you need to do in order to simulate Vim tags. Because
you haven't told us what the tags are used for, I can't comment further.
Next, do whatever you need to do with those simulated tags.
Finally, within Vim, move the ending line numbers to the front of each
line, and re-sort again, to put it in the original order. Finally, use
Vim to get rid of those line numbers.
SteveT
Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20211010042520.5103b5c2%40mydesk.domain.cxm.
Tuesday, October 5, 2021
Re: Sort lines, then tag, then unsort
On Mon, Oct 04, 2021 at 11:52:28AM +0200, Julius Hamilton wrote:
>On Sun 19. Sep 2021 at 16:29, 'Paul' via vim_use <vim_use@googlegroups.com>
>wrote:
>> Will marks suffice?
>
>Thanks for your message.
>
>Not sure, can you apply the same mark, i.e. "h", to multiple lines? I don't
>think so but I'm not sure.
No, you can't, but there are a limited number of marks available.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YVwin4LGIiRpVAFC%40rainslide.net.
>On Sun 19. Sep 2021 at 16:29, 'Paul' via vim_use <vim_use@googlegroups.com>
>wrote:
>> Will marks suffice?
>
>Thanks for your message.
>
>Not sure, can you apply the same mark, i.e. "h", to multiple lines? I don't
>think so but I'm not sure.
No, you can't, but there are a limited number of marks available.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YVwin4LGIiRpVAFC%40rainslide.net.
Monday, October 4, 2021
Re: opening utf-16 fileencoded ucs-2 Little Endian
hum, now it's log UCS16 that is bad displayed.
Le lun. 4 oct. 2021 à 18:02, Ni Va <nivaemail@gmail.com> a écrit :
this is better : set fencs=ucs-bom,utf-8,utf16le,latin9Le lun. 4 oct. 2021 à 18:02, Ni Va <nivaemail@gmail.com> a écrit :it's now my vimrc bad displayed with this fencs : set fencs=ucs-bom,utf16le,utf-8,latin9Le lun. 4 oct. 2021 à 13:39, Ni Va <nivaemail@gmail.com> a écrit :Hum I see Jürgen. Thank you.Le lun. 4 oct. 2021 à 13:24, 'Jürgen Krämer' via vim_use <vim_use@googlegroups.com> a écrit :Hi,
Christian Brabandt schrieb am 04.10.2021 um 12:44:
>
> On Mo, 04 Okt 2021, Ni Va wrote:
>
>> No error message but I don't happen to read the file.
>
> And you did use ':e! ++enc=utf16le' for the already loaded file? Because
> with this exact same command, I can reload the loaded file perfectly.
>
> Alternatively, try to add utf16le to the (global) fileencodings
> settings. But you need to add it before utf-8 I believe. So this should
> also work:
>
> ':set fencs=ucs-bom,utf16le,utf-8,latin9'
>
> But I am not sure, if this will not break for utf-8 files, so I tend to
> only explicitly re-load files using the `:e ++enc ` command
this will probably break utf-8 files without BOM. With BOM they would be
correctly detected by ucs-bom. Without a BOM all or almost all utf-8 files
can be interpreted as utf-16 -- even those with an odd number of bytes; in
this case Vim puts out a conversion error, but loads the file anyway. Even
incomplete surrogate pairs don't seem to prevent Vim from loading the file
as utf-16.
Better put utf16le after utf-8, because a misinterpretation of utf16 (both
little endian and big endian) can be detected by Vim.
But then you will probably run into the same dilemma with utf-16 and
latin9 ... :-(
Regards,
Jürgen
--
~
~
~
:wq
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/92aX9rHFCeE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6282c4d4-9137-5a70-bea5-ea1a7a818216%40googlemail.com.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAOKxv4G2JVmgi87UHinTiCch9ZNfWkMu0iSq5eVyHObi27gBVA%40mail.gmail.com.
Re: opening utf-16 fileencoded ucs-2 Little Endian
this is better : set fencs=ucs-bom,utf-8,utf16le,latin9
Le lun. 4 oct. 2021 à 18:02, Ni Va <nivaemail@gmail.com> a écrit :
it's now my vimrc bad displayed with this fencs : set fencs=ucs-bom,utf16le,utf-8,latin9Le lun. 4 oct. 2021 à 13:39, Ni Va <nivaemail@gmail.com> a écrit :Hum I see Jürgen. Thank you.Le lun. 4 oct. 2021 à 13:24, 'Jürgen Krämer' via vim_use <vim_use@googlegroups.com> a écrit :Hi,
Christian Brabandt schrieb am 04.10.2021 um 12:44:
>
> On Mo, 04 Okt 2021, Ni Va wrote:
>
>> No error message but I don't happen to read the file.
>
> And you did use ':e! ++enc=utf16le' for the already loaded file? Because
> with this exact same command, I can reload the loaded file perfectly.
>
> Alternatively, try to add utf16le to the (global) fileencodings
> settings. But you need to add it before utf-8 I believe. So this should
> also work:
>
> ':set fencs=ucs-bom,utf16le,utf-8,latin9'
>
> But I am not sure, if this will not break for utf-8 files, so I tend to
> only explicitly re-load files using the `:e ++enc ` command
this will probably break utf-8 files without BOM. With BOM they would be
correctly detected by ucs-bom. Without a BOM all or almost all utf-8 files
can be interpreted as utf-16 -- even those with an odd number of bytes; in
this case Vim puts out a conversion error, but loads the file anyway. Even
incomplete surrogate pairs don't seem to prevent Vim from loading the file
as utf-16.
Better put utf16le after utf-8, because a misinterpretation of utf16 (both
little endian and big endian) can be detected by Vim.
But then you will probably run into the same dilemma with utf-16 and
latin9 ... :-(
Regards,
Jürgen
--
~
~
~
:wq
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/92aX9rHFCeE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6282c4d4-9137-5a70-bea5-ea1a7a818216%40googlemail.com.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAOKxv4EWC%3D7Zyv8PkxTdVp%3DtJfdJr2iLZWELWeLf%2BdAxNUeAeA%40mail.gmail.com.
Re: opening utf-16 fileencoded ucs-2 Little Endian
it's now my vimrc bad displayed with this fencs : set fencs=ucs-bom,utf16le,utf-8,latin9
Le lun. 4 oct. 2021 à 13:39, Ni Va <nivaemail@gmail.com> a écrit :
Hum I see Jürgen. Thank you.Le lun. 4 oct. 2021 à 13:24, 'Jürgen Krämer' via vim_use <vim_use@googlegroups.com> a écrit :Hi,
Christian Brabandt schrieb am 04.10.2021 um 12:44:
>
> On Mo, 04 Okt 2021, Ni Va wrote:
>
>> No error message but I don't happen to read the file.
>
> And you did use ':e! ++enc=utf16le' for the already loaded file? Because
> with this exact same command, I can reload the loaded file perfectly.
>
> Alternatively, try to add utf16le to the (global) fileencodings
> settings. But you need to add it before utf-8 I believe. So this should
> also work:
>
> ':set fencs=ucs-bom,utf16le,utf-8,latin9'
>
> But I am not sure, if this will not break for utf-8 files, so I tend to
> only explicitly re-load files using the `:e ++enc ` command
this will probably break utf-8 files without BOM. With BOM they would be
correctly detected by ucs-bom. Without a BOM all or almost all utf-8 files
can be interpreted as utf-16 -- even those with an odd number of bytes; in
this case Vim puts out a conversion error, but loads the file anyway. Even
incomplete surrogate pairs don't seem to prevent Vim from loading the file
as utf-16.
Better put utf16le after utf-8, because a misinterpretation of utf16 (both
little endian and big endian) can be detected by Vim.
But then you will probably run into the same dilemma with utf-16 and
latin9 ... :-(
Regards,
Jürgen
--
~
~
~
:wq
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/92aX9rHFCeE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6282c4d4-9137-5a70-bea5-ea1a7a818216%40googlemail.com.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAOKxv4HNP7aW64bKB9OkU4AHyJySMjd_z1xUrx8NSomkwBGs0A%40mail.gmail.com.
Re: opening utf-16 fileencoded ucs-2 Little Endian
Hum I see Jürgen. Thank you.
Le lun. 4 oct. 2021 à 13:24, 'Jürgen Krämer' via vim_use <vim_use@googlegroups.com> a écrit :
Hi,
Christian Brabandt schrieb am 04.10.2021 um 12:44:
>
> On Mo, 04 Okt 2021, Ni Va wrote:
>
>> No error message but I don't happen to read the file.
>
> And you did use ':e! ++enc=utf16le' for the already loaded file? Because
> with this exact same command, I can reload the loaded file perfectly.
>
> Alternatively, try to add utf16le to the (global) fileencodings
> settings. But you need to add it before utf-8 I believe. So this should
> also work:
>
> ':set fencs=ucs-bom,utf16le,utf-8,latin9'
>
> But I am not sure, if this will not break for utf-8 files, so I tend to
> only explicitly re-load files using the `:e ++enc ` command
this will probably break utf-8 files without BOM. With BOM they would be
correctly detected by ucs-bom. Without a BOM all or almost all utf-8 files
can be interpreted as utf-16 -- even those with an odd number of bytes; in
this case Vim puts out a conversion error, but loads the file anyway. Even
incomplete surrogate pairs don't seem to prevent Vim from loading the file
as utf-16.
Better put utf16le after utf-8, because a misinterpretation of utf16 (both
little endian and big endian) can be detected by Vim.
But then you will probably run into the same dilemma with utf-16 and
latin9 ... :-(
Regards,
Jürgen
--
~
~
~
:wq
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/92aX9rHFCeE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6282c4d4-9137-5a70-bea5-ea1a7a818216%40googlemail.com.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAOKxv4E89CaiG%3DmN1U9xDy8COd6CbZaSJPK9Tcnv-kGgO_7mEQ%40mail.gmail.com.
Subscribe to:
Posts (Atom)