Re: Dual-Monitor help
Bob Proulx <bob@proulx.com> writes:
> lee wrote:
>> Bob Proulx <bob@proulx.com> writes:
>> > For email I use the 'mutt' mail user agent. It is extremely fast. It
>> > ...
>>
>> I totally agree :) And you're definitely going to love gnus! I've used
>> mutt for 15 years or so and never could find anything better --- until I
>> tried gnus. Gnus is like the "power version" of mutt. Give it a try,
>> it's part of emacs. Use emacs 24.2.x, there have been important fixes
>> to gnus.
>
> Maybe I should give gnus a new try. I had tried it before and found
> it much to slow to use. But every couple of decades it is good to
> give programs a second try. :-) I can't remember when I last tried it
> now but I am sure it was on HP-UX 10.20 at the time and the last
> release there was in 1996. It is probably time to give gnus another
> chance.
Yeah, when it has been so long ago ... I think I tried to try it before
long ago and couldn't figure out how to do anything. This time, it
wasn't too difficult.
>> Mutt always felt like badly integrated with emacs. It doesn't work
>> so well to run mutt in emacs, and using emacs as an external editor
>> for mutt isn't ideal, either.
>
> Mutt does have the feel of the other editor rather than emacs. It
Not really, I wouldn't have been able to use it :)
> feels more like do one thing at a time and don't get interrupted. But
> I have many text terminals and will create another one to operate in
> parallel when I am interrupted.
Yes, there's no way around opening another mutt in another terminal when
you need to look at more than group at a time or when you need to look
up other articles in a thread. With gnus, it's only a matter of
switching buffers.
> I have used the configuration of using emacsclient and screen and
> mutt. That works fairly well when running from a very thin client
> where I am going to log into a server system for everything. But for
> running on the local desktop that way never quite hooked me in.
> Although I know other people really like that configuration. I
> definitely use screen and emacs and everything else when working on
> servers remotely. But I usually don't live in email remotely.
Most of the time, I was using an emacs frame and mutt in a terminal.
Some key bindings in emacs are different in a terminal, and I didn't
like that (and I still don't like it). So it was always two different
windows, needing more screen space, and switching back and forth.
Now I just have a maximised emacs frame as a client of an emacs --daemon
and can simply switch buffers as needed. Since emacs works in a
terminal and on the console, it's still only a matter of switching
buffers, everything being the same (except for some key bindings). For
other things I can just use smaller emacs frames --- and even switch to
my emails in them if I want to.
>> Gnus removes this issue. Gnus has features I've been missing in
>> mutt, and mutt will probably never have them. Gnus has features I
>> never even dreamed of.
>
> You have motivated me to queue gnus up for another try. :-)
Cool :) One thing with mutt that bothered me is that you can't really
see what groups (mail folders) you have, and switching between them can
be awkward. The patch that gives you the side panel doesn't really
solve the problem. You can't even rename a group (folder) from within
mutt. Gnus doesn't have this problem --- and it supports an amazing lot
of ways to access your mail. You can even tell it to read an arbitrary
directory and show you the files in it as if it was emails. I'm not
using IMAP --- which is a pain with mutt --- yet gnus seems to be great
with that. You can even work offline if you want to.
>> Gnus is slower than mutt, yet not so slow that I couldn't live with it.
>> It's not really slow.
>
> It being slow was the main reason I had moved away from it before.
Hm, I'm using gnus' native storage method, nnml, which is similar to
maildir in that it stores each mail in its own file, which I've been
using before. I've converted over 100k mails from maildir to nnml, and
that was awfully slow. Other than that, it takes maybe a second or two
to enter a group like for this mailing list which currently has 118700
mails in it. That's because, depending on what you have configured,
gnus shows you a selection of mails, like some of a thread around a new
one that has arrived, and that doesn't take long. You can do things
like bring up all the mails that belong to a thread, and that doesn't
take long, either. It's definitely fast enough for every day
use. You'll see when you try it. You can't really compare it to mutt
because it does so much more.
>> Have you tried dwb? It uses vi-like key bindings and webkit. I kept
>> pressing the wrong keys and went back to seamonkey. Vi just isn't my
>> thing.
>
> No. I will try it. Have you tried midori web browser? It is quite a
> nice lightweight web browser too and it is also based on webkit. It
> also has a nice default set of key bindings for the Unix user.
Not yet, I'll try it :) I really like seamonkey, it just does what it's
supposed to, and the current version is amazingly stable. Other fully
featured browsers aren't so much better on resource usage, so it's hard
to find a replacement.
>> > for the growing 10% that requires fluff and glitter of massive
>> > Javascript and Flash I use Chromium with the 'vimium' extension.
>>
>> Hm I tried Chromium a while ago and found it can't do anything at all.
>
> I find Chromium to have the best support for heavy web sites that have
> lots of Javascript and make use of complicated html and html5. I
> normally use a different browser but then when a site isn't working
> correctly I break out Chromium for the heavy lifting.
Hm, I've never had any issues with seamonkey. I'm currently trying
chromium and found out that for unknown reasons, I apparently can view
flash videos in both seamonkey and chromium without having a player
installed. Now I'm missing something to block advertisements in
chromium --- there's a package xul-ext-adblock-plus and I'm not sure if
that will work with it.
> The only real problem is Chromium not having the support team for
> backports similar to Iceweasel. Therefore I can only really recommend
> Chromium for Testing and Unstable. For Stable Squeeze Midori works
> the best that I have found so far for difficult sites. Or Iceweasel
> from Backports.
Uh I don't like iceweasel. Since I'm running testing, chromium is
available.
> Chromium is annoying for keystrokes because of the architecture of a
> supervisor process and children processes in tabs. Plugins and key
> customization only work in external windows, not internal windows.
> Therefore the user interface is very inconsistent. That drives me
> crazy sometimes.
Hm that's a bad feature.
>> Cool, maybe I should try it again. Seamonkey uses so much CPU and
>> memory that I'd really like to have a replacement.
>
> Or a supplement. Use your favorite on most sites but use a different
> browser on difficult sites.
Yeah, I might end up continuing to use seamonkey. The only thing I
don't like about it is the resource usage it has.
> A problem for me if I were to use Iceweasel for everything is that it
> would grow to consume all memory. By using separate browsers then the
> idle browser can be swapped out by the system. But with using
> Iceweasel for everything it would grow so large that it would consume
> all memory. The system is happier if I keep Iceweasel small and only
> temporarily use other browsers for memory hog sites and then exit them
> afterward.
I have about 60 tabs open in seamonkey, and top says it's using about
1470MB of virtual memory and has about 818MB resident. I have only 2
tabs open in chromium and it shows up 7 times in top, adding up to
3805MB virtual memory, plus a bit for chromium-sandbox. When I look at
chrome://memory-redirect/ , it says 190616k.
Wasn't chromium supposed to be somewhat lightweight or something? I
guess I can just purge that thing.
>> > user I have customized the default screen command key from C-a (used
>> > by me in emacs all of the time) to C-z.
>>
>> That was something that really annoyed me with screen. I couldn't agree
>> with myself with key to use instead and left it at the default and
>> always greatly missed C-a. Tmux uses C-b instead of C-a by default ---
>> somehow that is much better :)
>
> As an emacs user C-b would be a conflict. I use that key all of the
> time.
It's ok for me, I don't use it. Most of the time, I use the cursor
keys, and I use C-a and C-e. It was really hard to get used to not
press C-a in screen, and now I'll have to get used to do that again.
> I chose C-z by default suspend-emacs because in screen I don't
> normally use job control.
Sometimes I use that. In the first window in screen or now tmux, I
become root. When I edit configuration files, I use emacs -nw, and I
put it into the background with C-z rather than quitting it or opening
more windows where I would become root. One window where I'm root is
usually enough. It's always window 0, that helps not to get confused
about who I am. Hm, I should look into giving that window a different
background than the others, maybe that's possible with tmux. If not,
it's a feature request ...
--
Debian testing amd64
Reply to: