Another proposal about `mml-parse'.

Another proposal about `mml-parse'.

[Lloyd Zusman]

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.

With this piece of information, it would then be very easy to use
`mml-parse' to locate the `#part' tags that contain the mml directives
that separate the message buffer, thereby making it easy to alter or
delete these tags, if desired.  Since `mml-parse-1' (the helper
function for `mml-parse') already knows the exact points at which the
mml tags exist, it seems to me that it would be very easy for this
extra `location' information to be added to the results of
`mml-parse'.

Thoughts?

By the way, I forgot to mention this in my previous message concerning
`mml-parse': I'm planning to make all the changes I'm discussing here,
after I get feedback from all of you; and then I'll post the patches
here.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Another proposal about `mml-parse'.

[Simon Josefsson]

Lloyd Zusman <ljz@asfast.com> 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.)

Re: Another proposal about `mml-parse'.

[Lloyd Zusman]

Simon Josefsson <sj@extundo.com> writes:

> Lloyd Zusman <ljz@asfast.com> 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

First patch affecting `mml-parse' (was: Another proposal about `mml-parse'.)

[Lloyd Zusman]

Here's my first patch affecting `mml-parse'.  It's actually just the
first half of what I want to do, since as I mentioned earlier, I want
to enchance `mml-parse' so that I can then use the results of
`mml-parse' to rationalize the results of `mml-secure-part'.

In this patch, I actually just made a minor change to the
`mml-read-tag' function within `mml.el'.  This is a helper function
that is called within `mml-parse-1'.  In my changed `mml-read-tag',
whenever it generates a `contents' entry, it also generates a
corresponding `tag-location' entry, whose cdr is the location within
the message buffer of the tag in question.

As I mentioned earlier, I intend to rewrite `mml-secure-part' to make
use of the `mml-parse' output that now contains this `tag-location'
entry.  I'll now start working on my changes to `mml-secure-part',
and I'll post that patch whenever it's ready.

But for now, this current patch should work just fine, and as far as I
can tell, the new, extra info returned by `mml-parse' will not harm
any existing code.

The patch:

*** mml.el.orig	Sun Dec 24 20:28:07 2000
--- mml.el	Sun Dec 24 20:37:22 2000
***************
*** 216,222 ****
  
  (defun mml-read-tag ()
    "Read a tag and return the contents."
!   (let (contents name elem val)
      (forward-char 2)
      (setq name (buffer-substring-no-properties
  		(point) (progn (forward-sexp 1) (point))))
--- 216,223 ----
  
  (defun mml-read-tag ()
    "Read a tag and return the contents."
!   (let ((orig-point (point))
! 	contents name elem val)
      (forward-char 2)
      (setq name (buffer-substring-no-properties
  		(point) (progn (forward-sexp 1) (point))))
***************
*** 234,239 ****
--- 235,242 ----
      (goto-char (match-end 0))
      ;; Don't skip the leading space.
      ;;(skip-chars-forward " \t\n")
+     ;; Put the tag location into the returned contents
+     (setq contents (append (list (cons 'tag-location orig-point)) contents))
      (cons (intern name) (nreverse contents))))
  
  (defun mml-read-part (&optional mml)


-- 
 Lloyd Zusman
 ljz@asfast.com

Re: First patch affecting `mml-parse' (was: Another proposal about `mml-parse'.)

[Simon Josefsson]

Lloyd Zusman <ljz@asfast.com> writes:

> But for now, this current patch should work just fine, and as far as I
> can tell, the new, extra info returned by `mml-parse' will not harm
> any existing code.

Commited, thanks.