Re: Happy New Year!
On Fri, Jan 02, 2009 at 04:53:54PM EST, Kyle Wheeler wrote:
> On Friday, January 2 at 04:18 PM, quoth Chris Jones:
> > Since I wasn't blessed with photographic memory, the only thing
> > that's missing in mutt's interface as far as I am concerned is some
> > form of screen-splitting capablity that would let me display/scroll
> > a few messages in "windows" in that huge vacant empty space at the
> > right of the screen while replying to one post rather than have to
> > switch to another screen "window" and fire up another instance of
> > mutt because I can't remember who said what .. when .. etc. That's
> > one patch I would love to be able to write.
>
> Heh. Baloney - what you really want is the ability to have multiple
> mutt's up and visible at the same time in the same terminal, right? I
> mean, dig into vim's behavior a bit, and that's essentially what it
> does. Granted, there's a single engine behind the whole thing, but
> essentially vim is an editing engine that operates on "buffers", and
> vim's screen splitting gives you full vim functionality on another
> buffer (which can be tied to the same file as the original buffer or
> can be something else entirely). The connection between buffers in a
> split-vim is somewhat tenuous... the copy-paste buffers are shared,
> and there's some variable scoping you can do, but that's about it.
No, I'm talking about being able to display/scroll a couple of related
messages that I would like to refer to.. or possibly copy/paste from..
when I'm replying to a post without having to fire up another term and
then fire up another mutt instance .. and then.. etc. The reason I
mentioned vim's split-screen mode had nothing to do with implementation
details.. I'm just another Joe User and for the sake of clarification,
I was comparing my experience with mutt with the one I have with another
great text-mode screen-mode application that has considerably improved
my experience as a _user_ where I all I need to do to access the
contents of some document that I need to refer to here & now, is issue
the relevant flavor of the :split command.. done. Firing up an xterm
(or creating a new gnu/screen window) .. firing up another instance of
mutt .. drilling down to the particular message I need .. having
gnu/screen do a screen split .. bringing up the other instance of mutt
in said split window .. and what..? repeat the process if I happen to
need to refer to a second message? You can't be serious.
> And what, really, do you want these two mutt "screens" to share? Do
> you care whether they use the same connection to the server or not?
> (I'm guessing no). Do you want hooks that trigger in one to affect the
> other? To put it a different way, do you want them to share the
> current configuration? (I'm guessing no - and a power user would
> probably say "absolutely not!"))
I'm a powerless _user_ .. as such I am only interested in these aspects
insofar as they affect my experience as a _user_
I would be totally out of line making any kind of assumptions relative
to implementation choices.
> So, when you think about it, you're actually asking for a kind of
> "meta"-mutt that maintains multiple mutts and allows you to see them
> and keep them up at the same time and makes it convenient (and fast)
> to switch between them. Right?
No, I am more prosaically suggesting that it might be a good thing if
mutt could have the added capability of displaying one or several
messages (and why not the fine mutt manual that I'm constantly being
referred to) in the unused space to the right of my screen .. not sure
what a "meta-mutt that maintains multiple mutts" has to do with that.
Come on, Kyle .. Say, I want to check something about the flags in
mutt's index in the mutt manual .. so I hit <F1> .. painstakingly locate
the relevant paragraph in the manual .. and then I need to take another
look at the display of my index .. so I get out of the manual .. take a
long hard look at my index and flags .. hit <F1> again .. iterate the
above maybe what .. another ten times? I guess that's when I suddenly
remember I should've fired up another instance of mutt in the first
place.
> From that perspective, what's wrong with running multiple screen
> sessions? GNU Screen can split the terminal, and allows you to run
> multiple mutts in the same terminal (ctrl-a S).
For one thing GNU/screen might not be available .. another is that
vertical split in GNU/screen is not very mature at this point ..
scrolling in particular is terribly slow and at least with my terminfo
entry leaves artefacts all over my display .. not a trivial problem,
btw.. but more to the point .. this approach does not strike me as the
right way to handle issues that belong in the application's interface
and as such should be handled by the application.
> As I see it, the biggest problem with GNU Screen's split-terminal
> approach is that the keys for switching between sections is *awful* -
> vim's ability to do control-W-{direction} is much better. GNU Screen
> needs a patch (http://fungi.yuggoth.org/vsp4s/) to do vertical splits
> of course, but supposedly version 4.1 will have that natively. And of
> course, you'd want screen to simply start up another mutt
> automatically when you split the screen. You can *kinda* get that by
> running screen like this:
>
> env SHELL=mutt screen
>
> ... but that's not perfect (there *ought* to be a way to make GNU
> screen automatically run $SHELL for a newly created region, but I
> can't find it in the documentation at the moment).
Yes, I always found gnu/screen's coming up with an apparently "dead"
sub-window rather disconcerting .. but then why a shell ..? Maybe what
the developer had in mind is just open the "viewport" and leave it to
the user to decide which existing "window" he wants to move therein..
At the totally non-technical intuitive level I function, I have a
feeling that this makes sense because it only reproduces the usual
behavior of window managers when you create a new workspace/desktop ..
Where gnu/screen is concerned, once you have opened your new viewport
(region, subwindow) you can either move to it the contents of an already
existing screen "window":
CTRL+A S
CTRL+A <TAB>
CTRL+A n
.. where "n" is an integer that specifies the existing screen "window"
whose contents you want to display..
or,
launch therein a new instance of some application or other:
CTRL+A S
CTRL+A <TAB>
CTRL+A :
:screen application_name
e.g. CTRL+A :screen elinks .. CTRL+A :screen vim .. etc.
> Anyway, it *seems* like GNU Screen 4.1 will solve the problem, more or
> less, right?
I don't see this as a "problem" ..
GNU/screen already has horizontal screen split .. vertical splits as
offered by the CVS snapshot or the upcoming new release will just add
more flexibility. There's nothing wrong with firing up another Xterm
under X or Alt_Fx .. logon .. mutt -y etc. under the linux console. The
latter will not let you have the two instances side by side, or copy and
paste between the two, but then I strongly believe linux console users
only deserve to burn in hell anyway :-)
All the same, I do feel that having those read-only viewports where one
could refer to a few related messages while replying to a post within
one instance of mutt would be considerably more effective than any of
the above work-arounds.
Thanks much for the insight you provided as to why from the designer's
angle this might not be such a trivial feature to implement.
CJ.