MH-E

Peter S Galbraith <p.galbraith@...> writes:

> The `l' key being right next to the `k' key, I sometimes print messages
> that I really don't want in folder-mode.
> 
> I'd be a happy user of a `mh-print-msg-confirm' variable.
> It could default to nil since that's the way it works now.
> 
> Comments?

I agree... I do the following myself to avoid the problem.

	-- Mark

(defadvice mh-print-msg (around query-before-printing-message-or-seq
				activate)
  (if (yes-or-no-p (format "Really print this message or sequence? "))
      ad-do-it))

Jeffrey C Honig <jch@...> wrote:

> Peter S Galbraith <p.galbraith@...> wrote:
> 
> > The `l' key being right next to the `k' key, I sometimes print messages
> > that I really don't want in folder-mode.
> 
> I do the same thing.
> 
> > I'd be a happy user of a `mh-print-msg-confirm' variable.
> > It could default to nil since that's the way it works now.
> 
> Sounds good.  Enclosed is some printing code that uses ps-print that I
> have been using for a while.  I should probably fix it up and get it
> into the distribution.  I have it assigned to `PP', maybe the default
> printing style could be `Pl' and the use of `l' could be deprecated.
> 
> I remember Satyaki saying that some special processing is needed for
> messages that might require user interaction, but I do not remember much
> about it.  Maybe this would be a good time to solicit comments on it.

Actually, Moving to a `P' prefix would replace the need for the
suggested defcustom, so I like that a lot better.

`P' is hard to type by mistake, and even if you do you'd need to type
another character to actually get anything printed.

Let's do that!

Peter S Galbraith <p.galbraith@...> wrote:

> The `l' key being right next to the `k' key, I sometimes print messages
> that I really don't want in folder-mode.

I do that all the time too. In fact, I did the equivalent of what Mark
did by having it query first. I'd therefore be open to having the query
always, or rebinding to P. I think I'm leaning towards the latter.

-- 
Bill Wohler <wohler@...>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Hi Satyaki,

A few points on the patch...

 1) ps-print-color-p

    The ps-print-color-p variable has odd semantics.
    
    It is a variable rather than a predicate function.
    
    It returns one of 
       nil
       t
       black-white
    
    I understand why we have our own version of the variable, what I don't
    understand is why we have to break our own naming conventions to create
    it...


  2) use of eql rather than eq ... I was under the impression that using
     common lisp macros was okay, but using the functions was a bad idea.
     This is just something like

	  (if (and (numberp a) (numberp b)) (equal a b) (eq a b))

     right? If so, why do we need to use eql to compare against nil or t
     or 'black-white or 'ps-spool-buffer-with-faces. Could we just use
     eq instead please?

The rest of the file looks fairly nice.

	Thanks,
	-- Mark

Mark D. Baushke <mdb@...> writes:

> Hi Satyaki,
> 
> A few points on the patch...
> 
>  1) ps-print-color-p
> 
>     The ps-print-color-p variable has odd semantics.

We can't control it, since it is a part of Emacs. As you suggest,
we should probably change the name of mh-ps-print-color-p to
something more appropriate.

>   2) use of eql rather than eq ... I was under the impression that using
>      common lisp macros was okay, but using the functions was a bad idea.
>      This is just something like
> 
> 	  (if (and (numberp a) (numberp b)) (equal a b) (eq a b))
> 
>      right? If so, why do we need to use eql to compare against nil or t
>      or 'black-white or 'ps-spool-buffer-with-faces. Could we just use
>      eq instead please?

You are right. I have replaced all calls to eql with eq.

Thanks for looking at it. I had just done some renaming and added
license verbiage at the beginning of the file.

Satyaki

Mark D. Baushke <mdb@...> wrote:

> Hi Satyaki,
> 
> A few points on the patch...
> 
>  1) ps-print-color-p
> 
>     The ps-print-color-p variable has odd semantics.
>     
>     It is a variable rather than a predicate function.
>     
>     It returns one of 
>        nil
>        t
>        black-white
>     
>     I understand why we have our own version of the variable, what I don't
>     understand is why we have to break our own naming conventions to create
>     it...

Actually, there was some disagreement about whether this feature should
be included.  Do we want to reopen the discussion?

Thanks.

Jeff

-- 
Jeffrey C. Honig <jch@...>
http://www.honig.net/jch
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>

Jeffrey C Honig <jch@...> writes:

> Mark D. Baushke <mdb@...> wrote:
> 
> > Hi Satyaki,
> > 
> > A few points on the patch...
> > 
> >  1) ps-print-color-p
> > 
> >     The ps-print-color-p variable has odd semantics.
> >     
> >     It is a variable rather than a predicate function.
> >     
> >     It returns one of 
> >        nil
> >        t
> >        black-white
> >     
> >     I understand why we have our own version of the variable, what I don't
> >     understand is why we have to break our own naming conventions to create
> >     it...
> 
> Actually, there was some disagreement about whether this feature should
> be included.  Do we want to reopen the discussion?

I think it was already re-opened with regard to the keybinding of the
"l" key with a suggestion that it go onto "P" as a prefix character.

The rest of this feature implementation is, of course, open for discussion.

	Enjoy!
	-- Mark

Now that the California recall is over, let's have a poll to see
if mh-print.el gets into CVS. Here are the votes so far:

  Me:     Yes
  Jeff:   Yes (since he wrote it and posted it here :-)
  Peter:  Yes (deduced from mail in this thread)
  Mark:   Yes (with reservations about some features)
  Bill:   ???

Feel free to holler if you think I am misrepresenting you or have
left you out of the above list.

Satyaki

Satyaki Das <satyakid@...> wrote:

> Now that the California recall is over, let's have a poll to see
> if mh-print.el gets into CVS. Here are the votes so far:

Don't have the time to give it a good look right now (interviewing sucks
lads), so I'll trust your good judgement.

-- 
Bill Wohler <wohler@...>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Bill previously had some concerns about my key binding to change the use
of color to print e-mail.  He wasn't against having an mh-specific
override of the default ps-print value.  I'm fine with removing this
functionality in the integrated version.

I'm flying home from Alameda tomorrow and then am on vacation (and not
around the computer) through next Thursday.  So feel free to run with
Satyaki's modifications to my code.  I'll be happy to see it integrated.

Thanks.

Jeff

-- 
Jeffrey C. Honig <jch@...>
http://www.honig.net/jch
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>