On 07Oct2019 09:31, martin f krafft <madduck@madduck.net> wrote:
>I've set up Vim in tandem with Mutt to compose format=flowed emails,
>i.e. using &fo+=aw in Vim.
For the record, I use:
set formatoptions=walqj
It also matters what your mail headers are set to. Your Content-Type
header says:
Content-Type: text/plain; charset="UTF-8"; format=flowed
Notably there is no delsp=yes; that means delsp=no.
When delsp is "yes", the trailing space on the line before the physical
line ending is logically removed when assembling the post-flowed line.
>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.
RFC 3676 doesn't address lists in any way. It is deliberately designed
to turn plain text into flowable text. The RFC is here:
https://tools.ietf.org/rfcmarkup?doc=3676
>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.
The quoted text above seems to be 2 physical lines here (in vim), with 3
spaces at the end. The final space is the padding to indicate a
flowedline. I find that a little weird myself. because your original
(quoted-printable) message has:
1. This is the first item, spanning two rows because the text is a=20
bit longer than 80 characters, or whatever &tw is set to.
I've indented that 2 spaces, but what we've got there, post quoted
printable decoding, is:
- a line hard against the left margin starting with "1" and ending in a
single space.
- an indented line with 3 leading spaces and no trailing spaces.
So the former line is flowed (trailing space) and the latter line is
space stuffed (a leading space). A leading space is dropped from the
logical line.
Post handling format=flowed, that should become a single logical line
with 2 or 3 spaces between "a" and "bit" depending on delsp=yes or no
respectively.
The purpose of delsp is to make the SP-CR-LF phusical line break
entirely removed; in principle it can thus be planted anywhere in the
logical line, though it is meant to occur between words.
>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.
The first space is. The others are not, at least as far as format=flowed
is concerned.
>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 |
Yes, because those leading spaces are just... spaces.
>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.
I agree.
>Is this possible? Or am I doing something fundamentally wrong?
Well, vim is producing text which is unfriendly to a format-flowed mail
presenter.
What you may need to do is to post process your message before mutt
picks it up, eg by wrapping the invocation of vim in a little script to
post process nicely indents list items item format=flowed friendly
lines, eg by recognising a numbered or bulleted item and dropping the
leading spaces from the second and following lines.
All that would be unnecessary if someone pipes up with some nice vim
setting to help.
For the record, I compose format=flowed mutt emails in vim by setting
$editor to my script "vim-flowed", which presently just invokes vim like
this:
exec vim \
-c 'silent 1,/^$/s/ *$//' \
-c 'set filetype=mail' \
-c 'set formatoptions=walqj' \
${1+"$@"}
Cheers,
Cameron Simpson <cs@cskk.id.au>
--
--
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/20191007092421.GA6211%40cskk.homeip.net.
Monday, October 7, 2019
Sunday, October 6, 2019
format=flowed and extra spaces
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?
Thank you!
--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
in seattle, washington, it is illegal to carry a concealed weapon that
is over six feet in length.
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/20191006203157.GA13998%40fishbowl.rw.madduck.net.
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?
Thank you!
--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
in seattle, washington, it is illegal to carry a concealed weapon that
is over six feet in length.
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/20191006203157.GA13998%40fishbowl.rw.madduck.net.
Re: sed whole file
Jorge Almeida wrote:
> I just noticed an obnoxious behaviour that I think is a new "feature".
> Or maybe it was always like this and I forgot. Or maybe I did
> something wrong, in which case I apologize in advance.
>
> It goes like this:
> I want to replace each occurrence of "foo" by "bar". In command mode I
> start typing
> :%s/foo
>
> and the cursor moves to the first occurrence of foo, even if it means
> moving the page down. Maybe the user would like to copy something in
> the original page? Maybe that's where the string "bar" occurs and the
> user didn't memorize it?
>
> Please help me to restore a sane behaviour
You can reset 'incsearch'.
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.
--
Save the plankton - eat a whale.
/// 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/201910061025.x96APKFo032403%40masaka.moolenaar.net.
> I just noticed an obnoxious behaviour that I think is a new "feature".
> Or maybe it was always like this and I forgot. Or maybe I did
> something wrong, in which case I apologize in advance.
>
> It goes like this:
> I want to replace each occurrence of "foo" by "bar". In command mode I
> start typing
> :%s/foo
>
> and the cursor moves to the first occurrence of foo, even if it means
> moving the page down. Maybe the user would like to copy something in
> the original page? Maybe that's where the string "bar" occurs and the
> user didn't memorize it?
>
> Please help me to restore a sane behaviour
You can reset 'incsearch'.
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.
--
Save the plankton - eat a whale.
/// 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/201910061025.x96APKFo032403%40masaka.moolenaar.net.
Re: sed whole file
Jorge Almeida (12019-10-06):
> I just noticed an obnoxious behaviour that I think is a new "feature".
> Or maybe it was always like this and I forgot. Or maybe I did
> something wrong, in which case I apologize in advance.
>
> It goes like this:
> I want to replace each occurrence of "foo" by "bar". In command mode I
> start typing
> :%s/foo
>
> and the cursor moves to the first occurrence of foo, even if it means
> moving the page down. Maybe the user would like to copy something in
> the original page? Maybe that's where the string "bar" occurs and the
> user didn't memorize it?
It is a new consequence of the 'incsearch' option. It used to affect
searching /, but it recently started to affect replacing during while
editing the command line. And it has the drawbacks you mention about
copy-pasting and in general perusing context.
My work-around for now is to remove the % while editing and put it back
before executing. But I also would like a way of enabling 'incsearch'
for searches and disabling for replacement.
Regards,
--
Nicolas George
--
--
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/20191006100125.z7kfbmzgzldrqm6a%40phare.normalesup.org.
> I just noticed an obnoxious behaviour that I think is a new "feature".
> Or maybe it was always like this and I forgot. Or maybe I did
> something wrong, in which case I apologize in advance.
>
> It goes like this:
> I want to replace each occurrence of "foo" by "bar". In command mode I
> start typing
> :%s/foo
>
> and the cursor moves to the first occurrence of foo, even if it means
> moving the page down. Maybe the user would like to copy something in
> the original page? Maybe that's where the string "bar" occurs and the
> user didn't memorize it?
It is a new consequence of the 'incsearch' option. It used to affect
searching /, but it recently started to affect replacing during while
editing the command line. And it has the drawbacks you mention about
copy-pasting and in general perusing context.
My work-around for now is to remove the % while editing and put it back
before executing. But I also would like a way of enabling 'incsearch'
for searches and disabling for replacement.
Regards,
--
Nicolas George
--
--
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/20191006100125.z7kfbmzgzldrqm6a%40phare.normalesup.org.
sed whole file
I just noticed an obnoxious behaviour that I think is a new "feature".
Or maybe it was always like this and I forgot. Or maybe I did
something wrong, in which case I apologize in advance.
It goes like this:
I want to replace each occurrence of "foo" by "bar". In command mode I
start typing
:%s/foo
and the cursor moves to the first occurrence of foo, even if it means
moving the page down. Maybe the user would like to copy something in
the original page? Maybe that's where the string "bar" occurs and the
user didn't memorize it?
Please help me to restore a sane behaviour
Thanks
Jorge Almeida
--
--
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/CAKpSnpKRxTKqhc8HGbC24QQ%3DbzOmF%3Dn1azvp7N4nzx5EVEU8DA%40mail.gmail.com.
Or maybe it was always like this and I forgot. Or maybe I did
something wrong, in which case I apologize in advance.
It goes like this:
I want to replace each occurrence of "foo" by "bar". In command mode I
start typing
:%s/foo
and the cursor moves to the first occurrence of foo, even if it means
moving the page down. Maybe the user would like to copy something in
the original page? Maybe that's where the string "bar" occurs and the
user didn't memorize it?
Please help me to restore a sane behaviour
Thanks
Jorge Almeida
--
--
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/CAKpSnpKRxTKqhc8HGbC24QQ%3DbzOmF%3Dn1azvp7N4nzx5EVEU8DA%40mail.gmail.com.
Saturday, October 5, 2019
Re: cmdline regex ques
Hi,
-- I was able to use the 'Konfekt/vim-alias' plugin for this -
:Alias q call\ Quit()
:Alias q! call\ QuitBang()
thx again everyone,
-m
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/a2a39da7-2d91-4fd5-94f2-70951e31b29a%40googlegroups.com.
Friday, October 4, 2019
Re: cmdline regex ques
Hi,
-- I guess it evaluates as I type ? So no real way around this.
Perhaps a cmap <CR> could trigger a cmdline substitution ?
Maybe there is such a plugin already.
thx,
-m
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/fa354de4-232d-44a0-9b25-91148f657617%40googlegroups.com.
Subscribe to:
Posts (Atom)