Self-introduction of a new vimpulse user
Hi all, let me introduce myself as a new user of vimpulse. I have been using it for around two weeks or so and studied most of the list archives, as I was eager to learn as much as possible. My background: I'm an experienced user of both Emacs and vim; I used to use Emacs for large files (e.g. large LaTeX documents) and tracking my working hours with org-mode (still need to learn more about the other features of org-mode), and vim for small files (e.g. configuration files). Vimpulse now enables me to combine vi's healthy key bindings with Emacs's rich functionality. I also know some Emacs Lisp (unfortunately not yet enough for actively contributing to vimpulse), whereas I have never really customized vim. For the record: I hardly know more about git than "clone" and "pull", but I think it's worth running vimpulse from the git sources – which I do. I have bound the tab key to viper-intercept-ESC-key and appreciate that it is so easy now, with vmap and imap. I have vimpulse-surround and viper-in-more-modes installed. Eventually I will also give vim-mode a try, but so far I'm quite busy and vimpulse works well. A few more mails with bug reports and feature requests will follow within the next days. Cheers, thanks for vimpulse, and keep the good work up, Christoph PS: This mail was sent from KMail (KDE), where I had been using gvim as an external editor for composing mails so far. But now I have switched that to Emacs+vimpulse, using post-mode (and some abbrevs), which boosted my productivity in writing mails. -- Christoph Lange, http://kwarc.info/clange/, Skype duke4701
Hi Christoph, welcome to the list! We no longer use Trac, so the mailing list is indeed the preferred medium for bug reports. By the way, which Emacs version are you using? Note that Vimpulse is now hosted at Gitorious, not Assembla. The project URL is http://gitorious.org/vimpulse, and you can clone the repository with git clone git://gitorious.org/vimpulse/vimpulse.git To get the latest Git commits, use "git pull"; to see a list of updates, use "git log". (If something stinks, you can always revert to an earlier commit with "git checkout <SHA-1>" -- e.g., "git checkout a007716". To go back to the newest commit, use "git checkout master".) I will be pushing some fixes to the repository in the upcoming days. -- Vegard PS: Your e-mails are not wrapped properly. Could you please toggle autowrapping in KMail or use "M-q" in Emacs? Thanks!
Hi Vegard, hi all, thanks a lot for your quick help! Sunday 2010-10-31 18:38 Vegard Øye:
We no longer use Trac, so the mailing list is indeed the preferred medium for bug reports. By the way, which Emacs version are you using?
GNU Emacs 23.2 on Linux (Gtk/X.org interface)
Note that Vimpulse is now hosted at Gitorious, not Assembla.
Sorry, it was easy to misunderstand that from my comments, but I was aware of that. The only reason why I referred to Assembla was the Trac, for which I had not noticed a replacement.
...
To get the latest Git commits, use "git pull"; to see a list of updates, use "git log". (If something stinks, you can always revert to an earlier commit with "git checkout <SHA-1>" -- e.g., "git checkout a007716". To go back to the newest commit, use "git checkout master".)
But thanks for these git hints – all that is good to know.
PS: Your e-mails are not wrapped properly. Could you please toggle autowrapping in KMail or use "M-q" in Emacs? Thanks!
I should have realized that reading non-wrapped mails is particularly inconvenient in the online list archive. And of course I should respect the preferences of the recipients of my mails, i.e. you. So I hope I won't forget wrapping mails to this list any more. Other than that, and I'm aware that on a list related to text editors, I am opening a can of worms, my opinion is: Most contemporary mail clients wrap mails with long lines to the width of the window. 70 characters on a widescreen is IMHO not always user-friendly. I, as the reader of a mail, would like to have full control over the display of a mail, and when the mail contains long lines, I have full control in that I can resize the window as preferred. I know few mail clients that give me that much control if the lines of a mail are wrapped, i.e. mail clients that would re-wrap such mails from, say, 70 to 90 columns, if my window is 90 columns wide. (Maybe mutt can do that, I don't recall.) For that reason I intentionally switched to non-wrapped lines in e-mails some time ago. Cheers, Christoph -- Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701
On 2010-10-31 19:20, Christoph LANGE wrote:
Other than that, and I'm aware that on a list related to text editors, I am opening a can of worms, my opinion is: Most contemporary mail clients wrap mails with long lines to the width of the window. 70 characters on a widescreen is IMHO not always user-friendly.
Actually, there exists a technical solution to this problem: Format=Flowed. The idea is that the mail client inserts a space at the end of each line it breaks, so that lines are divided by a space+newline sequence rather than just a newline. These are referred to as "soft" line breaks. A mail client which knows about Format=Flowed will ignore the soft breaks and flow the text, while a client which doesn't will display it as regular hard-broken text (since the trailing spaces are invisible). I know Thunderbird supports this by default, but I haven't used it as I prefer to edit my mails outside of Thunderbird. (Plus that I would need to come up with a way to distinguish flowed passages from unflowed, since I don't want code fragments and the like to flow. It's not impossible -- I tend to indent code by four spaces, so I could conceivably write a routine in Emacs which overlooks such lines and adds trailing spaces to the rest.) Format=Flowed is defined in RFC 2646, which see: http://www.ietf.org/rfc/rfc2646.txt -- Vegard
Sunday 2010-10-31 20:55 Vegard Øye:
Actually, there exists a technical solution to this problem: Format=Flowed. ... http://www.ietf.org/rfc/rfc2646.txt
Thanks for the background! – I didn't know that. Indeed KMail does not support it. I have just voted for that bug.
(Plus that I would need to come up with a way to distinguish flowed passages from unflowed, since I don't want code fragments and the like to flow. It's not impossible -- I tend to indent code by four spaces, so I could conceivably write a routine in Emacs which overlooks such lines and adds trailing spaces to the rest.)
A quick Google search tells me, IIUC, that it has at least been implemented in an Emacs-based mail client, and that _that_ implementation respects Emacs's filling behavior in that it distinguishes hard newlines from the soft newlines that line filling generates: http://www.gnus.org/manual/emacs-mime_16.html Not sure, however, if that is helpful when merely using Emacs as an external editor for some other mail client. Cheers, Christoph -- Christoph Lange, http://de.wikipedia.org/wiki/Benutzer:Langec, Skype duke4701
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Vegard, one more comment on this: On 10/31/2010 08:55 PM, Vegard Øye wrote:
Actually, there exists a technical solution to this problem: Format=Flowed. ? I know Thunderbird supports this by default,
I made some experiments with Thunderbird (or muttator, I should rather say; http://vimperator.org/muttator), and it turned out that it does not cooperate with Enigmail, i.e. GPG.
but I haven't used it as I prefer to edit my mails outside of Thunderbird. (Plus that I would need to come up with a way to distinguish flowed passages from unflowed, since I don't want code fragments and the like to flow. It's not impossible -- I tend to indent code by four spaces, so I could conceivably write a routine in Emacs which overlooks such lines and adds trailing spaces to the rest.)
Not sure if that is a problem. IIUC, the "flowing" is not applied as long as a message is in Thunderbird's composer (or in an external editor), but only when sending. But I'm not exactly sure. Cheers, Christoph - -- Christoph Lange, http://de.wikipedia.org/wiki/Benutzer:Langec, Skype duke4701 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzbBg4ACgkQvqg+op3jsjPsUQCfY4IA5tnJXzzeHublVzxIo644 ZNgAoMawiT0aYWDzICuMmPHVjFoB89ie =+gDw -----END PGP SIGNATURE-----
participants (3)
-
Christoph LANGE -
Christoph LANGE -
Vegard Øye