This old bug is about post ignoring a login name in .netrc:
http://savannah.nongnu.org/bugs/index.php?23168
I had closed it, but I really think that it should be fixed.
The current behavior is to determine the user using the
first of:
1) -user switch
2) local login name
I'd like to
2) matching host entry with login in a .netrc
.netrc isn't the right mechanism. Its long-standing use is for mapping
system login credentials for things like telnet and ftp. If, as you state,
pop account names are becoming divorced from login names, then it would be
impossible to use
Lyndon Nerenberg lyn...@orthanc.ca writes:
On 2013-04-03, at 5:25 AM, Paul Fox wrote:
$ scan unseen
...notice that third-from-end message is spam...
$ refile unseen_3 +spam
I don't think '_' is a very good choice. It's too commonly used as a word
separator in text strings. Why
On 2013-04-06, at 4:28 PM, Bill Wohler wrote:
At first I was going to go along, but perhaps we want to reserve the git
terminology in case we do threading which would be a closer analogy
(parent relationship).
Wouldn't threading be handled by external scripts? This sounds like something
I
Wouldn't threading be handled by external scripts? This sounds like
something I would do by generating a list of message-id and references
headers, then doing a tsort and feeding the whole mess back into scan/show.
In fact, the whole concept of 'threads' is something I would like to keep
On Sat, 06 Apr 2013 16:38:22 -0700, Lyndon Nerenberg said:
In fact, the whole concept of 'threads' is something I would like to keep
outside of the base toolset. The reason being there is no single definition
of
what a 'thread' is, and even when you can come up with a definition, it's
On 2013-04-06, at 5:44 PM, valdis.kletni...@vt.edu wrote:
You'd really want to have a cheap incremental method of adding incoming
messages to a thread database, similar to how rcvstore currently updates
the unseen sequence.
A simple per-folder replay log of message-id/reference header data
Lyndon Nerenberg lyn...@orthanc.ca wrote:
On 2013-04-06, at 4:28 PM, Bill Wohler wrote:
At first I was going to go along, but perhaps we want to reserve the git
terminology in case we do threading which would be a closer analogy
(parent relationship).
Wouldn't threading be handled by
On 2013-04-06, at 6:13 PM, Bill Wohler wrote:
Actually, now that I think of it, since threading is usually a toggle,
we can use ~ and ^ whether threading is enabled or not. If it's enabled,
these characters operate upon the thread; if not, they operate on
previous messages.
But how do you
Lyndon Nerenberg lyn...@orthanc.ca wrote:
On 2013-04-06, at 6:13 PM, Bill Wohler wrote:
Actually, now that I think of it, since threading is usually a toggle,
we can use ~ and ^ whether threading is enabled or not. If it's enabled,
these characters operate upon the thread; if not, they
On 2013-04-06, at 6:31 PM, Bill Wohler wrote:
But how do you set or track state on a modeless set of command-line tools?
Add a profile entry to the context file?
It still gets very complicated. Where is the use case that mandates this be
supported in the core tools, vs. providing the
valdis.kletni...@vt.edu writes:
On Sat, 06 Apr 2013 16:38:22 -0700, Lyndon Nerenberg said:
In fact, the whole concept of 'threads' is something I would like to keep
outside of the base toolset. The reason being there is no single definition
of
what a 'thread' is, and even when you can come
12 matches
Mail list logo
