Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!sumax!amc-gw!sigma!uw-nsr!uw-warp!cjsa!jeff From: jeff@cjsa.WA.COM (Jeffery Small) Newsgroups: comp.mail.elm Subject: Re: Signature functionality change Summary: I agree Message-ID: <792@cjsa.WA.COM> Date: 2 Jun 89 16:17:27 GMT References: <204@grc.UUCP> <9388@b-tech.ann-arbor.mi.us> <281@levels.sait.edu.au> Organization: C. Jeffery Small and Associates - Woodinville, WA Lines: 50 In article <281@levels.sait.edu.au>, ccdn@levels.sait.edu.au (DAVID NEWALL) writes: > Certainly it's nice to have different local and remote signatures. But > I don't consider it a crime if elm occasionally chooses the wrong one. > Especially since elm does, or at least it used to, include the signature > in the edit buffer. At least I knew what I was getting. And I could > change it if it was wrong. Now I have to hope that elm is going to get > it right. And to be honest, I don't have that much faith in a computer. > I'd like to be sure of what I'm getting. > I agree with this completely. This change in the handling of signatures is the first modification that has been made which I don't feel I will be able to live with*. Elm frequently does not give me the signature I want for a particular individual (I have suggested linking the signature file to the aliases to solve this problem) and I often edit it as I compose my message. I too, want to see what elm is going to do. For this reason, I am hesitant to use the encode feature of elm because I have no easy way to verify that the sensitive material has actually been encoded prior to sending it. It seems to me that most of these problems concerning headers, signatures, encoded messages, etc. are created because we are trying to accommodate the simple-minded builtin+ editor - which is actually not an editor at all - and users of real editors (vi, emacs, wordprocessors) are suffering the consequences. We are spending a lot of energy talking about and resolving these incompatible message-creation strategies. I would like to throw out for comment the following idea: Why don't we junk the builtin+ "editor" and replace it with a small and very simple **buffered** editor which doesn't have a lot of bells and whistles, could emulate the Berkeley commands to a good extent and yet, could handle the inclusion of header/signature/etc material. Then, create elmrc options for each of the items in question which allow the user to either include the material in the editor buffer or defer tacking on the info until the message is sent. This provides a uniform method of dealing with the problem and would allow future enhancements to be more easily integrated into elm. For users who now use builtin+, if you specify the new builtin editor and defer inclusion of headers and signatures, then you could simulate exactly the environment that exists now. The rest of us could pick and choose the set of options we like. Doesn't code for a very simple editor exist in the public domain which could be used as a starting point for inclusion in elm? Comments? -- Jeffery Small (206) 485-5596 uw-beaver!uw-nsr!uw-warp C. Jeffery Small and Associates !cjsa!jeff 19112 152nd Ave NE - Woodinville, WA 98072 uunet!nwnexus *[BTW - Patch 8 hasn't made it to this site either.]