personalized x-face

personalized x-face

[David Hedbor]

What about adding two new symbols to gnus-posting-styles;

x-face and x-face-file. The reason is, of course, that it would be a
lot easier inserting your x-face without (e)lisp knowledge then.

On the same subject, how would I do to add x-face to posting styles
today (ie load a file and return it as a string)?
-- 
[ Below is a random fortune, which is unrelated to the above message. ]
Reichel's Law:
	A body on vacation tends to remain on vacation unless acted upon by
	an outside force.

Re: personalized x-face

[Edward J. Sabol]

Excerpts from mail: (20-Apr-99) personalized x-face  by David Hedbor
> What about adding two new symbols to gnus-posting-styles; x-face and
> x-face-file. The reason is, of course, that it would be a lot easier
> inserting your x-face without (e)lisp knowledge then.

That was actually suggested as part of the original discussion (circa
September 1995) that led to the implementation of posting styles. I would be
in favor of this.

> On the same subject, how would I do to add x-face to posting styles
> today (ie load a file and return it as a string)?

Probably something like what Matt Pharr <mmp@Graphics.Stanford.EDU> posted to
this mailing list back on 1999-02-19 which was for doing the same thing but
for signature files. This is untested modification of that elisp code
snippet, but it should work. You may or may not need to delete the trailing
newline, depending upon whether your x-face-file has a trailing newline or
not.

(defun my-x-face-file-to-string()
  (with-temp-buffer
    (insert-file "/path/to/your/x-face-file")
    (goto-char (point-max))
    (delete-backward-char 1)
    (buffer-string)))

Later,
Ed

Re: personalized x-face

[Didier Verna]

David Hedbor <david@hedbor.org> writes:

> What about adding two new symbols to gnus-posting-styles;
>
> x-face and x-face-file. The reason is, of course, that it would be a
> lot easier inserting your x-face without (e)lisp knowledge then.

        Yes, but since multiple similar entries in the posting styles override
the preceding value, you couldn't have two `X-Faces' in your messages ;-)

        Seriously, I'm rather against the idea. Actually I'm also against the
`organization' field. Posting styles are usefull when you have a _real_
treatment to perform. For instance, the `name' or `address' field must be
handled in a way that outputs a correct `From:' header.

        But if we add a new posting style field for each header the user might
be interested in, the list is likely to grow day after day. Better use the
generic header functionality (a string as header name), and improve it if
needed.

        What would be really nice to have is better ways of specifying how to
fetch the value for posting style fields: from a function, a file, a plain
string, a variable etc. You basically would like to write something like:

("X-Face" :file "~/.face") or ("Organization" :value "The Gnus Consortium")

        I actually think that this mechanism would also be usefull for other
fields, like `signature' and `body' one. And why not adding another field
specifying whether you want the value to replace a possibly former one, or
to be just added (I want to keep my two faces! :-)

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /      E.N.S.T. INF C201.1      mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   (33) 01 45 81 73 46
                      75634 Paris  cedex 13     Fax.   (33) 01 45 81 31 19

Re: personalized x-face

[Lars Magne Ingebrigtsen]

Didier Verna <verna@inf.enst.fr> writes:

>         What would be really nice to have is better ways of specifying how to
> fetch the value for posting style fields: from a function, a file, a plain
> string, a variable etc. You basically would like to write something like:
> 
> ("X-Face" :file "~/.face") or ("Organization" :value "The Gnus Consortium")

That's a good idea.

On the whole, I think that the current posting style implementation is 
lacking.  The counter-intuitive "last value wins" thing; the "some of
these insert things and other set obscure variables" thing.  All the
questions that pop up about these things show that the design is bad.

So I kinda want to re-do it.

The precedence will be the traditional "the first matching element
wins".

Er.

No, now I remember why it is the way it is.  It was imagined that the
user may want to have one slew of settings for a complete hierarchy,
and then some more settings for a particular hierarchy in that
super-hierarchy.  The rational way to do that is the current way.

Ok; so I won't change that.

But, by golly, I'll change the function to insert everything
immediately and not set any variables!  So there!

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen