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+unsubscr...@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 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20230619011433.7b82%40gmail.com.
Re: How to know in which patch a feature was added
On Sun, Jun 18, 2023 at 8:40 PM 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.
>
> 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+unsubscr...@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+unsubscr...@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
wrote:
> On Sun, Jun 18, 2023 at 7:15 PM Enan Ajmain <3nan.ajm...@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+unsubscr...@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+unsubscr...@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.ajm...@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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_use/20230618231537.6e42%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+unsubscr...@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 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("\]12;red\x7")
> au CmdlineLeave * call echoraw("\]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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_use/20230618215412.493f%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" 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20230618213556.5ecf%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 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+unsubscr...@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.
