gmane.mail.exmh.devel

MAFE help page update suggestions

David Levine — 2012-11-06T00:36:15

Hello,

Re: exmh-2.7.2/misc/mafe/help/mafe.html

There was a mistake, recently corrected, in the MH/nmh
mh-alias(5) man page:  a blind list must not be terminated
with a semicolon.  The MAFE help page contains such
semicolons in its Introduction and Terminology sections:

    2. nmh alias files can the format
          friends: All-Friends:, friend1< at >b.com, friend2< at >c.edu, ...
       friend< at >z.ca, ;
       (note the semicolon at the end as well as the comma usage) so that


   2: name: tag:, {list}, ;

Preceding the semicolon with a comma prevents its
deleterious effect.  However, to avoid confusion I suggest
removing both, something like:

    2. nmh alias files can the format
          friends: All-Friends:, friend1< at >b.com, friend2< at >c.edu, ...
       friend< at >z.ca
       (note that there is no semicolon at the end) so that


   2: name: tag:, {list}

And "nmh alias files can the format" could use adjustment.

[I apologize if this is posted multiple times.  I sent it a
few weeks ago and it hasn't shown up in the a

Re: exmh-2.7.2_3 mangles attachments with file names >= 59 chars

Julian H. Stacey — 2012-09-10T18:14:50

Hi exmh-workers< at >redhat.com

To users< at > I just sent a much more detailed version of this:

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


Cheers,
Julian

RE: current source code?

Welch, Brent — 2012-06-22T02:44:27

I'd prefer a site like sourceforge or github.  Simply switching from cvs to git on sourceforge may be the path of least resistance (and disturbance).  I think the folks that are actively contributing should weigh in on this.

--
Brent

-----Original Message-----
From: Wolfgang Denk [mailto:wd< at >denx.de] 
Sent: Wednesday, June 13, 2012 1:54 AM
To: Welch, Brent
Cc: valdis.kletnieks< at >vt.edu; exmh-workers< at >redhat.com
Subject: Re: current source code?

Dear Brent,

In message <DA636AC7BF798243A4007D3AA0B3D3A75AB40D81< at >seabiscuit.int.panasas.com> you wrote:

I think SF now also supports git, but I've never used it before; we
got sick with the sluggish performance of all SF user interfaces and
moved our projects (mainly the U-Boot boot loader) away.

https://sourceforge.net/apps/trac/sourceforge/wiki/Git  describes how
to set up the git repo at SF;  importing the content of the CVS repo
is a trivial task then.  I could help with that if needed.

I can also offer to set up and host a git repository for exmh on our
serv

How to use (or debug) encryption?

Wolfgang Denk — 2012-06-15T18:14:58

Hello,

I just switched to 2.8.0 (current top of CVS) for routine use, and I
still notice some problms I've always had - whre I hoped updating
could fix these.  But eventually I'm just doing something wrong.

Question: how does one use signing/encryption - and how dooes one
debug this if it isn't working?

Assume I have a message ready for sending. In the "What now?" window I
select I select "More" => "Crypt..." and check "Encrypt".  Then I
click on "Send".  A window "Please select a GnuPG key to use or
signing" pops up, I select a key, and klick "OK".  A new window "Enter
GnuPG passphrase" pops up, I enter it, and click "OK".

Now I get an "Address or Header Error-1" window with an error message:
"couldn't open "/tmp/wd/0.pgp.32187.exmh": no such file or directory".

This is 100% repeatable - only the PID changes. ANd indeed there is no
such file - there is only a "/tmp/wd/0.msg.32187.exmh" file.
~/Mail/.exmhaudit does not show any interesting information either.

Am I doing something wrong?  And how can I

[PATCH] Fix RPM build errors on 64bit systems.

Wolfgang Denk — 2012-06-15T18:02:30

Tested on Fedora 17.

Signed-off-by: Wolfgang Denk <wd< at >denx.de>
---
Notes:
- I dropped the dependency on metamail, since this package appears to
  be not included in any recent distributions any more.
- I somewhat dout about the config options for "faces" and "glimpse"
  still make sense.  I cannot find such packages for any of therecent
  distros - is anybody still using these?  Where can I foind recent
  source code?

 misc/RPM/exmh.spec |   23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/misc/RPM/exmh.spec b/misc/RPM/exmh.spec
index 5d2c7e8..ed75b34 100644
--- a/misc/RPM/exmh.spec
+++ b/misc/RPM/exmh.spec
< at >< at > -3,7 +3,7 < at >< at > Name: exmh
 Version: EXMHVERSION 
 Release: 1
 BuildArchitectures: noarch
-Requires: mh, metamail
+Requires: nmh
 License: freeware
 Group: Applications/Mail
 Source0: ftp://ftp.tcl.tk/pub/tcl/exmh/exmh-%{version}.tar.gz
< at >< at > -64,6 +64,8 < at >< at > exmh.
 for i in *.MASTER; do
 cp $i ${i%%.MASTER}
 done
+pwd
+sed -i -e 's!/usr/lib!%{_libdir}!g' $RPM_SOUR

RE: current [exmh] source code?

Welch, Brent — 2012-06-13T15:56:55

Of course - 2.8.1 would be based off the CVS tree.

--
Brent

-----Original Message-----
From: exmh-workers-bounces< at >redhat.com [mailto:exmh-workers-bounces< at >redhat.com] On Behalf Of Kevin Cosgrove
Sent: Wednesday, June 13, 2012 1:38 AM
To: exmh-workers< at >redhat.com
Subject: Re: current [exmh] source code?

On 12 June 2012 at 16:38, "Welch, Brent" <welch< at >panasas.com> wrote:

Seems fine.  Nice to see any movement. :-)

I'd rather see the change to git be it's own release, either
2.8.2 or 2.9.  It just seems that it's a major change to the
build & distribution process, maybe not something to roll into an
otherwise nearly done deal.

I like git quite well, and would welcome the change, just not in
2.8.1.

Thanks....
--
Kevin

_______________________________________________
Exmh-workers mailing list
Exmh-workers< at >redhat.com
https://www.redhat.com/mailman/listinfo/exmh-workers

Re: [PATCH 1/2] Add separate "Append to file" button

Randy Kramer — 2012-06-13T15:35:49

+1

I'm getting plumb wore out from all the writing I'm doing in this thread ;-)

Randy Kramer

Re: [PATCH 1/2] Add separate "Append to file" button

Julian H. Stacey — 2012-06-13T15:15:35

Hi all

Wolfgang Denk wrote:

It would be nice in the tree as it adds functionality.
I first commented just so we'd be careful how we did it, not to stop it :-)

Append being in same position (first of 2 in list) sounds sensible. 
The new & more dangerous create/truncate should be adjacent, 2nd.
Just a question of best names for old & new functions,
Before we had:
"Save to file"
Now maybe:
"Append to file"
"Overwrite file"
With clear names like that we wouldn't need "Are you sure"
(Except in case of "Aargh! My mouse skidded down too far ;-)

Cheers,
Julian

Re: [PATCH 1/2] Add separate "Append to file" button

Randy Kramer — 2012-06-13T14:22:04

+1

Randy Kramer

Re: [PATCH 1/2] Add separate "Append to file" button

Wolfgang Denk — 2012-06-13T14:21:05

Dear Chris,

In message <20120613140712.4F472B0001C< at >testapps.cs.toronto.edu> you wrote:

I understand your position; I'm not going to fight about this.  I have
no problems maintaining this out of tree.

Best regards,

Wolfgang Denk

Re: [PATCH 1/2] Add separate "Append to file" button

Chris Siebenmann — 2012-06-13T14:11:28

| What about labelling the buttons
| 
| "Save to file (append)"
| and
| "Save to file"
| 
| This should be sufficiently clear to all users.

 I don't think that this is at all safe for existing users. I expect
them to reflexively use the 'Save to file' option that they have been
using for some time without slowing down to notice that there is now a
new button with a related-looking title, reading the title, and then
inferring that because the new button specifically says '(append)' that
this means that 'Save to file' now does *not* append.

 Getting it right is a multi-step process that requires people to apply
indirect logic to work out what 'Save to file' now does. I think that
this is not a good idea and is not going to work in practice. I would
expect even new users to have problems working out what's going on and
I doubt existing users will notice until they lose data.

- cks

Re: [PATCH 1/2] Add separate "Append to file" button

Chris Siebenmann — 2012-06-13T14:07:12

| >  If 'Save to file' has been appending to files for more than a
| > decade, I really think that it shouldn't be changed on people. If
| > people really want this change in the main source, I would suggest
| > two modifications here:
|
| Yes, changing long-standing behavious is always a critical thing
| to do.  But I really wonder how many users are actually aware of
| this behaviour and using it?  The current behaviour is pretty much
| counter-intuitive, and I tend to consider it a bug that should be
| fixed. [...]

 When something has been the way it currently is for more than a decade,
it can no longer be described as 'counter-intuitive' for its current
users (only potentially for new users) or a bug, regardless of what one
feels about the wording it uses. In fact, a change is counter-intuitive
for all current users. Since this is a destructive change that can lose
data, it is especially dangerous for current users.

 Were exmh my program I would reject this change on the grounds that
it is about a deca

Re: [PATCH 1/2] Add separate "Append to file" button

Wolfgang Denk — 2012-06-13T10:56:43

Dear Randy,

In message <201206130618.58783.rhkramer< at >gmail.com> you wrote:

Because this is not generally correct.  "Overwrite" can only take
place if the output file already exists, which may or may not be the
case.

What about labelling the buttons

"Save to file (append)"
and
"Save to file"

This should be sufficiently clear to all users.

Best regards,

Wolfgang Denk

Re: [PATCH 1/2] Add separate "Append to file" button

Randy Kramer — 2012-06-13T10:18:58

+1


+1


Or why not name this option "Overwrite file" 

In addition, on a temporary basis, maybe the names could include a note, like:

"Append to File" (old "Save") (or (old behavior))
"OverWrite File" (new option) (or (new behavior))


Randy Kramer

Re: current source code?

Wolfgang Denk — 2012-06-13T08:56:15

Dear Brent,

In message <DA636AC7BF798243A4007D3AA0B3D3A75AB40EDD< at >seabiscuit.int.panasas.com> you wrote:


I'm currently reanimating the building of RPM packages; this seems to
have been unmaintained for years.  I will have some more patches for
this.


If nobody else does, I'd be willing to volunteer.

Best regards,

Wolfgang Denk

Re: current source code?

Wolfgang Denk — 2012-06-13T08:53:53

Dear Brent,

In message <DA636AC7BF798243A4007D3AA0B3D3A75AB40D81< at >seabiscuit.int.panasas.com> you wrote:


I think SF now also supports git, but I've never used it before; we
got sick with the sluggish performance of all SF user interfaces and
moved our projects (mainly the U-Boot boot loader) away.

https://sourceforge.net/apps/trac/sourceforge/wiki/Git  describes how
to set up the git repo at SF;  importing the content of the CVS repo
is a trivial task then.  I could help with that if needed.

I can also offer to set up and host a git repository for exmh on our
server (git.denx.de) if there is any interest - that could be done in
less than 5 minutes...

Best regards,

Wolfgang Denk

Re: current [exmh] source code?

Kevin Cosgrove — 2012-06-13T08:38:03

On 12 June 2012 at 16:38, "Welch, Brent" <welch< at >panasas.com> wrote:


Seems fine.  Nice to see any movement. :-)


I'd rather see the change to git be it's own release, either
2.8.2 or 2.9.  It just seems that it's a major change to the
build & distribution process, maybe not something to roll into an
otherwise nearly done deal.

I like git quite well, and would welcome the change, just not in
2.8.1.

Thanks....
--
Kevin

Re: [PATCH 1/2] Add separate "Append to file" button

Wolfgang Denk — 2012-06-13T06:11:45

Dear Chris,

In message <20120613025010.6D3F7361C3< at >apps0.cs.toronto.edu> you wrote:

Yes, changing long-standing behavious is always a critical thing to
do.  But I really wonder how many users are actually aware of this
behaviour and using it?  The current behaviour is pretty much
counter-intuitive, and I tend to consider it a bug that should be
fixed.  [Actually my initial versions of this patch _only_ fixed this;
I added the "Append" only later and only for backward copatibility,
as I never used this myself.]


That would be a trivial change.

Should I submit an updated patch with such a version?


Well, I dislike this.  "Save" and "Write" are pretty much synonyms to
me in this context, so this is likely to add confusion.

Best regards,

Wolfgang Denk

Re: [PATCH 1/2] Add separate "Append to file" button

Wolfgang Denk — 2012-06-13T06:05:50

Dear Valdis,

In message <40021.1339545291< at >turing-police.cc.vt.edu> you wrote:

Oops?  When you run a function that writes data to a file this is
supposed just to do what you tell it - write data to a file.  There is
no difference between behaviour with or without this patch - in both
cases the data will be writen to that file.

The existing code does not use any waning either - and I have to admit
that I consider all these "Do you really want..." interactions a major
PITA. 

Best regards,

Wolfgang Denk

Re: [PATCH 1/2] Add separate "Append to file" button

Chris Siebenmann — 2012-06-13T02:50:10

| > There are many cases where I would like to overwrite an existing file,
| > but the "Save to file" funtion always appends only.  So create a new
| > "Append to file" button for this functionality, and make "Save to
| > file" just perform a plain write, overwriting any existing data.
| 
| Nice idea.
| However I bet changing "Save to file" from append to creat() will bite 
| someone.  Not that I'm arguing against it, just might be worth
| considering for an interim release or so:
| maybe add temporary codebefore the O_TRUNC or whatever to
| warn or confirm ?  (but as we all hate "Are you sure", let
| the "Are you sure" also announce "This warning will be
| removed next release" - Just an idea ?

 If 'Save to file' has been appending to files for more than a decade,
I really think that it shouldn't be changed on people. If people really
want this change in the main source, I would suggest two modifications
here:

- put the 'Append to file' button in the physical position where 'Save
  to file' has been.

Re: [PATCH 1/2] Add separate "Append to file" button

2012-06-12T23:54:51

On Wed, 13 Jun 2012 01:05:50 +0200, "Julian H. Stacey" said:


I'd opine that maybe it shouldn't be temporary code.  Accidentally trashing
a file sucks.
_______________________________________________
Exmh-workers mailing list
Exmh-workers< at >redhat.com
https://www.redhat.com/mailman/listinfo/exmh-workers