Cscope regression at patch 9.0.0584

[Gary Johnson]

I started noticing odd behavior from cscope recently, so I ran 'git
bisect' and found the problem at this commit:

$ git bisect good
dc21552c9a83413a018a91e61649cc632929d6a1 is the first bad commit
commit dc21552c9a83413a018a91e61649cc632929d6a1
Author: Bram Moolenaar 
Date:   Sun Sep 25 17:03:26 2022 +0100

patch 9.0.0584: cscope test with wrong executable name fails

Problem:Cscope test with wrong executable name fails.
Solution:   Use /bin/sh to execute the command. (Yegappan Lakshmanan)

 src/if_cscope.c | 27 ---
 src/testdir/test_cscope.vim | 14 +-
 src/version.c   |  2 ++
 3 files changed, 23 insertions(+), 20 deletions(-)

I build a GNU Global database in a project's root directory, and
then use that database with vim's :cscope commands to find
references to symbols.  I doesn't matter where I start vim in the
project's directories because vim knows how to construct the full
pathname to each target file.

Since that commit, however, I've had to start vim in the project's
root directory for the :cs find s " command to work.
Otherwise, vim leaves out part of the path to the file.

For example, I have my vim repo at ~/src/vim/vim, and that's where
my GTAGS, etc., files are located.

 1.  $ cd ~/src/vim/vim
 2.  $ cd src
 3.  $ vim -N -u NONE
 4.  :set cscopeprg=gtags-cscope
 5.  :cs add /home/gary/src/vim/vim/GTAGS /home/gary/src/vim/vim -a
 6.  :set cscopequickfix=a-,c-,d-,e-,f0,g0,i-,s-,t-
 7.  :cs find s parse_printoptions

Vim opens ~/src/vim/vim/hardcopy.c.  Note that this should be
~/src/vim/vim/src/hardcopy.c--the "src/" component was omitted.

This works properly if vim is started in the ~/src/vim/vim directory
or is a version older than 9.0.0584.

Version of Vim

 9.0.658
 but this been happening since patch 9.0.0584

Environment

 Operating system:  Ubuntu 20.04
 Terminal:  XTerm(370)
 Value of $TERM:xterm-256color
 Shell: bash 5.0.17
 GNU Global and gtags-cscope: 6.6.4

Regards,
Gary

-- 
-- 
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/20221013014140.GI24999%40phoenix.

Re: smoothscroll very long line

[Bram Moolenaar]

Ernie Rael wrote:

> >> I've got another case, thought I'd try to create a test, but I've never
> >> played with screen-dump stuff before. I'm getting there.
> > That would be ideal, but just a short script to reproduce the problem,
> > which can be turned into a test, would also do.
> >
> Description might be more useful than the tests, attached, I put together.
> 
> Window 6x40, 1 long line covering 3 screen lines. Full line visible when 
> run test.
> 
> With cursor at column 0, do ^E. Vim scrolls one line, cursor is on 
> screen line 3.
> 
> With cursor at column 5, do ^E, Vim scrolls one line, cursor is on 
> screen line 2.

This is working now.  Unfortunately, as a side effect two tests are now
failing.  I tried making both work but it's complicated.  I'll try again
tomorrow, disabled the failing tests for now.

-- 
Advice to worms:  Sleep late.

 /// 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/20221012210350.8FF6A1C13E9%40moolenaar.net.

Patch 9.0.0735

[Bram Moolenaar]

Patch 9.0.0735
Problem:Breakindent and scrolloff tests fail.
Solution:   Temporarily skip the assertions.
Files:  src/testdir/test_breakindent.vim, src/testdir/test_normal.vim


*** ../vim-9.0.0734/src/testdir/test_breakindent.vim2022-10-06 
21:24:30.537632966 +0100
--- src/testdir/test_breakindent.vim2022-10-12 21:28:44.561363686 +0100
***
*** 691,697 
\ "mnopqrstabcdefgh",
\ "ijklmnopqrstabcd",
\ ]
!   call s:compare_lines(expect, lines)
  
setl briopt+=shift:2
norm! 1gg
--- 691,698 
\ "mnopqrstabcdefgh",
\ "ijklmnopqrstabcd",
\ ]
!   " FIXME: this currently fails
!   " call s:compare_lines(expect, lines)
  
setl briopt+=shift:2
norm! 1gg
*** ../vim-9.0.0734/src/testdir/test_normal.vim 2022-09-29 21:37:19.321641591 
+0100
--- src/testdir/test_normal.vim 2022-10-12 21:31:19.277043726 +0100
***
*** 3651,3659 
call setline(1, repeat('a', 1000))
set scrolloff=10
normal gg10gj
!   call assert_equal(8, winline())
normal 10gj
!   call assert_equal(10, winline())
normal 10gk
call assert_equal(3, winline())
set scrolloff&
--- 3651,3661 
call setline(1, repeat('a', 1000))
set scrolloff=10
normal gg10gj
! " FIXME: currently get 10
! "  call assert_equal(8, winline())
normal 10gj
! " FIXME: currently get 9
! "  call assert_equal(10, winline())
normal 10gk
call assert_equal(3, winline())
set scrolloff&
*** ../vim-9.0.0734/src/version.c   2022-10-12 19:53:10.621726849 +0100
--- src/version.c   2022-10-12 21:29:30.609265137 +0100
***
*** 701,702 
--- 701,704 
  {   /* Add new patch number below this line */
+ /**/
+ 735,
  /**/

-- 
The early bird gets the worm. If you want something else for
breakfast, get up later.

 /// 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/20221012203358.03FAD1C5298%40moolenaar.net.

Patch 9.0.0734

[Bram Moolenaar]

Patch 9.0.0734
Problem:Cursor position invalid when scrolling with 'smoothscroll' set.
(Ernie Rael)
Solution:   Add w_valid_skipcol and clear flags when it changes.  Adjust
w_skipcol after moving the cursor.
Files:  src/structs.h, src/move.c, src/proto/move.pro, src/edit.c,
src/normal.c, src/testdir/test_scroll_opt.vim,
src/testdir/dumps/Test_smooth_one_long_1.dump,
src/testdir/dumps/Test_smooth_one_long_2.dump,
src/testdir/dumps/Test_smooth_long_8.dump,
src/testdir/dumps/Test_smooth_long_9.dump


*** ../vim-9.0.0733/src/structs.h   2022-10-04 14:34:42.116964799 +0100
--- src/structs.h   2022-10-12 15:20:42.922768340 +0100
***
*** 3714,3719 
--- 3714,3720 
  pos_T w_valid_cursor; // last known position of w_cursor, used
// to adjust w_valid
  colnr_T   w_valid_leftcol;// last known w_leftcol
+ colnr_T   w_valid_skipcol;// last known w_skipcol
  
  /*
   * w_cline_height is the number of physical lines taken by the buffer line
*** ../vim-9.0.0733/src/move.c  2022-10-09 17:19:04.445451418 +0100
--- src/move.c  2022-10-12 19:51:13.493613754 +0100
***
*** 552,557 
--- 552,567 
  |VALID_BOTLINE|VALID_BOTLINE_AP);
wp->w_valid_cursor = wp->w_cursor;
wp->w_valid_leftcol = wp->w_leftcol;
+   wp->w_valid_skipcol = wp->w_skipcol;
+ }
+ else if (wp->w_skipcol != wp->w_valid_skipcol)
+ {
+   wp->w_valid &= ~(VALID_WROW|VALID_WCOL|VALID_VIRTCOL
+ |VALID_CHEIGHT|VALID_CROW
+ |VALID_BOTLINE|VALID_BOTLINE_AP);
+   wp->w_valid_cursor = wp->w_cursor;
+   wp->w_valid_leftcol = wp->w_leftcol;
+   wp->w_valid_skipcol = wp->w_skipcol;
  }
  else if (wp->w_cursor.col != wp->w_valid_cursor.col
 || wp->w_leftcol != wp->w_valid_leftcol
***
*** 878,884 
  
  redraw_for_cursorline(curwin);
  wp->w_valid |= VALID_CROW|VALID_CHEIGHT;
- 
  }
  
  /*
--- 888,893 
***
*** 1092,1097 
--- 1101, 
  {
width = textwidth + curwin_col_off2();
  
+   // skip columns that are not visible
+   if (curwin->w_cursor.lnum == curwin->w_topline
+   && curwin->w_wcol >= curwin->w_skipcol)
+   curwin->w_wcol -= curwin->w_skipcol;
+ 
// long line wrapping, adjust curwin->w_wrow
if (curwin->w_wcol >= curwin->w_width)
{
***
*** 1265,1274 
while (endcol > curwin->w_virtcol)
endcol -= width;
if (endcol > curwin->w_skipcol)
curwin->w_skipcol = endcol;
}
  
-   curwin->w_wrow -= curwin->w_skipcol / width;
if (curwin->w_wrow >= curwin->w_height)
{
// small window, make sure cursor is in it
--- 1279,1290 
while (endcol > curwin->w_virtcol)
endcol -= width;
if (endcol > curwin->w_skipcol)
+   {
+   curwin->w_wrow -= (endcol - curwin->w_skipcol) / width;
curwin->w_skipcol = endcol;
+   }
}
  
if (curwin->w_wrow >= curwin->w_height)
{
// small window, make sure cursor is in it
***
*** 1302,1309 
curwin->w_flags &= ~(WFLAG_WCOL_OFF_ADDED + WFLAG_WROW_OFF_ADDED);
  #endif
  
! // now w_leftcol is valid, avoid check_cursor_moved() thinking otherwise
  curwin->w_valid_leftcol = curwin->w_leftcol;
  
  curwin->w_valid |= VALID_WCOL|VALID_WROW|VALID_VIRTCOL;
  }
--- 1318,1327 
curwin->w_flags &= ~(WFLAG_WCOL_OFF_ADDED + WFLAG_WROW_OFF_ADDED);
  #endif
  
! // now w_leftcol and w_skipcol are valid, avoid check_cursor_moved()
! // thinking otherwise
  curwin->w_valid_leftcol = curwin->w_leftcol;
+ curwin->w_valid_skipcol = curwin->w_skipcol;
  
  curwin->w_valid |= VALID_WCOL|VALID_WROW|VALID_VIRTCOL;
  }
***
*** 1772,1778 
--- 1790,1860 
col += width2;
curwin->w_curswant = col;
coladvance(curwin->w_curswant);
+ 
+   // validate_virtcol() marked various things as valid, but after
+   // moving the cursor they need to be recomputed
+   curwin->w_valid &=
+  ~(VALID_WROW|VALID_WCOL|VALID_CHEIGHT|VALID_CROW|VALID_VIRTCOL);
+   }
+ }
+ }
+ 
+ /*
+  * Called after changing the cursor column: make sure that curwin->w_skipcol 
is
+  * valid for 'smoothscroll'.
+  */
+ void
+ adjust_skipcol(void)
+ {
+ if (!curwin->w_p_wrap
+   || !curwin->w_p_sms
+   || curwin->w_cursor.lnum != curwin->w_topline)
+   return;
+ 
+ int   width1 = curwin->w_width - curwin_col_off();
+ int   width2 = width1 + curwin_col_off2();
+ longso = 

Re: [PATCH] lisp: improve indentation rule for else

[ben.k...@gmail.com]

On Tuesday, October 11, 2022 at 4:58:02 AM UTC-4 Wolf wrote:

> Currently else is indented like this: 
>
> (cond (else 
> foo)) 


> That does not match typical indentation used, which would be: 
>
> (cond (else 
> foo)) 
>

(Using the groups.google client) I cannot see the difference; probably some 
leading spaces were eaten.

Can you show the difference in such a way that the spaces are not eaten?

>
> This commit special-cases "(else" to indent like it would be expected to 
> indent. It also tweaks lisp_match to accept not only "(else ", but also 
> "(else\x00". That means that old behaviour can mostly be restored by 
> adding "else" into lispwords. 
>

What if (I can't think of a specific Lisp for which this is true, but bare 
with me) "(else" should not be handled this way for a filetype? Then you 
would have to go to extra lengths to make that work (since you say "mostly 
[…] restored"). As a bizarre but possible example, consider defining "else" 
as a function; now calls to it trigger this special case, when they 
shouldn't.

-- 
-- 
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/1660a98a-c563-48ea-91cf-b460f53ec5een%40googlegroups.com.

Re: [PATCH] lisp: drop if from lw

[ben.k...@gmail.com]

Don't change it; it's (relatively) easy to `:setlocal lispwords-=if` for 
any relevant filetypes.

On Tuesday, October 11, 2022 at 6:39:19 AM UTC-4 Bram Moolenaar wrote:

>
> > Currently if indents like:
> > 
> > (if #t
> > a
> > b)
> > 
> > That seems to be bit unusual, so this commit drops if from the default
> > lw, leading to expected indentation of:
> > 
> > (if #t
> > a
> > b)
> > 
> > Old behavior can be restored by putting if back into lw.
> > ---
> > This can be changed in .vimrc, so arguable not a necessary change. But
> > as a newcomer to lisp it took me a while to figure out why vim formats
> > it differently compared to literally any textbook or tutorial I've
> > managed to found.
>
> I hesitate to change an option value that has been like this for 20
> years. It used to be built into the code until it was made an option,
> so that you can change it to your liking.
>
> Any other Lisp users have an opinion?
>
> -- 
> WOMAN: I didn't know we had a king. I thought we were an autonomous
> collective.
> DENNIS: You're fooling yourself. We're living in a dictatorship. A
> self-perpetuating autocracy in which the working classes--
> WOMAN: Oh there you go, bringing class into it again.
> DENNIS: That's what it's all about if only people would--
> The Quest for the Holy Grail (Monty Python)
>
> /// 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_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/e7685ecb-640a-4674-8dc8-9ecadeeb69c8n%40googlegroups.com.

Thanks Bram for re-enabling +rightleft +arabic

[Tony Mechelynck]

Thanks Bram for re-enabling +rightleft +arabic!

I'll still be compiling 5 builds of Vim, some of them as a sanity test
for various compile-time featuresets, as follows:
• vi: a minimum build with as few features as possible and in
particular -eval and no GUI
• vim-small: a build with -eval but with Motif GUI
• vim-normal: the Normal featureset, with GTK3 GUI
• vim: a build (formerly Big, now described as Huge) with GTK3 GUI and
with +keymap +langmap +rightleft +arabic +autoservername but with no
interpreted languages
• vim-huge: a Huge build with GTK3 GUI and as many features as I can
find how to add, and in particular with several interpreted languages

A +gui build and a minimum "vi" build from my distro are also
installed, and there is no conflict with the above, but I rarely use
them. They are there as a fallback, for instance for the case when
there is a big change in the OS, I should have run "make reconfig" on
Vim to catch changes in the libraries and include files, forgot to do
it, and suddenly my own-compiled Vim gets a startup crash at every
run.

I think that the "typical user" might want to choose one or two of the
above configurations, or similar ones, but of course there are other
possibilities and Your Mileage May Vary: one of the great pluses of
Vim (in addition to its full documentation) is IMHO that it is not a
corset: different users can arrive at the same result by different
paths and among others with different successions of keystrokes.

To save wall clock time when compiling, rather than giving Make a -j
argument (which I might still add sometime, now that I have a more
powerful computer, with 12 virtual cores), I compile them in parallel,
each in its own shell in its own shadow directory, with its own
configure environment and no changes to the distributed Makefile.

Best regards, and have fun
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/CAJkCKXv%3Dz8kvWKaj1E8REvg0RPCU%3DqJcPT0%3Dycvz8jqqpLWA9g%40mail.gmail.com.

Re: Cannot compile with +rightleft and +arabic

[Ron Aaron]

Thank you, Bram -
I don't usually view the newsgroup, which is why I didn't see the 
discussion around this. I certainly would have jumped in had I noticed it.

Best regards,
Ron

On Wednesday, October 12, 2022 at 12:56:59 PM UTC+3 Bram Moolenaar wrote:

>
> Ron Aaron wrote:
>
> > I, for one, use the rightleft functionality all the time, and I believe 
> > many others do as well. It's not perfect, but it works well enough. 
> Getting 
> > it yanked out all of a sudden came as a bad surprise.
>
> Thanks for your feedback. I got a couple more remarks like this.
> Not much though.
>
> I'll put back the flags, so it will be in the huge build again.
>
> I do hope that someone takes the time to make improvements. And at
> least adds more tests. There currently are only a few tests for Arabic
> mode. With these tests we should be able to prevent it from breaking
> when code is changed.
>
> -- 
> ARTHUR: You fight with the strength of many men, Sir knight.
> I am Arthur, King of the Britons. [pause]
> I seek the finest and the bravest knights in the land to join me
> in my Court of Camelot. [pause]
> You have proved yourself worthy; will you join me? [pause]
> You make me sad. So be it. Come, Patsy.
> BLACK KNIGHT: None shall pass.
> The Quest for the Holy Grail (Monty Python)
>
> /// 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_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/bbc3f43a-4e89-4365-a85e-29d878a2cd7bn%40googlegroups.com.

Patch 9.0.0733

[Bram Moolenaar]

Patch 9.0.0733
Problem:Use of strftime() is not safe.
Solution:   Check the return value of strftime().  Use a larger buffer and
correctly pass the available space. (Dominique Pellé, closes
#11348)
Files:  src/time.c


*** ../vim-9.0.0732/src/time.c  2022-10-07 11:20:24.034352636 +0100
--- src/time.c  2022-10-12 13:30:01.530292365 +0100
***
*** 82,88 
  char *
  get_ctime(time_t thetime, int add_newline)
  {
! static char buf[50];
  #ifdef HAVE_STRFTIME
  struct tm tmval;
  struct tm *curtime;
--- 82,88 
  char *
  get_ctime(time_t thetime, int add_newline)
  {
! static char buf[100];  // hopefully enough for every language
  #ifdef HAVE_STRFTIME
  struct tm tmval;
  struct tm *curtime;
***
*** 90,101 
  curtime = vim_localtime(, );
  // MSVC returns NULL for an invalid value of seconds.
  if (curtime == NULL)
!   vim_strncpy((char_u *)buf, (char_u *)_("(Invalid)"), sizeof(buf) - 1);
  else
  {
// xgettext:no-c-format
!   (void)strftime(buf, sizeof(buf) - 1, _("%a %b %d %H:%M:%S %Y"),
!   curtime);
  # ifdef MSWIN
if (enc_codepage >= 0 && (int)GetACP() != enc_codepage)
{
--- 90,109 
  curtime = vim_localtime(, );
  // MSVC returns NULL for an invalid value of seconds.
  if (curtime == NULL)
!   vim_strncpy((char_u *)buf, (char_u *)_("(Invalid)"), sizeof(buf) - 2);
  else
  {
// xgettext:no-c-format
!   if (strftime(buf, sizeof(buf) - 2, _("%a %b %d %H:%M:%S %Y"), curtime)
! == 0)
!   {
!   // Quoting "man strftime":
!   // > If the length of the result string (including the terminating
!   // > null byte) would exceed max bytes, then strftime() returns 0,
!   // > and the contents of the array are undefined.
!   vim_strncpy((char_u *)buf, (char_u *)_("(Invalid)"),
! sizeof(buf) - 2);
!   }
  # ifdef MSWIN
if (enc_codepage >= 0 && (int)GetACP() != enc_codepage)
{
***
*** 105,111 
acp_to_enc((char_u *)buf, (int)strlen(buf), _free, );
if (to_free != NULL)
{
!   STRCPY(buf, to_free);
vim_free(to_free);
}
}
--- 113,119 
acp_to_enc((char_u *)buf, (int)strlen(buf), _free, );
if (to_free != NULL)
{
!   STRNCPY(buf, to_free, sizeof(buf) - 2);
vim_free(to_free);
}
}
***
*** 318,327 
convert_setup(, p_enc, enc);
if (conv.vc_type != CONV_NONE)
p = string_convert(, p, NULL);
!   if (p != NULL)
!   (void)strftime((char *)result_buf, sizeof(result_buf),
! (char *)p, curtime);
!   else
result_buf[0] = NUL;
  
if (conv.vc_type != CONV_NONE)
--- 326,333 
convert_setup(, p_enc, enc);
if (conv.vc_type != CONV_NONE)
p = string_convert(, p, NULL);
!   if (p == NULL || strftime((char *)result_buf, sizeof(result_buf),
! (char *)p, curtime) == 0)
result_buf[0] = NUL;
  
if (conv.vc_type != CONV_NONE)
***
*** 1117,1132 
  #ifdef HAVE_STRFTIME
  struct tm tmval;
  struct tm *curtime;
  
  if (vim_time() - tt >= 100)
  {
curtime = vim_localtime(, );
if (vim_time() - tt < (60L * 60L * 12L))
// within 12 hours
!   (void)strftime((char *)buf, buflen, "%H:%M:%S", curtime);
else
// longer ago
!   (void)strftime((char *)buf, buflen, "%Y/%m/%d %H:%M:%S", curtime);
  }
  else
  #endif
--- 1123,1141 
  #ifdef HAVE_STRFTIME
  struct tm tmval;
  struct tm *curtime;
+ int   n;
  
  if (vim_time() - tt >= 100)
  {
curtime = vim_localtime(, );
if (vim_time() - tt < (60L * 60L * 12L))
// within 12 hours
!   n = strftime((char *)buf, buflen, "%H:%M:%S", curtime);
else
// longer ago
!   n = strftime((char *)buf, buflen, "%Y/%m/%d %H:%M:%S", curtime);
!   if (n == 0)
!   buf[0] = NUL;
  }
  else
  #endif
*** ../vim-9.0.0732/src/version.c   2022-10-12 12:58:50.385618448 +0100
--- src/version.c   2022-10-12 13:28:40.030510098 +0100
***
*** 701,702 
--- 701,704 
  {   /* Add new patch number below this line */
+ /**/
+ 733,
  /**/

-- 
-rwxr-xr-x  1 root  24 Oct 29  1929 /bin/ed
-rwxr-xr-t  4 root  131720 Jan  1  1970 /usr/ucb/vi
-rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs

 /// Bram Moolenaar -- 

Patch 9.0.0732

[Bram Moolenaar]

Patch 9.0.0732
Problem:No check for white space before and after "=<<". (Doug Kearns)
Solution:   Check for white space in Vim9 script. (closes #11351)
Files:  src/evalvars.c, src/testdir/test_vim9_assign.vim


*** ../vim-9.0.0731/src/evalvars.c  2022-10-01 19:43:48.606494048 +0100
--- src/evalvars.c  2022-10-12 12:42:00.563305223 +0100
***
*** 1066,1076 
  }
  else if (expr[0] == '=' && expr[1] == '<' && expr[2] == '<')
  {
!   list_T  *l;
longcur_lnum = SOURCING_LNUM;
  
!   // HERE document
!   l = heredoc_get(eap, expr + 3, FALSE, FALSE);
if (l != NULL)
{
rettv_list_set(, l);
--- 1066,1083 
  }
  else if (expr[0] == '=' && expr[1] == '<' && expr[2] == '<')
  {
!   list_T  *l = NULL;
longcur_lnum = SOURCING_LNUM;
  
!   // :let text =<< [trim] [eval] END
!   // :var text =<< [trim] [eval] END
!   if (vim9script && !eap->skip && (!VIM_ISWHITE(expr[-1])
!|| !IS_WHITE_OR_NUL(expr[3])))
!   semsg(_(e_white_space_required_before_and_after_str_at_str),
! "=<<", expr);
!   else
!   l = heredoc_get(eap, expr + 3, FALSE, FALSE);
! 
if (l != NULL)
{
rettv_list_set(, l);
*** ../vim-9.0.0731/src/testdir/test_vim9_assign.vim2022-09-18 
13:46:03.699664837 +0100
--- src/testdir/test_vim9_assign.vim2022-10-12 12:46:51.226661137 +0100
***
*** 1904,1909 
--- 1904,1928 
STOP
END
v9.CheckDefAndScriptFailure(lines, 'E1012: Type mismatch; expected number 
but got list', 1)
+ 
+   lines =<< trim END
+   var lines=<< STOP
+ xxx
+   STOP
+   END
+   v9.CheckDefAndScriptFailure(lines, 'E1004: White space required before and 
after ''=<<'' at "=<< STOP"', 1)
+   lines =<< trim END
+   var lines =

Patch 9.0.0731

[Bram Moolenaar]

Patch 9.0.0731
Problem:clang-tidy configuration files are not recognized.
Solution:   Recognize clang-tidy files as yaml. (closes #11350)
Files:  runtime/filetype.vim, src/testdir/test_filetype.vim


*** ../vim-9.0.0730/runtime/filetype.vim2022-10-10 12:08:55.850043934 
+0100
--- runtime/filetype.vim2022-10-12 12:09:02.140829144 +0100
***
*** 369,374 
--- 369,377 
  " ChordPro
  au BufNewFile,BufRead *.chopro,*.crd,*.cho,*.crdpro,*.chordprosetf 
chordpro
  
+ " Clang-tidy
+ au BufNewFile,BufRead .clang-tidy setf yaml
+ 
  " Clean
  au BufNewFile,BufRead *.dcl,*.icl setf clean
  
*** ../vim-9.0.0730/src/testdir/test_filetype.vim   2022-10-10 
12:08:55.850043934 +0100
--- src/testdir/test_filetype.vim   2022-10-12 12:06:51.688664469 +0100
***
*** 640,646 
  \ 'xsd': ['file.xsd'],
  \ 'xslt': ['file.xsl', 'file.xslt'],
  \ 'yacc': ['file.yy', 'file.yxx', 'file.y++'],
! \ 'yaml': ['file.yaml', 'file.yml'],
  \ 'yang': ['file.yang'],
  \ 'z8a': ['file.z8a'],
  \ 'zig': ['file.zig'],
--- 640,646 
  \ 'xsd': ['file.xsd'],
  \ 'xslt': ['file.xsl', 'file.xslt'],
  \ 'yacc': ['file.yy', 'file.yxx', 'file.y++'],
! \ 'yaml': ['file.yaml', 'file.yml', '.clang-tidy'],
  \ 'yang': ['file.yang'],
  \ 'z8a': ['file.z8a'],
  \ 'zig': ['file.zig'],
*** ../vim-9.0.0730/src/version.c   2022-10-12 11:54:31.379668231 +0100
--- src/version.c   2022-10-12 12:08:36.360800065 +0100
***
*** 701,702 
--- 701,704 
  {   /* Add new patch number below this line */
+ /**/
+ 731,
  /**/

-- 
ARTHUR:I command you as King of the Britons to stand aside!
BLACK KNIGHT:  I move for no man.
  The Quest for the Holy Grail (Monty Python)

 /// 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/20221012111013.0ACAE1C5296%40moolenaar.net.

Re: [PATCH] lisp: improve indentation rule for else

[Wolf]

On 2022-10-11 11:39:07 +0100, Bram Moolenaar wrote:
> 
> > Currently else is indented like this:
> > 
> >   (cond (else
> >   foo))
> > 
> > That does not match typical indentation used, which would be:
> > 
> >   (cond (else
> >  foo))
> > 
> > This commit special-cases "(else" to indent like it would be expected to
> > indent. It also tweaks lisp_match to accept not only "(else ", but also
> > "(else\x00". That means that old behaviour can mostly be restored by
> > adding "else" into lispwords.
> > ---
> > If you are not willing to accept this change in behavior, I can try to
> > make it configurable. Currently I do not know of a way to work around
> > this in .vimrc, so code change seems necessary, but (if desired), I can
> > send another patch that keeps the default behavior and only makes this
> > opt-in.
> > 
> >  src/indent.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/indent.c b/src/indent.c
> > index 95fc74ee4..8e21f20ce 100644
> > --- a/src/indent.c
> > +++ b/src/indent.c
> > @@ -1907,7 +1907,7 @@ lisp_match(char_u *p)
> >  {
> > (void)copy_option_part(, buf, LSIZE, ",");
> > len = (int)STRLEN(buf);
> > -   if (STRNCMP(buf, p, len) == 0 && p[len] == ' ')
> > +   if (STRNCMP(buf, p, len) == 0 && (p[len] == ' ' || !p[len]))
> > return TRUE;
> 
> This makes a lot of sense.  How can we test the effect?  The example
> above does not appear to be affected.  The lispwords test doesn't fail.

Right, this change is technically not necessary for what I want to do
(changing the indent of consequent from 2 to 1). But while I cannot
imagine why someone would want the original behavior (indent of 2), I
still think it would be nice to have an option to restore it.

That can be done by lw+=else, however original code here does not handle
else\x00 (else\x20 does work, but having to put the space there is
annoying). Therefore this change.

> Perhaps IS_WHITE_OR_NUL() should be used here.

I did not know this is a thing, should I send a version 2 of the patch
or is it faster for you to change on your end? I've tested locally that
it seems to work.

> >  }
> >  return FALSE;
> > @@ -2039,6 +2039,8 @@ get_lisp_indent(void)
> > if (!vi_lisp && (*that == '(' || *that == '[')
> >   && lisp_match(that + 1))
> > amount += 2;
> > +   else if (!vi_lisp && STRICMP(that, "(else") == 0)
> > +   amount += 1;
> > else
> > {
> > that++;
> 
> Is the example at the top a good test for this change?  Does it affect
> other situations?

Yes, I think it is a good example. I've tried it on few pieces of
guile's source code and it seems to work even on more complex ones. I'm
not aware of any side effects.

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

-- 
-- 
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/Y0ae1GS9DhSUDda9%40ws.


signature.asc
Description: PGP signature

Patch 9.0.0730

[Bram Moolenaar]

Patch 9.0.0730 (after 9.0.0729)
Problem:Startup test fails with right-left feature.
Solution:   Do not delete test file too early.
Files:  src/testdir/test_startup.vim


*** ../vim-9.0.0729/src/testdir/test_startup.vim2022-10-10 
22:39:38.207545888 +0100
--- src/testdir/test_startup.vim2022-10-12 11:52:56.147685887 +0100
***
*** 392,398 
  " Test the -A, -F and -H arguments (Arabic, Farsi and Hebrew modes).
  func Test_A_F_H_arg()
let after =<< trim [CODE]
! call writefile([, , , ], "Xtestout", 'D')
  qall
[CODE]
  
--- 392,398 
  " Test the -A, -F and -H arguments (Arabic, Farsi and Hebrew modes).
  func Test_A_F_H_arg()
let after =<< trim [CODE]
! call writefile([, , , ], "Xtestout")
  qall
[CODE]
  
***
*** 412,417 
--- 412,419 
  let lines = readfile('Xtestout')
  call assert_equal(['1', '0', '0', '1'], lines)
endif
+ 
+   call delete('Xtestout')
  endfunc
  
  " Test the --echo-wid argument (for GTK GUI only).
*** ../vim-9.0.0729/src/version.c   2022-10-12 11:12:42.657140252 +0100
--- src/version.c   2022-10-12 11:53:53.175676084 +0100
***
*** 701,702 
--- 701,704 
  {   /* Add new patch number below this line */
+ /**/
+ 730,
  /**/

-- 
f y cn rd ths thn y cn hv grt jb n cmptr prgrmmng

 /// 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/20221012105503.18ED01C5296%40moolenaar.net.

Patch 9.0.0729

[Bram Moolenaar]

Patch 9.0.0729 (after 9.0.0696)
Problem:The rightleft and arabic features are disabled.
Solution:   Re-enable the features, some users want to use the functionality.
Files:  runtime/doc/rileft.txt, src/feature.h


*** ../vim-9.0.0728/runtime/doc/rileft.txt  2022-06-28 11:21:06.0 
+0100
--- runtime/doc/rileft.txt  2022-10-12 11:03:45.882886887 +0100
***
*** 35,40 
--- 35,45 
  as this kind of support is out of the scope of a simple addition to an
  existing editor (and it's not sanctioned by Unicode either).
  
+ As many people working on the code do not use the right-to-left mode, this
+ feature may not work in some situations.  If you can describe what is wrong
+ and how it would work when fixed, please create an issue on github, see
+ |bug-reports|.
+ 
  
  Highlights
  --
*** ../vim-9.0.0728/src/feature.h   2022-10-08 19:26:35.698195391 +0100
--- src/feature.h   2022-10-12 10:58:33.664434309 +0100
***
*** 186,192 
  #endif
  
  /*
!  * +linebreak 'showbreak', 'breakat'  and 'linebreak' options.
   *Also 'numberwidth'.
   */
  #ifdef FEAT_NORMAL
--- 186,192 
  #endif
  
  /*
!  * +linebreak 'showbreak', 'breakat' and 'linebreak' options.
   *Also 'numberwidth'.
   */
  #ifdef FEAT_NORMAL
***
*** 216,221 
--- 216,223 
  
  /*
   * +rightleft Right-to-left editing/typing support.
+  *Note that this isn't perfect, but enough users say they
+  *use it to keep supporting it.
   */
  #if defined(FEAT_HUGE) && !defined(DISABLE_RIGHTLEFT)
  # define FEAT_RIGHTLEFT
***
*** 234,251 
  # endif
  #endif
  
- // It is unclear if there are any users of the +rightleft and +arabic fetures.
- // The lack of feedback and bug reports suggests that they are not actively
- // being used.
- // FOR NOW: disable the features here.  If nobody complains the code can be
- // removed.
- #ifdef FEAT_RIGHTLEFT
- # undef FEAT_RIGHTLEFT
- #endif
- #ifdef FEAT_ARABIC
- # undef FEAT_ARABIC
- #endif
- 
  /*
   * +emacs_tagsWhen FEAT_EMACS_TAGS defined: Include support 
for
   *emacs style TAGS file.
--- 236,241 
*** ../vim-9.0.0728/src/version.c   2022-10-11 23:12:55.624404996 +0100
--- src/version.c   2022-10-12 11:05:09.074559556 +0100
***
*** 701,702 
--- 701,704 
  {   /* Add new patch number below this line */
+ /**/
+ 729,
  /**/

-- 
"Hegel was right when he said that we learn from history that man can
never learn anything from history."   (George Bernard Shaw)

 /// 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/20221012101334.54BC01C5296%40moolenaar.net.

Re: Cannot compile with +rightleft and +arabic

[Bram Moolenaar]

Ron Aaron wrote:

> I, for one, use the rightleft functionality all the time, and I believe 
> many others do as well. It's not perfect, but it works well enough. Getting 
> it yanked out all of a sudden came as a bad surprise.

Thanks for your feedback.  I got a couple more remarks like this.
Not much though.

I'll put back the flags, so it will be in the huge build again.

I do hope that someone takes the time to make improvements.  And at
least adds more tests.  There currently are only a few tests for Arabic
mode.  With these tests we should be able to prevent it from breaking
when code is changed.

-- 
ARTHUR:  You fight with the strength of many men, Sir knight.
 I am Arthur, King of the Britons.  [pause]
 I seek the finest and the bravest knights in the land to join me
 in my Court of Camelot.  [pause]
 You have proved yourself worthy; will you join me?  [pause]
 You make me sad.  So be it.  Come, Patsy.
BLACK KNIGHT:  None shall pass.
  The Quest for the Holy Grail (Monty Python)

 /// 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/20221012095648.4AAD01C5296%40moolenaar.net.

Re: Cannot compile with +rightleft and +arabic

[Ron Aaron]

I, for one, use the rightleft functionality all the time, and I believe 
many others do as well. It's not perfect, but it works well enough. Getting 
it yanked out all of a sudden came as a bad surprise.

On Sunday, October 9, 2022 at 7:21:42 PM UTC+3 Tony Mechelynck wrote:

> On Sun, Oct 9, 2022 at 12:45 PM Bram Moolenaar  
> wrote:
> > It is rather arbitrary. I moved features related to highlighting to the
> > normal build, and features related to natural language support to the
> > huge build. Now we have three builds that are different enough to
> > justify their existence. You can pick the normal build and cherry-pick
> > some features, or use the huge build and disable features that you don't
> > want.
>
> OK, I'll compile a not-so-huge build and a really-huge build then (in
> addition to smaller builds used mostly as a sanity check), as follows:
>
> This is the really-huge build:
>
> # configuration for Huge Vim
> export CONF_OPT_GUI='--enable-gui=gtk3'
> export CONF_OPT_PERL='--enable-perlinterp'
> export CONF_OPT_PYTHON='--enable-pythoninterp'
> export CONF_OPT_PYTHON3='--disable-python3interp'
> export CONF_OPT_TCL='--enable-tclinterp'
> # /usr/bin/tclsh (softlink) is correctly set
> export CONF_OPT_RUBY='--enable-rubyinterp'
> export CONF_OPT_LUA='--enable-luainterp'
> export CONF_OPT_MZSCHEME='--disable-mzschemeinterp'
> #export CONF_OPT_PLTHOME='--with-plthome=/usr/local/plt'
> export CONF_OPT_CSCOPE='--enable-cscope'
> export CONF_OPT_MULTIBYTE='--enable-multibyte'
> export CONF_OPT_TERMINAL='--enable-terminal'
> export CONF_OPT_AUTOSERVE='--enable-autoservername'
> export CONF_OPT_FEAT='--with-features=huge'
> export CONF_ARGS2='--with-vim-name=vim-huge'
> export CONF_OPT_COMPBY='"--with-compiledby=antoine.m...@gmail.com"'
>
> and this is ne not-so-huge one:
>
> # Configuration for Big (or "simplified Huge") Vim build
> export CONF_OPT_GUI='--enable-gui=gtk3'
> # the multibyte feature (+multi_byte) is now always enabled
> # so the following is not really needed anymore
> export CONF_OPT_MULTIBYTE='--enable-multibyte'
> export CONF_OPT_TERMINAL='--disable-terminal'
> export CONF_OPT_AUTOSERVE='--enable-autoservername'
> export CONF_OPT_FEAT='--with-features=huge'
> # export CONF_ARGS2='--with-vim-name=vim-big'
> # let's actually name it "vim" (with symlinks from gvim, view, etc.)
> export CONF_OPT_COMPBY='"--with-compiledby=antoine.m...@gmail.com"'
>
> The difference is mostly in the interpreted languages and in the
> terminal feature, all of which are disabled in the lesser of the two.
> I'll keep an eye on how the featureset (as shown by :version) evolves.
>
> 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/e6fcbcdb-81d5-4198-9c53-7af3c88d0537n%40googlegroups.com.

Re: [vim/vim] patch 9.0.0696: it is unclear if the +rightleft and +arabic features are used (fbdce18)

[Ron Aaron]

I just rebuilt gvim, and to my unhappiness, "--enable-rightleft" does not 
in fact enable +rightleft.

I need that functionality, I've used it for a very long time. Please 
re-enable it.

On Sunday, October 9, 2022 at 11:09:16 PM UTC+3 Yee Cheng Chin wrote:

> I think another aspect of this is maybe we could try to provide some bidi 
> support if full-on RTL support is too annoying to support (since it affects 
> everything like virtual text, number column, signs, wrapping, etc). Not 
> sure if it's harder or easier to be honest. My vote would be full RTL 
> support as it would be useful to keep supporting if it already works, but I 
> do understand there are maintenance cost to doing so.
>
> —
> Reply to this email directly, view it on GitHub 
> ,
>  
> or unsubscribe 
> 
> .
>
> You are receiving this because you are subscribed to this thread.Message 
> ID:  github.com>
>

-- 
-- 
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/4174bdf1-e62e-4454-8b7a-1af291f7b10dn%40googlegroups.com.