Re: untabify Lisp sources

On Wed, 01 Aug 2007 00:05:02 +0200 Reiner Steib <reinersteib+gmane <at> imap.cc> wrote: 

RS> On Tue, Jul 31 2007, Katsumi Yamaoka wrote:
>>>>>>> Ted Zlatanov wrote:
>>> I was told by Lars a while ago to use untabify on Gnus commits, so I do
>>> as a general rule.  That's what I mean by my question "aren't we
>>> supposed to use untabify?"
>> 
>> Oops.  I might have overlooked it in this list.  But I don't see
>> an advantage of untabifying the indentations.

RS> A quick search only shows messages about untabifying of texi files,
RS> AFAICS.

RS> <http://search.gmane.org/?query=untabify&group=emacs.gnus.general&author=Lars&sort=date>

This is not the first time I've remembered things wrong.  Having two
kids will do that to you.  Sorry for the nuisance.

Ted

Re: untabify Lisp sources

On Wed, 01 Aug 2007 07:57:31 +0900 Miles Bader <miles <at> gnu.org> wrote: 

MB> Katsumi Yamaoka <yamaoka <at> jpl.org> writes:
>> I can agree with the new convention if there is a good reason.
>> But even if the convention changes (or had changed?), I think
>> that we should separately do untabifying of the Lisp sources and
>> installing of changes.

MB> Well, _if_ you're going to do untabification, I guess it's best to keep
MB> it separate, but ... I think in general it's a very bad idea to make
MB> widespread source changes for purely cosmetic reasons (and in this case,
MB> it's not even really "cosmetic" -- whitespace is invisible!); it's a big
MB> pain for merging.

MB> Please, let's just stick with a recommended setting of
MB> `indent-tabs-mode', and not do any untabification.  The benefits of
MB> untabification seem very small compared to the pain (to be honest, what
MB> _are_ the benefits, exactly???).

This was all just my stupidity.  Please ignore.

Ted

Highlighting with GPG signed messages.

Hi !

When viewing a GPG signed message, the highlighting of citation and
signature isn't made. This is due to the `last' condition for the
highlighting to happen in the treatment functions.

For example, if you have a two parts message (Text + sig),
gnus-mime-display-security is called with the first one and the second
part is like discarded. So current-part and total-parts are never
equals and `last' is never validated.

This is the shortest patch I could came with :

Index: lisp/gnus-art.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-art.el,v
retrieving revision 7.222
diff -c -r7.222 gnus-art.el
*** lisp/gnus-art.el	20 Jul 2007 11:30:50 -0000	7.222
--- lisp/gnus-art.el	1 Aug 2007 14:11:14 -0000
***************
*** 8042,8048 ****
      (narrow-to-region (point) (point))
      (unless (gnus-unbuttonized-mime-type-p (car handle))
        (gnus-insert-mime-security-button handle))
!     (gnus-mime-display-part (cadr handle))
      (unless (bolp)
        (insert "\n"))
      (unless (gnus-unbuttonized-mime-type-p (car handle))
--- 8042,8051 ----

Re: Highlighting with GPG signed messages.

>>>>> Michaël Cadilhac wrote:

> When viewing a GPG signed message, the highlighting of citation and
> signature isn't made. This is due to the `last' condition for the
> highlighting to happen in the treatment functions.

> For example, if you have a two parts message (Text + sig),
> gnus-mime-display-security is called with the first one and the second
> part is like discarded. So current-part and total-parts are never
> equals and `last' is never validated.

> This is the shortest patch I could came with :

This is too short to work with forwarded signed messages.
How about this one?

Re: Highlighting with GPG signed messages.

>>>>> Katsumi Yamaoka wrote:

> How about this one?

This causes an error with format=flowed messages.  Oops.
Please use the next one:

Re: EasyPG 0.0.14

Hello Daiki!

I am currently using CVS easypg.

On XEmacs startup I got following backtrace:

(1) (initialization/error) An error has occurred while loading .emacs:

Malformed list: :bold

Backtrace follows:

  apply(face-custom-attributes-set epa-validity-high nil (custom) :bold)
  # bind (display atts tags frame spec face)
  face-display-set(epa-validity-high ((((class color) (background dark)) (:foreground
"PaleTurquoise" :bold t)) (t :bold t)) nil (custom))
  # bind (value frames frame args doc spec face)
  custom-declare-face(epa-validity-high ((((class color) (background dark)) (:foreground
"PaleTurquoise" :bold t)) (t :bold t)) "Face used for displaying the high validity." :group epa-faces)
  (defface epa-validity-high (backquote ((((class color) (background dark)) (:foreground
"PaleTurquoise" (\, <at>  (if (assq (quote :weight) custom-face-attributes) (quote (:weight bold))
(quote (:bold t)))))) (t (\, <at>  (if (assq (quote :weight) custom-face-attributes) (quote (:weight
bold)) (quote (:bold t))))))) "Face used for displaying the high validity." :group (quote epa-faces))
  # (unwind-protect ...)
<37 lines deleted by Adrian Aichner>
  require(epa-setup)

The fix for the error, which is in 0.0.14 as well, seems obvious:

Re: closing all inactive server connections

On Tue, 31 Jul 2007 17:52:42 +0900 Katsumi Yamaoka <yamaoka <at> jpl.org> wrote: 

>>>>>> Ted Zlatanov wrote:
KY> --- nntp.el~	2007-07-18 12:07:39 +0000
KY> +++ nntp.el	2007-07-31 03:04:52 +0000

>> I tried it and the IMAP server still hangs.  Maybe the fix is in
>> nnimap.el?  I haven't looked deeper into this issue but I'll be glad to
>> debug things on my side.

KY> Is the patch effective for the hanged nntp connections?

My NNTP connections are OK.

KY> Well, I tried looking into the IMAP code although I've never
KY> used nnimap.  And I found the functions that communicate with
KY> the server all have the following form:
KY>   (while (and (memq (process-status PROCESS) '(open run))
KY> 	      (wait-for-a-string-that-the-PROCESS-returns))
KY>     (accept-process-output PROCESS 1)
KY>     (sit-for 1))

KY> This can be an infinite loop if the process-status keeps `open'
KY> or `run' even though the connection has actually died.  In
KY> particular, the `imap-wait-for-tag' function can be the cause of
KY> the hanging since it sends the LOGOUT command to the dead server
KY> and waits for the response.  So, I tried modifying it so as to
KY> quit in a certain time.  The patch to imap.el is below.  Anyway,
KY> it needs to be reviewed by someone who is skilled in IMAP.  The
KY> default value of `imap-timeout-seconds' might be too small for

Re: Highlighting with GPG signed messages.

Katsumi Yamaoka <yamaoka <at> jpl.org> writes:

>>>>>> Katsumi Yamaoka wrote:
>
>> How about this one?
>
> This causes an error with format=flowed messages.  Oops.

I see you installed this version. Well, I didn't ACK because I was
searching for another solution: this one doesn't work for some of my
mail for a reason I haven't found yet.

I'll give you more information tomorrow or on Sunday.

--

-- 
 |   Michaël `Micha' Cadilhac       |       One user is enough.              |
 |   http://michael.cadilhac.name   |    People suck.                        |
 |   JID/MSN:                       |                                        |
 `----  michael.cadilhac <at> gmail.com  |          -- Tuomo Valkonen        -  --'

Re: Clickable '-- ' with signatures menu

[ Cc-ing ding ]

On Fri, Aug 03 2007, Michal Nazarewicz wrote:

> I've recently came up with an idea of making the signature separator
> clickable in such a way that after clicking it (or pressing enter when
> cursor is on it) a menu would pop-up with a list of signatures.  Then
> I can choose one signature and the current one would be replaced with
> the one I've chosen.
>
> Another thing would be making a "From:" header clickable in similar
> manner -- this time I could choose one of preset From headers.
>
> Surly it is possible do to this but I have no idea how to achieve such
> behaviour.  Any hints or code?

I'm not aware of such code.  But it would be a nice feature.  
Anyone?  

BTW, your User-Agent "Gnus/0.7" header is bogus.  Please fix it or
better use one of the predefined variants.

Bye, Reiner.
--

-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Prefering plain text over html parts in multipart messages

Reiner Steib <reinersteib+gmane <at> imap.cc> writes:

Hi Reiner,

>> Strange "text/html" is in it by default, but I have at least one
>> article with both html and text part where the html part is shown as
>> default...
>
> This should not happen.  Could you debug it or send the article
> (private info removed) to ding as a gzipped attachment?

Sure. After investigating a bit further I found out that gnus displays
always the html part and omits the text part with the default values of
`mm-discouraged-alternatives' and `gnus-buttonized-mime-types'.

With

(setq mm-discouraged-alternatives '("text/html" "text/richtext" "text/enriched")
      gnus-buttonized-mime-types  '("multipart/signed" "multipart/alternative"))

I get the buttons and the text part is displayed by default.

Here's an example multipart mail.

>> Anyway, this lead me to `gnus-buttonized-mime-types' which is a nice
>> feature.