Suggestions

Suggestions

[Ketil.Z]

Hi,

don't know if this is old stuff, but I currently use the times font
inside Xemacs.  I've even changed signature-face to courier, and I get
all yer beeeaaautiful ascii crap-hics, real neat.  For sure.

Anyway, what I'd really like for [SR]Gnus, is to recognize, and do
various things with different regions of a message.  In particular, I'd
like source code to be treated differently from text - perhaps according
to defaults in text-mode versus cc-mode (other modes might apply)?

Other things, like tables and such would be nice to recognize, too.  I
guess the most important problem is knowing when to auto fill, and when
not to.

Is this at all possible?  Any plans for implementations?

Oh, one more thing -- Supersedes:-articles aren't being threaded
properly, perhaps this isn't worth the trouble, anyway.

~kzm
-- 
    Mail from aol.com and interramp.com domains will be discarded
          Finger <ketil@haukugle.ii.uib.no> for more info

Re: Suggestions

[Kai Grossjohann]

>>>>> On 02 May 1996 16:31:07 +0200, "Ketil.Z" <ketil@ii.uib.no> said:

  Ketil> Anyway, what I'd really like for [SR]Gnus, is to recognize,
  Ketil> and do various things with different regions of a message.
  Ketil> In particular, I'd like source code to be treated differently
  Ketil> from text - perhaps according to defaults in text-mode versus
  Ketil> cc-mode (other modes might apply)?

  Ketil> Other things, like tables and such would be nice to
  Ketil> recognize, too.  I guess the most important problem is
  Ketil> knowing when to auto fill, and when not to.

I think this problem is AI complete if you want to do it properly.  I
propose the following view on this:

The author of a mail message wrote it in a monospaced (as opposed to
proportional) font.  The author of a message tries to make it
readable.  Therefore the rendition of a message that the author sees
can be expected to be rather readable.  Thus you shouldn't
second-guess that and just use a monospaced font for everything.

I'd imagine recognizing C might be rather easy: if the lines ends in
";" it's C, if the prev and/or the next line is C and the line
contains "else", it's C, too.

But how would you tell the difference between English and Cobol in
"add a to b giving c"?

Just my $0.02,
kai
-- 
Gleep!

Re: Suggestions

[Steven L Baur]

>>>>> "Kai" == Kai Grossjohann <grossjoh@charly.informatik.uni-dortmund.de> writes:

>>>>> On 02 May 1996 16:31:07 +0200, "Ketil.Z" <ketil@ii.uib.no> said:
Ketil> Anyway, what I'd really like for [SR]Gnus, is to recognize,
Ketil> and do various things with different regions of a message.
Ketil> In particular, I'd like source code to be treated differently
Ketil> from text - perhaps according to defaults in text-mode versus
Ketil> cc-mode (other modes might apply)?

Ketil> Other things, like tables and such would be nice to
Ketil> recognize, too.  I guess the most important problem is
Ketil> knowing when to auto fill, and when not to.

This is a reasonable idea, but well beyond the scope of what Gnus 5.2
or Red Gnus ought to be doing.  There are enough hooks in Gnus to let
one experiment with different ideas.  Hopefully the Gnus API is going
to stabilize thus encouraging this kind of experimentation ...

Kai> I think this problem is AI complete if you want to do it properly.  I
Kai> propose the following view on this:

Kai> The author of a mail message wrote it in a monospaced (as opposed to
Kai> proportional) font.  The author of a message tries to make it
Kai> readable.  Therefore the rendition of a message that the author sees
Kai> can be expected to be rather readable.  Thus you shouldn't
Kai> second-guess that and just use a monospaced font for everything.

Reading mail in a variable width font can be amusing.  It definitely
puts .signature ASCII graphics in their place.  Composing mail is
another story though.

Kai> I'd imagine recognizing C might be rather easy: if the lines ends in
Kai> ";" it's C, if the prev and/or the next line is C and the line
Kai> contains "else", it's C, too.

Kai> But how would you tell the difference between English and Cobol in
Kai> "add a to b giving c"?

You could at least start with the heuristics that file(1) uses.
Another possibility is to extend the categories of MIME types.  I
believe TM already supports an Emacs-LISP text MIME type, for example.

What I would really hate to see is Gnus support of the equivalent of
``WINMAIL.DAT''.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Suggestions

[Per Abrahamsen]

>>>>> "SLB" == Steven L Baur <steve@miranova.com> writes:

SLB> There are enough hooks in Gnus to let
SLB> one experiment with different ideas.  Hopefully the Gnus API is going
SLB> to stabilize thus encouraging this kind of experimentation ...

That part of the API is quite stable (since early (ding)).  Just use
`gnus-article-display-hook'. 

Re: Suggestions

[Ketil Z Malde]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

Kai Grossjohann <grossjoh@ls6.informatik.uni-dortmund.de> writes:

> I think this problem is AI complete if you want to do it properly. 

Well, I was planning on settling for non-proper solutions, then.

> The author of a mail message wrote it in a monospaced (as opposed to
> proportional) font.  The author of a message tries to make it
> readable.

...but then he shouldn't use a monospaced font! :-)

Besides, that's not really the issue -- the issue is when to break
lines, and when not to.  It's OK to accept things as they come on a 80
column vt100, but I have a fairly large Emacs window, and I'd like to
have text something more than just a narrow column.

I understand that it might be difficult to recognize when things can't
be broken, but some heuristics I'd suggest would be:

o lines with very few (non-wsp) characters, say less than 30
o lines with lots of non-letters [|\(){},+-*/&%$#]
o lines between «begin 644» and «end» :-)

Perhaps what we really need is for some well chosen SGML tags to get
accepted on Usenet.  How about an SGML-hierarchy?  RFD sgml.general,
anyone?  Have tags like <code>, <text>, <sig>, <footnote>, for instance.

> I'd imagine recognizing C might be rather easy: if the lines ends in
> ";" it's C, if the prev and/or the next line is C and the line
> contains "else", it's C, too.

And wouldn't it be way cool to have this display as any other C-code
(read: cc-mode/font-lock'ed)?  I likes it.  I likes it a lot.

> But how would you tell the difference between English and Cobol in
> "add a to b giving c"?

..and I'll worry about _that_ when somebody sends me messages with cobol
in them.  (Hey, how's font-locking in cobol-mode, anyway? :-)

~kzm
--
    Mail from aol.com and interramp.com domains will be discarded
          Finger <ketil@haukugle.ii.uib.no> for more info

Re: Suggestions

[Steven L Baur]

>>>>> "Ketil" == Ketil Z Malde <ketil@ii.uib.no> writes:<nl>
<nl>
<italic>Ketil></italic> Perhaps what we really need is for some well chosen SGML tags<nl>
<italic>Ketil></italic> to get accepted on Usenet.  How about an SGML-hierarchy?  RFD<nl>
<italic>Ketil></italic> sgml.general, anyone?  Have tags like <lt>code>, <lt>text>, <lt>sig>,<nl>
<italic>Ketil></italic> <lt>footnote>, for instance.<nl>
<nl>
Already implemented, as this message should indicate (if I haven't<nl>
<bold>screwed up</bold>).  The magic word is <italic>richtext</italic>.<nl>
<nl>
In MIME deficient environments, it's quite <bold>ugly</bold>.<nl>
-- <nl>
steve@miranova.com baur<nl>
Unsolicited commercial e-mail will be proofread for $250/hour.<nl>
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone<nl>
except you in November.<nl>

Re: Suggestions

[Per Abrahamsen]

>>>>> "Ketil" == Ketil Z Malde writes:

_\bK_\be_\bt_\bi_\bl_\b> Perhaps what we really need is for some well chosen SGML tags
_\bK_\be_\bt_\bi_\bl_\b> to get accepted on Usenet.  How about an SGML-hierarchy?  RFD
_\bK_\be_\bt_\bi_\bl_\b> sgml.general, anyone?  Have tags like <code>, <text>, <sig>,
_\bK_\be_\bt_\bi_\bl_\b> <footnote>, for instance.

>>>>> "SLB" == Steven L Baur <steve@miranova.com> writes:

SLB> Already implemented, as this message should indicate (if I haven't
SLB> s\bsc\bcr\bre\bew\bwe\bed\bd u\bup\bp).  The magic word is _\br_\bi_\bc_\bh_\bt_\be_\bx_\bt.

Actually, it is _\bt_\be_\bx_\bt_\b/_\be_\bn_\br_\bi_\bc_\bh_\be_\bd.  Too many people confused richtext with
some half-hearted and poorly defined attempt at a portable word
processor format created by Microsoft with a similar name.

But I think it worked, at least metamail (_\bM_\b-_\bt) could decode the
message.

Re: Suggestions

[Steven L Baur]

>>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

Per> Actually, it is _\bt_\be_\bx_\bt_\b/_\be_\bn_\br_\bi_\bc_\bh_\be_\bd.  Too many people confused richtext with
Per> some half-hearted and poorly defined attempt at a portable word
Per> processor format created by Microsoft with a similar name.

Per> But I think it worked, at least metamail (_\bM_\b-_\bt) could decode the
Per> message.

The code for it in tm is richtext.el, and the MIME type it put on that
message was:
Mime-Version: 1.0 (generated by tm-edit 7.53)
Content-Type: text/richtext; charset=US-ASCII

The copy I got was indeed enriched automatically by TM.

Is text/enriched preferred then instead of text/richtext?  My mailcap
came with both defined identically, so I guess it could go either way.
But if TM is using a suboptimal name, then now is the time to get it
fixed.

Regards,
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Suggestions

[Per Abrahamsen]

>>>>> "SLB" == Steven L Baur <steve@miranova.com> writes:

SLB> Is text/enriched preferred then instead of text/richtext?  

Yes, but they are not identical.  See RFC 1896 for the latest
definition of text/enriched.

Re: Suggestions

[Ketil.Z]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

Steven L Baur <steve@miranova.com> writes:

> Already implemented, as this message should indicate (if I haven't<nl>
> <bold>screwed up</bold>).  The magic word is
> <italic>richtext</italic>.<nl>

1) Didn't work for me, I tried to metamail it, as Per suggests, but
  nothing happened.  I see the <tag> tags.  (But in Per's message,
  things work out (apparently it contains ^Hs and such)

2) This is a very unSGMLish approach.  It lets people mark text as
  italic or bold, what they should do, is specify what parts of a
  message is what, and leave it to the client to decide what it looks
  like.

MIME «text/enriched» is ugly, broken and evil, and should be buried 
in a crossroads at midnight together with Quoted-Unreadable, Netscape
Extentions, and Bill Gates.

IMHO.

~kzm

Re: Suggestions

[Per Abrahamsen]

>>>>> "KZ" == Ketil Z <ketil@ii.uib.no> writes:

KZ> 1) Didn't work for me, I tried to metamail it, as Per suggests, but
KZ>   nothing happened.  I see the <tag> tags. 

I had to set MAILCAPS to make it work.  The default mailcaps file was
located in _\b/_\bp_\ba_\bc_\bk_\b/_\bm_\be_\bt_\ba_\bm_\ba_\bi_\bl_\b/_\be_\bt_\bc_\b/_\bm_\ba_\bi_\bl_\bc_\ba_\bp, while the metamail expected
_\b/_\bu_\bs_\br_\b/_\bl_\bo_\bc_\ba_\bl_\b/_\be_\bt_\bc_\b/_\bm_\ba_\bi_\bl_\bc_\ba_\bp.  Maybe your metamail has the same installation
glitch. 

KZ> 2) This is a very unSGMLish approach.  It lets people mark text as
KZ>   italic or bold, what they should do, is specify what parts of a
KZ>   message is what, and leave it to the client to decide what it looks
KZ>   like.

KZ> MIME «text/enriched» is ugly, broken and evil, and should be buried 
KZ> in a crossroads at midnight together with Quoted-Unreadable, Netscape
KZ> Extentions, and Bill Gates.

Well, we need s\bso\bom\bme\bet\bth\bhi\bin\bng\bg better than plain newline terminated ascii,
and even if we don't we are going to get it soon anyway.
_\bt_\be_\bx_\bt_\b/_\be_\bn_\br_\bi_\bc_\bh_\be_\bd is too little, too late, so donøt worry too much about
that.  My guess is that we will soon see _\bt_\be_\bx_\bt_\b/_\bh_\bt_\bm_\bl as the dominating
content type.  This might not be what the SGML purist would prefer,
but it beats the hell of the alternative, which would be
_\ba_\bp_\bp_\bl_\bi_\bc_\ba_\bt_\bi_\bo_\bn_\b/_\bm_\bs_\b-_\bw_\bo_\br_\bd.


There once were a text format called seetext, which was based on a
formalization of informal conventions like *bold* and _italic_.  It
was easily readable as plain text, yet quite powerful.  I can't find
it with archie or on the web, so I guess it has died by now.
Otherwise, it would have been a nice format to support. 

Re: Suggestions

[守岡 知彦 / MORIOKA Tomohiko]

[-- Attachment #1: Type: text/enriched, Size: 431 bytes --]

<nofill>
Steven> >>>>> "Per" == Per Abrahamsen <<abraham@dina.kvl.dk> writes:


Per> Actually, it is <underline>text/enriched</underline>.  Too many people confused richtext
Per> with some half-hearted and poorly defined attempt at a portable
Per> word processor format created by Microsoft with a similar name.


Per> But I think it worked, at least metamail (<underline>M-t</underline>) could decode the
Per> message.


</nofill>

[-- Attachment #2: Type: text/plain, Size: 1859 bytes --]


>>>>> In <m2hgtxary9.fsf@deanna.miranova.com> 
>>>>>	Steven L Baur <steve@miranova.com> wrote:

Steven> The code for it in tm is richtext.el, and the MIME type it put
Steven> on that message was:

Steven> Mime-Version: 1.0 (generated by tm-edit 7.53)
Steven> Content-Type: text/richtext; charset=US-ASCII

Steven> The copy I got was indeed enriched automatically by TM.

Steven> Is text/enriched preferred then instead of text/richtext?  My
Steven> mailcap came with both defined identically, so I guess it
Steven> could go either way. But if TM is using a suboptimal name,
Steven> then now is the time to get it fixed.

  tm supports both text/enriched and text/richtext. Because an news
reader for NeXT uses text/richtext. In fact, richtext support of tm
was made for a NeXT user.

  After that, RMS requested me to use enriched.el. So I rewrote
tm-rich.el to use enriched.el. However I supported text/richtext too
for compatibility. RMS requested me to write text/richtext converter
so I wrote richtext.el (however richtext.el wasn't bundled into Emacs
:-P)

  Anyway, richtext.el requires enriched.el so it supports both
formats. Maybe the name `richtext.el' is confusing.

  By the way, now enriched.el is included in Emacs 19.29 or later and
XEmacs 19.14 or later. text/enriched is more readable than
text/richtext. It uses ``n-1 rule'' instead of `<nl>' tag. ``n-1
rule'' is simple. N-1 line brakes is encoded to N line breaks. I think
`<underline>text/enriched</underline>' is more readable than
`_^Ht_^He_^Hx_^Ht_^H/_^He_^Hn_^Hr_^Hi_^Hc_^Hh_^He_^Hd'. So I think
text/enriched is not so bad.

  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
------- I protest resumption of French and Chinese nuclear testing.---

Re: Suggestions

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> There once were a text format called seetext, which was based on a
> formalization of informal conventions like *bold* and _italic_.  It
> was easily readable as plain text, yet quite powerful.  I can't find
> it with archie or on the web, so I guess it has died by now.
> Otherwise, it would have been a nice format to support. 

I have actually written support for this -- I just haven't included
it.  It'll be in Red Gnus for sure.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Suggestions

[Per Abrahamsen]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> Per Abrahamsen <abraham@dina.kvl.dk> writes:

>> There once were a text format called seetext, which was based on a
>> formalization of informal conventions like *bold* and _italic_.  It
>> was easily readable as plain text, yet quite powerful.  I can't find
>> it with archie or on the web, so I guess it has died by now.
>> Otherwise, it would have been a nice format to support. 

LMI> I have actually written support for this -- I just haven't included
LMI> it.  It'll be in Red Gnus for sure.

I guess this means *bold* and _italic_, not setext.

Apparently setext is still in use, it is just easier to find when you
spell it right.  

	<URL:http://www.bsdi.com/setext/>

Re: Suggestions

[Steven L Baur]

>>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> I have actually written support for this -- I just haven't included
LMI> it.  It'll be in Red Gnus for sure.

Per> I guess this means *bold* and _italic_, not setext.

Per> Apparently setext is still in use, it is just easier to find when you
Per> spell it right.  

Per> 	<URL:http://www.bsdi.com/setext/>

This is good stuff, and quite unintrusive.  It should be put on the
Red Gnus TODO list.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Suggestions

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I guess this means *bold* and _italic_, not setext.

Yup.

> Apparently setext is still in use, it is just easier to find when you
> spell it right.  
> 
> 	<URL:http://www.bsdi.com/setext/>

That sounds quite interesting, so perhaps Red Gnus should support that
as well?  We'll see.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Suggestions

[Jacob Morzinski]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> > 	<URL:http://www.bsdi.com/setext/>
> 
> That sounds quite interesting, so perhaps Red Gnus should support that
> as well?  We'll see.

While we're in the "Woundn't it be nice" frame of mind, have you
considered ProleText?  It's a formatting system used in the clari.*
newsgroups, which uses whitespace embedded at the ends of lines to
format the text.  (I can't judge how tough it would be to code,
though.  Perhaps not worth the trouble?)

More info is at <URL:http://proletext.clari.net/prole/proletext.html>

-- 
 Jacob Morzinski                                jmorzins@mit.edu

Re: Suggestions

[Lars Magne Ingebrigtsen]

Jacob Morzinski <jmorzins@MIT.EDU> writes:

> While we're in the "Woundn't it be nice" frame of mind, have you
> considered ProleText?  It's a formatting system used in the clari.*
> newsgroups, which uses whitespace embedded at the ends of lines to
> format the text. 

I haven't looked closely at ProleText, but it seems like something
that definitely should be given some consideration.  I've added it to
the Red Gnus todo list.  Perhaps I'll do something about it as well. 

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Suggestions

[Paul Franklin]

>>>>> Lars Magne Ingebrigtsen writes:

 > Per Abrahamsen <abraham@dina.kvl.dk> writes:

 >> Apparently setext is still in use, it is just easier to find when
 >> you spell it right.
 >> 
 >> 	<URL:http://www.bsdi.com/setext/>

 > That sounds quite interesting, so perhaps Red Gnus should support
 > that as well?  We'll see.

I haven't heard much about setext lately.  But I use it myself, mostly
because I **hate** writing HTML directly.

As far as I know, I have the sole copy of the latest version of the
perl setext-to-HTML converter.  I updated Tony Sanders' version, and
then asked Ian Feldman (the creator of setext) to comment.  All I've
heard from him is "There are problems with it; please don't distribute
it."  I have yet to find out what those problems are.

Since then, I've rewritten the script a few times, and I've also
ping'd Ian a couple of times.  I've also written a setext-to-LaTeX
converter; I currently plan to merge these back together so that most
of the code need not know about the target format.

If anyone wants a peek at what I have, let me know.  But I will ask
that you not pass it on until I merge the two scripts.

--Paul