headers
Jeffrey C Honig | 2 Jan 2007 03:23
Face

Re: Happy birthday, Jeff!

Daddy's little tax deduction...

They are most excited when my birthday is over though...

Thanks.

Jeff

Bill Wohler <wohler <at> newt.com> wrote:

> Cool birthday, by the way. Everybody parties all night for your birthday
> ;-).
> 
> -- 
> Bill Wohler <wohler <at> newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> mh-e-devel mailing list
> mh-e-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mh-e-devel
> 
> 

--

-- 
Jeffrey C. Honig <jch <at> honig.net>
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 6 Jan 2007 12:56
Picon
Favicon

[ mh-e-Bugs-1629357 ] Setting w3m-standalone requires w3m external program

Bugs item #1629357, was opened at 2007-01-06 06:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113357&aid=1629357&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: mh-e-8.0.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Lott (chrislott)
Assigned to: Bill Wohler (wohler)
Summary: Setting w3m-standalone requires w3m external program

Initial Comment:
I would like to suggest that the document
http://mh-e.sourceforge.net/manual/html/HTML.html gets updated to
indicate that setting the variable mm-text-html-renderer to the symbol w3m-standalone means an
external program
(w3m) is indeed required.  Also please clarify that the w3m setting calls the w3m Lisp code.  In short,
something extra is required for *every* setting of this variable.  But it sure makes it possible to view
HTML messages in mh-e. 

----------------------------------------------------------------------

You can respond by visiting:
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 7 Jan 2007 19:00
Picon
Favicon

[ mh-e-Bugs-1630008 ] Add X-MHE-Checksum to mh-new-draft-cleaned-headers

Bugs item #1630008, was opened at 2007-01-07 10:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113357&aid=1630008&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: mh-e-8.0.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bill Wohler (wohler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add X-MHE-Checksum to mh-new-draft-cleaned-headers

Initial Comment:
Add X-MHE-Checksum to mh-new-draft-cleaned-headers.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113357&aid=1630008&group_id=13357

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 7 Jan 2007 22:54
Picon
Favicon

[ mh-e-Feature Requests-1630152 ] Add screenshots for +mhe-index folders

Feature Requests item #1630152, was opened at 2007-01-07 13:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363357&aid=1630152&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: mh-e-8.0.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bill Wohler (wohler)
Assigned to: Bill Wohler (wohler)
Summary: Add screenshots for +mhe-index folders

Initial Comment:
It would be helpful to add screenshots for the +mhe-index virtual folders. One chapter includes 15
Searching Through Messages. 

In addition, chapter, 7 Organizing Your Mail with Folders, should include cross-references to Chapter 15
for F n and F ' for navigating the virtual folder.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363357&aid=1630152&group_id=13357
(Continue reading)

Permalink | Reply | 0 comments |
headers
Glenn Morris | 21 Jan 2007 04:00
Picon

emacs/lisp/mh-e mh-xface.el mh-utils.el mh-tool...

CVSROOT:	/cvsroot/emacs
Module name:	emacs
Changes by:	Glenn Morris <gm>	07/01/21 03:00:57

Modified files:
	lisp/mh-e      : mh-xface.el mh-utils.el mh-tool-bar.el 
	                 mh-thread.el mh-speed.el mh-show.el mh-seq.el 
	                 mh-search.el mh-scan.el mh-print.el mh-mime.el 
	                 mh-limit.el mh-letter.el mh-junk.el mh-inc.el 
	                 mh-identity.el mh-gnus.el mh-funcs.el 
	                 mh-folder.el mh-e.el mh-compat.el mh-comp.el 
	                 mh-buffers.el mh-alias.el mh-acros.el 
	                 ChangeLog.1 ChangeLog 

Log message:
	Add 2007 to copyright years.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-xface.el?cvsroot=emacs&r1=1.5&r2=1.6
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-utils.el?cvsroot=emacs&r1=1.66&r2=1.67
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-tool-bar.el?cvsroot=emacs&r1=1.9&r2=1.10
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-thread.el?cvsroot=emacs&r1=1.3&r2=1.4
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-speed.el?cvsroot=emacs&r1=1.17&r2=1.18
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-show.el?cvsroot=emacs&r1=1.6&r2=1.7
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-seq.el?cvsroot=emacs&r1=1.32&r2=1.33
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-search.el?cvsroot=emacs&r1=1.14&r2=1.15
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-scan.el?cvsroot=emacs&r1=1.3&r2=1.4
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-print.el?cvsroot=emacs&r1=1.17&r2=1.18
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-mime.el?cvsroot=emacs&r1=1.54&r2=1.55
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-limit.el?cvsroot=emacs&r1=1.5&r2=1.6
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Kupfer | 27 Jan 2007 07:55
Picon
Favicon

MH-E file layout in XEmacs

I'm (slowly) working on fitting MH-E 8.0.3 into the XEmacs package tree,
and I'm not sure how to fit in all the new image files.

The old (7.4.2) source tree is flat in XEmacs CVS--the Lisp files live
in xemacs-packages/mh-e.  I was planning on keeping the lisp files where
they are, and add an "etc/images" directory for the images.  Thus I'd
have

    mh-e/
        *.el
        etc/
            images/

I've seen at least one other package in XEmacs laid out this way.

Unfortunately, it doesn't work.  Compiling MH-E fails with "Could not
find image mh-logo.xpm for library mh-e".  The stack backtrace includes

  mh-image-load-path-for-library("mh-e" "mh-logo.xpm")

I looked at mh-image-load-path-for-library; it will check in
../../etc/images and ../etc/images, but not etc/images.  Thus, it
appears to want a source layout that looks like

    mh-e/
        lisp/
            *.el
        etc/
            images/
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bill Wohler | 27 Jan 2007 18:09
Picon
Picon
Gravatar

Re: MH-E file layout in XEmacs

Mike Kupfer <m.kupfer <at> acm.org> wrote:

> I'm (slowly) working on fitting MH-E 8.0.3 into the XEmacs package tree,
> and I'm not sure how to fit in all the new image files.

Thanks very much!

I suspect that you'll have to move things around since we switched to
the GNU Emacs image organization since Steve last updated XEmacs. I
wouldn't worry too much about losing the CVS history since most log
messages should be "Imported version m.n."

> So I think the right thing to do is change
> mh-image-load-path-for-library.  Does anyone think this is the wrong
> thing to do?  

Note that mh-image-load-path-for-library in MH-E and
gmm-image-load-path-for-library in Gnus are nearly identical
compatibility copies of GNU Emacs image-load-path-for-library.
Therefore, any changes to mh-image-load-path-for-library MUST be
reflected in gmm-image-load-path-for-library and
image-load-path-for-library.

Is the version of Gnus in XEmacs fairly recent? Does it contain
gmm-image-load-path-for-library? If so, you should mimic what Gnus does.
Reiner Steib <Reiner.Steib <at> gmx.de> can help you with this (who is
probably listening).

If not, you, me, and Reiner need to talk ;-).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mike Kupfer | 27 Jan 2007 22:43
Picon
Favicon

Re: MH-E file layout in XEmacs

>>>>> "Bill" == Bill Wohler <wohler <at> newt.com> writes:

Bill> I wouldn't worry too much about losing the CVS history
Bill> since most log messages should be "Imported version m.n."

Okay, I'll look into rearranging the source tree.

One thing that occurred to me after I sent my original mail was to
wonder why mh-image-load-path-for-library is being invoked during
compilation.  It looks like it comes from this defvar in mh-xemacs.el:

(defvar mh-xemacs-icon-map
  (let ((load-path (mh-image-load-path-for-library "mh-e" "mh-logo.xpm"))
        (background "c None s backgroundToolBarColor"))
    (loop for icon in mh-xemacs-icon-list
          collect (cons icon
                        (toolbar-make-button-list
                         (mh-icon-image icon background)))))
  "Map of GNU Emacs icon file names to XEmacs images.")

Is this going to bake into the .elc file the path to the images?  I
think the answer is no, but I don't understand the XEmacs glyph code.
(If paths do get baked in, this needs to be deferred until runtime.)  I
can do some more digging if nobody can give me a definitive answer.

Bill> Note that mh-image-load-path-for-library in MH-E and
Bill> gmm-image-load-path-for-library in Gnus are nearly identical
Bill> compatibility copies of GNU Emacs image-load-path-for-library.
Bill> Therefore, any changes to mh-image-load-path-for-library MUST be
Bill> reflected in gmm-image-load-path-for-library and
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mike Kupfer | 27 Jan 2007 22:49
Picon
Favicon

Re: MH-E file layout in XEmacs

Just to clarify something...

>>>>> "Mike" == Mike Kupfer <m.kupfer <at> acm.org> writes:

Mike> Is this going to bake into the .elc file the path to the images?

By "path" I meant "full path".  A path that is relative to some
top-level directory (that is determined at runtime) is fine.

mike

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
Bill Wohler | 27 Jan 2007 23:23
Picon
Picon
Gravatar

Re: MH-E file layout in XEmacs

Mike Kupfer <m.kupfer <at> acm.org> wrote:

> >>>>> "Bill" == Bill Wohler <wohler <at> newt.com> writes:
> 
> Bill> I wouldn't worry too much about losing the CVS history
> Bill> since most log messages should be "Imported version m.n."
> 
> Okay, I'll look into rearranging the source tree.
> 
> One thing that occurred to me after I sent my original mail was to
> wonder why mh-image-load-path-for-library is being invoked during
> compilation.  It looks like it comes from this defvar in mh-xemacs.el:
> 
> (defvar mh-xemacs-icon-map
>   (let ((load-path (mh-image-load-path-for-library "mh-e" "mh-logo.xpm"))
>         (background "c None s backgroundToolBarColor"))
>     (loop for icon in mh-xemacs-icon-list
>           collect (cons icon
>                         (toolbar-make-button-list
>                          (mh-icon-image icon background)))))
>   "Map of GNU Emacs icon file names to XEmacs images.")
> 
> Is this going to bake into the .elc file the path to the images?  I
> think the answer is no, but I don't understand the XEmacs glyph code.
> (If paths do get baked in, this needs to be deferred until runtime.)  I
> can do some more digging if nobody can give me a definitive answer.

The logic of the compiler evades me. It took me a long, long time to
shut up XEmacs compilation. I'm not going to be much help. Maybe someone
else could provide some thoughts. Also, you're likely on the XEmacs
(Continue reading)

Permalink | Reply | 0 comments |

Gmane