headers
Steve Youngs | 1 Nov 2003 01:49
X-Face
Picon

Re: MH-E: GNU Emacs front end for MH

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

  BW> Steve Youngs <sryoungs <at> bigpond.net.au> wrote:
  >>Let me know what you'd rather it say and I'll update it with the next
  >>release. 

  BW> The short description is:

  BW>   The XEmacs Interface to the MH Mail System

As good as done.

  BW> Just close your eyes when you type "interface." ;-)

:-)

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|              Ashes to ashes, dust to dust.               |
|      The proof of the pudding, is under the crust.       |
|------------------------------<sryoungs <at> bigpond.net.au>---|
Permalink | Reply | 0 comments |
headers
Bill Wohler | 1 Nov 2003 02:06
Picon
Picon
Gravatar

Re: MH-E: GNU Emacs front end for MH

Mark D. Baushke <mdb <at> gnu.org> wrote:

> Bill Wohler <wohler <at> newt.com> writes:
> 
> > Thanks. One alternate I just thought of is:
> > 
> >   <li> ticking messages
> >   <li> lightning-fast full-text indexed searches of all of your email
> >   <li> virtual folders to view ticked and unseen messages; results of search
> > 
> > What do you think?
> 
> Looks okay.

Thanks. I think I'm going to go with it.

> > By the way, you didn't answer the question: are your searches lightning
> > fast, or are they slow too? (By the way, I'm talking about searches that
> > have few hits so only the search time is considered--searches with many
> > hits can take a long time to render.)
> 
> Results are back in under five seconds typically....

I guess that isn't lightning-fast. But for the folks who have their
databases on local disk, maybe lightning-fast will still hold. It
certainly sounds good, but is it misleading advertising? Specific
suggestions anyone?

--

-- 
Bill Wohler <wohler <at> newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter S Galbraith | 1 Nov 2003 04:27
Favicon

Entry point autoloads

Following a discussion on mh-e-users, I will building an `autoloads'
file for the MH-E Debian package which will be loaded on Emacs startup.
This is to make sure the autoloads usually supplied by Emacs' own version
of MH-E are still correct for the updated packaged version of MH-E.

I can do this independently, but it occurred to me that we might want
`make; make install' to create such a file, called for example,
mh-initial.el.  Then users could create it and `require' it in their
~/.emacs to setup MH-E entry points.

How are we expecting users to setup MH-E for usage now anyway?
These autoloads are not provided as far as I know.  We are also relying
on Emacs providing them, right?

Peter
Permalink | Reply | 35 comments |
headers
Peter S Galbraith | 1 Nov 2003 04:34
Favicon

Re: MH-E: GNU Emacs front end for MH

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

> > Results are back in under five seconds typically....
> 
> I guess that isn't lightning-fast. But for the folks who have their
> databases on local disk, maybe lightning-fast will still hold. It
> certainly sounds good, but is it misleading advertising? Specific
> suggestions anyone?

Under 5 seconds is fast for anyone used to grep'ing for stuff in 500MB
of mail.
Permalink | Reply | 0 comments |
headers
Steve Youngs | 1 Nov 2003 06:30
X-Face
Picon

Re: Entry point autoloads

|--==> "PSG" == Peter S Galbraith <Peter> writes:

  PSG> Following a discussion on mh-e-users, I will building an
  PSG> `autoloads' file for the MH-E Debian package which will be
  PSG> loaded on Emacs startup.  This is to make sure the autoloads
  PSG> usually supplied by Emacs' own version of MH-E are still
  PSG> correct for the updated packaged version of MH-E.

For GNU/Emacs, isn't that the job of 'mh-loaddefs.el'?

Doesn't GNU/Emacs have a mechanism for automatically loading
autoloads?

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|              Ashes to ashes, dust to dust.               |
|      The proof of the pudding, is under the crust.       |
|------------------------------<sryoungs <at> bigpond.net.au>---|
Permalink | Reply | 34 comments |
headers
Bill Wohler | 1 Nov 2003 08:59
Picon
Picon
Gravatar

Re: Entry point autoloads

Steve Youngs <sryoungs <at> bigpond.net.au> wrote:

> |--==> "PSG" == Peter S Galbraith <Peter> writes:
> 
>   PSG> Following a discussion on mh-e-users, I will building an
>   PSG> `autoloads' file for the MH-E Debian package which will be
>   PSG> loaded on Emacs startup.  This is to make sure the autoloads
>   PSG> usually supplied by Emacs' own version of MH-E are still
>   PSG> correct for the updated packaged version of MH-E.
> 
> Doesn't GNU/Emacs have a mechanism for automatically loading
> autoloads?

D'oh! Yes, of course, we have the autoload cookie in place for
mh-version, and it's been there forever:

1.1          (wohler   20-Nov-00): ;;;###autoload
1.1          (wohler   20-Nov-00): (defun mh-version ()

--

-- 
Bill Wohler <wohler <at> newt.com>  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.
Permalink | Reply | 33 comments |
headers
Steve Youngs | 1 Nov 2003 10:20
X-Face
Picon

Re: Entry point autoloads

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

  BW> Steve Youngs <sryoungs <at> bigpond.net.au> wrote:
  >>Doesn't GNU/Emacs have a mechanism for automatically loading
  >>autoloads?

  BW> D'oh! Yes, of course, we have the autoload cookie in place for
  BW> mh-version, and it's been there forever:

  BW> 1.1          (wohler   20-Nov-00): ;;;###autoload
  BW> 1.1          (wohler   20-Nov-00): (defun mh-version ()

So, if you were to start Emacs in such a way that it bypasses your
~/.emacs (XEmacs speak: 'xemacs -vanilla') you could straight away do
'M-x mh-version RET'?

And if that's the case, you can get anything autoloaded in Emacs by
simply giving it an autoload cookie and whacking it in your
load-path.  Cool!

What's the purpose of 'mh-loaddefs.el' then?

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|              Ashes to ashes, dust to dust.               |
|      The proof of the pudding, is under the crust.       |
|------------------------------<sryoungs <at> bigpond.net.au>---|
Permalink | Reply | 32 comments |
headers
Peter S Galbraith | 1 Nov 2003 15:32
Favicon

Re: Entry point autoloads

Steve Youngs <sryoungs <at> bigpond.net.au> wrote:

> |--==> "BW" == Bill Wohler <wohler <at> newt.com> writes:
> 
>   BW> Steve Youngs <sryoungs <at> bigpond.net.au> wrote:
>   >>Doesn't GNU/Emacs have a mechanism for automatically loading
>   >>autoloads?
> 
>   BW> D'oh! Yes, of course, we have the autoload cookie in place for
>   BW> mh-version, and it's been there forever:
> 
>   BW> 1.1          (wohler   20-Nov-00): ;;;###autoload
>   BW> 1.1          (wohler   20-Nov-00): (defun mh-version ()
> 
> So, if you were to start Emacs in such a way that it bypasses your
> ~/.emacs (XEmacs speak: 'xemacs -vanilla') you could straight away do
> 'M-x mh-version RET'?
> 
> And if that's the case, you can get anything autoloaded in Emacs by
> simply giving it an autoload cookie and whacking it in your
> load-path.  Cool!

Yes, but my point was that our entry points might diverge from the ones
Emacs knows about from it's older version of MH-E.  I think users who
download MH-E separately should be able to set up these main entry point
autoloads correctly.  If nobody agrees or cares, I'll just do it in the
Debian package itself.

> What's the purpose of 'mh-loaddefs.el' then?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Wohler | 1 Nov 2003 20:34
Picon
Picon
Gravatar

Re: Entry point autoloads

Steve Youngs <sryoungs <at> bigpond.net.au> wrote:

> |--==> "BW" == Bill Wohler <wohler <at> newt.com> writes:
> 
>   BW> Steve Youngs <sryoungs <at> bigpond.net.au> wrote:
>   >>Doesn't GNU/Emacs have a mechanism for automatically loading
>   >>autoloads?
> 
>   BW> D'oh! Yes, of course, we have the autoload cookie in place for
>   BW> mh-version, and it's been there forever:
> 
>   BW> 1.1          (wohler   20-Nov-00): ;;;###autoload
>   BW> 1.1          (wohler   20-Nov-00): (defun mh-version ()
> 
> So, if you were to start Emacs in such a way that it bypasses your
> ~/.emacs (XEmacs speak: 'xemacs -vanilla') you could straight away do
> 'M-x mh-version RET'?
> 
> And if that's the case, you can get anything autoloaded in Emacs by
> simply giving it an autoload cookie and whacking it in your
> load-path.  Cool!

Not so fast. You need to build MH-E as part of an Emacs build to get
these cookies added to Emacs' loaddefs.el file. This isn't a problem
with GNU Emacs, but I'll bet this isn't going to work with XEmacs since
MH-E isn't distributed with it.

We get away with this in GNU Emacs since the main entry points don't
change that much, but as we saw in this example, if we do make a change
(as in autoloading mh-version), it won't be seen until the next Emacs
(Continue reading)

Permalink | Reply | 30 comments |
headers
Bill Wohler | 1 Nov 2003 21:13
Picon

CVS: doc mh-e.texi,1.63,1.64 ChangeLog,1.50,1.51

Update of /cvsroot/mh-e/doc
In directory sc8-pr-cvs1:/tmp/cvs-serv16733

Modified Files:
	mh-e.texi ChangeLog 
Log Message:
(cross-references): Fixed cross-references that were no longer
pointing to the correct node due to the reshuffling.
(editing): Removed terms like "below" and "above" that can easily get
out of date.
(Reading Mail, Getting Started): Moved mh-lib, mh-lib-progs, mh-progs
to Getting Started.

Index: mh-e.texi
===================================================================
RCS file: /cvsroot/mh-e/doc/mh-e.texi,v
retrieving revision 1.63
retrieving revision 1.64
diff -u -d -r1.63 -r1.64
--- mh-e.texi	30 Oct 2003 04:45:35 -0000	1.63
+++ mh-e.texi	1 Nov 2003 20:13:44 -0000	1.64
 <at>  <at>  -51,7 +51,7  <at>  <at> 
  <at> end direntry

  <at> titlepage
- <at> title MH-E - The Emacs Interface to the MH Mail System
+ <at> title MH-E - The GNU Emacs Interface to the MH Mail System
  <at> subtitle Edition  <at> value{EDITION} for MH-E Version  <at> value{VERSION}
  <at> subtitle  <at> value{UPDATE-MONTH}
  <at> author Bill Wohler
(Continue reading)

Permalink | Reply | 0 comments |

Gmane