headers
Richard Stallman | 1 Sep 2002 15:15
Picon
Picon

Re: problem with mh-e and 2002-08-20 change to font-core.el

    > With the current code, changing from Occur mode to Fundamental mode
    > and back to Occur mode would lose the font-lock-face properties.
    > That is a bug.
    > 
    > With the change you propose, changing from Occur mode to Fundamental
    > mode and then to Info mode would leave you with font-lock-face
    > properties left over from Occur mode.  That would be a bug.

    I'm not sure how important this is, really.

It isn't worth a large amount of work.

    but that might be run too late.  So maybe we should add some
    support in font-core.el to make it easier for a mode to tell
    "erase font-lock-face property when font-lock-mode is changed".

The whole point of the font-lock-face property is that it can be set
up unconditionally, and is there regardless of whether Font-Lock mode
is enabled.  It would be wrong to remove these properties when turning
off Font-Lock mode.  Only changing the major mode is a reason to
remove them.

    First, I think that the change-major-mode-hook should
    run (font-lock-mode -1) and that if it doesn't do the right thing,
    then we should fix (font-lock-mode -1) rather than change
    the change-major-mode-hook.

For the reason given above, this is simply wrong.

Perhaps the modes that use font-lock-face should set up
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Monnier | 2 Sep 2002 19:05
Picon

Re: problem with mh-e and 2002-08-20 change to font-core.el

>     > With the current code, changing from Occur mode to Fundamental mode
>     > and back to Occur mode would lose the font-lock-face properties.
>     > That is a bug.
>     > 
>     > With the change you propose, changing from Occur mode to Fundamental
>     > mode and then to Info mode would leave you with font-lock-face
>     > properties left over from Occur mode.  That would be a bug.
> 
>     I'm not sure how important this is, really.
> 
> It isn't worth a large amount of work.
> 
>     but that might be run too late.  So maybe we should add some
>     support in font-core.el to make it easier for a mode to tell
>     "erase font-lock-face property when font-lock-mode is changed".
> 
> The whole point of the font-lock-face property is that it can be set
> up unconditionally, and is there regardless of whether Font-Lock mode
> is enabled.  It would be wrong to remove these properties when turning
> off Font-Lock mode.  Only changing the major mode is a reason to
> remove them.

Good point.

>     First, I think that the change-major-mode-hook should
>     run (font-lock-mode -1) and that if it doesn't do the right thing,
>     then we should fix (font-lock-mode -1) rather than change
>     the change-major-mode-hook.
> 
> For the reason given above, this is simply wrong.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter S Galbraith | 4 Sep 2002 02:51
Picon

CVS: src ChangeLog,1.283,1.284 mh-e.el,1.121,1.122 mh-mime.el,1.51,1.52

Update of /cvsroot/mh-e/src
In directory usw-pr-cvs1:/tmp/cvs-serv3211

Modified Files:
	ChangeLog mh-e.el mh-mime.el 
Log Message:
Add mh-store-mime-parts command.

Index: ChangeLog
===================================================================
RCS file: /cvsroot/mh-e/src/ChangeLog,v
retrieving revision 1.283
retrieving revision 1.284
diff -u -d -r1.283 -r1.284
--- ChangeLog	22 Aug 2002 23:32:31 -0000	1.283
+++ ChangeLog	4 Sep 2002 00:51:39 -0000	1.284
 <at>  <at>  -1,3 +1,17  <at>  <at> 
+2002-09-03  Peter S Galbraith  <psg <at> debian.org>
+
+	* mh-mime.el (mh-store-mime-parts-directory): New defcustom.
+	Default directory to use for mh-store-mime-parts.
+	(mh-store-mime-parts): New Command.  Store the MIME parts of the
+	 current message.
+	(mh-store-mime-parts-directory-default): New internal working
+	variable.  Default to use for mh-store-mime-parts-directory, set
+	from last use.
+
+	* mh-e.el (mh-folder-seq-tool-bar-map): Add mh-store-mime-parts to
+	toolbar.
+
(Continue reading)

Permalink | Reply | 6 comments |
headers
Peter S Galbraith | 6 Sep 2002 04:06
X-Face
Favicon

Re: Guessing MIME type from file name

Davor Cubranic <cubranic <at> cs.ubc.ca> wrote:

> > > I noticed that the code in mh-mhn-compose-insertion gets the MIME
> > > type > either from output of 'file' command or from the user. 'File',
> > > at least > on my system, doesn't work very well, especially when '-i'
> > > flag is given.

> Examples:
> 
> $ file -b -i ~/bla.pdf 
> file: Using regular magic file `/usr/share/magic.mime'
> PDF document [not application/pdf]

I get application/pdf here.

> $ file -b -i ~/misc/bla.xls 
> file: Using regular magic file `/usr/share/magic.mime'
> data

I get application/msword on .xls and .ppt files.
I'll have to dig around in my inbox at work to find out what it should
be.

--

Here's what I thought of doing: create a list of entries with:

  filename extension, type returned by file, type to substitute for.

e.g. :
(Continue reading)

Permalink | Reply | 3 comments |
headers
Satyaki Das | 9 Sep 2002 05:51
Picon

CVS: src mh-e.el,1.122,1.123 ChangeLog,1.284,1.285

Update of /cvsroot/mh-e/src
In directory usw-pr-cvs1:/tmp/cvs-serv8569

Modified Files:
	mh-e.el ChangeLog 
Log Message:
(autoloads): Reorder autoload of mh-reply to avoid compiler warning.

Index: mh-e.el
===================================================================
RCS file: /cvsroot/mh-e/src/mh-e.el,v
retrieving revision 1.122
retrieving revision 1.123
diff -u -d -r1.122 -r1.123
--- mh-e.el	4 Sep 2002 00:51:39 -0000	1.122
+++ mh-e.el	9 Sep 2002 03:51:28 -0000	1.123
 <at>  <at>  -95,12 +95,22  <at>  <at> 
 (defconst mh-version "6.1+cvs" "Version number of mh-e.")

 ;;; Initial Autoloads
-;;; The autoloads for mh-undo-folder and mh-widen are needed before they are
-;;; used here to avoid compiler warnings.
+;;; The autoloads for mh-undo-folder, mh-widen and mh-reply are needed before
+;;; they are used to avoid compiler warnings.
 (autoload 'mh-undo-folder "mh-funcs"
   "Undo all commands in current folder." t)
 (autoload 'mh-widen "mh-seq"
   "Remove restrictions from current folder, thereby showing all messages." t)
+(autoload 'mh-reply "mh-comp"
+  "Reply to a MESSAGE (default: displayed message).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Wohler | 15 Sep 2002 06:46
X-Face
Picon
Picon
Gravatar

Re: Implemented automatic mh-yank-cur-msg

Peter S Galbraith <p.galbraith <at> globetrotter.net> writes:
> This is one more thing to document!  How to use supercite with mh-e!

  Great. Just great ;-).

  As was true in the past, rest assured that the weaknesses (or
  strengths) of the code will be revealed when I document it.

--
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 | 0 comments |
headers
Bill Wohler | 15 Sep 2002 07:09
X-Face
Picon
Picon
Gravatar

Re: Plans for online MH book

Peter S Galbraith <GalbraithP <at> dfo-mpo.gc.ca> writes:
> Jerry Peek <jpeek <at> jpeek.com> wrote:
> 
> > I'd wondered whether people still use the book, so I posted a message on 
> > nmh-workers.  A lot of people replied right away and said that, even if 
> > they don't use the book a lot, they'd like to see it stay online.  That 
> > makes it worthwhile to eventually ;-) do some revisions.
> > 
> > Because UCI seems to have basically no MH users around anymore, I'm 
> > thinking of moving the book to SourceForge or Savannah -- which would 
> > also make it easy for other people to contribute.  I'd also like to 
> > convert it to a more-universal format than what it is now (HTML with a 
> > custom-hacked index search script); DocBook XML is one idea.
> > 
> > The big question for me -- and for you guys, I hope -- is whether it 
> > makes sense to keep the xmh, mh-e and exmh coverage in the book.

  Yes, and no. Since the online book is, well, online, I'd keep them in
  the table of contents and point to the mh-e documentation at
  mh-e.sourceforge.net. That way, the book still references the mh-e
  stuff, and it is much easier to update the mh-e documentation in the
  MH book.

  Currently, the Documentation link at mh-e.sf.net points back to the
  mh-e chapter in the MH book, but going forward, it would be best to
  reverse the links as I suggest. Indeed, just give me the word, and
  I'll install the mh-e document at SourceForge to give you something to
  point at.

> > I could define a structure for the nmh information with entry points
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Wohler | 15 Sep 2002 07:16
X-Face
Picon
Picon
Gravatar

Re: Toolbar buttons for mh-reply variations

Peter S Galbraith <GalbraithP <at> dfo-mpo.gc.ca> writes:
> Currently, we have a toolbar button in emacs21 for 'mh-reply, but it
> causes a minibuffer prompt for "from", "to" or "all".
> 
> Should we instead have three buttons for each of these functions?
> I think I'd prefer that to answering that prompt all the time.

  Everyone else approved, but I would dissent. We don't have separate
  keystrokes for this. The button should do the same thing as the 'r'
  key.

  There should be a single reply button and it should respect the value
  of mh-reply-default-reply-to, which by default is Prompt but can be
  changed by the user. I use "all" (with the requisite risks) since it
  is easier to prune down than up.

  I suppose this is already the current behavior (unless Peter has
  changed it by now ;-).

--
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 | 1 comment |
headers
Bill Wohler | 15 Sep 2002 07:30
X-Face
Picon
Picon
Gravatar

Re: Guessing MIME type from file name

Davor Cubranic <cubranic <at> cs.ubc.ca> writes:
> I have a patch that if 'file' is unsuccessful tries to guess MIME type
> based on the file extension. I can post it here, but I first wanted to
> clear whether there is any interest in it and/or whether I need to go
> through any other steps (assignment of copyright?).

  Due to the maintenance headache and the inevitable extension
  collisions that would turn this into a rathole, I'd prefer not to
  implement this in mh-e if:

  a) There is a program like file already out there, or
  b) There is elisp already out there.
  c) There is a better way.

  Regarding c), what percentage of the time do you all think that file
  gets the right answer? If it is over 75%, then perhaps the correct
  solution is to create a customization variable that allows the user to
  map a file extension to a MIME type. We might prime the variable with
  a few common extensions that we know that file gets wrong (.xls, .ppt,
  apparently).

  On a completely different topic, if you were willing to do an
  assignment of copyright, perhaps you would like to do this anyway and
  become an mh-e developer? See
  http://mh-e.sourceforge.net/doc/devguide.html#SEC3. Thanks for your
  interest!

--
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!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bill Wohler | 15 Sep 2002 07:33
X-Face
Picon
Picon
Gravatar

Re: docstrings

Peter S Galbraith <p.galbraith <at> globetrotter.net> writes:
> Bill Wohler <wohler <at> newt.com> wrote:
> 
> >   OK, quick poll. Do we comment out non-interactive docstrings and use:
> > 
> >     (setq checkdoc-force-docstrings-flag nil)
> > 
> >   or do we change the comments to legitimate docstrings?
> 
> I vote to change them all to legitimate docstrings.

  2 ayes, a few abstains. So it shall be. I'll update the mh-e
  developers manual. Please update the docstrings in any functions you
  update. If you're really bored you can update all of them ;-), but be
  sure to run checkdoc since I know a lot of the commented-out versions
  are not legit.

--
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 | 0 comments |

Gmane