Hello Martin.
Martin Neitzel <[email protected]> wrote:
|steffen> (Aaah, colours again… (Is that already degeneration??))
Uh! Don't remind me of our messy, super restricted quoting
mechanism. Terrible!
And is that special treatment of *indentprefix*, deduced from
hfield1("from")? Hmm. I really would like to have a generic
format facility that could then be used for *indentprefix* and
something like mutt(1) $attribution. That is: sigh.
|Since you are asking: I usually detest coloring (when it's at the "word"
|level, as in ls output or with syntax coloring) but find it actually
|helpful as used in s-nail at the structure level (just marking the mail
|header), in particular since I have to deal with forwarded mails and
|embedded headers very often.
Yes, well. I am of such sort myself. I have, e.g., a three color
vim(1): anything black-on-white except for comments (darkred or
brown) and TODO/FIXME/ERROR markers (red, bold, reverse).
That is a level of structuring that meets my, well, needs.
I think it helps me especially as the hours pass by, or when
scrolling page-wise, since it disrupts the otherwise rather
uniform look.
The same is true for mail, i most often look over a page of
messages and collect the messages i want to look at on the command
line, then `p' them in one go. Having some structuring helps
here, especially so since our output is so unrefined.
Structurizing the message headers based on their field name is
something i use, so that Subject: and From: standout, and From_
stands back (we can't address it yet as such).
I'm sorry that message body content won't be addressed for
a while. If i look in my .muttrc i see i had rules that marked
out URIs and e-mail addresses.
|What I (and a colleague of mine) never understood: what's the point of
|the s-nail line-editor?
|
|Different users have different use cases, and I may well be missing
|the scenario where the line-editor makes a major difference, worth
|the efforts you obviously spend on it. Perhaps you could shed
|some light on your motivation for adding this feature?
^.^ I couldn't live without it, really.
My history file for example has a couple of `move' entries,
i usually just type "mo" and then ^R until i get where i want.
I also have some entries with quite complicated search
expressions, e.g., to select status messages of several
bugtrackers, etc.
|Did it start out at a sane level (editing the "ask"/"askcc"/... header
|inputs, as e.g. NetBSD mail(1) allows, too), and did then escalate
|into the msg body input, because it was just a simple change (and even
|option-controlled)? I could fully understand that.
With shortcuts, ghosts and such that is fine. What i always truly
hated was that prefilled fields, like in attachment filenames to
`write', couldn't be erased as easily as i wanted it.
The Mail codebase only has fewest places where the interactive
input function is called, so. I think...
I remember Stephen Isard mentioning a readline wrapper program,
which was actually cool (i have forgotten the name).
|Thanks for the editing feature, but as far as I'm concerned, please
|don't lose any sleep on it:
|
| (1) At the command level, most commands are just 1 or 2 characters.
| cmd-line-editing or cmd-history are of no use for me here.
Yes, yes, but...
| (2) At the message writing level, I can either compose a short new
| mail using ^H/^W/^U good enough or, if not (mostly the case :-),
| I quickly use "~v" to drop into a Real Editor.
I admit that i practically don't use tilde escapes, but ~p.
I use *editalong*.
|"Builtin Line-Editing" doesn't cut it for me, since it's *single*
|line-editing, and what I need to re-edit most is always multi-line:
|trimming quotes down, interleaving my reply, reformatting paragraphs.
Yes. Well. ...
|I'm afraid the s-nail builtin line-editor may entice users to send
|more senseless full-quotes. Be those coloured or not, I would call
|that "degeneration" :-)
I'm happy it is getting better! And one day, we will support
flowed text, too.
Ciao, Martin.
--steffen
------------------------------------------------------------------------------
__________________________________
[email protected]
