GetLatestVimScripts broken

Hi,

Since a while GetLatestVimScripts appears to be broken, it doesn't find
any newer releases of installed scripts. I checked
~/.vim/GetLatest/GetLatestVimScripts.dat versions against
https://www.vim.org/scripts/ and found several newer ones.

What could cause this?

Eike

--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.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/20191026100227.GA28371%40kulungile.erack.de.

Re: [vim/vim] :cdo does not abort on error (and the test for it seems wrong) (#5102)

diff --git a/src/ex_cmds2.c b/src/ex_cmds2.c
index 81f2c8f5b..c03346878 100644
--- a/src/ex_cmds2.c
+++ b/src/ex_cmds2.c
@@ -1130,7 +1130,8 @@ ex_listdo(exarg_T *eap)
if (eap->cmdidx == CMD_cdo || eap->cmdidx == CMD_ldo
|| eap->cmdidx == CMD_cfdo || eap->cmdidx == CMD_lfdo)
{
- if (i >= qf_size || i >= eap->line2)
+ if (did_emsg || got_int || did_throw
+ || i >= qf_size || i >= eap->line2)
break;

qf_idx = qf_get_cur_idx(eap);
Hi Ralf,

Thanks for testing the changes. See below.

On Tue, Oct 22, 2019 at 12:01 PM Ralf Schandl <ralf.schandl@gmx.de> wrote:
>
> On 21.10.19 21:57, Yegappan Lakshmanan wrote:
> > Hi,
> >
> > On Mon, Oct 21, 2019 at 12:12 PM D. Ben Knoble
> ...
> >
> > Hi,
> >
> > Can you try the attached patch?
> >
> > Thanks,
> > Yegappan
> >
>
> Yegappan,
>
> thank you for providing a patch.
>
> It seems the patch didn't make it to GitHub. I pinged Ben & Dedowsdi via
> stackexchange. Hope they see it.
>
> I tested your patch in three ways:
>
> 1) :cdo s/TEST/HELLO/
>
> This will always fail, as there is no string "TEST" in any line. This
> error was ignored and :cdo worked on all lines.
>
> Is that intended?
>

Can you try the attached patch to see whether this is fixed? I am not able
to reproduce this behavior.

Thanks,
Yegappan

>
> 2) Calling a function from :cdo
>
> I build a qf list by :vimgrep for the word "dog". The function should
> replace "dog" with "cat". On the third invocation it throws an exception.
>
> 2.1) :cdo call Test_cdo()
>
> The first two entries were replaced and on the third entry a exception
> was thrown. Processing stops immediately. All other "dog"s were unchanged.
>
> 2.2) :cdo silent call Test_cdo()
>
> Acts like 2.1
>
> 2.3) :cdo silent! call Test_cdo()
>
> Ignores the exception and works on all entries of the qf list.
>
> 3) :cdo echo x
>
> The variable x is not defined. This was detected and the command was
> executed for the first entry of the qf list.
> With 'silent!' it processes all entries from the list.
>
> I'm not sure if the behavior in the first test case is intended. In the
> other two cases it worked like I expected.
>
> Regards,
> Ralf
>

--
--
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/CAAW7x7nbArhopqYwo7Z%2BU4Xeqnjg3%3D7%3D_n3nHo2Ysc51b-VoUw%40mail.gmail.com.

Re: [vim/vim] :cdo does not abort on error (and the test for it seems wrong) (#5102)

diff --git a/src/ex_cmds2.c b/src/ex_cmds2.c
index 81f2c8f5b..c83dd3f71 100644
--- a/src/ex_cmds2.c
+++ b/src/ex_cmds2.c
@@ -944,6 +944,7 @@ ex_listdo(exarg_T *eap)
tabpage_T *tp;
buf_T *buf = curbuf;
int next_fnum = 0;
+ int save_did_emsg;
#if defined(FEAT_SYN_HL)
char_u *save_ei = NULL;
#endif
@@ -1042,6 +1043,8 @@ ex_listdo(exarg_T *eap)
setpcmark();
listcmd_busy = TRUE; /* avoids setting pcmark below */

+ save_did_emsg = did_emsg;
+ did_emsg = FALSE;
while (!got_int && buf != NULL)
{
if (eap->cmdidx == CMD_argdo)
@@ -1130,7 +1133,7 @@ ex_listdo(exarg_T *eap)
if (eap->cmdidx == CMD_cdo || eap->cmdidx == CMD_ldo
|| eap->cmdidx == CMD_cfdo || eap->cmdidx == CMD_lfdo)
{
- if (i >= qf_size || i >= eap->line2)
+ if (did_emsg || i >= qf_size || i >= eap->line2)
break;

qf_idx = qf_get_cur_idx(eap);
@@ -1159,6 +1162,7 @@ ex_listdo(exarg_T *eap)
break;
}
listcmd_busy = FALSE;
+ did_emsg = save_did_emsg;
}

#if defined(FEAT_SYN_HL)

Hi,

On Mon, Oct 21, 2019 at 12:12 PM D. Ben Knoble <vim-dev-github@256bit.org> wrote:

@yegappan thanks for the comparison to the other do commands, for the explanation of the test, and for demonstrating that that definition of :cdo explains basically all the behavior.

It is still unexpected behavior, and here is why:

:help :cdo        <			When the current file can't be |abandon|ed and the [!]    			is not present, the command fails.    			When an error is detected execution stops.    			The last buffer (or where an error occurred) becomes    			the current buffer.    

I see where you might have a point re: abandoning buffers. But the help says: "When an error is detected execution stops." Does this mean an error in :cdo (like the aforementioned abandon failure)? Or does this mean an error in {cmd} given to :cdo? Most users (myself included) seem to believe it's the latter—are you clarifying it is the former? Either way, we must update the help to be unambiguous (and it may be more useful to use the latter as actual behavior, given that :cdo operates at each entry, like :global (which, in fact, stops at the first error)).

Hi,

Can you try the attached patch?

Thanks,

Yegappan

 

--
--
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/CAAW7x7%3DHdmW8dDS5vjb3UWBt%3DkcngMMQYj5Qy_C59pssmqV39w%40mail.gmail.com.

Re: Help about missing mails

Christian,

I really appreciate your attention paid to my problem.

I suspected this issue was related to certificate mismatch, but finally
I got an error from google: "The MX host does not match any MX allowed
by the STS policy." So it's due to I forgot to update STS policy on my
side. It's my fault of course, I'm so sorry!

> I just received a help request from a subscriber of this list, who
> doesn't receive mails anymore. Looking into the groups admin page,
> showed his mail address being flagged as "undeliverable" yesterday, but
> today it isn't flagged anymore and looks good

--
sergio.

--
--
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/e6a86d62-071a-6898-976a-ae8ce3e2c30e%40outerface.net.

Re: Help about missing mails

Christian wrote:

> I just received a help request from a subscriber of this list, who
> doesn't receive mails anymore. Looking into the groups admin page,
> showed his mail address being flagged as "undeliverable" yesterday, but
> today it isn't flagged anymore and looks good. So theoretically, google
> should try to deliver to his account. However he doesn't see any
> attempts in his MTA logs that a delivery attempt from google is made.
>
> There is https://support.google.com/a/topic/1262452 but that does not
> mention the particular problem here. I am out of ideas here and since
> the google groups interface changed a couple of months ago, it doesn't
> seem to be possible to get into contact with google itself. It wants me
> to sign up for G Suite Admin account (which costs money) before I can
> get support.
>
> So to make a long story short, does anybody here knows a personal
> contact to google support that could help us resolve this issue here?

Most likely that's not going to help. I guess what happened is that the
mail server could not be found. I have seen DNS flakiness in the past.

--
If you only have a hammer, you tend to see every problem as a nail.
If you only have MS-Windows, you tend to solve every problem by rebooting.

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ 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/201910161207.x9GC7GLT004956%40masaka.moolenaar.net.

Help about missing mails

Hello everybody,

I just received a help request from a subscriber of this list, who
doesn't receive mails anymore. Looking into the groups admin page,
showed his mail address being flagged as "undeliverable" yesterday, but
today it isn't flagged anymore and looks good. So theoretically, google
should try to deliver to his account. However he doesn't see any
attempts in his MTA logs that a delivery attempt from google is made.

There is https://support.google.com/a/topic/1262452 but that does not
mention the particular problem here. I am out of ideas here and since
the google groups interface changed a couple of months ago, it doesn't
seem to be possible to get into contact with google itself. It wants me
to sign up for G Suite Admin account (which costs money) before I can
get support.

So to make a long story short, does anybody here knows a personal
contact to google support that could help us resolve this issue here?

Thanks,
Christian

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

Re: restore ^h to be the same as backspace in insert mode

On Wed, Oct 16, 2019 at 1:06 AM Tim Mooney <timothy.v.mooney@gmail.com> wrote:
>
> Hello fellow vimmers!
>
> I've been a happy vim user on Unix and later Linux since the vim 3.0 days (approximately 25 years!). I was on the vim mailing list for years, but dropped off when it moved to Google Groups in 2007. Vim has worked so comfortably and reliably for me that I haven't had any questions that couldn't be answered with a quick web search.
>
> However, a recent OS update has changed vim behavior that I've relied on for years, and I'm really struggling with how to restore the previous behavior.
>
> Specifically, in insert mode, the behavior I've used for ages is that both control-h and backspace do the same thing: move the cursor 1 character to the left and then delete the character under the new cursor position.
>
> Since the update, though, the backspace key continues to do that (move 1 left & delete) in insert mode, but control-h instead now deletes the character to the right. This has the unfortunate effect that when I'm at the end of a line of text in insert mode, if muscle memory has me press control-h with the intent of moving left and deleting the character, what I instead get is the removal of the newline after the cursor and the next line becomes joined to the current line.
>
> How do I restore the previous behavior?
>
> This changed (broke) after a round of OS updates. The updates included ncurses, vim, and other components, so it's not going to be easy to isolate which component is responsible for the change.
>
> Before the update, I was using vim 8.1.1002, after the update I'm on vim 8.1.1721
>
> The .vimrc that I've been using for the past 15 or more years looks like:
>
> set nobackup
> set ts=4 noai nohlsearch magic beautify nowrapscan wrapmargin=1
> :au VimEnter pico* set tw=74 spell spelllang=en_us
> :au VimEnter pico* set wrap
> :au VimEnter cvs* set tw=74
> :au VimEnter cvs* set wrap
> :au VimEnter *.py set ts=4 expandtab sm
> :au VimEnter *.pl set modeline ts=4 sm
>
>
> I tried adding :fixdel based on some web searches, but that didn't solve the issue. Both my control-h and backspace key are recognized just fine, it's just that now control h behavior is different than it was previously.
>
> When I'm not in vim, for example when I'm just typing at the shell (bash 5.0.11) command line, both control-h and backspace do the "move left and delete" action I would expect. stty reports:
>
> $ stty -a
> speed 9600 baud;
> rows = 41; columns = 80; ypixels = 0; xpixels = 0;
> csdata UTF-8
> eucw 1:0:0:0, scrw 1:0:0:0
> intr = ^c; quit = ^\; erase = ^?; erase2 = ^h; kill = ^u;
> eof = ^d; eol = <undef>; eol2 = <undef>; swtch = <undef>;
> start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
> rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v;
> status = ^t;
> -parenb -parodd cs8 -cstopb -hupcl cread -clocal -loblk -crtscts -crtsxoff -parext
> -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc
> ixon -ixany -ixoff imaxbel
> isig icanon -xcase echo echoe echok -echonl -noflsh
> -tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten
> opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3
>
>
>
>
> Anyone have any suggestions for what I can set to get the old behavior back?
>
> If there's additional informatio I can provide, please let me know!
>
> Thanks!
>
> Tim

You might want to check what Ctrl-V followed by Backspace and Ctrl-V
followed by Delete insert when in Insert mode, then lookup the help
for |:fixdel|

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

restore ^h to be the same as backspace in insert mode

Hello fellow vimmers!

I've been a happy vim user on Unix and later Linux since the vim 3.0 days (approximately 25 years!).  I was on the vim mailing list for years, but dropped off when it moved to Google Groups in 2007.  Vim has worked so comfortably and reliably for me that I haven't had any questions that couldn't be answered with a quick web search.

However, a recent OS update has changed vim behavior that I've relied on for years, and I'm really struggling with how to restore the previous behavior.

Specifically, in insert mode, the behavior I've used for ages is that both control-h and backspace do the same thing: move the cursor 1 character to the left and then delete the character under the new cursor position.

Since the update, though, the backspace key continues to do that (move 1 left & delete) in insert mode, but control-h instead now deletes the character to the right.  This has the unfortunate effect that when I'm at the end of a line of text in insert mode, if muscle memory has me press control-h with the intent of moving left and deleting the character, what I instead get is the removal of the newline after the cursor and the next line becomes joined to the current line.

How do I restore the previous behavior?

This changed (broke) after a round of OS updates.  The updates included ncurses, vim, and other components, so it's not going to be easy to isolate which component is responsible for the change.

Before the update, I was using vim 8.1.1002, after the update I'm on vim 8.1.1721

The .vimrc that I've been using for the past 15 or more years looks like:

set nobackup
set ts=4 noai nohlsearch magic beautify nowrapscan wrapmargin=1
:au VimEnter pico* set tw=74 spell spelllang=en_us
:au VimEnter pico* set wrap
:au VimEnter cvs* set tw=74
:au VimEnter cvs* set wrap
:au VimEnter *.py set ts=4 expandtab sm
:au VimEnter *.pl set modeline ts=4 sm

I tried adding :fixdel based on some web searches, but that didn't solve the issue.  Both my control-h and backspace key are recognized just fine, it's just that now control h behavior is different than it was previously.

When I'm not in vim, for example when I'm just typing at the shell (bash 5.0.11) command line, both control-h and backspace do the "move left and delete" action I would expect.  stty reports:

$ stty -a
speed 9600 baud;
rows = 41; columns = 80; ypixels = 0; xpixels = 0;
csdata UTF-8
eucw 1:0:0:0, scrw 1:0:0:0
intr = ^c; quit = ^\; erase = ^?; erase2 = ^h; kill = ^u;
eof = ^d; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v;
status = ^t;
-parenb -parodd cs8 -cstopb -hupcl cread -clocal -loblk -crtscts -crtsxoff -parext
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc
ixon -ixany -ixoff imaxbel
isig icanon -xcase echo echoe echok -echonl -noflsh
-tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3

Anyone have any suggestions for what I can set to get the old behavior back?

If there's additional informatio I can provide, please let me know!

Thanks!

Tim

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ed4d99cc-90eb-4525-b550-48c3a0a6118a%40googlegroups.com.

Re: help to determine script type

Am 15.10.2019 um 04:00 schrieb sergio:
> Hello.
>
> I'd like to publish my first script on vim.org. It updates bindzone's
> serial on BufWrite. It's file type plugin, but not to be placed in
> ftplugin folder.

So it's a file type plugin that's not a file type plugin?

Eg you can do `:au Bindzone BufWrite <buffer> :...' from within an ftplugin script.
(with augroup Bindzone)

To just add functionality, you can name the file (eg)
ftplugin/bindzone_serial.vim

> What are the types "patch" and "utility" used for?
> Which type should I select: utility, patch or ftplugin?

To just add a global plugin: "utility".

--
Andy

--
--
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/5DA5EE61.800%40yahoo.de.

help to determine script type

Hello.

I'd like to publish my first script on vim.org. It updates bindzone's
serial on BufWrite. It's file type plugin, but not to be placed in
ftplugin folder. What are the types "patch" and "utility" used for?
Which type should I select: utility, patch or ftplugin?


--
sergio.

--
--
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/dda14e6d-a042-3229-d0e0-60d6ffbfe89c%40outerface.net.

Re: netrw echoes message even if disable

Hi,

Ni Va schrieb am 13.10.2019 um 21:38:
>
> Even with loaded plugin status to disable netrw, it echoes 'is a directory'.
>
> This in my _vimrc as it is advised, and it echoes 'is a directory'...  ???
> let g:loaded_netrw       = 1
> let g:loaded_netrwPlugin = 1
>
> How can we disable plugin and echoing.

"is a directory" is a message displayed by Vim itself, not by the netrw
plugin. I doubt there is an option to disable it; at least there is no
fitting flag in 'shortmess'.

Regards,
Jürgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)

--
--
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/6fcdaee7-c9d3-2d01-2753-e5c0b52cda9d%40googlemail.com.

netrw echoes message even if disable

Hi,

Even with loaded plugin status to disable netrw, it echoes 'is a directory'.

This in my _vimrc as it is advised, and it echoes 'is a directory'...  ???

let g:loaded_netrw       = 1

let g:loaded_netrwPlugin = 1

How can we disable plugin and echoing.

Thank you

NiVa

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/e054d142-8331-418d-826e-84fba1e9cd47%40googlegroups.com.

Re: regexp : windows filename recognition

It works well with .*$ in order to substitute and get first backward reference.

^..\(.\{-}\)\s\+\d\+\.\d\+.\{,20} needed to add .*$

Thank you.

Le jeudi 10 octobre 2019 17:19:25 UTC+2, Andy Wokula a écrit :

Am 10.10.2019 um 10:44 schrieb Ni Va:
> Don't understand why it returns 2 first chars on this example :
>
> + 20191009_191004_Vim.8.1.2125/                                                                                              4.0 KiB [D] 2019-10-
> echo substitute(getline(line('.')),'^..\zs\(.\+\)\(\s\+\d\+\.\d\+\)\@=.*$','\1', "") returns + 20191009_191004_Vim.8.1.2125/

The match starts after `\zs', what comes before is not substituted.

I wonder why the greedy \(.\+\) does not include any spaces.
Looks like \(\s\+\d\+\.\d\+\)\@= is checked before any backtracking takes place.
"no backtracking" => actually this depends on re=0 or re=2.

:echo substitute(getline('.'), '^..\(.\{-}\)\s\+\d\+\.\d\+.\{,20}$', '\1', '')

--
Andy

--
--
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/e9d96fcc-6fd9-4072-9601-15ed01eb0c99%40googlegroups.com.

Re: regexp : windows filename recognition

Am 10.10.2019 um 10:44 schrieb Ni Va:
> Don't understand why it returns 2 first chars on this example :
>
> + 20191009_191004_Vim.8.1.2125/ 4.0 KiB [D] 2019-10-
> echo substitute(getline(line('.')),'^..\zs\(.\+\)\(\s\+\d\+\.\d\+\)\@=.*$','\1', "") returns + 20191009_191004_Vim.8.1.2125/

The match starts after `\zs', what comes before is not substituted.

I wonder why the greedy \(.\+\) does not include any spaces.
Looks like \(\s\+\d\+\.\d\+\)\@= is checked before any backtracking takes place.
"no backtracking" => actually this depends on re=0 or re=2.

:echo substitute(getline('.'), '^..\(.\{-}\)\s\+\d\+\.\d\+.\{,20}$', '\1', '')

--
Andy

--
--
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/5D9F4BEF.3030101%40yahoo.de.

Re: reading a 'tree -o' output file

Those color codes are called ANSI escape sequences; there's a plugin
that will interpret them:
https://www.vim.org/scripts/script.php?script_id=302

Hope that helps :)

--
Adrian

--
--
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/20191010150939.4bm6oeltsmtqo2kl%40gauss.localdomain.

Re: highlight match fails

Was overloaded by this one :

" syn match s7JumpStatement   /^\(L*\d\+:\)*\s\+\zs\(SPA\|SPL\|SPBNB\|SPBN\|SPBB\|SPB\|SPBI\|SPBIN\|SLW\|SPO\|SPS\|SPZ\|SPN\|SPP\|SPM\|SPPZ\|SPMZ\|SPU\|LOOP\)\(\w\)\@!/

Le jeudi 10 octobre 2019 15:57:44 UTC+2, Ni Va a écrit :

Hi,

I would like to recognize that label near SPBN.

      SPBN  _003;

syn match s7JumpToLabel     /^\s\+\(SPBN\|SPB\|SPA\)\s\+\zs\w\+/     ===> seems to highlight on normal search.

but syntax highlight does not success :

        syn match s7JumpToLabel     /^\s\+\(SPBN\|SPB\|SPA\)\s\+\zs\w\+/ 

highlight ColorLabel   ctermfg=88  guifg=#990000 guibg=#ffd4d4 gui=bold      cterm=bold

        hi def link  s7JumpToLabel         Function 

Thank you

--
--
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/9b99c0ae-3aaa-4440-a7bf-76cc3e52985b%40googlegroups.com.

highlight match fails

Hi,

I would like to recognize that label near SPBN.

      SPBN  _003;

syn match s7JumpToLabel     /^\s\+\(SPBN\|SPB\|SPA\)\s\+\zs\w\+/     ===> seems to highlight on normal search.

but syntax highlight does not success :

        syn match s7JumpToLabel     /^\s\+\(SPBN\|SPB\|SPA\)\s\+\zs\w\+/ 

highlight ColorLabel   ctermfg=88  guifg=#990000 guibg=#ffd4d4 gui=bold      cterm=bold

        hi def link  s7JumpToLabel         Function 

Thank you

--
--
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/744a442a-11c9-4a0d-acc7-6a9fa9156802%40googlegroups.com.

Re: How to let previous opened fold open reentering vim buffer.

This code well do the calling of func AvoidFolding when entering buffer but it returns E490 no fold found.

fun! AvoidFolding() 

  normal! zx

  normal! zv

  normal! za

endfunction

if has("autocmd")

  " augroup vimrc

  au!

" Avoid folding

autocmd BufEnter *.vim       :call AvoidFolding()

autocmd BufEnter $VIM/_vimrc :call AvoidFolding()

  " augroup END

endif " has("autocmd")

Le mercredi 2 octobre 2019 13:33:56 UTC+2, Ni Va a écrit :

Seems to not working..

It's disturbing that previsou opened fold is closed just when leaving and re entering the same buffer.

Le mercredi 2 octobre 2019 13:12:17 UTC+2, Enno a écrit :

The command `za` toggles the fold. Try instead

silent autocmd! BufEnter *.vim normal! zv

to open sufficiently many folds to show the line where the cursor is at.

Le vendredi 27 septembre 2019 12:58:23 UTC-3, Ni Va a écrit :

Hi,

I try this in _vimrc in order to let a previous opened fold, opened when I re enter buffer.

in _vimrc:

if has("autocmd")
silent autocmd! BufEnter *.vim norm za
endif

example of vim buffer :

function! sequencerutil#echomsg(startreltime,str) abort  " timestamp stolen from codi sorry :){{{
let seconds_and_microseconds = reltimestr(reltime(a:startreltime))
let decimal_i = stridx(seconds_and_microseconds, '.')
let seconds = seconds_and_microseconds[:decimal_i - 1]
let microseconds = seconds_and_microseconds[decimal_i + 1:]
let timestamp = strftime("%T.".microseconds, seconds)
echomsg strftime('%Y/%m/%d %T.').printf("%.3s",microseconds).printf(" %.3s secs %s", seconds, a:str)
endfunc "}}}
" vim: set ft=vim ff=dos fdm=marker ts=4 :expandtab:

It seems to not doing what I attempt but why ?

Thanks in advance.

NiVa

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/89c21ec9-48c8-43dd-b42a-ea39383c2b35%40googlegroups.com.

Re: regexp : windows filename recognition

+ ../ 16.0 KiB [D] 2019-10-10 10:37:27 +0200 55
configuremingw32 4.7 KiB 2019-10-10 10:37:04 +0200 644
+ Vim.8.1.2127/ 4.0 KiB [D] 2019-10-10 10:23:03 +0200 55
+ Vim.8.1.2122/ 4.0 KiB [D] 2019-10-10 10:16:09 +0200 55
+ 20191010_102841_Vim.8.1.2127/ 4.0 KiB [D] 2019-10-10 10:08:41 +0200 55
+ 20191010_101731_Vim.8.1.2127/ 4.0 KiB [D] 2019-10-10 09:59:24 +0200 55
+ 20191010_100613_Vim.8.1.2127/ 4.0 KiB [D] 2019-10-10 08:54:35 +0200 55
+ Vim.8.1.2125/ 4.0 KiB [D] 2019-10-09 19:04:40 +0200 55
+ 20191009_191004_Vim.8.1.2125/ 4.0 KiB [D] 2019-10-09 18:20:33 +0200 55
+ 20191009_182820_Vim.8.1.2125/ 4.0 KiB [D] 2019-10-09 11:16:00 +0200 55
+ 20191009_112320_Vim.8.1.2125/ 4.0 KiB [D] 2019-10-09 09:39:36 +0200 55
+ 20191009_094707_Vim.8.1.2125/ 4.0 KiB [D] 2019-10-09 09:30:49 +0200 55
+ 20191009_093639_Vim.8.1.2125/ 4.0 KiB [D] 2019-10-09 09:23:39 +0200 55
+ 20191009_092924_Vim.8.1.2125/ 4.0 KiB [D] 2019-10-09 09:16:20 +0200 55
+ 20191009_092151_Vim.8.1.2125/ 4.0 KiB [D] 2019-10-09 09:03:48 +0200 55
+ 20191008_142547_Vim.8.1.2122/ 4.0 KiB [D] 2019-10-08 09:38:42 +0200 55
sh.exe.stackdump 608.0 B 2019-10-08 09:13:04 +0200 644
git.exe.stackdump 669.0 B 2019-10-08 09:12:45 +0200 644
+ Vim.8.1.2120/ 4.0 KiB [D] 2019-10-07 17:50:21 +0200 55
+ 20191007_175658_Vim.8.1.2120/ 4.0 KiB [D] 2019-10-07 17:22:22 +0200 55
+ 20191007_172955_Vim.8.1.2120/ 4.0 KiB [D] 2019-10-07 17:13:11 +0200 55
+ 20191007_171951_Vim.8.1.2120/ 4.0 KiB [D] 2019-10-07 14:25:42 +0200 55
+ 20191007_143406_Vim.8.1.2120/ 4.0 KiB [D] 2019-10-07 08:41:50 +0200 55
+ Vim.8.1.2115/ 4.0 KiB [D] 2019-10-05 17:52:13 +0200 55
+ Vim.8.1.2110/ 4.0 KiB [D] 2019-10-04 14:41:06 +0200 55
+ 20191004_144736_Vim.8.1.2110/ 4.0 KiB [D] 2019-10-04 09:39:19 +0200 55
+ 20191004_093657_Vim/ 0.0 B [D] 2019-10-04 09:36:58 +0200 55
+ Vim.8.1.2109/ 4.0 KiB [D] 2019-10-03 10:44:46 +0200 55
+ 20191003_105314_Vim.8.1.2109/ 4.0 KiB [D] 2019-10-03 09:58:37 +0200 55
+ 20191003_100731_Vim.8.1.2109/ 4.0 KiB [D] 2019-10-03 08:08:27 +0200 55
+ Vim.8.1.2108/ 4.0 KiB [D] 2019-10-02 11:13:06 +0200 55
+ 20191002_112141_Vim.8.1.2108/ 4.0 KiB [D] 2019-10-02 09:21:17 +0200 55
+ 20191002_092904_Vim.8.1.2108/ 4.0 KiB [D] 2019-10-01 21:53:27 +0200 55
+ ruby/ 48.0 KiB [D] 2019-10-01 21:42:13 +0200 55
+ 20191001_215905_Vim.8.1.2108/ 4.0 KiB [D] 2019-10-01 21:03:30 +0200 55
+ Vim.8.1.2107/ 4.0 KiB [D] 2019-10-01 17:13:10 +0200 55
+ Vim.8.1.2106/ 4.0 KiB [D] 2019-10-01 15:12:23 +0200 55
+ Vim.8.1.2105/ 4.0 KiB [D] 2019-10-01 14:05:51 +0200 55
+ Vim.8.1.2090/ 4.0 KiB [D] 2019-10-01 11:31:52 +0200 55
+ gdb-8.3/ 8.0 KiB [D] 2019-09-23 14:43:25 +0200 55

Don't understand why it returns 2 first chars on this example :

+ 20191009_191004_Vim.8.1.2125/                                                                                              4.0 KiB [D] 2019-10-

echo substitute(getline(line('.')),'^..\zs\(.\+\)\(\s\+\d\+\.\d\+\)\@=.*$','\1', "") returns + 20191009_191004_Vim.8.1.2125/

Thank you for help.

NiVa

Le mercredi 9 octobre 2019 18:19:24 UTC+2, Andy Wokula a écrit :

Am 09.10.2019 um 14:16 schrieb Ni Va:
> Anything chars contained in windows'filename before a lot of spaces
> and begining on third char after start of line.
>
> Anything chars of filename= \w\s-_. many times
>
> ^..filename                                    some others chars.*$

     /^..\zs.\+$

List of false positives:
     XXX

--
Andy

--
--
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/68b5a53f-5d7d-4ae4-b733-fe58a125847f%40googlegroups.com.

Re: regexp : windows filename recognition

Am 09.10.2019 um 14:16 schrieb Ni Va:
> Anything chars contained in windows'filename before a lot of spaces
> and begining on third char after start of line.
>
> Anything chars of filename= \w\s-_. many times
>
> ^..filename some others chars.*$

/^..\zs.\+$

List of false positives:
XXX

--
Andy

--
--
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/5D9E087E.7030005%40yahoo.de.

Re: regexp : windows filename recognition

Anything chars contained in windows'filename before a lot of spaces and begining on third char after start of line.

Anything chars of filename= \w\s-_. many times

^..filename                                    some others chars.*$

Thank you

Le mercredi 9 octobre 2019 14:09:25 UTC+2, aro...@vex.net a écrit :

> Here is a kind of filename in fat chars that I would like to recognize:
>
>  * $FOOBBBAR_Foooofbar_f_oobar_(2019-07-29) - Copie.zed.lnk*
>                                   232.0 KiB     2019

There's a practically infinite universe of expressions that could be made
to match it. What's distinctive about it?

It might help if you could provide an example of something that you don't
want to match, and point out what discriminates the match vs non-match.

--
--
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/01252a18-de2d-4392-9391-e20376274aa8%40googlegroups.com.

Re: regexp : windows filename recognition

> Here is a kind of filename in fat chars that I would like to recognize:
>
> * $FOOBBBAR_Foooofbar_f_oobar_(2019-07-29) - Copie.zed.lnk*
> 232.0 KiB 2019

There's a practically infinite universe of expressions that could be made
to match it. What's distinctive about it?

It might help if you could provide an example of something that you don't
want to match, and point out what discriminates the match vs non-match.

--
--
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/4d6886909e5cbcdf5c26478f0cbc1fb6.squirrel%40webmail.vybenetworks.com.

regexp : windows filename recognition

Hi,

Here is a kind of filename in fat chars that I would like to recognize:

  $FOOBBBAR_Foooofbar_f_oobar_(2019-07-29) - Copie.zed.lnk                                                  232.0 KiB     2019

Thank you

--
--
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/e94f889a-e44e-4381-a960-6bb99131c7c1%40googlegroups.com.

Re: sed whole file

On Tue, Oct 8, 2019 at 4:29 AM Paul <vim91549@rainslide.net> wrote:

On Sun, Oct 06, 2019 at 12:25:20PM +0200, Bram Moolenaar wrote:
>Perhaps we could go back to the original view when typing the search
>separator.  So long as the user is typing the search pattern it is
>useful to show the match, but when typing ":%s/foo/", thus starting to
>type the replacement, it is useful to jump back?
>
>I actually cannot guess if the user wants to see the original text or
>the context of what is going to be replaced. If you have something
>specific, you can copy it beforehand.  And the jumping around can be
>annoying.  Thus I rather leave it like it is.

Not sure if this helps to contribute to the discussion, but personally, I like to see what is going to be replaced, and with what it will be replaced, so I can experiment and get the command right real-time, so I use the traces.vim plugin (https://github.com/markonm/traces.vim).

It can also be helpful to edit the command line as if it were a regular Vim buffer, by executing q: in normal mode or using C-f after you've already started entering the command line using :. I developed the habit of using q/ to edit search lines when I explicitly don't want the cursor to jump to the first occurrence of the string.

--

        Eric Christopherson

--
--
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/CADyB93Bx7m8GP4pktiq%3DLjQqp-7jCRtac-RUe1cRbJ-qQR1yfw%40mail.gmail.com.

Re: sed whole file

On Sun, Oct 06, 2019 at 12:25:20PM +0200, Bram Moolenaar wrote:
>Perhaps we could go back to the original view when typing the search
>separator. So long as the user is typing the search pattern it is
>useful to show the match, but when typing ":%s/foo/", thus starting to
>type the replacement, it is useful to jump back?
>
>I actually cannot guess if the user wants to see the original text or
>the context of what is going to be replaced. If you have something
>specific, you can copy it beforehand. And the jumping around can be
>annoying. Thus I rather leave it like it is.

Not sure if this helps to contribute to the discussion, but personally, I like to see what is going to be replaced, and with what it will be replaced, so I can experiment and get the command right real-time, so I use the traces.vim plugin (https://github.com/markonm/traces.vim).

--
--
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/20191008092907.GA11332%40rainslide.net.

Re: format=flowed and extra spaces

On 2019-10-08, martin f krafft wrote:
> Thanks, Gary, for your response. It made me realise something, namely
> that Mutt itself seems broken wrt format=flowed. I'll turn to the
> mutt-users list for that.
>
> However, I did have one comment relating to Vim:
>
> >Neither Vim nor mutt should do anything to messages to corrupt
> >their contents. In particular, neither should automatically remove
> >any leading spaces. See RFC 3676.
>
> I am 100% with you on that. However, with Vim being the composer of a
> message, I'd argue that there is no corruption of contents going on,
> if it differentiates between displaying spaces, and saving them to
> the file:
>
> Let me elaborate, using · for spaces and $ for EOL:
>
> Take the following paragraph.
>
> | 1. This is a multiline |
> | indented paragraph |
>
> If &formatoptions doesn't include "aw", then we need those leading
> spaces explicitly, because the indenting is done in such a way as to
> hard-code it into the file. Therefore, Vim should save:
>
> | 1. This is … a multiline$ |
> | ···indented paragraph.$ |
>
> However, if &fo=aw as well as &fo=n is in place, and there is a
> trailing space on the first line, then I would say Vim should really
> not be saving those spaces. Instead, the buffer should really be
>
> | 1. This is … a multiline$ |
> | indented paragraph.$ |
>
> But this then gets displayed as in the original example, i.e. Vim
> displays leading spaces, recognizing the numbered list.
>
> Or at least this should/could be configurable. Don't you agree?

I'm still thinking about this. You're asking for Vim to format its
display of a buffer according the formatting rules of
'formatoptions' without changing the actual contents of the buffer.
My first thought was, "Vim is an editor, not a word processor, and
it doesn't do that sort of formatting for display." But there are
exceptions. For example, I use 'linebreak', 'breakindent' and
conceal to make some text less cluttered more understandable.

However, as I wrote before, format=flowed is intended to help make
email text readable in mail readers that don't support it as well as
in those that do. So, in an email message sent to a general
audience, I would format it to look good in a mail reader that did
not understand format=flowed, then add the trailing spaces and the
Format=Flowed header to help a format=flowed-aware reader reflow the
text as necessary for its display.

So, if my message included a list item like this,

1. This is the first line
and this the second.

I would leave it like that for the benefit of
non-format=flowed-aware email readers, but add a trailing space to
the first line to show format=flowed-aware readers that the two
lines may be flowed together. I think it's up to the
format=flowed-aware reader to recognize that the leading spaces of
the second line are for indentation and should be collapsed to one
space, and that the leading "1. " indicates a list item and that
that line should be wrapped and indented according to its rules for
formatting list items.

> >If some receiving agent claims to support format=flowed, yet
> >blindly includes sequences of spaces in the middle of flowed lines,
> >as in your third example, I would say that agent is broken.
>
> Oh great. Yeah, I'll let the GMail admins know at noreply@gmail.com.

Yep, that's a problem.

> >Also, your second example suggests that mutt is using
> >quoted-printable encoding. RFC 3676 says that quoted-printable
> >encoding "SHOULD NOT be used for Format=Flowed unless absolutely
> >necessary...."
>
> Unfortunately, PGP/MIME needs quoted-printable (mutt's
> pgp_strict_enc), and so one could argue it is "absolutely necessary".
>
> I don't quite understand the ramifications of this though.

I don't either.

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/20191008051043.GB18733%40phoenix.

Re: format=flowed and extra spaces

Thanks, Gary, for your response. It made me realise something,
namely that Mutt itself seems broken wrt format=flowed. I'll turn to
the mutt-users list for that.

However, I did have one comment relating to Vim:

>Neither Vim nor mutt should do anything to messages to corrupt
>their contents. In particular, neither should automatically remove
>any leading spaces. See RFC 3676.

I am 100% with you on that. However, with Vim being the composer of
a message, I'd argue that there is no corruption of contents going
on, if it differentiates between displaying spaces, and saving them
to the file:

Let me elaborate, using · for spaces and $ for EOL:

Take the following paragraph.

| 1. This is a multiline |
| indented paragraph |

If &formatoptions doesn't include "aw", then we need those leading
spaces explicitly, because the indenting is done in such a way as to
hard-code it into the file. Therefore, Vim should save:

| 1. This is … a multiline$ |
| ···indented paragraph.$ |

However, if &fo=aw as well as &fo=n is in place, and there is a
trailing space on the first line, then I would say Vim should really
not be saving those spaces. Instead, the buffer should really be

| 1. This is … a multiline$ |
| indented paragraph.$ |

But this then gets displayed as in the original example, i.e. Vim
displays leading spaces, recognizing the numbered list.

Or at least this should/could be configurable. Don't you agree?

>If some receiving agent claims to support format=flowed, yet blindly
>includes sequences of spaces in the middle of flowed lines, as in
>your third example, I would say that agent is broken.

Oh great. Yeah, I'll let the GMail admins know at noreply@gmail.com.

>Also, your second example suggests that mutt is using
>quoted-printable encoding. RFC 3676 says that quoted-printable
>encoding "SHOULD NOT be used for Format=Flowed unless absolutely
>necessary...."

Unfortunately, PGP/MIME needs quoted-printable (mutt's
pgp_strict_enc), and so one could argue it is "absolutely
necessary".

I don't quite understand the ramifications of this though.

Best, and thanks again!

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

"women love us for our defects.
if we have enough of them,
they will forgive us everything,
even our gigantic intellects."
-- oscar wilde

spamtraps: madduck.bogus@madduck.net

--
--
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/20191007202203.GC27159%40fishbowl.rw.madduck.net.

Re: format=flowed and extra spaces

On 2019-10-07, Gary Johnson wrote:
> On 2019-10-07, martin f krafft wrote:
> > Hello list,
> >
> > I've set up Vim in tandem with Mutt to compose format=flowed emails,
> > i.e. using &fo+=aw in Vim.
> >
> > I'm also in the habit of using numbered and bulletted lists in emails
> > a lot.
> >
> > Unfortunately, the two don't seem to work together well, or I am
> > doing something wrong.
> >
> > For instance, consider the following:
> >
> > 1. This is the first item, spanning two rows because the text is a
> > bit longer than 80 characters, or whatever &tw is set to.
> >
> > 2. This is the second item.
> >
> > The way I have Vim configured means that the second line of the first
> > item is properly indented, i.e. I see:
> >
> > | 1. This is … |
> > | bit long… |
> >
> > At first, I thought those spaces at the start of the second line are
> > "local" in that they are only needed for presentation. However, when
> > Mutt creates a MIME message, it includes those spaces!
> >
> > | 1. This is … text is a=20 |
> > | ···bit longer |
> >
> > This means that recipients who don't use exactly the same font and
> > window size as I do might see the following instead:
> >
> > | 1. This is … text |
> > | is a bit longer |
> >
> > So there is no indent, but there are multiple subsequent spaces in
> > the middle of the line, which makes the whole thing harder to read.
> >
> > I think all of this would be avoided if Vim didn't add those spaces
> > it needs for indenting (presentation) in format=flowed mode.
> >
> > Is this possible? Or am I doing something fundamentally wrong?
>
> The idea of format=flowed is to allow email messages to be displayed
> nicely by email clients that do not support format=flowed as well as
> by those that do. Neither Vim nor mutt should do anything to
> messages to corrupt their contents. In particular, neither should
> automatically remove any leading spaces. See RFC 3676.
>
> Vim takes care of wrapping lines at 78 columns and adds a single
> trailing space to inter-paragraph line breaks. It can also handle

Oops. "inter-paragraph" should be "intra-paragraph".

> formatting quoted paragraphs. That's all it should do.
>
> Mutt takes care of space-stuffing and does something with quoted
> blocks, but I've forgotten what. That's all it should do.
>
> It is the responsibility of the receiving agent to reformat
> format=flowed text as it sees fit. How it does that is not
> specified by the RFC.
>
> If some receiving agent claims to support format=flowed, yet blindly
> includes sequences of spaces in the middle of flowed lines, as in
> your third example, I would say that agent is broken.
>
> Also, your second example suggests that mutt is using
> quoted-printable encoding. RFC 3676 says that quoted-printable
> encoding "SHOULD NOT be used for Format=Flowed unless absolutely
> necessary...."
>
> 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/20191007175404.GA18733%40phoenix.

Re: format=flowed and extra spaces

On 2019-10-07, martin f krafft wrote:
> Hello list,
>
> I've set up Vim in tandem with Mutt to compose format=flowed emails,
> i.e. using &fo+=aw in Vim.
>
> I'm also in the habit of using numbered and bulletted lists in emails
> a lot.
>
> Unfortunately, the two don't seem to work together well, or I am
> doing something wrong.
>
> For instance, consider the following:
>
> 1. This is the first item, spanning two rows because the text is a
> bit longer than 80 characters, or whatever &tw is set to.
>
> 2. This is the second item.
>
> The way I have Vim configured means that the second line of the first
> item is properly indented, i.e. I see:
>
> | 1. This is … |
> | bit long… |
>
> At first, I thought those spaces at the start of the second line are
> "local" in that they are only needed for presentation. However, when
> Mutt creates a MIME message, it includes those spaces!
>
> | 1. This is … text is a=20 |
> | ···bit longer |
>
> This means that recipients who don't use exactly the same font and
> window size as I do might see the following instead:
>
> | 1. This is … text |
> | is a bit longer |
>
> So there is no indent, but there are multiple subsequent spaces in
> the middle of the line, which makes the whole thing harder to read.
>
> I think all of this would be avoided if Vim didn't add those spaces
> it needs for indenting (presentation) in format=flowed mode.
>
> Is this possible? Or am I doing something fundamentally wrong?

The idea of format=flowed is to allow email messages to be displayed
nicely by email clients that do not support format=flowed as well as
by those that do. Neither Vim nor mutt should do anything to
messages to corrupt their contents. In particular, neither should
automatically remove any leading spaces. See RFC 3676.

Vim takes care of wrapping lines at 78 columns and adds a single
trailing space to inter-paragraph line breaks. It can also handle
formatting quoted paragraphs. That's all it should do.

Mutt takes care of space-stuffing and does something with quoted
blocks, but I've forgotten what. That's all it should do.

It is the responsibility of the receiving agent to reformat
format=flowed text as it sees fit. How it does that is not
specified by the RFC.

If some receiving agent claims to support format=flowed, yet blindly
includes sequences of spaces in the middle of flowed lines, as in
your third example, I would say that agent is broken.

Also, your second example suggests that mutt is using
quoted-printable encoding. RFC 3676 says that quoted-printable
encoding "SHOULD NOT be used for Format=Flowed unless absolutely
necessary...."

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/20191007174301.GB10270%40phoenix.