Re: Vim Windows binaries are 3 weeks old

2023-04-12 Fir de Conversatie Christian Brabandt


On Mi, 12 Apr 2023, igo...@gmail.com wrote:

> This should be correct link:
> https://github.com/vim/vim-win32-installer/releases/latest
> but it looks like web server automatically rewrites URL to the latest tag, so
> that is why I have got address from previous post.

I have no idea what is going on and don't see why appveyor is no longer 
triggered.


Best,
Christian
-- 
Die Kennworte des Wieners: Wie komm denn i dazu? Es zahlt sich ja net
aus! Tun S' Ihnen nix an!
-- Arthur Schnitzler

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ZDeoSNk70sZmlbwt%40256bit.org.


Re: Vim Windows binaries are 3 weeks old

2023-04-12 Fir de Conversatie igo...@gmail.com
This should be correct link:
https://github.com/vim/vim-win32-installer/releases/latest
but it looks like web server automatically rewrites URL to the latest tag, 
so that is why I have got address from previous post.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5c4674c8-debc-42d6-a70b-1652f611260cn%40googlegroups.com.


Vim Windows binaries are 3 weeks old

2023-04-12 Fir de Conversatie igo...@gmail.com
Vim development binaries for Windows are available almost every day and I 
regularly download them.

Now I have notices that they have not been updated for 3 weeks:
https://github.com/vim/vim-win32-installer/releases/tag/v9.0.1425

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/138474f6-27a6-40db-8eaf-c94b6b9067a1n%40googlegroups.com.


Re: [vim/vim] Not able to convert between byte index and UTF indices (PR #12216)

2023-04-12 Fir de Conversatie Yegappan Lakshmanan
Hi Bram,

On Wed, Apr 12, 2023 at 10:36 AM Bram Moolenaar 
wrote:

>
> Yegappan wrote:
>
> > The language server protocol supports specifying offsets in text
> > documents using UTF-8 or UTF-16 or UTF-32 code units.
> > The UTF-16 code unit is the default.
> >
> >
> https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocuments
> >
> > Different language servers have different levels of support for using
> > the different code units. Vim uses the UTF-32 code units for the
> > offsets. This makes it difficult to support different language
> > servers from a Vim LSP plugin.
> >
> > Port the strutfindex() and strbyteindex() functions from Neovim to
> > support this.
>
> I find the function names hard to read and confusing. We might be able
> to think of better names when the exact functionality is described.
>
> The terminology is confusing. "UTF-32 byte index" contradicts itself,
> since each character is four bytes. I think what is meant is "UTF-32
> encoded character index", which is equal to "character index", since
> there is no Unicode character that takes more than one UTF-32 code
> point.
>
> In Vim all Unicode characters are internally encoded with UTF-8. Thus
> the "{string}" argument of strbyteindex() will be UTF-8 encoded. This
> is also confusing. The help should be clearer about what this means
> exactly. I'm not sure how, saying something like "the character index
> of "{string}" if it would be encoded with UTF-32" makes it complex. I
> think that instead of using "UTF-32 index" we can just use "character
> index", and somewhere mention that "UTF-32" can be considered the same
> (if we need to mention this at all, since the term "UTF-32" isn't widely
> used).
>
> For "UTF-16" it gets more complicated, we can't avoid mentioning that
> the index applies to "{string}" encoded as UTF-16. Looking back UTF-16
> should have never been made a standard IMHO, but it exists and it is
> used (especially on MS-Windows), thus we need to support it.
>
> Conversion between UTF-8 and character index already exists, you can use
> charidx() and byteidx()/byteidxcomp(). Possibly we only need to add
> functions to convert between UTF-8 and UTF-16 indexes? Or between
> character (UTF-32) and UTF-16 indexes? The latter makes more sense.
>

What about introducing a function that converts a character index in a
string
to a UTF-16 index?

utf16idx({string}, {idx} [, {countcc}])

This is similar to the existing charidx() function.  The "idx" here
specifies
the character index in {string} and this function returns the corresponding
UTF-16 index.

To convert from a UTF-16 index to a character index, we can either introduce
a new function or modify the existing charidx() function to accept an
additional
boolean argument.  If this argument is specified, then {idx} is a UTF-16
index
instead of a byte index.  If we are going with a new function for this, what
do you think about naming the function as utf16tocharidx()?

- Yegappan


>
> It should also be possible to specify the handling of composing
> characters. Either as an argument, like with charidx(), or using
> separate functions, as with byteidx()/byteidxcomp().
>
>
>

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAAW7x7nCgUDw80Z-kVdd1Z95N%2B1CHX9uhffYhBGihdqx8pMOJA%40mail.gmail.com.


Re: Finding the Motif libs

2023-04-12 Fir de Conversatie Tony Mechelynck
On Wed, Apr 12, 2023 at 6:09 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > > > According to the YaST installer, openSUSE Tumbleweed package libXm4
> > > > titled "Motif runtime library" installs (only) files
> > > > /usr/lib64/libXm.so.4 and /usr/lib64/libXm.so.4.0.4
> > > >
> > > > so I did
> > > >
> > > > pushd /usr/lib64
> > > > ls -l libXm*
> > > >
> > > > which answered
> > > >
> > > > lrwxrwxrwx 1 root root  14 Mar 19 23:38 libXm.so -> libXm.so.4.0.4
> > > > lrwxrwxrwx 1 root root  14 Mar 19 23:38 libXm.so.4 -> libXm.so.4.0.4
> > > > -rwxr-xr-x 1 root root 3021784 Mar 19 23:38 libXm.so.4.0.4
> > > > lrwxrwxrwx 1 root root  15 Mar 19 23:28 libXmu.so -> libXmu.so.6.2.0
> > > > lrwxrwxrwx 1 root root  15 Mar 19 23:28 libXmu.so.6 -> 
> > > > libXmu.so.6.2.0
> > > > -rwxr-xr-x 1 root root  113936 Mar 19 23:28 libXmu.so.6.2.0
> > > > lrwxrwxrwx 1 root root  16 Mar 19 23:28 libXmuu.so -> 
> > > > libXmuu.so.1.0.0
> > > > lrwxrwxrwx 1 root root  16 Mar 19 23:28 libXmuu.so.1 -> 
> > > > libXmuu.so.1.0.0
> > > > -rwxr-xr-x 1 root root   22568 Mar 19 23:28 libXmuu.so.1.0.0
> > > >
> > > > I think only the first three lines in this list are relevant. IOW on
> > > > my system there are three files answering to /usr/lib64/libXm.so* in
> > > > your list, two of which are soft links to the third one. IIUC by
> > > > giving configure the argument --with-motif-lib=-lXm it doesn't search
> > > > for the lib but just passes -lXm to the linker, which finds
> > > > /usr/lib64/libXm.so -> libXm.so.4.0.4 and happily uses that (as it
> > > > should) to find the Motif entry points.
> > >
> > > So perhaps it's because configure doesn't check /usr/lib64, and the
> > > library was moved there recently?  You can try by editing
> > > src/auto/configure and around line 10221; add "/usr/lib64" before
> > > "/usr/lib/i386-linux-gnu" in the assignment to "gui_libs".
> > >
> > AFAIK on openSUSE /usr/lib has always been the 32-bit library (here
> > with interfaces for 32-bit executables running on this 64-bit system)
> > and /usr/lib64 the "purely" 64-bit library.
>
> Please try with patch 9.0.1445.  Hopefully it works without any special
> arguments now.

As I come back to the computer, the source is at patchlevel 9.0.1447
and the Motif libs are found even with no --with-motif-lib= argument
(and a "make reconfig").

Problem solved.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAJkCKXtiqiHXUvJsjVW7E8aBvpBvxE4HdoetFc2%2Bmm0sG2xmGw%40mail.gmail.com.


Patch 9.0.1447

2023-04-12 Fir de Conversatie Bram Moolenaar


Patch 9.0.1447
Problem:Condition is always true.
Solution:   Remove the useless condition. (closes #12253)
Files:  src/evalvars.c


*** ../vim-9.0.1446/src/evalvars.c  2023-03-07 17:13:47.309107774 +
--- src/evalvars.c  2023-04-12 21:32:17.133942782 +0100
***
*** 989,995 
  char_u*arg = eap->arg;
  char_u*expr = NULL;
  typval_T  rettv;
- int   i;
  int   var_count = 0;
  int   semicolon = 0;
  char_uop[4];
--- 989,994 
***
*** 1067,1074 
list_vim_vars(&first);
}
set_nextcmd(eap, arg);
  }
! else if (expr[0] == '=' && expr[1] == '<' && expr[2] == '<')
  {
list_T  *l = NULL;
longcur_lnum = SOURCING_LNUM;
--- 1066,1075 
list_vim_vars(&first);
}
set_nextcmd(eap, arg);
+   return;
  }
! 
! if (expr[0] == '=' && expr[1] == '<' && expr[2] == '<')
  {
list_T  *l = NULL;
longcur_lnum = SOURCING_LNUM;
***
*** 1096,1172 
}
clear_tv(&rettv);
}
  }
- else
- {
-   evalarg_T   evalarg;
-   int len = 1;
  
!   CLEAR_FIELD(rettv);
!   i = FAIL;
!   if (has_assign || concat)
!   {
!   int cur_lnum;
  
!   op[0] = '=';
!   op[1] = NUL;
!   if (*expr != '=')
!   {
!   if (vim9script && (flags & ASSIGN_NO_DECL) == 0)
!   {
!   // +=, /=, etc. require an existing variable
!   semsg(_(e_cannot_use_operator_on_new_variable_str),
!eap->arg);
!   }
!   else if (vim_strchr((char_u *)"+-*/%.", *expr) != NULL)
!   {
!   op[0] = *expr;   // +=, -=, *=, /=, %= or .=
!   ++len;
!   if (expr[0] == '.' && expr[1] == '.') // ..=
!   {
!   ++expr;
!   ++len;
!   }
!   }
!   expr += 2;
!   }
!   else
!   ++expr;
  
!   if (vim9script && !eap->skip && (!VIM_ISWHITE(*argend)
!  || !IS_WHITE_OR_NUL(*expr)))
!   {
!   vim_strncpy(op, expr - len, len);
!   semsg(_(e_white_space_required_before_and_after_str_at_str),
!  op, argend);
!   }
  
!   if (eap->skip)
!   ++emsg_skip;
!   fill_evalarg_from_eap(&evalarg, eap, eap->skip);
!   expr = skipwhite_and_linebreak(expr, &evalarg);
!   cur_lnum = SOURCING_LNUM;
!   i = eval0(expr, &rettv, eap, &evalarg);
!   if (eap->skip)
!   --emsg_skip;
!   clear_evalarg(&evalarg, eap);
! 
!   // Restore the line number so that any type error is given for the
!   // declaration, not the expression.
!   SOURCING_LNUM = cur_lnum;
!   }
!   if (eap->skip)
{
!   if (i != FAIL)
!   clear_tv(&rettv);
}
!   else if (i != FAIL)
{
!   (void)ex_let_vars(eap->arg, &rettv, FALSE, semicolon, var_count,
!   flags, op);
!   clear_tv(&rettv);
}
  }
  }
  
  /*
--- 1097,1163 
}
clear_tv(&rettv);
}
+   return;
  }
  
! evalarg_T   evalarg;
! int   len = 1;
  
! CLEAR_FIELD(rettv);
  
! int cur_lnum;
  
! op[0] = '=';
! op[1] = NUL;
! if (*expr != '=')
! {
!   if (vim9script && (flags & ASSIGN_NO_DECL) == 0)
{
!   // +=, /=, etc. require an existing variable
!   semsg(_(e_cannot_use_operator_on_new_variable_str), eap->arg);
}
!   else if (vim_strchr((char_u *)"+-*/%.", *expr) != NULL)
{
!   op[0] = *expr;   // +=, -=, *=, /=, %= or .=
!   ++len;
!   if (expr[0] == '.' && expr[1] == '.') // ..=
!   {
!   ++expr;
!   ++len;
!   }
}
+   expr += 2;
  }
+ else
+   ++expr;
+ 
+ if (vim9script && !eap->skip && (!VIM_ISWHITE(*argend)
+  || !IS_WHITE_OR_NUL(*expr)))
+ {
+   vim_strncpy(op, expr - len, len);
+   semsg(_(e_white_space_required_before_and_after_str_at_str),
+  op, argend);
+ }
+ 
+ if (eap->skip)
+   ++emsg_skip;
+ fill_evalarg_from_eap(&evalarg, eap, eap->skip);
+ expr = skipwhite_and_linebreak(expr, &evalarg);
+ cur_lnum = SOURCING_LNUM;
+ int eval_res = eval0(expr, &rettv, eap, &evalarg);
+ if (eap->skip)
+   --emsg_skip;
+ clear_evala

Patch 9.0.1446

2023-04-12 Fir de Conversatie Bram Moolenaar


Patch 9.0.1446
Problem:Unnecessary checks for the "skip" flag when skipping.
Solution:   Remove the unnecessary checks. (closes #12254)
Files:  src/userfunc.c


*** ../vim-9.0.1445/src/userfunc.c  2023-03-07 17:45:07.192247897 +
--- src/userfunc.c  2023-04-12 20:45:40.423830416 +0100
***
*** 5868,5873 
--- 5868,5876 
  clear_evalarg(&evalarg, eap);
  }
  
+ /*
+  * Lower level implementation of "call".  Only called when not skipping.
+  */
  static int
  ex_call_inner(
exarg_T *eap,
***
*** 5882,5905 
  typval_T  rettv;
  int   failed = FALSE;
  
! /*
!  * When skipping, evaluate the function once, to find the end of the
!  * arguments.
!  * When the function takes a range, this is discovered after the first
!  * call, and the loop is broken.
!  */
! if (eap->skip)
! {
!   ++emsg_skip;
!   lnum = eap->line2;  // do it once, also with an invalid range
! }
! else
!   lnum = eap->line1;
  for ( ; lnum <= eap->line2; ++lnum)
  {
funcexe_T funcexe;
  
!   if (!eap->skip && eap->addr_count > 0)
{
if (lnum > curbuf->b_ml.ml_line_count)
{
--- 5885,5896 
  typval_T  rettv;
  int   failed = FALSE;
  
! lnum = eap->line1;
  for ( ; lnum <= eap->line2; ++lnum)
  {
funcexe_T funcexe;
  
!   if (eap->addr_count > 0)
{
if (lnum > curbuf->b_ml.ml_line_count)
{
***
*** 5927,5940 
  
// Handle a function returning a Funcref, Dictionary or List.
if (handle_subscript(arg, NULL, &rettv,
!  eap->skip ? NULL : &EVALARG_EVALUATE, TRUE) == FAIL)
{
failed = TRUE;
break;
}
  
clear_tv(&rettv);
!   if (doesrange || eap->skip)
break;
  
// Stop when immediately aborting on error, or when an interrupt
--- 5918,5931 
  
// Handle a function returning a Funcref, Dictionary or List.
if (handle_subscript(arg, NULL, &rettv,
! &EVALARG_EVALUATE, TRUE) == FAIL)
{
failed = TRUE;
break;
}
  
clear_tv(&rettv);
!   if (doesrange)
break;
  
// Stop when immediately aborting on error, or when an interrupt
***
*** 5944,5951 
if (aborting())
break;
  }
- if (eap->skip)
-   --emsg_skip;
  return failed;
  }
  
--- 5935,5940 
***
*** 6185,6191 
return;
  }
  
! tofree = trans_function_name_ext(&arg, NULL, eap->skip, TFN_INT,
 &fudi, &partial, vim9script ? &type : NULL, NULL);
  if (fudi.fd_newkey != NULL)
  {
--- 6174,6180 
return;
  }
  
! tofree = trans_function_name_ext(&arg, NULL, FALSE, TFN_INT,
 &fudi, &partial, vim9script ? &type : NULL, NULL);
  if (fudi.fd_newkey != NULL)
  {
***
*** 6239,6245 
funcexe.fe_firstline = eap->line1;
funcexe.fe_lastline = eap->line2;
funcexe.fe_found_var = found_var;
!   funcexe.fe_evaluate = !eap->skip;
failed = ex_call_inner(eap, name, &arg, startarg, &funcexe, &evalarg);
  }
  
--- 6228,6234 
funcexe.fe_firstline = eap->line1;
funcexe.fe_lastline = eap->line2;
funcexe.fe_found_var = found_var;
!   funcexe.fe_evaluate = TRUE;
failed = ex_call_inner(eap, name, &arg, startarg, &funcexe, &evalarg);
  }
  
*** ../vim-9.0.1445/src/version.c   2023-04-12 16:23:59.460592878 +0100
--- src/version.c   2023-04-12 20:44:37.943880498 +0100
***
*** 697,698 
--- 697,700 
  {   /* Add new patch number below this line */
+ /**/
+ 1446,
  /**/

-- 
ARTHUR: Go on, Bors, chop its head off.
BORS:   Right.  Silly little bleeder.  One rabbit stew coming up.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@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_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/20230412194848.18C501C0F2A%40moolenaar.net.


Re: Finding the Motif libs

2023-04-12 Fir de Conversatie Bram Moolenaar


Tony wrote:

> > > According to the YaST installer, openSUSE Tumbleweed package libXm4
> > > titled "Motif runtime library" installs (only) files
> > > /usr/lib64/libXm.so.4 and /usr/lib64/libXm.so.4.0.4
> > >
> > > so I did
> > >
> > > pushd /usr/lib64
> > > ls -l libXm*
> > >
> > > which answered
> > >
> > > lrwxrwxrwx 1 root root  14 Mar 19 23:38 libXm.so -> libXm.so.4.0.4
> > > lrwxrwxrwx 1 root root  14 Mar 19 23:38 libXm.so.4 -> libXm.so.4.0.4
> > > -rwxr-xr-x 1 root root 3021784 Mar 19 23:38 libXm.so.4.0.4
> > > lrwxrwxrwx 1 root root  15 Mar 19 23:28 libXmu.so -> libXmu.so.6.2.0
> > > lrwxrwxrwx 1 root root  15 Mar 19 23:28 libXmu.so.6 -> libXmu.so.6.2.0
> > > -rwxr-xr-x 1 root root  113936 Mar 19 23:28 libXmu.so.6.2.0
> > > lrwxrwxrwx 1 root root  16 Mar 19 23:28 libXmuu.so -> libXmuu.so.1.0.0
> > > lrwxrwxrwx 1 root root  16 Mar 19 23:28 libXmuu.so.1 -> 
> > > libXmuu.so.1.0.0
> > > -rwxr-xr-x 1 root root   22568 Mar 19 23:28 libXmuu.so.1.0.0
> > >
> > > I think only the first three lines in this list are relevant. IOW on
> > > my system there are three files answering to /usr/lib64/libXm.so* in
> > > your list, two of which are soft links to the third one. IIUC by
> > > giving configure the argument --with-motif-lib=-lXm it doesn't search
> > > for the lib but just passes -lXm to the linker, which finds
> > > /usr/lib64/libXm.so -> libXm.so.4.0.4 and happily uses that (as it
> > > should) to find the Motif entry points.
> >
> > So perhaps it's because configure doesn't check /usr/lib64, and the
> > library was moved there recently?  You can try by editing
> > src/auto/configure and around line 10221; add "/usr/lib64" before
> > "/usr/lib/i386-linux-gnu" in the assignment to "gui_libs".
> >
> AFAIK on openSUSE /usr/lib has always been the 32-bit library (here
> with interfaces for 32-bit executables running on this 64-bit system)
> and /usr/lib64 the "purely" 64-bit library.

Please try with patch 9.0.1445.  Hopefully it works without any special
arguments now.


-- 
Save the plankton - eat a whale.

 /// Bram Moolenaar -- b...@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_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/20230412160942.EFA351C0F2A%40moolenaar.net.


Patch 9.0.1445

2023-04-12 Fir de Conversatie Bram Moolenaar


Patch 9.0.1445
Problem:openSUSE: configure doesn't find the Motif library. (Tony
Mechelynck)
Solution:   Also search in /usr/lib64.
Files:  src/configure.ac, src/auto/configure


*** ../vim-9.0.1444/src/configure.ac2023-04-05 18:24:46.140030379 +0100
--- src/configure.ac2023-04-11 22:08:03.801018102 +0100
***
*** 2976,2983 
  dnl Ubuntu has libXm.so in /usr/lib/i386-linux-gnu and elsewhere.  The
  dnl linker will figure out which one to use, we only check if one exists.
  dnl Cygwin uses the .dll.a extension.
  AC_MSG_CHECKING(for location of Motif GUI libs)
! gui_libs="`echo $x_libraries|sed 's%/[^/][^/]*$%%'` `echo "$gui_XXX" | 
sed s/XXX/lib/g` /usr/lib/i386-linux-gnu /usr/lib/x86_64-linux-gnu `echo 
"$GUI_INC_LOC" | sed s/include/lib/` $GUI_LIB_LOC"
  GUI_LIB_LOC=
  for try in $gui_libs; do
for libtry in "$try"/libXm.a "$try"/libXm.dll.a "$try"/libXm.so* 
"$try"/libXm.sl "$try"/libXm.dylib; do
--- 2976,2984 
  dnl Ubuntu has libXm.so in /usr/lib/i386-linux-gnu and elsewhere.  The
  dnl linker will figure out which one to use, we only check if one exists.
  dnl Cygwin uses the .dll.a extension.
+ dnl OpenSUSE appears to use /usr/lib64.
  AC_MSG_CHECKING(for location of Motif GUI libs)
! gui_libs="`echo $x_libraries|sed 's%/[^/][^/]*$%%'` `echo "$gui_XXX" | 
sed s/XXX/lib/g` /usr/lib64 /usr/lib/i386-linux-gnu /usr/lib/x86_64-linux-gnu 
`echo "$GUI_INC_LOC" | sed s/include/lib/` $GUI_LIB_LOC"
  GUI_LIB_LOC=
  for try in $gui_libs; do
for libtry in "$try"/libXm.a "$try"/libXm.dll.a "$try"/libXm.so* 
"$try"/libXm.sl "$try"/libXm.dylib; do
***
*** 2987,2994 
done
  done
  if test -n "$GUI_LIB_LOC"; then
!   dnl Remove /usr/lib, it causes trouble on some systems
if test "$GUI_LIB_LOC" = /usr/lib \
   -o "$GUI_LIB_LOC" = /usr/lib/i386-linux-gnu \
   -o "$GUI_LIB_LOC" = /usr/lib/x86_64-linux-gnu; then
GUI_LIB_LOC=
--- 2988,2997 
done
  done
  if test -n "$GUI_LIB_LOC"; then
!   dnl Remove /usr/lib, it causes trouble on some systems.
!   dnl For consistency also remove other standard lib directories.
if test "$GUI_LIB_LOC" = /usr/lib \
+  -o "$GUI_LIB_LOC" = /usr/lib64 \
   -o "$GUI_LIB_LOC" = /usr/lib/i386-linux-gnu \
   -o "$GUI_LIB_LOC" = /usr/lib/x86_64-linux-gnu; then
GUI_LIB_LOC=
*** ../vim-9.0.1444/src/auto/configure  2023-04-05 18:24:46.144030386 +0100
--- src/auto/configure  2023-04-12 16:23:19.360688274 +0100
***
*** 10216,10224 
  
  GUI_LIB_LOC="`echo $GUI_LIB_LOC|sed 's%-L%%g'`"
  
! { $as_echo "$as_me:${as_lineno-$LINENO}: checking for 
location of Motif GUI libs" >&5
  $as_echo_n "checking for location of Motif GUI libs... " >&6; }
! gui_libs="`echo $x_libraries|sed 's%/^/^/*$%%'` `echo "$gui_XXX" | sed 
s/XXX/lib/g` /usr/lib/i386-linux-gnu /usr/lib/x86_64-linux-gnu `echo 
"$GUI_INC_LOC" | sed s/include/lib/` $GUI_LIB_LOC"
  GUI_LIB_LOC=
  for try in $gui_libs; do
for libtry in "$try"/libXm.a "$try"/libXm.dll.a "$try"/libXm.so* 
"$try"/libXm.sl "$try"/libXm.dylib; do
--- 10216,10224 
  
  GUI_LIB_LOC="`echo $GUI_LIB_LOC|sed 's%-L%%g'`"
  
! { $as_echo "$as_me:${as_lineno-$LINENO}: checking for 
location of Motif GUI libs" >&5
  $as_echo_n "checking for location of Motif GUI libs... " >&6; }
! gui_libs="`echo $x_libraries|sed 's%/^/^/*$%%'` `echo "$gui_XXX" | sed 
s/XXX/lib/g` /usr/lib64 /usr/lib/i386-linux-gnu /usr/lib/x86_64-linux-gnu `echo 
"$GUI_INC_LOC" | sed s/include/lib/` $GUI_LIB_LOC"
  GUI_LIB_LOC=
  for try in $gui_libs; do
for libtry in "$try"/libXm.a "$try"/libXm.dll.a "$try"/libXm.so* 
"$try"/libXm.sl "$try"/libXm.dylib; do
***
*** 10228,10234 
done
  done
  if test -n "$GUI_LIB_LOC"; then
! if test "$GUI_LIB_LOC" = /usr/lib \
   -o "$GUI_LIB_LOC" = /usr/lib/i386-linux-gnu \
   -o "$GUI_LIB_LOC" = /usr/lib/x86_64-linux-gnu; then
GUI_LIB_LOC=
--- 10228,10235 
done
  done
  if test -n "$GUI_LIB_LOC"; then
!   if test "$GUI_LIB_LOC" = /usr/lib \
!  -o "$GUI_LIB_LOC" = /usr/lib64 \
   -o "$GUI_LIB_LOC" = /usr/lib/i386-linux-gnu \
   -o "$GUI_LIB_LOC" = /usr/lib/x86_64-linux-gnu; then
GUI_LIB_LOC=
*** ../vim-9.0.1444/src/version.c   2023-04-12 16:21:11.037023796 +0100
--- src/version.c   2023-04-12 16:23:15.068698732 +0100
***
*** 697,698 
--- 697,700 
  {   /* Add new patch number below this line */
+ /**/
+ 1445,
  /**/

-- 
TIM:Too late.
ARTHUR: What?
TIM:There he is!
   [They all turn, and see a large white RABBIT lollop a few yards out of the
   cave.  Accompanied by terrifying chord and jarring metallic monster noise.]
 "Monty P