[Nmh-workers] ml -- less-based mh mail reader
ralph wrote: > > > (My ~/bin/readlp abuses lesskey(1) so little-used keys in less for > > > reading email, e.g. D, do "quit ^@", and this is picked up by the > > > script which then adds it to the "delete" sequence and moves onto > > > the next email to show. N - next, P - previous, S - spam, etc.) thanks again, ralph -- as i mentioned the other day, i ran with this idea, to see where it went, and i like the result. it turns out my former trick, which formats a bunch of messages together serially, piped into a single instance of less, is still pretty handy when looking for a specific passage in a bunch of 'pick'ed messages, but this new one-less-per-message thing is nice. i haven't touched it for most of a day, and it seems to work, so i guess it's done, for the moment. lyndon, if there's interest in a contrib directory, feel free to add this, if it merits: http://dev.laptop.org/~pgf/mh/ml paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 27.3 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Implementation question: function or component for local mailbox?
ken wrote: > >If you go with a pseudo component, I recommend using a well-defined > >prefix for it to avoid any potential collisions with a real component. > > Fair enough ... but getting back to the higher-level question ... any > thoughts there? :-) well, if i'm still allowed to comment :-) -- i'd prefer the more broken-out solution, because it provides an in-line example of how one might also handle Reply-to: headers, etc. and there's less magic going on behind the curtain. so i'd choose door #3. paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 37.0 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Implementation question: function or component for local mailbox?
>If you go with a pseudo component, I recommend using a well-defined >prefix for it to avoid any potential collisions with a real component. Fair enough ... but getting back to the higher-level question ... any thoughts there? :-) --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Implementation question: function or component for local mailbox?
On Tue, Feb 14, 2012 at 1:23 PM, Ken Hornstein wrote:
> Okay ... so now that's been cleared up :-)
>
> Do people like the idea of:
>
> - A dedicated function %(localmbox)
> - A pseudo component %{localmbox}
> - Extra primitives to build the default local mailbox (%(myname), %(myhost)).
If you go with a pseudo component, I recommend using a well-defined
prefix for it to avoid any potential collisions with a real component.
For example: %{nmh-localmbox}
--ewh
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Implementation question: function or component for local mailbox?
Okay ... so now that's been cleared up :-)
Do people like the idea of:
- A dedicated function %(localmbox)
- A pseudo component %{localmbox}
- Extra primitives to build the default local mailbox (%(myname), %(myhost)).
?
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Implementation question: function or component for local mailbox?
ken wrote: > >it's completely possible that i'm misunderstanding the previous > >consensus, but i sort of thought that after allowing for "a knob in > >mh-profile" (which is satisfied with just the first half of what > >you just suggested), the second 2nd and 3rd bullets in the list you > >referenced would be handled outside the bounds of the message draft. > >after all, if the user edits the draft and removes the pertinent line, > >they MH still needs to provide a From: header. > > That was not my understanding of things. The plan is now if post doesn't > get a From: line, that's an error. See: > > http://lists.nongnu.org/archive/html/nmh-workers/2012-01/msg00090.html oops, right. i remember that now. sorry for the noise. paul > > So the question then becomes: "Okay, the user hasn't configured a > Local-Mailbox in .mh_profile - what do we put there instead?" Or > more specifically: "What should the DEFAULT component file put in there?" > > The start of the thread where this was all hashed out is below. > It's rather long, but you can read it if you want to see how the > discussion evolved. > > http://lists.nongnu.org/archive/html/nmh-workers/2012-01/msg00032.html > > >so there would be no need for new %(myname) and %(myhost) facilities. > >i'd honestly be surprised if many MH installations rely on the GECOS > >field, and its been a long time since my current hostname played any > >part in my email address. > > Well, right now the GECOS field gets put in as your "name" if you > don't supply anything. Actually, check out mmailid ... you might be > surprised as to what's happening there :-) > > --Ken > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 38.8 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Implementation question: function or component for local mailbox?
>it's completely possible that i'm misunderstanding the previous >consensus, but i sort of thought that after allowing for "a knob in >mh-profile" (which is satisfied with just the first half of what >you just suggested), the second 2nd and 3rd bullets in the list you >referenced would be handled outside the bounds of the message draft. >after all, if the user edits the draft and removes the pertinent line, >they MH still needs to provide a From: header. That was not my understanding of things. The plan is now if post doesn't get a From: line, that's an error. See: http://lists.nongnu.org/archive/html/nmh-workers/2012-01/msg00090.html So the question then becomes: "Okay, the user hasn't configured a Local-Mailbox in .mh_profile - what do we put there instead?" Or more specifically: "What should the DEFAULT component file put in there?" The start of the thread where this was all hashed out is below. It's rather long, but you can read it if you want to see how the discussion evolved. http://lists.nongnu.org/archive/html/nmh-workers/2012-01/msg00032.html >so there would be no need for new %(myname) and %(myhost) facilities. >i'd honestly be surprised if many MH installations rely on the GECOS >field, and its been a long time since my current hostname played any >part in my email address. Well, right now the GECOS field gets put in as your "name" if you don't supply anything. Actually, check out mmailid ... you might be surprised as to what's happening there :-) --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Implementation question: function or component for local mailbox?
ken wrote: > > > As previously discussed, I've been looking at putting the "From" > > > address in message draft via extensions to the format language (the > > > existing syntax doesn't have that ability). > > > >can you expand on that? what is it that can't be done? > > Wlll let me put it this way. There is no function or component > today that corresponds to nmh's idea of what the "local mailbox" is. > > > > > > > I see two possibilities as to how to implement this: > > > > > > - A new function, e.g. %(localmbox). > > > >can't this be done now, with something like "%(profile Local-Mailbox)"? > >(or similar -- my mh-format skilz are sketchy at best.) > > Hm, I forgot about that. But if you recall, this is what we > came up with in terms of "what my local mailbox is": > > http://www.mhonarc.org/archive/html/nmh-workers/2012-02/msg00021.html > > With %(profile Local-Mailbox) we can do the first one. I don't > think we have any escapes that can do the others although ... > maybe I'm over-thinking this (which always happens). We have %(me) > today. We could easily add an escape to get "local hostname" (which > would be either localname from mts.conf or the output of "hostname"). > So maybe we could get away with something like this: > > From: %<(profile Local-Mailbox)%(putstr)%|%(myname) <%(me)@%(myhost)>%> [ the agreed-on list again, for reference: Make the "default" email address be (in decreasing precedence order) - A knob in .mh_profile (Local-Mailbox ?) - `whoami`@mts.localname - `whoami`@`hostname` ] it's completely possible that i'm misunderstanding the previous consensus, but i sort of thought that after allowing for "a knob in mh-profile" (which is satisfied with just the first half of what you just suggested), the second 2nd and 3rd bullets in the list you referenced would be handled outside the bounds of the message draft. after all, if the user edits the draft and removes the pertinent line, they MH still needs to provide a From: header. in other words, once the user has been given a chance to configure their preferred From: address, or to add it manually during composition, then the other two fallback options are hard-coded internally. so there would be no need for new %(myname) and %(myhost) facilities. i'd honestly be surprised if many MH installations rely on the GECOS field, and its been a long time since my current hostname played any part in my email address. (but again, i'm probably missing something.) paul > > Where %(myname) would get the user's real name from either SIGNATURE or > the GECOS field, and %(myhost) would get the local hostname from > mts.conf (localname) or gethostname(). Hm, I'll have to parse ismymbox() > more closely to make sure that will DTRT. I guess I was thinking that > having one entry point inside of nmh to create the idea of "the local > mailbox" might be more useful. > > --Ken > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 38.1 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Implementation question: function or component for local mailbox?
> > As previously discussed, I've been looking at putting the "From" > > address in message draft via extensions to the format language (the > > existing syntax doesn't have that ability). > >can you expand on that? what is it that can't be done? Wlll let me put it this way. There is no function or component today that corresponds to nmh's idea of what the "local mailbox" is. > > > > I see two possibilities as to how to implement this: > > > > - A new function, e.g. %(localmbox). > >can't this be done now, with something like "%(profile Local-Mailbox)"? >(or similar -- my mh-format skilz are sketchy at best.) Hm, I forgot about that. But if you recall, this is what we came up with in terms of "what my local mailbox is": http://www.mhonarc.org/archive/html/nmh-workers/2012-02/msg00021.html With %(profile Local-Mailbox) we can do the first one. I don't think we have any escapes that can do the others although ... maybe I'm over-thinking this (which always happens). We have %(me) today. We could easily add an escape to get "local hostname" (which would be either localname from mts.conf or the output of "hostname"). So maybe we could get away with something like this: From: %<(profile Local-Mailbox)%(putstr)%|%(myname) <%(me)@%(myhost)>%> Where %(myname) would get the user's real name from either SIGNATURE or the GECOS field, and %(myhost) would get the local hostname from mts.conf (localname) or gethostname(). Hm, I'll have to parse ismymbox() more closely to make sure that will DTRT. I guess I was thinking that having one entry point inside of nmh to create the idea of "the local mailbox" might be more useful. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Implementation question: function or component for local mailbox?
ken wrote:
> As previously discussed, I've been looking at putting the "From" address
> in message draft via extensions to the format language (the existing
> syntax doesn't have that ability).
can you expand on that? what is it that can't be done?
>
> I see two possibilities as to how to implement this:
>
> - A new function, e.g. %(localmbox).
can't this be done now, with something like "%(profile Local-Mailbox)"?
(or similar -- my mh-format skilz are sketchy at best.)
paul
>
> - A new pseudo-component, e.g. %{localmbox}.
>
> In terms of implementation ... they are probably a wash. The first
> requires a new format instruction; the second does not, but it does
> require some stuff in the interpreter side, and that actually is a
> little bit magical as components you are interested in are "seeded"
> before you call fmt_scan() (this is why some programs use a special
> "text" component); obviously this one would be handled internally.
>
> The advantage to doing it as a component would be you could use address
> functions like %(proper) on it (but I don't know how common that is).
> The disadvantage is that you could never have a "real" message component
> called "localmbox"; I don't know how common that would be either.
>
> Thoughts? I've gone back and forth on this and I don't really know
> which would be better.
>
> --Ken
>
> ___
> Nmh-workers mailing list
> Nmh-workers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
=-
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 37.8 degrees)
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Implementation question: function or component for local mailbox?
As previously discussed, I've been looking at putting the "From" address
in message draft via extensions to the format language (the existing
syntax doesn't have that ability).
I see two possibilities as to how to implement this:
- A new function, e.g. %(localmbox).
- A new pseudo-component, e.g. %{localmbox}.
In terms of implementation ... they are probably a wash. The first
requires a new format instruction; the second does not, but it does
require some stuff in the interpreter side, and that actually is a
little bit magical as components you are interested in are "seeded"
before you call fmt_scan() (this is why some programs use a special
"text" component); obviously this one would be handled internally.
The advantage to doing it as a component would be you could use address
functions like %(proper) on it (but I don't know how common that is).
The disadvantage is that you could never have a "real" message component
called "localmbox"; I don't know how common that would be either.
Thoughts? I've gone back and forth on this and I don't really know
which would be better.
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
