Re: How can I refactor with regex, the right single quotation mark with an apostrophe

Thank you :-)

On Thu, 29 Jun 2023 at 17:55, Tony Mechelynck <antoine.mechelynck@gmail.com> wrote:

On Thu, Jun 29, 2023 at 9:05 AM K otgc <konthegoldcoast@gmail.com> wrote:
>
> Hello Vim forum,
> I hope this is the correct vim forum firstly?
>
> So my keyboard Belkin (Ergonomic Smart Keyboard) F8E208-BLK(K B23-BLK) has an apostrophe key, but not a right single quotation mark.
>
> However my Google Contacts has duplicate data and version1 has the approved apostrophe, but version2 has the unapproved right single quotation mark.
>
> How can I run a regex to refactor this in vimdiff?
> Something like Terminal > vimdiff > right window > :s/<findRightSingleQuotationMark>/' > Enter.
> The problem is I cannot type the right single quotation mark with the keyboard?  Perhaps I can somehow enter the regex with ISO 8859-1 Unicode U+2019?
>
> Thanks for any help, as manually typing r' could be a lot of repeat.

If your 'encoding' setting is utf-8 (usually set somewhere early in
your vimrc if your system doesn't default to it) you can type any
character in Vim if you know its codepoint number, see ":help
i_CTRL-V_digit". You should NOT change 'encoding' after Vim has
finished starting up; for some other values of 'encoding' there exist
characters which Vim cannot represent in memory.

For instance, to enter the codepoint U+2019 when in Insert or
Command-line mode, type Ctrl-V followed by u followed by 2019

To replace all right single quotation marks by apostrophes in the
current editfile, you would then type
    :%s/'/'/g
where the "replace from" character ' is obtained by Ctrl-V followed by
u2019 and the "replace by" character ' is the apostrophe.

Best regards,
Tony.

--
--
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/CAJkCKXuyehHycazd-8r21i%3DidAgDmp-aczpCdy%3DnW9t%2B-P_iQw%40mail.gmail.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/CANGUsTs0kCLRLWupUFkHYue-EkOVtcExhTR-RFiy_DXvvvM2CQ%40mail.gmail.com.

Re: How can I refactor with regex, the right single quotation mark with an apostrophe

On Thu, Jun 29, 2023 at 9:05 AM K otgc <konthegoldcoast@gmail.com> wrote:
>
> Hello Vim forum,
> I hope this is the correct vim forum firstly?
>
> So my keyboard Belkin (Ergonomic Smart Keyboard) F8E208-BLK(K B23-BLK) has an apostrophe key, but not a right single quotation mark.
>
> However my Google Contacts has duplicate data and version1 has the approved apostrophe, but version2 has the unapproved right single quotation mark.
>
> How can I run a regex to refactor this in vimdiff?
> Something like Terminal > vimdiff > right window > :s/<findRightSingleQuotationMark>/' > Enter.
> The problem is I cannot type the right single quotation mark with the keyboard? Perhaps I can somehow enter the regex with ISO 8859-1 Unicode U+2019?
>
> Thanks for any help, as manually typing r' could be a lot of repeat.

If your 'encoding' setting is utf-8 (usually set somewhere early in
your vimrc if your system doesn't default to it) you can type any
character in Vim if you know its codepoint number, see ":help
i_CTRL-V_digit". You should NOT change 'encoding' after Vim has
finished starting up; for some other values of 'encoding' there exist
characters which Vim cannot represent in memory.

For instance, to enter the codepoint U+2019 when in Insert or
Command-line mode, type Ctrl-V followed by u followed by 2019

To replace all right single quotation marks by apostrophes in the
current editfile, you would then type
:%s/'/'/g
where the "replace from" character ' is obtained by Ctrl-V followed by
u2019 and the "replace by" character ' is the apostrophe.

Best regards,
Tony.

--
--
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/CAJkCKXuyehHycazd-8r21i%3DidAgDmp-aczpCdy%3DnW9t%2B-P_iQw%40mail.gmail.com.

How can I refactor with regex, the right single quotation mark with an apostrophe

Hello Vim forum,

I hope this is the correct vim forum firstly?

So my keyboard Belkin (Ergonomic Smart Keyboard) F8E208-BLK(K B23-BLK) has an apostrophe key, but not a right single quotation mark.

However my Google Contacts has duplicate data and version1 has the approved apostrophe, but version2 has the unapproved right single quotation mark.

How can I run a regex to refactor this in vimdiff?

Something like Terminal > vimdiff > right window > :s/<findRightSingleQuotationMark>/' > Enter.

The problem is I cannot type the right single quotation mark with the keyboard?  Perhaps I can somehow enter the regex with ISO 8859-1 Unicode U+2019?

Thanks for any help, as manually typing r' could be a lot of repeat.

--
--
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/97929c1a-c211-489b-b2b6-a6990749a839n%40googlegroups.com.

Re: t_fe and t_fd in tmux corrupts split with ^[[O

> On Sat, 24 Jun 2023 19:35:47 +0100
> Bram Moolenaar <Bram@moolenaar.net> wrote:
> > You need to tell Vim to recognize these escape sequences:
> >
> > execute "set <FocusGained>=\<Esc>[I"
> > execute "set <FocusLost>=\<Esc>[O"
> >
> > Since this is quite common it was made the default in patch 9.0.1619.
> > You only need to define the escape sequences for older Vim versions.
>
> Interesting. I wondered why it was there in the help doc but Vim didn't
> seem to need it. Thank you for the clarification.

I have been working on the terminal configuration support, removing
built-in hard coded values and depending more on termcap/terminfo.
Unfortunately, the latter has not been kept up-to-date for recently added
terminal features. Partly to blame on Vim's built-in support for xterm
and terminals declaring themselves to be xterm-compatible (even though
that's not 100% true). Result is that there was hardly any motivation
to make termcap/terminfo work better.

I'm trying to make support for various terminals work "properly", but it
is quite a struggle, it will take time. I hope terminal emulator
authors will cooperate, but there is a tendency of having a different
opinion of what "properly" is. This can lead to very long discussions
without a clear outcome. To avoid getting stuck I may sometimes pull
the "dictator" card and decide what is best for Vim.

For example, for supporting modifiers on special keys there is the
"modifyOtherKeys" protocol (supported by xterm and a few others). But
for some this was considered insufficient and the Kitty keyboard
protocol was added (which for a large part does the same thing, but with
some differences that helps some users and makes it complicated for
others).

The first step is to agree on how to make it work, then convince enough
people to implement it that way. Hopefully we then have enough traction
that others will follow.

For the keyboard protocol support I didn't see a way to convince all
terminal authors to support modifyOtherKeys or Kitty, thus I chose to
support both. It's a bit tricky, but it looks like it is working OK
now.

--
hundred-and-one symptoms of being an internet addict:
240. You think Webster's Dictionary is a directory of WEB sites.

/// 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/20230626153549.112B71C054C%40moolenaar.net.

Re: t_fe and t_fd in tmux corrupts split with ^[[O

On Sat, 24 Jun 2023 19:35:47 +0100
Bram Moolenaar <Bram@moolenaar.net> wrote:
> You need to tell Vim to recognize these escape sequences:
>
> execute "set <FocusGained>=\<Esc>[I"
> execute "set <FocusLost>=\<Esc>[O"
>
> Since this is quite common it was made the default in patch 9.0.1619.
> You only need to define the escape sequences for older Vim versions.

Interesting. I wondered why it was there in the help doc but Vim didn't
seem to need it. Thank you for the clarification.


By the way, in my second email, I wrote what the solution to my problem
was:
> [...]
> Turns out, the control code "^[[O" was emitted from TmuxOrSplitSwitch().
> All I had to do was prepend a ":h :silent" (not ":h map-<silent>; that
> was already there) to the keymap. Now Vim corrupt the window with that
> control code.

But I forgot "doesn't" in there. The last line should've said: Now Vim
_doesn't_ corrupt the window with that control code.

--
Enan

--
--
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/20230625100617.00001bfc%40gmail.com.

Re: t_fe and t_fd in tmux corrupts split with ^[[O

Enan Ajmain wrote:

> I have this in my vimrc according to ":h xterm-focus-event":
>
> if &term =~ '\v^(screen|tmux)'
> let &t_fe = "\<Esc>[?1004h"
> let &t_fd = "\<Esc>[?1004l"
> endif
>
> With it in tmux, when I switch panes, the pane with Vim running shows a
> control sequence "^[[O" where "^[" is Esc.

You need to tell Vim to recognize these escape sequences:

execute "set <FocusGained>=\<Esc>[I"
execute "set <FocusLost>=\<Esc>[O"

Since this is quite common it was made the default in patch 9.0.1619.
You only need to define the escape sequences for older Vim versions.


--
hundred-and-one symptoms of being an internet addict:
231. You sprinkle Carpet Fresh on the rugs and put your vacuum cleaner
in the front doorway permanently so it always looks like you are
actually attempting to do something about that mess that has amassed
since you discovered the Internet.

/// 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/20230624183547.E884A1C054C%40moolenaar.net.

Re: BUG: terminal vim 9.0.1506 x64 window 10

> On *Windows Terminal Preview* (Windows 11) with Windows PowerShell or CMD
> as the shell, the 'columns=600' or any other such setting will be ignored
> and the variable will remain at whatever vim set it to. So nothing happens
> to the display.

OK, so this is for when Vim is started directly in the terminal.
It would be good if ":set columns=80" is working here. I often use that
after messing with the window size for whatever reason (I use 80
columns so I can fit several terminal windows side-by-side).

> Using the Windows CMD shell under the old CMD terminal, whatever that is
> called, will result in columns value being changed, but the terminal does
> not change and has no issues after the setting.
>
> Using RedHat's cygwin bash, which comes with Git-Desktop for instance,
> inside of *Windows Terminal*, performing a "set columns=600" will result in
> a corrupted terminal which cannot be fixed using the standard terminal
> reset commands (tset(1) or reset(1)). Only closing and reopening the
> terminal will return a good work session.

Perhaps it sets some environment variable only on startup?

> Using cygwin bash under the RedHat provided *mintty* terminal and
> performing a "set columns=600" will cause vim to resize to the maximum
> width of the system monitor and set Columns to a number that equates to the
> new terminal size. This is the only terminal software I found that behaves
> as one would expect a Linux terminal to work. This was the best terminal I
> saw on Windows.
>
> Finally, using the *GVim* provided with VIM for Windows will also change
> the Terminal size according to changes in the 'columns' setting. Again, vim
> will change the size of the terminal up to the actual maximum available on
> the system monitor. The columns variable reflects the proper terminal size
> like the *mintty *version does. I don't know what terminal that means is
> used or even if it can be called a terminal, but clearly it works properly
> with vim by design.

Vim uses libvterm, a "virtual" terminal that is build into Vim. On
MS-Windows it uses ConPTY or WinPTY. libvterm resembles an xterm and
many programs can work with it.

> So my conclusion is that this is a terminal software problem. Some
> terminals adhere to the resizing commands that vim sends, some ignore it
> but remain stable, and yet others become hopelessly corrupted requiring
> that the software be closed and restarted.

We can try to make it work. For some terminals we may require the
maintainers to make changes. I suppose there is no standard way for
handling size changes, like SIGWINCH on Unix. If there is a terminal
that does this well we can suggest to use it as an example, hopefully we
can then avoid every terminal doing something different.

> Obviously Bram knows far more than I do, but my recommendation would
> be to use a Terminal package that behaves like a fully functional soft
> terminal should or don't resize the window *after* launching VIM.

In the help we can list terminals we know and what works for each of
them. That can function as a recommendation. It will take some effort
to keep up-to-date, but it's worth it.

> Personally I use bash and Windows Terminal when I'm on Windows. It has
> features I prefer and I don't usually resize my work space after I've
> got set up. Will Microsoft fix their issues. Not gonna hold my breath.

I'm sure Microsoft will not fix *all* their issues, but the team working
on the Windows Terminal has been responsive. I hope at least one of
them is using Vim and fixes any encountered problems. That's why Vim
works well in the Chrome secure shell :-).

> Should there be smoke coming out of my CPU?

No, it's bad for the cooling system and shortens life.

--
hundred-and-one symptoms of being an internet addict:
200. You really believe in the concept of a "paperless" office.

/// 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/20230621230529.C8FAB1C0A9C%40moolenaar.net.

Re: BUG: terminal vim 9.0.1506 x64 window 10

On Wed, 21 Jun 2023 19:16:28 +0200
Christian Brabandt <cblists@256bit.org> wrote:
> > Am 21.06.2023 um 18:13 schrieb Enan Ajmain <3nan.ajmain@gmail.com>:
> >
> > ___On Wed, 21 Jun 2023 13:41:03 +0100
> > Bram Moolenaar <Bram@moolenaar.net> wrote:
> >> Can we assume that MS Terminal is included with the distribution, or
> >> installed most widely? If so, then investing time in making this work
> >> properly is well worth it.
> >
> > Windows 11 comes with MS Terminal and is the default [1].
>
>
> Is this true? I thought I had to manually install it on my win 11 system.

Informed by good source. I asked on a PowerShell Discord server. A lot
of MS employees frequent there. One of them said Windows 11 should
include MS Terminal. He also said to tell him or Kayla (for some reason
he thought I know all of them) if I find any edge case.

There is also the link I provided in my previous email. It declares
that Windows 11 will not only come with MS Terminal, it will come with
it as default (which is what Stan Brown talked about in the other reply
to your email).

> Thanks
> Chris
>

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

Re: BUG: terminal vim 9.0.1506 x64 window 10

It's true.

I use TCCLE (free version of Take Command) as a command-line shell on my
Windows machine. In an April round of updates, Windows 11 shifted to
opening TCCLE as a tab in a MS Terminal window rather than independently
as in the past. Fortunately, with a published hack I change Windows 11
back to the previous behavior.

Windows Terminal was there before the updates, but Windows didn't try as
aggressively to have us use it.

Maybe you are thinking of the Bash shell in Windows, part of the Windows
Subsystem for Linux? I don't use it myself; but, if I'm not mistaken,
you have to change some settings to activate WSL. Googling for
"bash shell" "Windows 11"
turns up many useful-looking pages. This one seems straightforward:
<https://mspoweruser.com/different-ways-to-run-shell-script-files-on-windows/>

Stan Brown
Tehachapi, CA, USA
https://BrownMath.com

On 2023-06-21 10:16, Christian Brabandt wrote:
>
>
>> Am 21.06.2023 um 18:13 schrieb Enan Ajmain <3nan.ajmain@gmail.com>:
>>
>> On Wed, 21 Jun 2023 13:41:03 +0100
>> Bram Moolenaar <Bram@moolenaar.net> wrote:
>>> Can we assume that MS Terminal is included with the distribution, or
>>> installed most widely? If so, then investing time in making this work
>>> properly is well worth it.
>>
>> Windows 11 comes with MS Terminal and is the default [1].
>
>
> Is this true? I thought I had to manually install it on my win 11 system.
>
> Thanks
> Chris
>

--
--
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/ccf7fcc7-406a-6365-c33b-c8537783e486%40fastmail.fm.

Re: BUG: terminal vim 9.0.1506 x64 window 10

> Am 21.06.2023 um 18:13 schrieb Enan Ajmain <3nan.ajmain@gmail.com>:
>
> On Wed, 21 Jun 2023 13:41:03 +0100
> Bram Moolenaar <Bram@moolenaar.net> wrote:
>> Can we assume that MS Terminal is included with the distribution, or
>> installed most widely? If so, then investing time in making this work
>> properly is well worth it.
>
> Windows 11 comes with MS Terminal and is the default [1].


Is this true? I thought I had to manually install it on my win 11 system.

Thanks
Chris

--
--
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/043EABA3-907D-4888-BCAF-0979F8A173BA%40256bit.org.

Re: BUG: terminal vim 9.0.1506 x64 window 10

On Wed, 21 Jun 2023 13:41:03 +0100
Bram Moolenaar <Bram@moolenaar.net> wrote:
> Can we assume that MS Terminal is included with the distribution, or
> installed most widely? If so, then investing time in making this work
> properly is well worth it.

Windows 11 comes with MS Terminal and is the default [1]. As for making
this work: it already works fine. You may be referencing a previous
issue I raised about colors [2]. That's a veeery minor issue. And it
only appears when 'termguicolors' is disabled, which isn't the case for
most users.

(after re-reading the earlier emails:)

I see that Rob Solomon wrote:
> I'm following up w/ my last post, to say that it's been fixed by making the
> terminal window size smaller. This fixed the same issue whether it was
> cmd.exe, windows terminal, or TakeCommand.

That's a contradiction between what they and I are experiencing. On my
end, when I resize MS Terminal or Conhost, Vim resizes accordingly. My
system is:

OS: Windows 11 22H2 (Microsoft Windows [Version 10.0.22621.1848])
Terminal: Windows Terminal Preview v1.18.1462.0
Shell: cmd.exe, PowerShell 7, git-bash, msys (tried all)
Vim: v9.0.1640 (built with mingw-w64 toolchain of MSys2/UCRT64)

--
Enan

[1]: https://devblogs.microsoft.com/commandline/windows-terminal-is-now-the-default-in-windows-11/
[2]: https://groups.google.com/g/vim_dev/c/SuVLCni9WCw/m/UtZ2DXLDAQAJ

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

Re: BUG: terminal vim 9.0.1506 x64 window 10

> On Tue, 20 Jun 2023 22:52:05 -0700 (PDT)
> Steve Martin <smartin5590@gmail.com> wrote:
> > [...]
> >
> > Using the Windows CMD shell under the old CMD terminal, whatever that
> > is called
>
> It's Console Host or Conhost in short.

There also is mention of "Win32 virtual console", the +vtp feature.
This is currently enabled for all MS-Windows non-GUI versions, thus it
doesn't appear to have an effect on how Vim works. The feature itself
is useful to distinguish from an old Vim version that didn't support
this.

> > Personally I use bash and Windows Terminal when I'm on Windows. It
> > has features I prefer and I don't usually resize my work space after
> > I've got set up. Will Microsoft fix their issues. Not gonna hold my
> > breath.
>
> I assume by "Microsoft" and "their issue" you mean the issue in Conhost.
> If so, then yeah, it's not gonna get fixed. There are compatibility
> reasons for that (which I don't care about), but to circumvent this the
> team decided to overhaul Conhost and replace it with the new Terminal.
> It'll be the default in the next . . . I donno, year perhaps? Decade?
>
> And just to clarify, resizing MS Terminal window after launching Vim
> doesn't cause any problem. MS Terminal should behave like a Linux
> terminal emulator. It advertizes itself as supporting all xterm
> features. Well, perhaps not all, but most of the oft-used ones.

A problem related to this is that Vim was originally made for the
console, not for a generic terminal like on Unix. In the code there are
calls to is_term_win32() and different behavior when it returns true.
That is when 'term' is set to "win32". And it is set to that value in a
few places, some may not be correct. E.g. near the end of
did_set_string_option():

#if defined(FEAT_VTP) && defined(FEAT_TERMGUICOLORS)
if (args.os_did_swaptcap)
{
set_termname((char_u *)"win32");
init_highlight(TRUE, FALSE);
}

Re: BUG: terminal vim 9.0.1506 x64 window 10

> Looking at the Take Command website and Googling about it I can find no
> reference to Take Command as a Terminal emulator *anywhere*. I am guessing
> it has very basic, if any, capabilities at all. Thus it probably doesn't
> heed any *':set columns=*' or other vim terminal commands.

If Vim's assumption of the terminal size (which is in the 'lines' and
'columns' options) does not match the actual terminal size, then display
problems are to be expected.

There are two sides: getting and setting the size.

Getting the size is always needed, unless you keep the terminal at the
default 25 x 80 size (which is unlikely). On top of that, Vim would
need to get notified if the terminal size is changed (e.g. by dragging
the border) while it is running, see below.

Setting the size is needed to support ":set lines=123" and ":set
columns=123". Or Vim needs to know that the size cannot be set and it
should give an error message and not change the number of lines/columns
used.

It is not so easy to figure out what happens in what sequence. I'll add
a few log messages to the Unix implementation. Handling the size works
fine there, thus this can be used as an example. But it might be that
for MS-Windows it works differently. E.g., in Unix a signal is used:
SIGWINCH. I don't know if MS-Windows has something similar. Also, the
implementation of term_report_winsize() needs to be checked. This
should trigger the signal in any Vim instance running in a terminal
window, initiated from the Vim instance that has the terminal window.

--
hundred-and-one symptoms of being an internet addict:
196. Your computer costs more than your car.

/// 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/20230621124103.ABC7D1C0A8A%40moolenaar.net.

Re: BUG: terminal vim 9.0.1506 x64 window 10

On Wed, 21 Jun 2023 04:05:52 -0700 (PDT)
"rwmit...@gmail.com" <rwmitchell@gmail.com> wrote:
> Wow, that must have really hit a nerve for you to go into such
> lengths for a platform that is and has always been subpar, always
> several years behind everyone else.

Couldn't agree more. On Windows being subpar. Not on my nerve being
hit. I despise Windows. Thankfully my programming laptop is a Linux
machine. I donno what I would've done otherwise.

I also don't know what "length" I went to. I just shared my knowledge
on something I hate. That might sound unintuitive. Why would someone
speak on something they hate? To that all I can say is, you should hear
me rant about OOP.

--
--
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/20230621182247.54e34422%40cirdan.

Re: BUG: terminal vim 9.0.1506 x64 window 10

Wow, that must have really hit a nerve for you to go into such lengths for a platform that is and has always been subpar, always several years behind everyone else.

On Wednesday, June 21, 2023 at 2:27:59 AM UTC-4 Enan Ajmain wrote:

On Tue, 20 Jun 2023 22:52:05 -0700 (PDT)
Steve Martin <smart...@gmail.com> wrote:
> [...]
>
> Using the Windows CMD shell under the old CMD terminal, whatever that
> is called

It's Console Host or Conhost in short.

> Personally I use bash and Windows Terminal when I'm on Windows. It
> has features I prefer and I don't usually resize my work space after
> I've got set up. Will Microsoft fix their issues. Not gonna hold my
> breath.

I assume by "Microsoft" and "their issue" you mean the issue in Conhost.
If so, then yeah, it's not gonna get fixed. There are compatibility
reasons for that (which I don't care about), but to circumvent this the
team decided to overhaul Conhost and replace it with the new Terminal.
It'll be the default in the next . . . I donno, year perhaps? Decade?

And just to clarify, resizing MS Terminal window after launching Vim
doesn't cause any problem. MS Terminal should behave like a Linux
terminal emulator. It advertizes itself as supporting all xterm
features. Well, perhaps not all, but most of the oft-used ones.

> In the end there are a lot of choices out there, which can be both
> good and bad.

Before MS Terminal, Wezterm was the best choice. Before that, Cmder and
ConEmu. And the problem with Mintty is that it's not independent. The
reason it behaves so like a Linux terminal is because it's built with
Cygwin or Cygwin-like shells (MSys, git-bash, etc.) in mind. You can't
run Command Prompt or PowerShell on it. You can't even run Win32
version of Vim on it. You'll need a Vim built with Cygwin. That's an
extra hassle in my opinion.

> __
>
> Should there be smoke coming out of my CPU?
>
> On Tuesday, June 20, 2023 at 1:47:23 AM UTC-6 Steve Martin wrote:
>
> Looking at the Take Command website and Googling about it I can find
> no reference to Take Command as a Terminal emulator *anywhere*. I am
> guessing it has very basic, if any, capabilities at all. Thus it
> probably doesn't heed any *':set columns=*' or other vim terminal
> commands.
>
> On Monday, June 19, 2023 at 12:32:07 PM UTC-6 Ed Blackman wrote:
>
> On Mon, Jun 19, 2023 at 09:53:12AM +0200, Christian Brabandt wrote:
> > On Sa, 17 Jun 2023, Robert Solomon wrote:
> > > Windows 10
> > >
> > > My quick testing involved me starting take command and using the
> > > mouse
> to size the window. Take command shows the window size in the
> bottom right corner.
> >
> > So, can you reproduce the issue using `vim --clean` to disable any
> > of your usual customizations? What exactly is this `take` command.
> > Does it reproduce without it?
> >
> > What terminal did you use, you said?
>
> Take Command is a replacement shell (and maybe a replacement
> terminal?) for Windows: https://jpsoft.com/products/take-command.html
>
> I don't know anything about it, but thought I'd interject to clarify.
>



--
Enan

--
--
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/7ac91cac-53d4-439d-8825-fb7cf352f4b4n%40googlegroups.com.

Re: BUG: terminal vim 9.0.1506 x64 window 10

On Tue, 20 Jun 2023 22:52:05 -0700 (PDT)
Steve Martin <smartin5590@gmail.com> wrote:
> [...]
>
> Using the Windows CMD shell under the old CMD terminal, whatever that
> is called

It's Console Host or Conhost in short.

> Personally I use bash and Windows Terminal when I'm on Windows. It
> has features I prefer and I don't usually resize my work space after
> I've got set up. Will Microsoft fix their issues. Not gonna hold my
> breath.

I assume by "Microsoft" and "their issue" you mean the issue in Conhost.
If so, then yeah, it's not gonna get fixed. There are compatibility
reasons for that (which I don't care about), but to circumvent this the
team decided to overhaul Conhost and replace it with the new Terminal.
It'll be the default in the next . . . I donno, year perhaps? Decade?

And just to clarify, resizing MS Terminal window after launching Vim
doesn't cause any problem. MS Terminal should behave like a Linux
terminal emulator. It advertizes itself as supporting all xterm
features. Well, perhaps not all, but most of the oft-used ones.

> In the end there are a lot of choices out there, which can be both
> good and bad.

Before MS Terminal, Wezterm was the best choice. Before that, Cmder and
ConEmu. And the problem with Mintty is that it's not independent. The
reason it behaves so like a Linux terminal is because it's built with
Cygwin or Cygwin-like shells (MSys, git-bash, etc.) in mind. You can't
run Command Prompt or PowerShell on it. You can't even run Win32
version of Vim on it. You'll need a Vim built with Cygwin. That's an
extra hassle in my opinion.

> __
>
> Should there be smoke coming out of my CPU?
>
> On Tuesday, June 20, 2023 at 1:47:23 AM UTC-6 Steve Martin wrote:
>
> Looking at the Take Command website and Googling about it I can find
> no reference to Take Command as a Terminal emulator *anywhere*. I am
> guessing it has very basic, if any, capabilities at all. Thus it
> probably doesn't heed any *':set columns=*' or other vim terminal
> commands.
>
> On Monday, June 19, 2023 at 12:32:07 PM UTC-6 Ed Blackman wrote:
>
> On Mon, Jun 19, 2023 at 09:53:12AM +0200, Christian Brabandt wrote:
> > On Sa, 17 Jun 2023, Robert Solomon wrote:
> > > Windows 10
> > >
> > > My quick testing involved me starting take command and using the
> > > mouse
> to size the window. Take command shows the window size in the
> bottom right corner.
> >
> > So, can you reproduce the issue using `vim --clean` to disable any
> > of your usual customizations? What exactly is this `take` command.
> > Does it reproduce without it?
> >
> > What terminal did you use, you said?
>
> Take Command is a replacement shell (and maybe a replacement
> terminal?) for Windows: https://jpsoft.com/products/take-command.html
>
> I don't know anything about it, but thought I'd interject to clarify.
>



--
Enan

--
--
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/20230621122746.329b1a8d%40cirdan.

Re: BUG: terminal vim 9.0.1506 x64 window 10

To be clear, testing on various terminals on Windows results in the following conclusions.

On Windows Terminal Preview (Windows 11) with Windows PowerShell or CMD as the shell, the 'columns=600' or any other such setting will be ignored and the variable will remain at whatever vim set it to. So nothing happens to the display.

Using the Windows CMD shell under the old CMD terminal, whatever that is called, will result in columns value being changed, but the terminal does not change and has no issues after the setting.

Using RedHat's cygwin bash, which comes with Git-Desktop for instance, inside of Windows Terminal, performing a "set columns=600" will result in a corrupted terminal which cannot be fixed using the standard terminal reset commands (tset(1) or reset(1)). Only closing and reopening the terminal will return a good work session.

Using cygwin bash under the RedHat provided mintty terminal and performing a "set columns=600" will cause vim to resize to the maximum width of the system monitor and set Columns to a number that equates to the new terminal size. This is the only terminal software I found that behaves as one would expect a Linux terminal to work. This was the best terminal I saw on Windows.

Finally, using the GVim provided with VIM for Windows will also change the Terminal size according to changes in the 'columns' setting. Again, vim will change the size of the terminal up to the actual maximum available on the system monitor. The columns variable reflects the proper terminal size like the mintty version does. I don't know what terminal that means is used or even if it can be called a terminal, but clearly it works properly with vim by design.

So my conclusion is that this is a terminal software problem. Some terminals adhere to the resizing commands that vim sends, some ignore it but remain stable, and yet others become hopelessly corrupted requiring that the software be closed and restarted. 

Obviously Bram knows far more than I do, but my recommendation would be to use a Terminal package that behaves like a fully functional soft terminal should or don't resize the window after launching VIM.

Personally I use bash and Windows Terminal when I'm on Windows. It has features I prefer and I don't usually resize my work space after I've got set up. Will Microsoft fix their issues. Not gonna hold my breath.

In the end there are a lot of choices out there, which can be both good and bad.

__ 

Should there be smoke coming out of my CPU?

On Tuesday, June 20, 2023 at 1:47:23 AM UTC-6 Steve Martin wrote:

Looking at the Take Command website and Googling about it I can find no reference to Take Command as a Terminal emulator anywhere. I am guessing it has very basic, if any, capabilities at all. Thus it probably doesn't heed any ':set columns=' or other vim terminal commands.

On Monday, June 19, 2023 at 12:32:07 PM UTC-6 Ed Blackman wrote:

On Mon, Jun 19, 2023 at 09:53:12AM +0200, Christian Brabandt wrote:
> On Sa, 17 Jun 2023, Robert Solomon wrote:
> > Windows 10
> >
> > My quick testing involved me starting take command and using the mouse to size the window.   Take command shows the window size in the bottom right corner. 
>
> So, can you reproduce the issue using `vim --clean` to disable any of
> your usual customizations? What exactly is this `take` command. Does it
> reproduce without it?
>
> What terminal did you use, you said?

Take Command is a replacement shell (and maybe a replacement terminal?) for Windows: https://jpsoft.com/products/take-command.html

I don't know anything about it, but thought I'd interject to clarify.

--
Ed Blackman

--
--
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/bea3e0f6-94f4-421c-a9e0-c85e056a4987n%40googlegroups.com.

Re: BUG: terminal vim 9.0.1506 x64 window 10

Looking at the Take Command website and Googling about it I can find no reference to Take Command as a Terminal emulator anywhere. I am guessing it has very basic, if any, capabilities at all. Thus it probably doesn't heed any ':set columns=' or other vim terminal commands.

On Monday, June 19, 2023 at 12:32:07 PM UTC-6 Ed Blackman wrote:

On Mon, Jun 19, 2023 at 09:53:12AM +0200, Christian Brabandt wrote:
> On Sa, 17 Jun 2023, Robert Solomon wrote:
> > Windows 10
> >
> > My quick testing involved me starting take command and using the mouse to size the window.   Take command shows the window size in the bottom right corner. 
>
> So, can you reproduce the issue using `vim --clean` to disable any of
> your usual customizations? What exactly is this `take` command. Does it
> reproduce without it?
>
> What terminal did you use, you said?

Take Command is a replacement shell (and maybe a replacement terminal?) for Windows: https://jpsoft.com/products/take-command.html

I don't know anything about it, but thought I'd interject to clarify.

--
Ed Blackman

--
--
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/079e656e-3c10-417c-b6b0-d4bf7716b813n%40googlegroups.com.

Re: BUG: terminal vim 9.0.1506 x64 window 10

On Mon, Jun 19, 2023 at 09:53:12AM +0200, Christian Brabandt wrote:
> On Sa, 17 Jun 2023, Robert Solomon wrote:
> > Windows 10
> >
> > My quick testing involved me starting take command and using the mouse to size the window.   Take command shows the window size in the bottom right corner. 
>
> So, can you reproduce the issue using `vim --clean` to disable any of
> your usual customizations? What exactly is this `take` command. Does it
> reproduce without it?
>
> What terminal did you use, you said?

Take Command is a replacement shell (and maybe a replacement terminal?) for Windows: https://jpsoft.com/products/take-command.html

I don't know anything about it, but thought I'd interject to clarify.

--
Ed Blackman

--
--
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/1687199199.ec432a%40strabo.garrett.

Re: t_fe and t_fd in tmux corrupts split with ^[[O

I forgot to add a vital piece of info. I also have vim-tmux-navigator.
Not the Vim plugin, but the minimal necessary code stolen from it.

function! TmuxOrSplitSwitch(wincmd, tmuxdir) abort
let previous_winnr = winnr()
silent! execute "wincmd " . a:wincmd
if previous_winnr == winnr()
call system("tmux list-panes -F '#F' | grep -q Z
\|| tmux select-pane -" . a:tmuxdir)
endif
endfunction

let previous_title = substitute(system("tmux display-message -p
\ '#{pane_title}'"), '\n', '', '')
let &t_ti = "\<Esc>]2;vim\<Esc>\\" . &t_ti
let &t_te = "\<Esc>]2;". previous_title . "\<Esc>\\" . &t_te

nnoremap <silent> <C-h> :call TmuxOrSplitSwitch('h', 'L')<CR>
nnoremap <silent> <C-j> :call TmuxOrSplitSwitch('j', 'D')<CR>
nnoremap <silent> <C-k> :call TmuxOrSplitSwitch('k', 'U')<CR>
nnoremap <silent> <C-l> :call TmuxOrSplitSwitch('l', 'R')<CR>

Turns out, the control code "^[[O" was emitted from TmuxOrSplitSwitch().
All I had to do was prepend a ":h :silent" (not ":h map-<silent>; that
was already there) to the keymap. Now Vim corrupt the window with that
control code.

--
Enan

--
--
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/20230619225513.00007ad3%40gmail.com.

t_fe and t_fd in tmux corrupts split with ^[[O

I have this in my vimrc according to ":h xterm-focus-event":

if &term =~ '\v^(screen|tmux)'
let &t_fe = "\<Esc>[?1004h"
let &t_fd = "\<Esc>[?1004l"
endif

With it in tmux, when I switch panes, the pane with Vim running shows a
control sequence "^[[O" where "^[" is Esc. I had to add this autocmd to
circumvent this:

if &term =~ '\v^(screen|tmux)'
augroup autoread
au!
au FocusLost * :redraw!
augroup END
endif

It works well enough in local machine, but over ssh, it causes annoying
flickering. Did anyone face this before (or does now) and solved it?


In .tmux.conf, I have:

set -g escape-time 10 # wait 10ms after Esc key
set -g repeat-time 500 # wait 100ms for repeating command
set -g focus-events on
set -g set-clipboard on
set -g history-limit 5000

set -g default-terminal "tmux-256color"
set -ga terminal-overrides ',xterm-256color*:Tc'
set -as terminal-overrides ',st-256color:Ms=\E]52;%p1%s;%p2%s\007'
set -ga terminal-overrides '*:Ss=\E[%p1%d q:Se=\E[ q'

is_vim="ps -o state= -o comm= -t '#{pane_tty}' \
| grep -iqE '^[^TXZ ]+ +(\\S+\\/)?g?(view|n?vim?x?)(diff)?$'"

bind-key -n C-h if-shell "$is_vim" "send-keys C-h" "select-pane -L"
bind-key -n C-j if-shell "$is_vim" "send-keys C-j" "select-pane -D"
bind-key -n C-k if-shell "$is_vim" "send-keys C-k" "select-pane -U"
bind-key -n C-l if-shell "$is_vim" "send-keys C-l" "select-pane -R"
bind-key -n C-\ if-shell "$is_vim" "send-keys C-\\" "select-pane -l"

The later part of the tmux config lets me switch tmux panes and vim
splits with the same keys. The if-shell syntax is straight-forward but
let me know if it's confusing and I can explain.

The versions of Vim and Tmux I'm using is postscripted.

--
Enan

$ tmux -V
tmux 3.2a

$ vim --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Apr 14 2023 03:28:41)
Included patches: 1-1403
Modified by <amazon-linux-engine@amazon.com>
Compiled by <amazon-linux-engine@amazon.com>
Huge version without GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_urxvt -tag_any_white
+arabic +find_in_path +mouse_xterm -tcl
+autocmd +float +multi_byte +termguicolors
+autochdir +folding +multi_lang +terminal
-autoservername -footer -mzscheme +terminfo
-balloon_eval +fork() +netbeans_intg +termresponse
+balloon_eval_term +gettext +num64 +textobjects
-browse -hangul_input +packages +textprop
++builtin_terms +iconv +path_extra +timers
+byte_offset +insert_expand +perl/dyn +title
+channel +ipv6 +persistent_undo -toolbar
+cindent +job +popupwin +user_commands
-clientserver +jumplist +postscript +vartabs
-clipboard +keymap +printer +vertsplit
+cmdline_compl +lambda +profile +vim9script
+cmdline_hist +langmap -python +viminfo
+cmdline_info +libcall +python3/dyn +virtualedit
+comments +linebreak +quickfix +visual
+conceal +lispindent +reltime +visualextra
+cryptv +listcmds +rightleft +vreplace
+cscope +localmap +ruby/dyn +wildignore
+cursorbind +lua/dyn +scrollbind +wildmenu
+cursorshape +menu +signs +windows
+dialog_con +mksession +smartindent +writebackup
+diff +modify_fname -sodium -X11
+digraphs +mouse -sound -xfontset
-dnd -mouseshape +spell -xim
-ebcdic +mouse_dec +startuptime -xpm
+emacs_tags +mouse_gpm +statusline -xsmp
+eval -mouse_jsbterm -sun_workshop -xterm_clipboard
+ex_extra +mouse_netterm +syntax -xterm_save
+extra_search +mouse_sgr +tag_binary
-farsi -mouse_sysmouse -tag_old_static
system vimrc file: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -g -pipe -Wall -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DSYS_VIMRC_FILE=/etc/vimrc -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE -Wl,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim -lm -lselinux -lncurses -lrt -lacl -lattr -lgpm -ldl -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE -fstack-protector -L/usr/lib64/perl5/CORE -lperl -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc

--
--
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/20230619222021.0000342a%40gmail.com.

Re: how to ignore a dir for vimgrep but not for cmdline completion

On Mon, 19 Jun 2023 11:11:12 +0200
Tom M <7tommm@gmail.com> wrote:
> Hi all,
>
> Is there a way to ignore a dir when searching with vimgrep and not
> ignored when doing command line autocompletion? The wildignore option
> makes vim ignore the dir in both cases. Thanks in advance,

I don't know about :vimgrep, but in :grep, you can include/exclude files
or folders according to your ":h grepprg". I use "git grep" as my grep
program, so to exclude files or folders I do this.

:grep --no-index pattern -- :!folder :!file.txt

To reiterate, my 'grepprg' is set to this:
:let &gp = 'git grep --recursive-submodules -In $*'

--
Enan

--
--
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/20230619163047.6a839383%40cirdan.

how to ignore a dir for vimgrep but not for cmdline completion

Hi all,

Is there a way to ignore a dir when searching with vimgrep and not ignored when doing command line autocompletion? The wildignore option makes vim ignore the dir in both cases. Thanks in advance,

Tom M

--
--
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/CAD_dSXh%2B8e_1kNdRw%2BzS8kJUbHkT50U06ieuHC9Vzm%2BoqUywhQ%40mail.gmail.com.

Re: How to know in which patch a feature was added

On Sun, Jun 18, 2023 at 11:15:37PM +0600, Enan Ajmain wrote:
> In the beginning, I used a simple vimrc, basically ":se nu", etc. Those
> features were available in all available Vim installations. Later when
> I got into tweaking, I used nightly builds of Vim, so I always had the
> latest features. But nowadays I have to work in a few ssh machines,
> some of which have slightly older versions of Vim. Which means some of
> my settings emit errors.
>
> The proper way to handle this is with ":has()" and ":exists()". For
> checking the existence of things like functions, autocommand events,
> variables, etc., they work fine. Even for options, I can use exists().
> But what about option values? Let's say I want to set 'wildoptions' to
> use 'popupmenu'. This was introduced in a late patch of 8.2. The only
> way I can include this setting with sanity check is by using ":if
> has('patch-8.2.4325')". The problem is: I had to find the patch number
> by using "git grep --log=pum".
>
> Is there an easier way to find the patch number where an option was
> introduced? Perhaps with ":helpgrep"?

I usually rely on helpful.vim (https://github.com/tweekmonster/helpful.vim)
when I need to find a version because I can't use has()/exists() to
detect a feature. Unfortunately I don't know if it can help with new
option values.

I've used git blame on the help file to roughly find the date, but help
file changes are sometimes committed separately from code changes.

Marius Gedminas
--
Seen on a button at an SF Convention:
Veteran of the Bermuda Triangle Expeditionary Force. 1990-1951.

--
--
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/yjfzakqzdbjeam62ci654poftyiwjbmee3ka4d6fusir4ttt4v%40leztqetrjufr.

Re: BUG: terminal vim 9.0.1506 x64 window 10

On Sa, 17 Jun 2023, Robert Solomon wrote:

> Windows 10
>
> My quick testing involved me starting take command and using the mouse to size the window.   Take command shows the window size in the bottom right corner. 
>
> After setting the window  size, I start vim using my _vimrc as I usually do.   I did not change anything from within vim.

So, can you reproduce the issue using `vim --clean` to disable any of
your usual customizations? What exactly is this `take` command. Does it
reproduce without it?

What terminal did you use, you said?

Best,
Christian
--
Wohl dem, der seiner Väter gern gedenkt.
-- Johann Wolfgang von Goethe (Iphigenie I)

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

Re: How to know in which patch a feature was added

On 2023-06-19, Enan Ajmain wrote:
> On Sun, 18 Jun 2023 14:40:20 -0400
> Salman Halim wrote:
> > This isn't exactly what you asked for, but how about a custom command, such
> > as Set, that calls a function to do the option set in a try/catch? If it
> > succeeds, great. If it fails, you can just ignore it or use an echomsg or
> > something.
> >
> > You won't know when a feature was introduced, but you also won't have to
> > have existence checks around everything.
>
> Great idea! I learned about try-catch in VimScript only a few days ago.
> Don't know why it slipped my mind so soon. Thanks!
>
> I'll set up an user function, as you said, and iteratively replace "set"
> with "Set" for the options that I get an error for.

If all you care about is avoiding the error message, just use
:silent!, e.g.,

:silent! set wildoptions+=pum

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/20230618194612.GF6600%40phoenix.

Re: How to know in which patch a feature was added

On Sun, 18 Jun 2023 14:40:20 -0400
Salman Halim <salmanhalim@gmail.com> wrote:
> This isn't exactly what you asked for, but how about a custom command, such
> as Set, that calls a function to do the option set in a try/catch? If it
> succeeds, great. If it fails, you can just ignore it or use an echomsg or
> something.
>
> You won't know when a feature was introduced, but you also won't have to
> have existence checks around everything.

Great idea! I learned about try-catch in VimScript only a few days ago.
Don't know why it slipped my mind so soon. Thanks!

I'll set up an user function, as you said, and iteratively replace "set"
with "Set" for the options that I get an error for.

--
Enan

--
--
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/20230619011433.00007b82%40gmail.com.

Re: How to know in which patch a feature was added

On Sun, Jun 18, 2023 at 8:40 PM Salman Halim <salmanhalim@gmail.com> wrote:
>
> This isn't exactly what you asked for, but how about a custom command, such as Set, that calls a function to do the option set in a try/catch? If it succeeds, great. If it fails, you can just ignore it or use an echomsg or something.
>
> You won't know when a feature was introduced, but you also won't have to have existence checks around everything.
>
> Salman

This would work great… as long as you are certain in advance that the
Vim you're running on has a built-in (and non-buggy) try-catch
feature. This can be checked, of course, with
:if exists(':try') == 2
but I remember a time when that feature (introduced when? At some
point in Vim 7, I think) didn't exist. As a belt-and-suspenders man, I
try to make the fewest possible unsupported assumptions. ;-)

Best regards,
Tony.

--
--
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/CAJkCKXvY%3D4piHH721EcxfK_%2BOixU0BKtsq7wD7%3DS%3DmVZhtbaOQ%40mail.gmail.com.

Re: How to know in which patch a feature was added

P.S. Beware that has('patch-m.n.p') only works in Vim 7.4.237 or
later. If there is a possibility that you are running an earlier Vim,
the equivalent

if (version > 701 || version == 701 && has('patch103'))

will check for equal or later than patchlevel 7.1.103 including some
builds which would not recognize what has('patch-7.1.103') means. I
use "version" rather than "v:version" because the former is an older
synonym, now deprecated but recognized by older versions of Vim. (Of
course if you run the risk of having to use Vim 8 or even Vim 7 you
won't use Vim 9 language.)

Best regards,
Tony.

--
--
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/CAJkCKXu2f%2B_587xdrKK5adsLV2zmXvyxsThuBq5aOX-tnjzq3w%40mail.gmail.com.

Re: How to know in which patch a feature was added

This isn't exactly what you asked for, but how about a custom command, such as Set, that calls a function to do the option set in a try/catch? If it succeeds, great. If it fails, you can just ignore it or use an echomsg or something.

You won't know when a feature was introduced, but you also won't have to have existence checks around everything. 

Salman

On Sun, Jun 18, 2023, 14:29 Tony Mechelynck <antoine.mechelynck@gmail.com> wrote:

On Sun, Jun 18, 2023 at 7:15 PM Enan Ajmain <3nan.ajmain@gmail.com> wrote:
>
> In the beginning, I used a simple vimrc, basically ":se nu", etc.  Those
> features were available in all available Vim installations.  Later when
> I got into tweaking, I used nightly builds of Vim, so I always had the
> latest features.  But nowadays I have to work in a few ssh machines,
> some of which have slightly older versions of Vim.  Which means some of
> my settings emit errors.
>
> The proper way to handle this is with ":has()" and ":exists()".  For
> checking the existence of things like functions, autocommand events,
> variables, etc., they work fine.  Even for options, I can use exists().
> But what about option values?  Let's say I want to set 'wildoptions' to
> use 'popupmenu'.  This was introduced in a late patch of 8.2.  The only
> way I can include this setting with sanity check is by using ":if
> has('patch-8.2.4325')".  The problem is: I had to find the patch number
> by using "git grep --log=pum".
>
> Is there an easier way to find the patch number where an option was
> introduced?  Perhaps with ":helpgrep"?
>
> --
> Enan

See
  :help version5.txt
  :help version6.txt
  :help version7.txt
  :help version8.txt
  :help version9.txt

Each of these begins with a section explaining what was new in version
n.0, then lower down there are a series of sections about versions
n.1, n.2 etc., each containing a series of short paragraphs about each
new patch concerning that section.

I suppose that anything added earlier than version 5.0 can now be
assumed to be "always present". For later features, the simplest is,
as you said, to take advantage, when possible, of the has() and
exists() functions. Only when neither of these gives the clear-cut
result you need, will you have to resort to checking by patch number,
after having searched (possibly with the Normal-mode / command) some
or all of the five helpfiles mentioned above.

Best regards,
Tony.

--
--
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/CAJkCKXsMg_Kk77G785oVt4jXaTFkiUvFWUZ6-4-e5SML08QjGQ%40mail.gmail.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/CANuxnEc55LripVVmdt3BkZRu6h1qu5KPo_4MrR%2BKnEeeCYOQog%40mail.gmail.com.

Re: How to know in which patch a feature was added

On Sun, Jun 18, 2023 at 7:15 PM Enan Ajmain <3nan.ajmain@gmail.com> wrote:
>
> In the beginning, I used a simple vimrc, basically ":se nu", etc. Those
> features were available in all available Vim installations. Later when
> I got into tweaking, I used nightly builds of Vim, so I always had the
> latest features. But nowadays I have to work in a few ssh machines,
> some of which have slightly older versions of Vim. Which means some of
> my settings emit errors.
>
> The proper way to handle this is with ":has()" and ":exists()". For
> checking the existence of things like functions, autocommand events,
> variables, etc., they work fine. Even for options, I can use exists().
> But what about option values? Let's say I want to set 'wildoptions' to
> use 'popupmenu'. This was introduced in a late patch of 8.2. The only
> way I can include this setting with sanity check is by using ":if
> has('patch-8.2.4325')". The problem is: I had to find the patch number
> by using "git grep --log=pum".
>
> Is there an easier way to find the patch number where an option was
> introduced? Perhaps with ":helpgrep"?
>
> --
> Enan

See
:help version5.txt
:help version6.txt
:help version7.txt
:help version8.txt
:help version9.txt

Each of these begins with a section explaining what was new in version
n.0, then lower down there are a series of sections about versions
n.1, n.2 etc., each containing a series of short paragraphs about each
new patch concerning that section.

I suppose that anything added earlier than version 5.0 can now be
assumed to be "always present". For later features, the simplest is,
as you said, to take advantage, when possible, of the has() and
exists() functions. Only when neither of these gives the clear-cut
result you need, will you have to resort to checking by patch number,
after having searched (possibly with the Normal-mode / command) some
or all of the five helpfiles mentioned above.

Best regards,
Tony.

--
--
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/CAJkCKXsMg_Kk77G785oVt4jXaTFkiUvFWUZ6-4-e5SML08QjGQ%40mail.gmail.com.

How to know in which patch a feature was added

In the beginning, I used a simple vimrc, basically ":se nu", etc. Those
features were available in all available Vim installations. Later when
I got into tweaking, I used nightly builds of Vim, so I always had the
latest features. But nowadays I have to work in a few ssh machines,
some of which have slightly older versions of Vim. Which means some of
my settings emit errors.

The proper way to handle this is with ":has()" and ":exists()". For
checking the existence of things like functions, autocommand events,
variables, etc., they work fine. Even for options, I can use exists().
But what about option values? Let's say I want to set 'wildoptions' to
use 'popupmenu'. This was introduced in a late patch of 8.2. The only
way I can include this setting with sanity check is by using ":if
has('patch-8.2.4325')". The problem is: I had to find the patch number
by using "git grep --log=pum".

Is there an easier way to find the patch number where an option was
introduced? Perhaps with ":helpgrep"?

--
Enan

--
--
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/20230618231537.00006e42%40gmail.com.

Re: BUG: terminal vim 9.0.1506 x64 window 10

On Fri, Jun 16, 2023 at 6:28 PM 'Susan McElheny' via vim_use <vim_use@googlegroups.com> wrote:

I have used VI on Unix for over 30 years and now have to use it in Windows where it works much differently.  If I open gVim 9.0 in a GUI session, how do I open another file without having to go to the top with my mouse and select File, Open?  At the command level I can just :vi "filename", but I've been having issues working with VI at the command level - maybe be because it didn't like that I made the window larger as people have just mentioned.

Hopefully a simple question for you experts!

Susan McElheny
Senior Analyst, Data Operations

Apart from the fact that you ought to have started a new thread and not jumped onto any passing thread with an unrelated question:

To open a 2nd (or 3rd, ..., nth) file in a new window in a running Vim or gvim on any OS, just do

     :new filename.ext

or

     :split filename.ext

replacing filename.ext by the desired filename (with path if necessary).

If, instead, you want to _replace_ the file currently being edited by another one in the same window, then do

      :e filename.ext

If the file has modifications, Vim will refuse to wipe it out (unless 'autowriteall' is on, which is not the default): in that case you should either save the file first, or use :e! instead of :e to forget all changes.

See

    :h :new

    :h :split_f

    :h :edit

and also accessorily

    :h 'awa'

    :h ++opt
    :h +cmd

Best regards,

Tony.

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

Re: Change cursor shape in command-line mode

On Sat, 17 Jun 2023 21:05:58 +0100
Bram Moolenaar <Bram@moolenaar.net> wrote:
> Enan Ajmain wrote:
>
> > Vim allows changing cursor shapes according to the current mode: insert,
> > replace, or normal. Vim does this using terminal escape sequences.
> > Details are in ':h termcap-cursor-shape'.
> >
> > I was wondering if I could change the cursor shape in command-line mode.
> > I'm fairly certain it's not possible, but I thought it wouldn't hurt to
> > ask.
>
> You should be able to make this work with the CmdlineEnter and
> CmdlineLeave autocommand events. You can use echoraw() to output the
> terminal codes. As a starting point, this appears to work:
>
> au CmdlineEnter * call echoraw("\<Esc>]12;red\x7")
> au CmdlineLeave * call echoraw("\<Esc>]12;blue\x7")
>

Works perfectly. I thought of using autocommands but didn't know about
"echoraw()". The helpdoc says to use it carefully because it may mess
up the console, but I'll see to it when it happens.

Thank you.

--
Enan

--
--
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/20230618215412.0000493f%40gmail.com.

Re: BUG: terminal vim 9.0.1506 x64 window 10

On Fri, 16 Jun 2023 12:27:59 -0400
"'Susan McElheny' via vim_use" <vim_use@googlegroups.com> wrote:
> I have used VI on Unix for over 30 years and now have to use it in Windows
> where it works much differently. If I open gVim 9.0 in a GUI session, how
> do I open another file without having to go to the top with my mouse and
> select File, Open? At the command level I can just :vi "filename", but
> I've been having issues working with VI at the command level - maybe be
> because it didn't like that I made the window larger as people have just
> mentioned.

Confusing post on two angles:
1. What has opening file got to do with this thread which is about
console corruption in Windows?
2. Where did you find the command ":vi"? I'm guessing it was
available in Vi (not Vim) 30 years ago, but that seems unlikely.

--
Enan

P.S. Upon closer reading, I see that you thought increasing window size
might have had something to do with it, so that explains posting on this
thread. I can say that in Windows GVim, resizing the window shouldn't
cause any problem, specially not problems like removing ex commands.

--
--
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/20230618213556.00005ecf%40gmail.com.

Re: BUG: terminal vim 9.0.1506 x64 window 10

> - start "vim --clean"
> - :set columns=260
> - :term
> - vim --clean somefile
> - ?

Wait, are we saying that we're setting the internal vim 'columns' to something other than the terminal's size? Because if that is the case, I can clearly see an issue is going to be caused when the Terminal does not resize when asked by vim. This definitely does cause problems in Windows Terminal. The window is corrupted and even exiting vim the window has issues as it is still the same size, but the shell reports ColumnsxLines=NEWColumnsxLines and nothing works well after that.

--- 

Should my CPU be smoking?

On Saturday, June 17, 2023 at 7:09:39 PM UTC-6 Steve Martin wrote:

I'm puzzled by this, and have to believe this must be either a terminal problem or some vim plugin interaction with that terminal.

I just used Windows Terminal (Preview to be exact) set to max screen size (2560x1440) and set the font to 6pt. 

That results in terminal Lines x Columns=134x585. Five hundred and eighty five characters across. My old eyes had problems seeing that. Still, nothing untoward happened in VIM. I edited some large files and tried various "command type" things. No problems.

I'm really curious what problems people are having and what is causing it for some and not for others.

BTW: vim v9.0.1637, as I tend to build vim nightly for my regular use. Windows 11.

On Saturday, June 17, 2023 at 2:30:54 PM UTC-6 Robert Solomon wrote:

To be clearer:

Windows 10

My quick testing involved me starting take command and using the mouse to size the window.   Take command shows the window size in the bottom right corner. 

After setting the window  size, I start vim using my _vimrc as I usually do.   I did not change anything from within vim.

On Sat, Jun 17, 2023, 4:06 PM Bram Moolenaar <Br...@moolenaar.net> wrote:

> Quick experimentation indicates that console mode vim fails when width >=
> 250.  But not every time.
>
> I don't think height matters.

OK, so what reproduction steps are required?  I tried this:

- start "vim --clean"
- :set columns=260
- :term
- vim --clean somefile
- ?

I could not make this show any problems.  This might be because I'm
using Linux.  Or:

- What would be the content of "somefile"?  I tried some long (wrapping)
  lines and a few short lines.
- What commands do you use once "somefile" is loaded?  Move the cursor,
  join/split lines, etc.?

I hope you can give an example that is simple and reproduces the problem
consistently.

--
I thought I was eating a crab salad.  It turned out to be a crap salad.

 /// 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/b18efb30-b75f-4f25-8e4a-cf3ece5d4e53n%40googlegroups.com.