hashcash - buffer modification

hashcash - buffer modification

[Karl Chen]

Hi, I'm glad hashcash is now integrated and on by default.

One thing that bothers me about the asynchronous payment
insertion, which is otherwise awesome, is that it sets the message
buffer modification bit.

I use the advice below to get around it; how about integrating it
into hashcash-insert-payment-async-2?


(defadvice hashcash-insert-payment-async-2 (around kc-hashcash-set-notmodified
                                                   (buffer &rest l)
                                                   activate)
  (let ((modified (buffer-modified-p buffer)))
    ad-do-it
    (save-excursion
      (set-buffer buffer)
      (set-buffer-modified-p modified))))


-- 
Karl 2006-11-14 15:44

Re: hashcash - buffer modification

[Katsumi Yamaoka]

>>>>> In <quack.20061114T1548.lthmz6tmvyk@roar.cs.berkeley.edu>
>>>>>	Karl Chen wrote:

> Hi, I'm glad hashcash is now integrated and on by default.

> One thing that bothers me about the asynchronous payment
> insertion, which is otherwise awesome, is that it sets the message
> buffer modification bit.

> I use the advice below to get around it; how about integrating it
> into hashcash-insert-payment-async-2?

> (defadvice hashcash-insert-payment-async-2 (around kc-hashcash-set-notmodified
>                                                    (buffer &rest l)
>                                                    activate)
>   (let ((modified (buffer-modified-p buffer)))
>     ad-do-it
>     (save-excursion
>       (set-buffer buffer)
>       (set-buffer-modified-p modified))))

I see no oddness there.  I'll install the following change in
the trunk if no objection:

--8<---------------cut here---------------start------------->8---
--- hashcash.el~	2006-04-15 18:12:07 +0000
+++ hashcash.el	2006-11-15 04:57:42 +0000
@@ -247,7 +247,9 @@
 					hashcash-process-alist))
 	  (message-goto-eoh)
 	  (when pay
-	    (insert-before-markers "X-Hashcash: " pay)))))))
+	    (let ((modified (buffer-modified-p buffer)))
+	      (insert-before-markers "X-Hashcash: " pay)
+	      (set-buffer-modified-p modified))))))))
 
 (defun hashcash-cancel-async (&optional buffer)
   "Delete any hashcash processes associated with BUFFER.
--8<---------------cut here---------------end--------------->8---

BTW, how do you add hashcash headers when you write a mail from
scratch (i.e., the case where To and Cc have not been filled yet)?
I use `mail-add-payment', not `mail-add-payment-async'.

Regards,

Re: hashcash - buffer modification

[Karl Chen]

>>>>> On 2006-11-14 21:00 PST, Katsumi Yamaoka writes:

    Katsumi> I see no oddness there.  I'll install the following
    Katsumi> change in the trunk if no objection
 
Looks good; thanks.

    Katsumi> BTW, how do you add hashcash headers when you write a
    Katsumi> mail from scratch (i.e., the case where To and Cc
    Katsumi> have not been filled yet)?  I use `mail-add-payment',
    Katsumi> not `mail-add-payment-async'.

We could add an overlay on the headers with modification-hooks
that adds asynchronous payment for valid email addresses if the
user hasn't modified headers for (configurable) 30 seconds.

-- 
Karl 2006-11-15 00:31

Re: hashcash - buffer modification

[gdt]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>>>>> In <quack.20061114T1548.lthmz6tmvyk@roar.cs.berkeley.edu>
>>>>>>	Karl Chen wrote:
>
>> Hi, I'm glad hashcash is now integrated and on by default.
>
>> One thing that bothers me about the asynchronous payment
>> insertion, which is otherwise awesome, is that it sets the message
>> buffer modification bit.

This could result in saving a draft and then having hashcash appear,
and then the +hashcash draft will not necessarily be saved.  It's
arguable what the right behavior is.

Given timestamps in hashcash, one could argue that hashcash stamps
shouldn't necessarily be saved in draft mode, but generated fresh
nearer to sending.

> BTW, how do you add hashcash headers when you write a mail from
> scratch (i.e., the case where To and Cc have not been filled yet)?
> I use `mail-add-payment', not `mail-add-payment-async'.

I think both work, but the former makes you wait.

It would be nice to have a keybinding for mail-add-payment-async in
Message mode.  Perhaps C-c C-f C-h (for hashcash header), or just C-c
C-h.

It would also be nice to have a hook that runs when the cursor leaves
an address fields and remains outside it for 5 seconds and that
invokes mail-add-payment-async.  I don't know how to do that.

-- 
    Greg Troxel <gdt@work.lexort.com>

Re: hashcash - buffer modification

[Katsumi Yamaoka]

>>>>> In <smu3b8kbxis.fsf@linuxpal.mit.edu> gdt@work.lexort.com wrote:

> This could result in saving a draft and then having hashcash appear,
> and then the +hashcash draft will not necessarily be saved.  It's
> arguable what the right behavior is.

I see, but I have none to insist about that.  So, I decided not
to modify the behavior rashly.  Karl, please keep using the
advice for some time.

> Given timestamps in hashcash, one could argue that hashcash stamps
> shouldn't necessarily be saved in draft mode, but generated fresh
> nearer to sending.

>> BTW, how do you add hashcash headers when you write a mail from
>> scratch (i.e., the case where To and Cc have not been filled yet)?
>> I use `mail-add-payment', not `mail-add-payment-async'.

> I think both work, but the former makes you wait.

> It would be nice to have a keybinding for mail-add-payment-async in
> Message mode.  Perhaps C-c C-f C-h (for hashcash header), or just C-c
> C-h.

> It would also be nice to have a hook that runs when the cursor leaves
> an address fields and remains outside it for 5 seconds and that
> invokes mail-add-payment-async.  I don't know how to do that.

The fundamental problem is that generating of hashcach takes
time, isn't it?  I'm not troubled with it, though.

I vaguely think it would be nice to lock To and Cc headers.
Those headers are unlocked at the beginning if they are empty.
A user fills them if needed, and locks them using a special
command which is a trigger to start generating hashcash (it
might be `mail-add-payment-async').  When a user wants to change
some of them, one unlocks them using another special command,
which removes existing hashcash headers.

>>>>> In <quack.20061115T0037.lthfyclt8aw@roar.cs.berkeley.edu>
>>>>>	Karl Chen wrote:

> We could add an overlay on the headers with modification-hooks
> that adds asynchronous payment for valid email addresses if the
> user hasn't modified headers for (configurable) 30 seconds.

I see.  It would be nice too.  The second question.  What
happens if a user modifies headers or types `C-c C-c' when
hashcash is being generated?  Or shouldn't those commands be
inhibited or deferred then?  Though it doesn't seem to be easy
to implement.

Regards,