From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/33891 Path: main.gmane.org!not-for-mail From: Lloyd Zusman Newsgroups: gmane.emacs.gnus.general Subject: Re: Another proposal about `mml-parse'. Date: 23 Dec 2000 21:34:39 -0500 Organization: FreeBSD/Linux Hippopotamus Preserve Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035169914 27534 80.91.224.250 (21 Oct 2002 03:11:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:11:54 +0000 (UTC) Return-Path: Original-Received: from spinoza.math.uh.edu (spinoza.math.uh.edu [129.7.128.18]) by mailhost.sclp.com (Postfix) with ESMTP id E3297D04A1 for ; Sat, 23 Dec 2000 21:43:17 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by spinoza.math.uh.edu (8.9.1/8.9.1) with ESMTP id UAB10247; Sat, 23 Dec 2000 20:35:42 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sat, 23 Dec 2000 20:35:01 -0600 (CST) Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged)) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id UAA02487 for ; Sat, 23 Dec 2000 20:34:48 -0600 (CST) Original-Received: from home.acholado.net (acholado.net [216.182.19.128]) by mailhost.sclp.com (Postfix) with ESMTP id 55704D04A1 for ; Sat, 23 Dec 2000 21:35:01 -0500 (EST) Original-Received: by home.acholado.net (Postfix, from userid 510) id 0E15019E96; Sat, 23 Dec 2000 21:34:39 -0500 (EST) Original-To: ding@gnus.org X-Face: "!ga1s|?LNLE3MeeeEYs(%LIl9q[xV9!j4#xf4!**BFW_ihlOb;:Slb>)vy>CJM Original-Lines: 55 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.1 (Canyonlands) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:33891 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:33891 Simon Josefsson writes: > Lloyd Zusman writes: > > > In thinking about how I'd like to use the `mml-parse' function within > > `mml-secure-part', it occurs to me that it would be useful to make use > > of another entry within structure that `mml-parse' returns in addition > > to `sign', `encrypt', and `contents'. I'd like to propose that along > > with `contents' there be an entry named `location' or something > > similar, whose value would be the point at which the mml tag appears > > within the message buffer. > > > > Thoughts? > > Sounds good to me. Btw, does `mml-secure-part' actually fail on > some messages, or why do you want to make the change? (I would > agree that it would be more aesthetically, `mml-secure-part' was a > hack.) Well, it doesn't fail outright, but it does cause inconsistent behavior. To see what I'm referring to, do the following: -- Compose a message in gnus, either email or news. -- Select to the MML -> Security -> Sign -> PGP/MIME menu entry. A tag that says '#part sign=pgpmime' will appear right at the top of the message (surrounded by less-than/greater-than signs). -- Position the cursor *before* this `#part' tag, and re-select the same menu entry. You will see a second, idential `#part' tag appear above the first one. -- Now, delete the extra `#part' tag and move the cursor to a a point *after* the remaining `#part' tag. Then, select the same menu entry once more. This time, you'll see a second `sign=pgpmime' attribute added top this `#part' tag. Now, none of this is all that horrible, but it's inconsistent behavior. In addition, each of these causes a redundant tag or attribute to be added. The behavior I'm looking for is for tags and attributes to only be added when they are not redundant. Also, I'd like to be able to write functions to remove tags and attributes. My proposed changes to `mml-secure-part' would make both of these behaviors easy to implement. And so yes, I agree with you that this is more of aesthetic change, at least the part concerning the prevention of redundant tags/attributes. But to be able to delete tags/attributes is more than an aesthetic change, in my opinion. -- Lloyd Zusman ljz@asfast.com