Re: Happy New Year!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday, January 3 at 12:07 AM, quoth Chris Jones:
> No, I'm talking about being able to display/scroll a couple of
> related messages that I would like to refer to..
... which you can do with multiple mutts.
> or possibly copy/paste from..
... and since mutt doesn't use a copy/paste buffer for anything, what
are you wishing mutt would do here that would affect copy/paste
behavior? For vim it makes sense: it is useful to be able to copy from
one buffer and paste it into a different buffer. But for mutt, what
are you proposing here?
> when I'm replying to a post without having to fire up another term
> and then fire up another mutt instance .. and then.. etc.
I understand that currently it requires multiple steps, and that's
annoying. But it seems to me that the simplest solution to a problem
with too many steps is to try to find a way to automate it, not to
demand a completely new way of doing it.
>> 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_
Well let's think about how this might affect your experience as a
_user_, eh? For example, do you use hooks? Many mutt folks use
folder-hooks to change their sending address, especially for mailing
lists, like this:
folder-hook . 'my_hdr From: me@xxxxxxxxxxx'
folder-hook =mutt 'my_hdr From: me-mutt@xxxxxxxxxxx'
folder-hook =vim 'my_hdr From: me-vim@xxxxxxxxxxx'
Or, if you prefer, change the status_format or index_format based on
what folder you're in.
If you have mutt split into two "screens" and then make one screen
navigate to the mutt folder and the other navigate to the vim folder,
how should that work? Do the folder-hooks get triggered? If they do,
does the hook triggered for the vim folder in one "screen" affect the
sending address (of *_format variable) that gets used for new messages
composed in the other "screen" that's looking at the mutt folder? I
imagine, as a user, you'd say: no, that wouldn't make sense. But then
what? Hooks can be rather complex. Should both mutt "screens" maintain
completely independent configuration states so that each one has its
own sending address? How about all the other configuration options
that can be altered from a hook (i.e. ALL of them)? So, if you've got
a single mutt instance that's maintaining separate configuration
states for every "screen". What about folks who use a macro to set
their return address? Like this:
macro pager,index F1 '<enter-command>my_hdr From: work@xxxxxxxxxxx<enter>'
Should that macro affect all "screens"? If so, how is it different
from the folder hooks? If not, why not? How do you tell which screen
you've triggered the macro in? Perhaps we should have some sort of a
way of saying "this setting change should affect all screens" and
"this change is local-only". But if we do, what's the default
assumption? And how badly will it break user's existing configurations
in surprising, potentially destructive ways?
How this works affects you as a *user*.
> I would be totally out of line making any kind of assumptions relative
> to implementation choices.
It's not just a measly implementation detail that you'd never notice
as a user, it's a question of how mutt should behave in response to
common configurations.
> Come on, Kyle ..
I don't think I'm being unreasonable by pointing out some real
functional user-visible problems with what you're suggesting. I'm not
saying it can't be done, I'm saying that it would require a *major*
overhaul of how mutt configurations work, and would essentially ensure
that your (and everyone else's) carefully crafted muttrc would
probably need to be completely rewritten.
> 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.
Seriously? I don't think mutt is a very good manual browser, so I
*never* just press <F1> to read the manual. Do you think mutt's very
good at that? It's basically `less`, only not as convenient.
> For one thing GNU/screen might not be available ..
Oh come on. And a sufficiently modern version of mutt with all the
latest features might not be available either.
> 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 ..
I haven't used screen's vertical split capability much, but this
sounds like your terminfo doesn't quite match your terminal correctly.
> 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.
And my question is: why does this naturally seem to you to be a mutt
problem?
> CTRL+A S CTRL+A <TAB>
> CTRL+A :
> :screen application_name
>
> e.g. CTRL+A :screen elinks .. CTRL+A :screen vim .. etc.
It seems like screen ought to have a way to shorten this chain of
commands. The man page mentions that there's a way to establish your
own control-key to spawn a command of your choice in a new window
which can then be placed into the dead split screen area, but doesn't
say how to span the command of your choice in a new split-screen
window.
> 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,
? Copy and paste in mutt?
> 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.
... read-only? I'm curious what you mean by that.
> 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.
I'm not trying to be a jerk here, I'm just trying to point out that
even basic interface questions require more thought than just "I wish
it would do X", because most of the time it often turns into "in order
to do X, that would mean that Y would have to happen, which would be
either bad or very confusing for users". In this case, X is "open
another message in a separate little 'window'-type thing" and Y is
"changing how all of mutt's configuration variables and syntax work to
account for having more than one context in which commands can
execute". That doesn't seem worth it just to be able to save a few
keystrokes over what can be achieved with GNU Screen or even just
multiple terminals (and we're not even discussing the amount of
developer effort that such a thing would require, even if everyone was
okay with how disruptive it would be to existing mutt installs).
Am I misunderstanding you?
~Kyle
- --
Time is an illusion. Lunchtime doubly so.
-- Douglas Adams
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iD8DBQFJXxapBkIOoMqOI14RAmdxAKDMO29sAyu9EqKWAyDt7GrzyREkSgCg9axQ
ZyWv3WgtzHeU35/89NR9lJA=
=N+Bx
-----END PGP SIGNATURE-----