The <word>.<word>.<word> rule

The <word>.<word>.<word> rule

[Per Abrahamsen]

Could we please remove the "<word>.<word>.<word> is a http address"
heuristic?  It is embarrassing.  While I'm, all for heuristics, they
should bear some resemblance to reality.  I'm getting hits on version
numbers, cvs servers and partial mail addresses.  It's making the
buttonization of the article buffer a joke rather than a help.

Any heuristic that assumes than a name that doesn't have http: method
prepended or at least start with "www." is a http server is going to
generate zillions of false positives.

Re: The <word>.<word>.<word> rule

[Hrvoje Niksic]

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

> Could we please remove the "<word>.<word>.<word> is a http address"
> heuristic?  It is embarrassing.

I agree.  The number of false positives is astounding.

Re: The <word>.<word>.<word> rule

[Stein A. Strømme]

[Hrvoje Niksic]

| Per Abrahamsen <abraham@dina.kvl.dk> writes:
| 
| > Could we please remove the "<word>.<word>.<word> is a http address"
| > heuristic?  It is embarrassing.
| 
| I agree.  The number of false positives is astounding.

If this is turning into a vote:  count me in too!
-- 
Stein Arild Strømme <mailto:stromme@mi.uib.no>  telefon +47 55584825
Universitetet i Bergen, Matematisk insitutt       mobil +47 95801887
Johs Brunsg 12, N--5008 Bergen                  telefax +47 55589672

Re: The <word>.<word>.<word> rule

[Stainless Steel Rat]

* stromme@mi.uib.no (Stein A. Strømme)  on Fri, 12 May 2000
| If this is turning into a vote:  count me in too!

Me three, four, five and six :).
-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.

Re: The <word>.<word>.<word> rule

[Kai Großjohann]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * stromme@mi.uib.no (Stein A. Strømme)  on Fri, 12 May 2000
> | If this is turning into a vote:  count me in too!
> 
> Me three, four, five and six :).

Seven.  Eight.  I have been convinced.

kai
-- 
Beware of flying birch trees.

Re: The <word>.<word>.<word> rule

[Jaap-Henk Hoepman]

On Fri, 12 May 2000 17:47:24 +0200 (MET DST) Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> 
> > * stromme@mi.uib.no (Stein A. Strømme)  on Fri, 12 May 2000
> > | If this is turning into a vote:  count me in too!
> > 
> > Me three, four, five and six :).
> 
> Seven.  Eight.  I have been convinced.

How many false positives would you get if you match <word>.<word>.[a-z][a-z] 
or <word>.<word>.("com"|"net"|"org"|"mil")?

Jaap Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: The <word>.<word>.<word> rule

[Karl Kleinpaste]

ratinox@peorth.gweep.net writes...
        ^      ^     ^
stromme@mi.uib.no (Stein A. Strømme) writes...
        ^  ^   ^
Kai.Grossjohann@CS.Uni-Dortmund.DE writes...
                ^  ^            ^
Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:
                           ^  ^       ^
> How many false positives would you get if you match <word>.<word>.[a-z][a-z] 
> or <word>.<word>.("com"|"net"|"org"|"mil")?

Just for starters, you get false positives on _lots_ of mail
addresses, including yours.

But you missed .edu as a case that should have been included.

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> Karl Kleinpaste <karl@charcoal.com>:

>> How many false positives would you get if you match
>> <word>.<word>.[a-z][a-z] or
>> <word>.<word>.("com"|"net"|"org"|"mil")?

> Just for starters, you get false positives on _lots_ of mail
> addresses, including yours.

What if we match on
	[ \n\r\t]\w+\.\w+\.\("com"\|"net"\|"edu"\|"org"\|"mil"\)
?

What if we put all legal domains into that latter part?  Is that
possible or will all of those alternatives be one of the things that
drive the emacs regexp engine to its knees?

Re: The <word>.<word>.<word> rule

[Karl Kleinpaste]

Steinar Bang <sb@metis.no> writes:
> What if we put all legal domains into that latter part?  Is that
> possible or will all of those alternatives be one of the things that
> drive the emacs regexp engine to its knees?

I think the situation should be that, if you really like the excessive
false positive hit rate of the new style of naked URL buttonizing, you
should customize it any way you like (feel free to probe the depths
and limits of the emacs regexp engine), but that the apparent vast
majority who don't like it should get the previous default regexp
back, which only matches real, legitimate URLs.

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> Karl Kleinpaste <karl@charcoal.com>:

> ... that the apparent vast majority who don't like it should get the
> previous default regexp back, which only matches real, legitimate
> URLs.

Ah!  So you have a pipeline into "the vast majority's" opionions?

I see.

I'm impressed.

Re: The <word>.<word>.<word> rule

[Karl Kleinpaste]

Steinar Bang <sb@metis.no> writes:
> Ah!  So you have a pipeline into "the vast majority's" opionions?

That was uncalled for.

So far, in this discussion, you are the single, lone, individual
supporter of naked URL buttonization.  There have even been requests
on gnu.emacs.gnus for updates to the regexp, to tone it back down to
what it previously was.  "N-large opposed to 1" represents "vast", IMHO.

If you have some indication that there is anyone at all other than
yourself interested in perpetuating the current misbehavior, I'm sure
we would all be most interested to see it.  By comparison, it seems
that every day brings yet another dissatisfied distress call over the
bad behavior.  I see that Miroslav Zubcic has just weighed in with his
own brief compendium of false positives.

The fact remains that naked URL buttonization has a huge false
positive rate, and a lot of us are getting rather tired of it.  It
seems peculiar indeed that an objectively erroneous behavior should be
retained as the default.

Re: The <word>.<word>.<word> rule

[Bruce Stephens]

Karl Kleinpaste <karl@charcoal.com> writes:

[...]

> The fact remains that naked URL buttonization has a huge false
> positive rate, and a lot of us are getting rather tired of it.  It
> seems peculiar indeed that an objectively erroneous behavior should
> be retained as the default.

I agree.  However, someone else suggested a workable solution: change
the face that's used so that it's only bold (or whatever) when the
mouse is over it.  That way people can get the convenience of clicking
on 0.9.5a (if they really think that's a hostname) without the visual
distractions.

Re: The <word>.<word>.<word> rule

[Karl Kleinpaste]

Bruce Stephens <bruce+gnus@cenderis.demon.co.uk> writes:
> I agree.  However, someone else suggested a workable solution: change
> the face that's used so that it's only bold (or whatever) when the
> mouse is over it.

M-x customize RET gnus-article-buttons RET

    `gnus-article-button-face' is a variable declared in Lisp.
      -- loaded from "gnus-art"

    Value: bold

    Documentation:
    Face used for highlighting buttons in the article buffer.

Change it to be a normal font, and buttons will still be clickable,
and will highlight-on-mouse-hover on the basis gnus-article-mouse-face,
but will not be in bold text

Personally, I like bold text for /bona fide/ (syntactically correct)
URLs -- that much visual support is good.

Re: The <word>.<word>.<word> rule

[Toby Speight]

Karl> Karl Kleinpaste <URL:mailto:karl@charcoal.com>

0> In article <vxkd7mokltf.fsf@mesquite.charcoal.com>, Karl wrote:

Karl> M-x customize RET gnus-article-buttons RET
Karl>
Karl> Change it to be a normal font, and buttons will still be
Karl> clickable, and will highlight-on-mouse-hover on the basis
Karl> gnus-article-mouse-face, but will not be in bold text

They'll still interrupt tab-traversal; I don't think it's as good a
solution as tuning the regexp (or supplying a predicate function
against which to test possible matches - regexps aren't the hammer
for every lisp problem).

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> Toby Speight <streapadair@gmx.net>:

> They'll still interrupt tab-traversal; I don't think it's as good a
> solution as tuning the regexp (or supplying a predicate function
> against which to test possible matches - regexps aren't the hammer
> for every lisp problem).

Oh, I so agree.  Especially when the regexps get hairy.

A predicate function where one can apply heuristics.  I like that a
lot. 

naked URLs -- a little data (Re: The <word>.<word>.<word> rule)

[Karl Kleinpaste]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

I just finished going back through the most recent 200 articles in
nnml:list.ding, in which I manually walked through the articles,
finding everything that was naked-URL-buttonized.  In cases where it
mattered, I included anything left of an `@' for sake of contextual
clarity.  There were 159 buttonized naked URLs in those 200 articles,
of which nearly 100 were mail addresses, generally (though not always)
in attribution lines.  Some of the erroneous buttonization is
particularly exciting: See the last element, as well as Jaap Henk's
signature URL (#27).

As far as I can see, naked URL highlighting was correct on only 7
distinct strings (out of a total of 49), for an error rate of 86%.

--karl


[-- Attachment #2: naked URLs, counted and ranked --]
[-- Type: text/plain, Size: 1702 bytes --]

     1	     22	Kai.Grossjohann@CS.Uni-Dortmund.DE
     2	     14	zsh@cs.rochester.edu
     3	     14	ratinox@peorth.gweep.net
     4	      8	imap.akamai.com
     5	      7	abraham@dina.kvl.dk
     6	      6	fw@deneb.cygnus.argh.org
     7	      6	abcselect.tar.gz
     8	      5	vvv@vvv.vsu.ru
     9	      5	PerlTraining.Stonehenge.com
    10	      4	www.dict.org
    11	      4	sunsite.auc.dk
    12	      4	stromme@mi.uib.no
    13	      4	rlb@cs.utexas.edu
    14	      3	jsbien@mimuw.edu.pl
    15	      3	hoepman@cs.utwente.nl
    16	      3	halfdome.holdit.com
    17	      3	group.name.here
    18	      3	dodrt.dod.no
    19	      3	bmay@csse.monash.edu.au
    20	      3	aa0bt@aa0bt.ampr.org
    21	      2	mail.company.com
    22	      2	latte@uq.net.au
    23	      2	ke@gnu.franken.de
    24	      2	jas@pdc.kth.se
    25	      2	gnu.emacs.gnus
    26	      2	21.0.90
    27	      1	www.cs.utwente.nl/~hoepman
    28	      1	site.config.m4
    29	      1	sendmail-8.11.0.Beta1
    30	      1	palmieri@math.washington.edu
    31	      1	mail-source.el.old
    32	      1	mail-source.el.new
    33	      1	jwr@icm.edu.pl
    34	      1	i386-*-nt4.0.1381
    35	      1	ftp.gnus.org
    36	      1	foo@bar.org.au
    37	      1	foo.bar.tar.gz
    38	      1	foo.bar.com
    39	      1	flsc@hp.fciencias.unam.mx
    40	      1	every.second.dot
    41	      1	bruce+gnus@cenderis.demon.co.uk
    42	      1	bold.bold.bold
    43	      1	Peter.Weiss@germany.sun.com
    44	      1	Emacs/21.0.90
    45	      1	87n1m3rgyc.fsf@deneb.cygnus.argh.org
    46	      1	5.0.2.34.XXX
    47	      1	21.2.b31
    48	      1	0.9.5a
    49	      1	/home/justin/News/agent/nnimap/imap.akamai.com/.imap/inbox

Re: naked URLs -- a little data (Re: The <word>.<word>.<word> rule)

[Steinar Bang]

>>>>> Karl Kleinpaste <karl@charcoal.com>:

> As far as I can see, naked URL highlighting was correct on only 7
> distinct strings (out of a total of 49), for an error rate of 86%.

	grep "@" | wc -l
on the list gave me 24, so if we could eliminate all message ids and
email addresses (no, I don't feel a particular urge into making these
be mailto: URLs), we would be on to an error rate of about 50%
(assuming that 49 samples is statistically significant).

Would that be acceptable.

If so, then these would be the matches:
     4	      8	imap.akamai.com
     7	      6	abcselect.tar.gz
    16	      3	halfdome.holdit.com
    17	      3	group.name.here
    18	      3	dodrt.dod.no
    21	      2	mail.company.com
    25	      2	gnu.emacs.gnus
    27	      1	www.cs.utwente.nl/~hoepman
(I'm not sure why the domain name of this one matches, but it does)
    28	      1	site.config.m4
    31	      1	mail-source.el.old
    32	      1	mail-source.el.new
    35	      1	ftp.gnus.org
    37	      1	foo.bar.tar.gz
    38	      1	foo.bar.com
    40	      1	every.second.dot
    42	      1	bold.bold.bold
    46	      1	5.0.2.34.XXX
    47	      1	21.2.b31
    48	      1	0.9.5a
    49	      1	/home/justin/News/agent/nnimap/imap.akamai.com/.imap/inbox

If we require that a naked URL is preceeded by white space, then these 
would be the matches:
     4	      8	imap.akamai.com
     7	      6	abcselect.tar.gz
    16	      3	halfdome.holdit.com
    17	      3	group.name.here
    18	      3	dodrt.dod.no
    21	      2	mail.company.com
    25	      2	gnu.emacs.gnus
    27	      1	www.cs.utwente.nl/~hoepman
    28	      1	site.config.m4
    35	      1	ftp.gnus.org
    38	      1	foo.bar.com
    40	      1	every.second.dot
    42	      1	bold.bold.bold
(note that the current match disallows "-" as a word character)

If we require that the last word is one of the top level domains
(".com", ".edu" etc.), or a two-letter combination, we would get the
following matches:

     4	      8	imap.akamai.com
     7	      6	abcselect.tar.gz
    16	      3	halfdome.holdit.com
    18	      3	dodrt.dod.no
    21	      2	mail.company.com
    35	      1	ftp.gnus.org
    38	      1	foo.bar.com

Of these, only two are legal URLs (dodrt.dod.no and
halfdome.holdit.com). 

The question is if these narrowings make the error rate low enough to
be acceptable?

Re: The <word>.<word>.<word> rule

[Miroslav Zubcic]

[oops... I didn't see this thread before]

Karl Kleinpaste <karl@charcoal.com> writes:

> If you have some indication that there is anyone at all other than
> yourself interested in perpetuating the current misbehavior, I'm sure
> we would all be most interested to see it.  By comparison, it seems
> that every day brings yet another dissatisfied distress call over the
> bad behavior.  I see that Miroslav Zubcic has just weighed in with his
> own brief compendium of false positives.

Maybe it's posible to make this "maximal URL behaviour" like user
option, something like:

(add-hook 'gnus-button-url-regexp 'normal-button-url-regexp)

and

(add-hook 'gnus-button-url-regexp 'maximal-button-url-regexp)

and then two definitions for button-url-regexp in code. I don't know
is this posible or good...

> The fact remains that naked URL buttonization has a huge false
> positive rate, and a lot of us are getting rather tired of it.  It
> seems peculiar indeed that an objectively erroneous behavior should be
> retained as the default.

Is there any avaiable hot fix for this? Can I just copy old code from
5.8.3 (which one?) to new (I think) gnus-art.el and recompile?

Developers, no hard feelings but this is like a bug. :-(

-- 
This signature intentionally left blank

Re: The <word>.<word>.<word> rule

[Karl Kleinpaste]

Miroslav Zubcic <miroslav.zubcic@zesoi.fer.hr> writes:
> Is there any avaiable hot fix for this? Can I just copy old code from
> 5.8.3 (which one?) to new (I think) gnus-art.el and recompile?

M-x customize RET gnus-article-buttons RET
Look at gnus-button-url-regexp.
Strip off everything from the last "\|" to the end.
Set, save, exit customize, exit Gnus, exit Emacs.
Start a fresh Emacs, start Gnus.

Re: The <word>.<word>.<word> rule

[Miroslav Zubcic]

Karl Kleinpaste <karl@charcoal.com> writes:

> M-x customize RET gnus-article-buttons RET
> Look at gnus-button-url-regexp.
> Strip off everything from the last "\|" to the end.
> Set, save, exit customize, exit Gnus, exit Emacs.
> Start a fresh Emacs, start Gnus.

Yes, I know that, but I preffer to edit .gnus myself rather then
allowing automatic writing to .xemacs-options or .emacs.

I found good string posted by
Per Abrahamsen <rj1z339a3z.fsf_-_@zuse.dina.kvl.dk> This string is
just fine, not too much, not too small. (Main problem was strings and
regexps, this `|\(%' are hardly readible to me).

Thanks anyway...
-- 
This signature intentionally left blank

Re: The <word>.<word>.<word> rule

[Hrvoje Niksic]

Miroslav Zubcic <miroslav.zubcic@zesoi.fer.hr> writes:

> Karl Kleinpaste <karl@charcoal.com> writes:
> 
> > M-x customize RET gnus-article-buttons RET
> > Look at gnus-button-url-regexp.
> > Strip off everything from the last "\|" to the end.
> > Set, save, exit customize, exit Gnus, exit Emacs.
> > Start a fresh Emacs, start Gnus.
> 
> Yes, I know that, but I preffer to edit .gnus myself rather then
> allowing automatic writing to .xemacs-options or .emacs.

Then use `M-x find-variable RET gnus-button-url-regexp RET' to locate
the variable definition, copy/paste it to your .gnus (remember to
change `defvar' to `setq' and lose the docstring and custom options),
and edit it at your leasure.

> I found good string posted by
> Per Abrahamsen <rj1z339a3z.fsf_-_@zuse.dina.kvl.dk> This string is
> just fine, not too much, not too small. (Main problem was strings and
> regexps, this `|\(%' are hardly readible to me).

Sigh, a standard problem in languages that don't support a regexp
syntax.

Re: The <word>.<word>.<word> rule

[François Pinard]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> Miroslav Zubcic <miroslav.zubcic@zesoi.fer.hr> writes:

> > I found good string posted by
> > Per Abrahamsen <rj1z339a3z.fsf_-_@zuse.dina.kvl.dk> This string is
> > just fine, not too much, not too small. (Main problem was strings and
> > regexps, this `|\(%' are hardly readible to me).

> Sigh, a standard problem in languages that don't support a regexp syntax.

I did not follow this thread in detail, but let me add my grain of salt
nevertheless (or my grain of sand, depending on how you see it :-).

When I saw all this new highlighting, my first impression was positive,
as I like non-language to stand out in some way.  It was not perfect:
for example, the name part (before the `@') was forgotten, but overall,
it looked like a step in a good direction.

But when I realised that associated with the highlighting, was a button
invariably presuming, wrongly in most cases, that we were facing an HTTP
reference, my joy disappeared: this was far too dumb to be clever.

In a word, I like non-language to be highlighted.  However, button
association should be done _much_ more carefully.

I do not know if this might be useful, but here is some Python code I use to
highlight, then buttonize plain text while converting it into HTML pages.
The results are satisfying most of times, and maybe it could point towards
some compromise?  [Python regexps are Perlish more than Emacsish.]


def enhance(text, verbatim=0):
    text = string.replace(text, '&', '&amp;')
    text = string.replace(text, '<', '&lt;')
    text = string.replace(text, '>', '&gt;')
    text = string.replace(text, '\f', '')
    if verbatim:
        text = re.sub(r'((mailto:|http://|ftp://)[-_.@~/a-zA-Z0-9]+)',
                      r'<a href="\1">\1</a>', text)
    else:
        text = re.sub(r'((mailto:|http://|ftp://)([-_.@~/a-zA-Z0-9]+))',
                      r'<a href="\1">\3</a>', text)
    text = re.sub((r'(^|[^-_%+./a-zA-Z0-9:])'
                   r'([-_%+./a-zA-Z0-9]+@[-a-zA-Z0-9]+\.[-.a-zA-Z0-9]+)'),
                  r'\1<a href="mailto:\2">\2</a>', text)
    if verbatim:
        text = re.sub(r'_([-_@./a-zA-Z0-9]+)_', r'_<i>\1</i>_', text)
        text = re.sub(r'\*([-_@./a-zA-Z0-9]+)\*', r'*<b>\1</b>*', text)
        text = re.sub(r"`([-_@./a-zA-Z0-9]+)'", r"`<tt><b>\1</b></tt>'",
                      text)
    else:
        text = re.sub(r'_([-_@./a-zA-Z0-9]+)_', r'<i>\1</i>', text)
        text = re.sub(r'\*([-_@./a-zA-Z0-9]+)\*', r'<b>\1</b>', text)
        text = re.sub(r"`([-_@./a-zA-Z0-9]+)'", r'<tt><b>\1</b></tt>',
                      text)
    return text


P.S. - By the way, Lars, I would much like having a Python version of Gnus!
Would you add this to the Gnus TODO file? :-) :-) :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Python Emacs (was Re: The <word>.<word>.<word> rule)

[Jaap-Henk Hoepman]

On 16 May 2000 07:58:24 -0400 François Pinard <pinard@iro.umontreal.ca> writes:
> P.S. - By the way, Lars, I would much like having a Python version of Gnus!
> Would you add this to the Gnus TODO file? :-) :-) :-)

I'd very much like to see a Python Emacs!!!! Does your remark mean it 
exists :-O !?

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[François Pinard]

Jaap-Henk Hoepman <hoepman@cs.utwente.nl> écrit:

> François Pinard <pinard@iro.umontreal.ca> writes:
> > P.S. - By the way, Lars, I would much like having a Python version of Gnus!
> > Would you add this to the Gnus TODO file? :-) :-) :-)

> I'd very much like to see a Python Emacs!!!!  Does your remark mean it 
> exists :-O !?

Even if a Python Emacs existed, I could not switch using it unless Gnus
followed me.  If Lars does rewrite Gnus in Python, who knows if it would
not be the initial push that we need to do something sensible! :-)

The idea of a Python Emacs comes from time to time, outside the FSF
of course, but nothing serious gets done about it, so far that I know.
Emacs is very deep in my habits, and I have huge configuration files.
But if there was a sufficiently interesting editor (something hard to find)
with Python as an extension language, I would seriously consider switching.
Someone told me that `vim' supports Python, but I do not see myself using
`vi', as I suffer too much each time I try :-).  But I just do not dare
to imagine how I could handle all my mail, without Gnus.

Lars, my dear Lars, aren't you tired of Emacs LISP? :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Kai Großjohann]

What's so bad about Lisp that people are requesting a Java Emacs or a
Python Emacs or a Perl Emacs?
kai
-- 
Beware of flying birch trees.

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Stainless Steel Rat]

* Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)  on Wed, 17 May 2000
| What's so bad about Lisp that people are requesting a Java Emacs or a
| Python Emacs or a Perl Emacs?

Lisp is considered to be evil by allegedly "real programmers" who think C++
is the be-all, end-all language for everything.
-- 
Rat <ratinox@peorth.gweep.net>    \ Do not taunt Happy Fun Ball.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Brian Edmonds]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> Lisp is considered to be evil by allegedly "real programmers" who
> think C++ is the be-all, end-all language for everything.

Or there are some of us who think C++ sucks, but have serious trouble
thinking in Lisp.  Learning Perl was a no-brainer for me, but every time
I go to hack anything more difficult than a setq in my Emacs config I'm
tearing my hair out.  For whatever it's worth my brain just doesn't work
in the Lisp way.

There are others for whom it's exactly the opposite experience, and as
long as there are Lisp gods like Lars producing this cool code for
Emacs, I'm a happy camper.

Brian.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE5IwkdcCEFQUX5+OwRAujRAKConjtQIWl7dUBWyg+DKaicnYD8BwCdFzqQ
LbWDivWy5zTs/Nygbq9NSaI=
=RZhj
-----END PGP SIGNATURE-----

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Stainless Steel Rat]

* Brian Edmonds <brian@gweep.bc.ca>  on Wed, 17 May 2000
| Or there are some of us who think C++ sucks, but have serious trouble
| thinking in Lisp.  Learning Perl was a no-brainer for me, but every time
| I go to hack anything more difficult than a setq in my Emacs config I'm
| tearing my hair out.  For whatever it's worth my brain just doesn't work
| in the Lisp way.

My guess is that you are attempting to "translate" Lisp into something you
are familiar with.  This is bad for natural languages, and it is bad for
Lisp.  The mark of well-written Lisp is that you can read it almost like a
natural language.  In other words, when you see

	(+ 1 2 3 4)

You are consciously translating it into something like

	one plus two plus three plus four

Of course you have trouble; you are making it more complex than it is.
Instead, try reading it as

	add one, two, three, four

Once you can do that, parentheses become useful punctuation, just as they
are with complex algebraic notation.  Lisp works that way becuause it is a
functional language.  Everything in Lisp is a function of one sort or
another, from the simplest setq to the most complex lambda (now, some of
those give *me* a headache, but I've never laid claim to programming
godhead :).
-- 
Rat <ratinox@peorth.gweep.net>    \ Do not use Happy Fun Ball on concrete.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Russ Allbery]

Brian Edmonds <brian@gweep.bc.ca> writes:

> Or there are some of us who think C++ sucks, but have serious trouble
> thinking in Lisp.  Learning Perl was a no-brainer for me, but every time
> I go to hack anything more difficult than a setq in my Emacs config I'm
> tearing my hair out.  For whatever it's worth my brain just doesn't work
> in the Lisp way.

That's interesting, because I learned LISP before I learned Perl and while
I know Perl far better and much prefer it, I tend to write very LISP-like
Perl a lot of the time (heavy on map, grep, and list manipulation and
transforms).  Perl's actually pretty friendly to a LISP-like way of
thinking, far more so than most imperative languages, given that it
supports closures, application of functions to lists, and the like.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Jaap-Henk Hoepman]

On Wed, 17 May 2000 16:37:21 -0400 Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> * Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)  on Wed, 17 May 2000
> | What's so bad about Lisp that people are requesting a Java Emacs or a
> | Python Emacs or a Perl Emacs?
> 
> Lisp is considered to be evil by allegedly "real programmers" who think C++
> is the be-all, end-all language for everything.

Actually, C is a macro assembler which makes C++ ... an object oriented macro
assembler :-)

My problem with LISP is that it is a functional programming language used
imperatively, which, at least to me, makes any reasonably complex lisp function
very hard to read...

If only lisp didn't have setq... :-)

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Stainless Steel Rat]

* Jaap-Henk Hoepman <hoepman@cs.utwente.nl>  on Thu, 18 May 2000
| Actually, C is a macro assembler which makes C++ ... an object oriented
| macro assembler:-)

Very good.  Paste a star on your forehead. :)

| My problem with LISP is that it is a functional programming language used
| imperatively, which, at least to me, makes any reasonably complex lisp
| function very hard to read...

The idea is that you recursively break a task up into successively smaller
tasks, then you write functions to implement these little tasks.  Getting
back to the natural language analogy, each of these simple, "microtask"
functions is like a word.  Words are joined to form phrases, which are
joined to form sentences, which are joined to form paragraphs, etc.
-- 
Rat <ratinox@peorth.gweep.net>    \ Caution: Happy Fun Ball may suddenly
Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds.
PGP Key: at a key server near you!  \ 

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Jaap-Henk Hoepman]

On Fri, 19 May 2000 10:42:00 -0400 Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> * Jaap-Henk Hoepman <hoepman@cs.utwente.nl>  on Thu, 18 May 2000
> | Actually, C is a macro assembler which makes C++ ... an object oriented
> | macro assembler:-)
> 
> Very good.  Paste a star on your forehead. :)
> 

I feel radiant... :-)

> | My problem with LISP is that it is a functional programming language used
> | imperatively, which, at least to me, makes any reasonably complex lisp
> | function very hard to read...
> 
> The idea is that you recursively break a task up into successively smaller
> tasks, then you write functions to implement these little tasks.  Getting
> back to the natural language analogy, each of these simple, "microtask"
> functions is like a word.  Words are joined to form phrases, which are
> joined to form sentences, which are joined to form paragraphs, etc.

I know the basic idea of functional programming, thank you. I also know it's
good for certain programming tasks, and bad for others, and is actually not
used all that often... 

LISP is a very bad functional programming language, because
it allows you to use it imperatively: first do this, change the program state,
then do that, etc.... and the syntax is really horrible.

I have managed, over the years, to write simple LISP code for emacs-related
stuff. There have been many times I would have liked to do something more
complex, but was stopped by the `obnoxiousness' of LISP...

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Kai Großjohann]

Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

> LISP is a very bad functional programming language, because it
> allows you to use it imperatively: first do this, change the program
> state, then do that, etc.... and the syntax is really horrible.

Why are you using it imperatively, then, if you don't want to?  Or are
you speaking of modifying existing code?

kai
-- 
Beware of flying birch trees.

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Jaap-Henk Hoepman]

On Sun, 21 May 2000 00:43:11 +0200 Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:
> 
> > LISP is a very bad functional programming language, because it
> > allows you to use it imperatively: first do this, change the program
> > state, then do that, etc.... and the syntax is really horrible.
> 
> Why are you using it imperatively, then, if you don't want to?  Or are
> you speaking of modifying existing code?

Yep, mostly modifying existing code. Also, when I program I tend to think
imperatively... 

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Why are you using it imperatively, then, if you don't want to?  

>From the Emacs Lisp Reference Manual:

   * Use iteration rather than recursion whenever possible.  Function
     calls are slow in Emacs Lisp even when a compiled function is
     calling another compiled function.

My first "real" Emacs Lisp project (a Pascal mode) was a failure,
because I had used recursion (as I had learned in class was the true
Lisp way) instead of recursion throughout, and it was way too slow to
be useful.

I see no problem with allowing imperative programming as Lisp does,
but the implementation should make functional programming efficient.
As it is, I can write nice fast recursive and side-effect free code in
C and C++, but in Emacs Lisp I have to recode the recursion as
"side-effecs-and-iterations" whenever speed matters. 

Python and Perl seems in that light like side-steps to me, they don't
solve any of the real problems with Emacs Lisp.  A step forward would
be a real modern Lisp, preferably Scheme.  Or maybe even a statically
typed language.

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Hal Snyder]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:
> 
> > LISP is a very bad functional programming language, because it
> > allows you to use it imperatively: first do this, change the program
> > state, then do that, etc.... and the syntax is really horrible.
> 
> Why are you using it imperatively, then, if you don't want to?  Or are
> you speaking of modifying existing code?

Ok, so what we *really* need is Emacs based on Erlang or Haskell.

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Eric S. Johansson]

----- Original Message ----- 
From: "Stainless Steel Rat" <ratinox@peorth.gweep.net>
To: "(ding)" <ding@gnus.org>
Sent: Monday, May 22, 2000 9:03 PM
Subject: Re: Python Emacs (was Re: The <word>.<word>.<word> rule)


> * Hal Snyder <hal@vailsys.com>  on Mon, 22 May 2000
> | Ok, so what we *really* need is Emacs based on Erlang or Haskell.
> 
> Bah!  Real Programmers write hand-optimized assembly opcodes from memory.
> Macro assemblers are for wussies.  And don't get me started on those
> so-called "high-level" languages.

I thought real programmers used:

emacs a.out

:-) 

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Lloyd Zusman]

"Eric S. Johansson" <esj@harvee.billerica.ma.us> writes:

> From: "Stainless Steel Rat" <ratinox@peorth.gweep.net>
> >
> > [ ... ]
> >
> > Bah!  Real Programmers write hand-optimized assembly opcodes from memory.
> > Macro assemblers are for wussies.  And don't get me started on those
> > so-called "high-level" languages.
> 
> I thought real programmers used:
> 
> emacs a.out

Nope, they use ...

   adb a.out

... to create executables from scratch.  This includes creating the
`emacs' executable for all those wusses on the system who want to
use it.

Also, they just use `adb' to patch the kernel while it's running.

And for those systems that no longer have `adb', they create their own
`adb' by using `ed' and entering the binary opcodes to create `adb'.

> :-) 

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: real programmers(TM)

[Brian May]

>>>>> "Lloyd" == Lloyd Zusman <ljz@asfast.com> writes:

    Lloyd> Nope, they use ...

    Lloyd>    adb a.out

I always thought that the proper tool was

cat > a.out

or

echo "[insert program string here]" > a.out

(then again, not sure what adb is...)
-- 
Brian May <bmay@csse.monash.edu.au>

Re: real programmers(TM)

[Hrvoje Niksic]

Brian May <bmay@csse.monash.edu.au> writes:

> (then again, not sure what adb is...)

`adb' is the thing you use for control characters that `ed' and `cat'
won't grok.  Linux wussies don't have adb.  Har har har har!

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Luc MAZARDO]

"Eric S. Johansson" <esj@harvee.billerica.ma.us> writes:


> I thought real programmers used:
> 
> emacs a.out
> 
> :-) 
but real emacs user used :
User-Agent: Gnus/5.0806 (Gnus v5.8.6) Emacs/20.6
instead of 
X-Mailer: Microsoft Outlook Express 5.00.2919.6700

;)

<next page>

-- 
Luc Mazardo
Gnu Emacs:flame.el Why, technology is evil!

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Stainless Steel Rat]

* Jaap-Henk Hoepman <hoepman@cs.utwente.nl>  on Sat, 20 May 2000
| I have managed, over the years, to write simple LISP code for emacs-related
| stuff. There have been many times I would have liked to do something more
| complex, but was stopped by the `obnoxiousness' of LISP...

Keep in mind that many things in Emacs-Lisp are just plain broken compared
to Common Lisp or Scheme.  I suspect that this is the wall you are running
into, rather than a general inferiority of Lisp.
-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Jaap-Henk Hoepman]

On 21 May 2000 00:22:47 -0400 Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> * Jaap-Henk Hoepman <hoepman@cs.utwente.nl>  on Sat, 20 May 2000
> | I have managed, over the years, to write simple LISP code for emacs-related
> | stuff. There have been many times I would have liked to do something more
> | complex, but was stopped by the `obnoxiousness' of LISP...
> 
> Keep in mind that many things in Emacs-Lisp are just plain broken compared
> to Common Lisp or Scheme.  I suspect that this is the wall you are running
> into, rather than a general inferiority of Lisp.

Most of my rants againts (Emacs) LISP hold for Common lisp as well. I don't
know Scheme, so I can't comment on that...

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Jim Davidson]

Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

> LISP is a very bad functional programming language, because
> it allows you to use it imperatively: first do this, change the program state,
> then do that, etc.... 

LISP *let* you do things imperatively.  This can offer the prospect of
performance improvements.

> and the syntax is really horrible.

?  I don't think you understand programming languages.  

LISP has an extremely elegant syntax.  If you've ever heard of, say,
C++ or Java, those are examples of horrible syntaxes.  

-- 
Jim Davidson
jdavidson @ acm.org

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Jaap-Henk Hoepman]

On Mon, 22 May 2000 17:59:40 GMT Jim Davidson <jdavidson@nospam.com> writes:
> Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:
> > and the syntax is really horrible.
> 
> ?  I don't think you understand programming languages.  
> 
> LISP has an extremely elegant syntax.  If you've ever heard of, say,
> C++ or Java, those are examples of horrible syntaxes.  

Right, I would guess the syntax description of LISP is very elegant
indeed. Which makes LISP programs probably very easy to parse for a
_computer_. However, a LISP program is very hard to read for a _human_. Which
is what I meant when I said I find LISP's syntax horrible.

PASCAL has (had? anybody still using this) a good syntax.... Java is
reasonable, but it really borrowed too much from C.

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[François Pinard]

Jim Davidson <jdavidson@nospam.com> writes:

> Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

> > LISP [...] syntax is really horrible.

> LISP has an extremely elegant syntax.  If you've ever heard of, say,
> C++ or Java, those are examples of horrible syntaxes.

More exactly, LISP has almost no syntax, and that simplicity has elegance,
especially since programs and data use the same simple syntax.  However, at
the conceptual level, some LISPs are more elegant than others.  Emacs LISP
is not the best I know in that respect! :-)

Like Didier, I think Scheme is especially attractive.  And Python is
a kind of Scheme with a bit more of syntax and redundancy, increasing
overall legibility.  Object oriented programming is also more friendly
than in Scheme.

Guilified Emacs might easily become a bit repulsive from the mix of LISP
styles, leading to impurity all over.  While a Python Emacs would have
enough distance with LISP to maintain enough clarity.  But the definitive
advantage of Python Emacs is that it would support Python Gnus :-).

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[François Pinard]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> What's so bad about Lisp that people are requesting a Java Emacs or a
> Python Emacs or a Perl Emacs?

No Java, no Perl, but Python! :-)

It's just that Python is concise and legible.  Perl and Java don't match.

Yesterday, I rewrote in Python a little piece of Emacs LISP code.  Not only
it used less vertical space, but it became much clearer.  Always the same
story, for the few times I did this, so far.  But these were always toys.
I honestly do not know how it would go for a major piece of code, and how to
organise on a large scale a few LISP idioms which do not translate well in
Python.  But more it goes, more I dare to think that Python might be usable.

Stainless Steel Rat <ratinox@peorth.gweep.net> écrit:

> Lisp is considered to be evil by allegedly "real programmers" who think
> C++ is the be-all, end-all language for everything.

Not my case, then.  I'm not a real programmer.  I do like LISP.  Scheme
better than Emacs LISP, but in practice, Python much better than both.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Eric S. Johansson]

----- Original Message -----
From: "François Pinard" <pinard@iro.umontreal.ca>
To: "Kai Großjohann" <Kai.Grossjohann@CS.Uni-Dortmund.DE>
Cc: <ding@gnus.org>
Sent: Wednesday, May 17, 2000 4:59 PM
Subject: Re: Python Emacs (was Re: The <word>.<word>.<word> rule)


> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
> > What's so bad about Lisp that people are requesting a Java Emacs or a
> > Python Emacs or a Perl Emacs?
>
> No Java, no Perl, but Python! :-)
>
> It's just that Python is concise and legible.  Perl and Java don't match.

when people ask for scripting in <their favorite language>, all they are
asking for use for the tool to accommodate their current knowledgebase.
Lisp has an perceived extremely high learning curve.  When people are trying
to solve a problem with a tool, the last thing they want to be told is that
they need to discard what they know and learn a new way of thinking.

When a user is told they need to climb a very large learning curve, the
usual reaction is to put the software on the shelf and do things the brute
force/bloody ignorance way because it is perceived as easier.

A case in point is Gnus.  I'm very impressed at its power but using it to
read IMAP e-mail is sufficiently difficult that I've given up and gone back
to outlook (or pine on heavy virus days).  One of these days when I have a
week to spare, I'll go back to using it as my newsreader.  For now, tin is
sufficiently simple that I can do what I want without needing to spend a lot
of time learning.

As an aside, I stay on the list because I am collecting bits of emacs
knowledge I find very useful and I'm willing to learn slowly if I don't need
it (the knowledge) right now.

> Yesterday, I rewrote in Python a little piece of Emacs LISP code.  Not
only
> it used less vertical space, but it became much clearer.  Always the same
> story, for the few times I did this, so far.  But these were always toys.
> I honestly do not know how it would go for a major piece of code, and how
to
> organise on a large scale a few LISP idioms which do not translate well in
> Python.  But more it goes, more I dare to think that Python might be
usable.

I would love to see emacs integrate python and/or Perl as a first-class
scripting language like lisp with complete access to all of the internals
and primitive functions.  it would be extremely powerful (not to mention
large :-)

--- eric

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Felix Lee]

"Eric S. Johansson" <esj@harvee.billerica.ma.us>:
> I would love to see emacs integrate python and/or Perl as a first-class
> scripting language like lisp with complete access to all of the internals
> and primitive functions.  it would be extremely powerful (not to mention
> large :-)

you could always spawn an external process for the scripting
engine and use a message-passing protocol.  elisp is an
adequate message-passing protocol.

so it's a little slow.

the main problem I see with integrating perl with emacs is
the 'buffer'.  eg, perl's regexp engine won't work on
buffers.  I don't see a simple way of adding a buffer type
to perl without forcing you to do buffer<->string
conversions all the time, which is nasty.

python might be easier.
--

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Randal L. Schwartz]

>>>>> "Felix" == Felix Lee <flee@teleport.com> writes:

Felix> the main problem I see with integrating perl with emacs is
Felix> the 'buffer'.  eg, perl's regexp engine won't work on
Felix> buffers.  I don't see a simple way of adding a buffer type
Felix> to perl without forcing you to do buffer<->string
Felix> conversions all the time, which is nasty.

Well, there's already a Perl-embedded-in-Emacs available, so you
could just try it. :)  It's been in the CPAN for quite a while,
and recently updated to support 5.6.

See <http://search.cpan.org/search?dist=Emacs-PerlmacsPatch>

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Felix Lee]

merlyn@stonehenge.com (Randal L. Schwartz):
> Well, there's already a Perl-embedded-in-Emacs available, so you
> could just try it. :)  It's been in the CPAN for quite a while,
> and recently updated to support 5.6.
> 
> See <http://search.cpan.org/search?dist=Emacs-PerlmacsPatch>

scary.

it doesn't do anything special for buffers.  if you want to
manipulate a buffer in perl, you either have to call the
lisp routines, or use buffer-string to convert the buffer to
a string that perl can use, which is ... icky.

but what worries me more is I'm not clear on how safe the
wedding is.  like, I don't know if things work right if you
'die' out of a perl function called from a lisp function
called from a perl function.  and the intertwined garbage
collection is a mess.
--

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Steve Harris]

"Eric S. Johansson" <esj@harvee.billerica.ma.us> writes:

[...]

> A case in point is Gnus.  I'm very impressed at its power but using it to
> read IMAP e-mail is sufficiently difficult that I've given up and gone back
> to outlook (or pine on heavy virus days).  One of these days when I have a
> week to spare, I'll go back to using it as my newsreader.  For now, tin is
> sufficiently simple that I can do what I want without needing to spend a lot
> of time learning.

I didn't find there to be any extra complexity in using Gnus to read
from an IMAP server as opposed to a local spool.

If you already use Gnus as a newsreader and you subscribe to any
mailing lists, I can't see there being a better tool than Gnus to
actually get _value_ out of the mailing lists. Reading lists always
seemed like a hopeless mess with other mail tools. Personal mail
benefits as well. Gnus is the only thing that could finally knock me
off of Outlook and Pine. If only we didn't need Outlook at work...

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Brian May]

>>>>> "Eric" == Eric S Johansson <esj@harvee.billerica.ma.us> writes:

    Eric> all they are asking for use for the tool to accommodate
    Eric> their current knowledgebase.  Lisp has an perceived
    Eric> extremely high learning curve.  When people are trying to
    Eric> solve a problem with a tool, the last thing they want to be
    Eric> told is that they need to discard what they know and learn a
    Eric> new way of thinking.

My main dislike of LISP, is in my experience LISP programs seem
rather fragile and not robust compared with other programming languages.

When something goes wrong with a LISP program, more often then not, I
get a LISP error that means nothing to me. I send bug reports, etc,
but most of the time never get any response or nobody is able to help
me. (No offence to the people who *do* try to help).

I can only conclude that it is harder to write and maintain robust 
programs in LISP compared with other languages.

I suspect part of the problem, is that there might be tight bindings
between independent components. ie implement A, then fix problem B,
and accidently break A, without any warning unless it A is
specifically tested again.

Take, for instance, the mml-narrow-to-part command, M-m n, in gnus
message mode, "Symbol's function definition is void:
mml-narrow-to-part". Perhaps this has never has been properly
implemented.  Or perhaps, something happened to break it. I don't
know.

As another example, take the revision history of Gnus. Sure, it is
Beta, but when you consider the new bugs which have been introduced
since 5.8.0, I think it is significant. eg MIME attachments recently
breaking.

Note to mention downright weird behaviour that people often complain
about. Sure, some of these are user errors (eg the user sharing the
same directories for multiple back-ends), while others are gnus errors
(eg duplicate groups appearing). However, all these small things, in
my mind, add up to mean a fragile program, that must be used exactly
as intended, or you risk data loss.

I have had similar problems with other LISP code that I have used in
the past.

This isn't meant to undermine the efforts that anybody has made in
maintaining any of these programs in question.

To be honest, yes, I have seen a number of problems in beta perl code,
such as "Uninitialised variable" warnings, but in practise, the program
seems to work fine, regardless.
-- 
Brian May <bmay@csse.monash.edu.au>

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Kai Großjohann]

Brian May <bmay@csse.monash.edu.au> writes:

> My main dislike of LISP, is in my experience LISP programs seem
> rather fragile and not robust compared with other programming languages.

Hm.  Below, you mention Gnus.  There is a problem with Gnus: Lars is
now actually having a life, and therefore he has much less time for
working on Gnus.  But the previous Gnus release has been so long ago,
and people had been screaming for new release.  Therefore, Gnus 5.8
was released.  On the whole, I think it is better to have that MIME
support, but this does mean there are a few rough edges.

> When something goes wrong with a LISP program, more often then not, I
> get a LISP error that means nothing to me. I send bug reports, etc,
> but most of the time never get any response or nobody is able to help
> me. (No offence to the people who *do* try to help).

Hm.

> I can only conclude that it is harder to write and maintain robust 
> programs in LISP compared with other languages.
> 
> I suspect part of the problem, is that there might be tight bindings
> between independent components. ie implement A, then fix problem B,
> and accidently break A, without any warning unless it A is
> specifically tested again.

Well, this might be a problem.  Emacs Lisp does not enforce
encapsulation and hiding.  It relies on good programming to keep
things manageable.

But have you seen problems with a package other than Gnus?

> I have had similar problems with other LISP code that I have used in
> the past.

Maybe I have been lucky -- I didn't have all that many problems.

kai
-- 
Beware of flying birch trees.

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Felix Lee]

Brian May <bmay@csse.monash.edu.au>:
> My main dislike of LISP, is in my experience LISP programs seem
> rather fragile and not robust compared with other programming languages.
> When something goes wrong with a LISP program, more often then not, I
> get a LISP error that means nothing to me. I send bug reports, etc,

part of this is lack of static checking.  most lisp relies
on run-type checking of types and function arguments and
stuff, so if code is never exercised, then you'll never
notice the errors.  this is a class of bugs that doesn't
turn up (much) in a language like C.  (though some lisp
compilers will do a large amount of static checking, partly
as a side effect of trying to safely remove run-time checks.
but emacs lisp doesn't do this.)

on the other hand, lisp doesn't have runtime pointer or
malloc errors.  you don't get bus errors or segvs or memory
leaks or buffer overruns that cause strange results or
security holes (except for the occasional bug in the
underlying lisp runtime support).  memory corruption errors
are almost impossible to locate in large C programs, but
they don't happen in lisp.

so there are tradeoffs.

on the whole, I think I prefer lisp over C, but really, they
just need different types of programming discipline,
different types of paranoia on the part of the programmer.
inexperienced programmers will write shoddy code in either
language, for different reasons.

ok, lisp vs C isn't a fair comparison.  lisp vs perl might
be a better comparison, but it's a complicated issue and
tends to drift into religious wars.
--

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Kai Großjohann]

"Eric S. Johansson" <esj@harvee.billerica.ma.us> writes:

> A case in point is Gnus.  I'm very impressed at its power but using
> it to read IMAP e-mail is sufficiently difficult that I've given up
> and gone back to outlook (or pine on heavy virus days).  One of
> these days when I have a week to spare, I'll go back to using it as
> my newsreader.  For now, tin is sufficiently simple that I can do
> what I want without needing to spend a lot of time learning.

Have you ever used Gnus for reading mail before?  Maybe you only have
a small problem which is easy to help you with.  What was the problem
you saw when using Gnus for IMAP mail?

Getting the configuration right is a bit of a problem, but that's a
one-time-only event, and we can help you with that.

kai
-- 
Beware of flying birch trees.

getting started again was:Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Eric S. Johansson]

----- Original Message -----
From: "Kai Großjohann" <Kai.Grossjohann@CS.Uni-Dortmund.DE>
To: "Eric S. Johansson" <esj@harvee.billerica.ma.us>
Cc: "François Pinard" <pinard@iro.umontreal.ca>; <ding@gnus.org>
Sent: Thursday, May 18, 2000 5:17 AM
Subject: Re: Python Emacs (was Re: The <word>.<word>.<word> rule)


> "Eric S. Johansson" <esj@harvee.billerica.ma.us> writes:
>
> > A case in point is Gnus.  I'm very impressed at its power but using
> > it to read IMAP e-mail is sufficiently difficult that I've given up
> > and gone back to outlook (or pine on heavy virus days).  One of
> > these days when I have a week to spare, I'll go back to using it as
> > my newsreader.  For now, tin is sufficiently simple that I can do
> > what I want without needing to spend a lot of time learning.
>
> Have you ever used Gnus for reading mail before?  Maybe you only have
> a small problem which is easy to help you with.  What was the problem
> you saw when using Gnus for IMAP mail?
>
> Getting the configuration right is a bit of a problem, but that's a
> one-time-only event, and we can help you with that.

I had never used gnus before trying pnews even though I am a long time emacs
user (since version 17).  I must admit that I miss the simplicity of rmail
but enjoy the freedom that IMAP gives me.

You are right that most of the problems I have seem to be configuration
problems.  If I remember correctly, I was seeing things like conflicts with
programming-by-voice tools, seeing my IMAP folders listed two and three
times in the same buffer, I couldn't get messages marked for deletion,
expiration/expunge, and draft buffers to work.  I haven't even begun to
experiment with directing e-mail messages to other folders.

from past learning experiences, I believe part of my failure to use guns
successfully was due to the fact I haven't been able to sit with the
concepts that Gnus uses and really understand them.  In contrast, every
other IMAP based mail client I've used (except mahogany which is excused
because it still not very mature) has been a two-hour learning experience to
get everything working the way I want ranging from synchronizing with all
the mailboxes to filtering to URL launching.

I love emacs, I would love to build a grammar to drive gnus from speech
recognition and added to my current emacs grammar (FYI, I'm partially
handicapped (rsi) and need to use speech recognition for most computer use).
I just need to be able to get my head around all of the concepts so that I
can write the grammar.

I'm perfectly willing to play the role of an idiot user and make the whole
process of learning very transparent so that the documentation and
instructions on how to get started can be improved.  Is this something
people on the list are willing to do?

--- eric (village idiot in training)

Re: getting started again was:Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Kai Großjohann]

"Eric S. Johansson" <esj@harvee.billerica.ma.us> writes:

> I'm perfectly willing to play the role of an idiot user and make the whole
> process of learning very transparent so that the documentation and
> instructions on how to get started can be improved.  Is this something
> people on the list are willing to do?

I'm interested in improving the Gnus documentation.  I make no
promises as to the speed, but I can promise that I will tick all todo
items and will try to get to all of them eventually.

I'm sure others would be willing to do that, too.

kai
-- 
Beware of flying birch trees.

Re: getting started again

[Eric S. Johansson]

----- Original Message -----
From: "Kai Großjohann" <Kai.Grossjohann@CS.Uni-Dortmund.DE>
To: "Eric S. Johansson" <esj@harvee.billerica.ma.us>
Cc: <ding@gnus.org>
Sent: Thursday, May 18, 2000 10:08 AM
Subject: Re: getting started again was:Re: Python Emacs (was Re: The
<word>.<word>.<word> rule)


> "Eric S. Johansson" <esj@harvee.billerica.ma.us> writes:
>
> > I'm perfectly willing to play the role of an idiot user and make the
whole
> > process of learning very transparent so that the documentation and
> > instructions on how to get started can be improved.  Is this something
> > people on the list are willing to do?
>
> I'm interested in improving the Gnus documentation.  I make no
> promises as to the speed, but I can promise that I will tick all todo
> items and will try to get to all of them eventually.
>
> I'm sure others would be willing to do that, too.

well, I am looking forward to ditching outlook... so, here's the start of my
experiences

Installing and loading up gnus:

the documentation covers how to download gnus just fine.  I wasn't able to
dig out the information on how to install it and let emacs find it.
Rummaging through some old notes, I found:

cd into the gnus directory.  Type "./configure" then type "make" which will
byte compile the gnus package.  (How do you do this on Windows/NT/w2k?  I
did the byte compile on my Linux box and I'm accessing the image via Samba
as you'll see below.)

enter the following line into your .emacs file and exit then re-enter emacs
to activate the changes (is there a better way to do this?)
Don't forget to change the path in quotes to your path leading to the gnus
package.

(setq load-path (cons (expand-file-name "\\harvee\esj\elcode\gnus\lisp")
load-path))

(if I didn't have the notes, I would have been seriously up the creek on
installation.)

startup news by typing: "M-x gnus".  At this point you should see a screen
containing 3 groups (at least I did).  The groups I found were:
gnu.emacs.gnus, nndoc+gnus-help:gnus-help and nndraft:drafts

***READ THE GNUS-HELP MESSAGES***

--------- now I need to stop and go back to billable. futher adventures
later. -------
--- eric

Re: getting started again

[Erik Johannessen]

"Eric S. Johansson" <esj@harvee.billerica.ma.us> writes:

> the documentation covers how to download gnus just fine.  I wasn't able to
> dig out the information on how to install it and let emacs find it.
> Rummaging through some old notes, I found:
> 
> cd into the gnus directory.  Type "./configure" then type "make" which will
> byte compile the gnus package.  (How do you do this on Windows/NT/w2k?  I
> did the byte compile on my Linux box and I'm accessing the image via Samba
> as you'll see below.)

byte-compiling and installing gnus is explained in the README file in
the top-level directory of the distribution.  

> enter the following line into your .emacs file and exit then re-enter emacs
> to activate the changes (is there a better way to do this?)

there should be no need to restart your emacs.  you can eval the
expression from the buffer where you edit your .emacs file.

> Don't forget to change the path in quotes to your path leading to the gnus
> package.
> 
> (setq load-path (cons (expand-file-name "\\harvee\esj\elcode\gnus\lisp")
> load-path))

-Erik
-- 
/d{def}def/m{mul}d/a{add}d/q{repeat}d/y 1 d 300{/x 1 d 600{/c x 600 div 4 m 2
sub d/z y 300 div 2 m 1 sub d/r 0 d/i 0 d/t 0 d{t 1 le{/n r r m i i m sub c a
d/b 2 r m i m z a d/r n d/i b d r r m i i m a 16 gt{exit}if} {exit}ifelse/t t 
.01 a d}loop t setgray x y moveto 1 1 rlineto stroke/x x 1 a d}q /y y 1 a d}q

Re: getting started again

[Eric S. Johansson]

hey! you spell my name funny :-)  or maybe it was immigration that mutilated
my grandfather's name?

----- Original Message -----
From: "Erik Johannessen" <erij@online.no>
> "Eric S. Johansson" <esj@harvee.billerica.ma.us> writes:
>
> > the documentation covers how to download gnus just fine.  I wasn't able
to
> > dig out the information on how to install it and let emacs find it.
> > Rummaging through some old notes, I found:
...
> byte-compiling and installing gnus is explained in the README file in
> the top-level directory of the distribution.

that explains it!  When you grab gnus via CVS you do not get the README
file.  you get:

[esj@harvee gnus]$ ls
CVS        GNUS-NEWS  Makefile.in  config.cache  config.status  configure.in
etc         lisp      mkinstalldirs  todo
ChangeLog  Makefile   aclocal.m4   config.log    configure      contrib
install-sh  make.bat  texi           xemacs.mak

> > enter the following line into your .emacs file and exit then re-enter
emacs
> > to activate the changes (is there a better way to do this?)
>
> there should be no need to restart your emacs.  you can eval the
> expression from the buffer where you edit your .emacs file.

I tried that but it did not work.  I probably fat fingered something.

--- eric

Re: getting started again

[Rene Matteau]

Kai,

For Windows NT and 2000, use the supplied make.bat instead of
./configure and make.

"Kai Großjohann" <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
> ----- Original Message -----
> cd into the gnus directory.  Type "./configure" then type "make" which will
> byte compile the gnus package.  (How do you do this on Windows/NT/w2k?  I
> did the byte compile on my Linux box and I'm accessing the image via Samba
> as you'll see below.)
-- 
Rene

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Jim Davidson]

"Eric S. Johansson" <esj@harvee.billerica.ma.us> writes:

> A case in point is Gnus.  I'm very impressed at its power but using it to
> read IMAP e-mail is sufficiently difficult that I've given up and gone back
> to outlook (or pine on heavy virus days).  One of these days when I have a
> week to spare, I'll go back to using it as my newsreader.  For now, tin is
> sufficiently simple that I can do what I want without needing to spend a lot
> of time learning.

No, you're right.  Gnus is much harder to learn than, say, the Netscape
mail reader, even for someone who's Emacs-savvy.

Part of is that you need to get your head around the concepts.  That includes
the fact that Gnus was built as a newsreader.

Once you get it set, it *does* work fine as an IMAP client, and of course
gives you all the Emacs features at the same time.
-- 
Jim Davidson
jdavidson @ acm.org

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> What's so bad about Lisp that people are requesting a Java Emacs or a
> Python Emacs or a Perl Emacs?

FWIW, I believe JEmacs' goal is to run ELisp (unmodified hanoi.el
work) so there is no need to rewrite Gnus.

But since it is java, we'd get access to portable libraries (Curys
SASL, a nice widget library etc).  It's also multithreaded, and uses
Unicode.  If you can compile python or perl into java bytecode, you
could run that code in JEmacs too.

(Oh.  What's that?  Slow?  Oh yes.)

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Luc MAZARDO]

You have forgotten Efuns an emacs clone written in ocaml
(http://pauillac.inria.fr/para/cdrom/prog/unix/efuns/eng.htm). 

I don't know if people are requesting or try just for the fun to make
a Java or others languages "Emacs release".
Java, perl and python seems to be a bit too imperative languages for
doing the same thing like lisp do.
"load-library" may be in java "Class.forName()"

I don't think lisp is bad but ocaml could be better. 
Ocaml is a strongly-typed functional programming language and we can
read on efuns home page:
" Advantages of Caml on Lisp are numerous. In particular, static typing gives some security before loqding a module inside the editor"

why not ?

for the moment, I prefer my Gnu emacs and my gnus reader !

-- 
Luc Mazardo
Gnu Emacs:flame.el Furthermore, you dogmatist, I was Karl Marx in a
previous life.

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Jaap-Henk Hoepman]

On Wed, 17 May 2000 22:27:31 +0200 (MET DST) Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> What's so bad about Lisp that people are requesting a Java Emacs or a
> Python Emacs or a Perl Emacs?

EVERYTHING!

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Kai Großjohann]

Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> > What's so bad about Lisp that people are requesting a Java Emacs or a
> > Python Emacs or a Perl Emacs?
> 
> EVERYTHING!

Ah, right.  How could I have overlooked this?  To begin with, Lisp is
a four-letter word, right?

kai
-- 
Beware of flying birch trees.

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Didier Verna]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

> What's so bad about Lisp that people are requesting a Java Emacs or a
> Python Emacs or a Perl Emacs?

        For what's not worth: I'm a big fan of Lisp and Python, I hate Java
and I don't want ot know Perl. For what's worth, considering the ammount of
user-contributed Emacs packages and their size, I'd like to see python used
because:

- it's easy to learn
- it's easy to use
- it's easy to interface with C
- it's object oriented.

        I can't comment on efficiency issues because I don't have the material
to test the equivalent of Emacs packages written in Python.

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /        EPITA / LRDE         mailto:didier@lrde.epita.fr
/_/ / /_/ / /__ /      14-16 rue Voltaire        Tel. +33 (1) 44 08 01 77
                   94276 Kremlin-Bicêtre cedex   Fax. +33 (1) 44 08 01 99

Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Lars Magne Ingebrigtsen]

François Pinard <pinard@iro.umontreal.ca> writes:

> The idea of a Python Emacs comes from time to time, outside the FSF
> of course, but nothing serious gets done about it, so far that I know.

I have zero experience with Python, but it does seem like this week's
Java, although the hype is coming from a different direction this
time.

But I'm sure it's a lovely language.

> Lars, my dear Lars, aren't you tired of Emacs LISP? :-)

Nah.  I actually find it kinda comforting writing in Emacs Lisp -- my
day job is Common Lisp, which is a much more complex entity.  Emacs
Lisp is so simple and cuddly and nice and primitive.  No lexical
variables!  No packages!  No `loop'!  while!  "%" in format strings!

Er, uhm.

Anyway.

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

Re: The <word>.<word>.<word> rule

[Jørgen Wahlberg]

[ Miroslav Zubcic <miroslav.zubcic@zesoi.fer.hr> ]

|  Maybe it's posible to make this "maximal URL behaviour" like user
|  option, something like:
|  
|  (add-hook 'gnus-button-url-regexp 'normal-button-url-regexp)
|  
|  and
|  
|  (add-hook 'gnus-button-url-regexp 'maximal-button-url-regexp)
|  
|  and then two definitions for button-url-regexp in code. I don't know
|  is this posible or good...

I'd like a minmal URL behaviour as well, where only URLs on the form
<URL:http://www.gnus.org> are buttonized.  

I find it easier to use copy-and-paste to the address field of my web
browser when the URLs are in other formats.

 - jørgen

-- 
Jørgen Wahlberg <jw@nimrod.no>

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> jw@nimrod.no (Jørgen Wahlberg):

> I'd like a minmal URL behaviour as well, where only URLs on the form
> <URL:http://www.gnus.org> are buttonized.

Then you might as well not have it at all, because very few people
follow this convention today.

Re: The <word>.<word>.<word> rule

[Karl Eichwalder]

Steinar Bang <sb@metis.no> writes:

> Ah!  So you have a pipeline into "the vast majority's" opionions?

If I really want to browse <word>.<word>.<word> I use
`browse-url-at-point'.  No need to have a button to click on.

-- 
work : ke@suse.de                          |
     : http://www.suse.de/~ke/             |          ------    ,__o
home : ke@gnu.franken.de                   |         ------   _-\_<,
     : http://www.franken.de/users/gnu/ke/ |        ------   (*)/'(*)

Re: The <word>.<word>.<word> rule

[Stainless Steel Rat]

* Steinar Bang <sb@metis.no>  on Sun, 14 May 2000
| What if we match on
| 	[ \n\r\t]\w+\.\w+\.\("com"\|"net"\|"edu"\|"org"\|"mil"\)
| ?

peorth.gweep.net exists only as an MX record.  Any regexp that matches it
is technically a false positive because the only thing you can do with it
is send mail to it, and `peorth.gweep.net' is not a valid mailbox.
-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball contains a liquid core,
Minion of Nathan - Nathan says Hi! \ which, if exposed due to rupture, should
PGP Key: at a key server near you!  \ not be touched, inhaled, or looked at.

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

> peorth.gweep.net exists only as an MX record.  Any regexp that matches it
> is technically a false positive because the only thing you can do with it
> is send mail to it, and `peorth.gweep.net' is not a valid mailbox.

You can't eliminate positive matches completely (ie. there is no way
to avoid matching the domain names in the quoted text, and at the same
time match naked URLs (or "non-URLs faking it", if you will)), but you
can cut considerably down on them.

Re: The <word>.<word>.<word> rule

[Andreas Fuchs]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 782 bytes --]


Today, Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> peorth.gweep.net exists only as an MX record.  Any regexp that matches it
> is technically a false positive because the only thing you can do with it
> is send mail to it, and `peorth.gweep.net' is not a valid mailbox.

Also, there is gnu.emacs.gnus, or comp.lang.lisp[1], which are
newsgroups. Many uucp hosts match as well.

kind regards,
Andreas


[1]  isn't this annoying? Let's see what happens if I throw in a
9.3.$)!"§$NO CARRIER
-- 
Andreas Stefan Fuchs                             in Real Life aka
asf@acm.org, asfuchs@gmx.at, asf@ycom.at         in NNTP and SMTP,
antifuchs                                        in IRCNet and
Relf Herbstfresser, Male 1/2 Elf Priest          in AD&D

Re: The <word>.<word>.<word> rule

[Andreas Fuchs]

Today, Karl Kleinpaste <karl@charcoal.com> wrote:
> Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:
>                            ^  ^       ^
>> How many false positives would you get if you match <word>.<word>.[a-z][a-z] 
>> or <word>.<word>.("com"|"net"|"org"|"mil")?

> Just for starters, you get false positives on _lots_ of mail
> addresses, including yours.
> But you missed .edu as a case that should have been included.

Then what about
'[^@]word.word.("com"|"net"|"org"|"mil"|"edu"|[a-z][a-z]) '?

kind regards,
-- 
Andreas Stefan Fuchs                             in Real Life aka
asf@acm.org, asfuchs@gmx.at, asf@ycom.at         in NNTP and SMTP,
antifuchs                                        in IRCNet and
Relf Herbstfresser, Male 1/2 Elf Priest          in AD&D

Re: The <word>.<word>.<word> rule

[Kai Großjohann]

Karl Kleinpaste <karl@charcoal.com> writes:

> Just for starters, you get false positives on _lots_ of mail
> addresses, including yours.

The buttonizing algoithm should buttonize mail addresses, first.  WIB
nifty if I could click on a mail address mentioned in a posting to
send a message?

kai
-- 
Beware of flying birch trees.

Re: The <word>.<word>.<word> rule

[Jaap-Henk Hoepman]

On 14 May 2000 15:17:13 -0400 Karl Kleinpaste <karl@charcoal.com> writes:
> ratinox@peorth.gweep.net writes...
>         ^      ^     ^
> stromme@mi.uib.no (Stein A. Strømme) writes...
>         ^  ^   ^
> Kai.Grossjohann@CS.Uni-Dortmund.DE writes...
>                 ^  ^            ^
> Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:
>                            ^  ^       ^
> > How many false positives would you get if you match <word>.<word>.[a-z][a-z] 
> > or <word>.<word>.("com"|"net"|"org"|"mil")?
> 
> Just for starters, you get false positives on _lots_ of mail
> addresses, including yours.
> 
> But you missed .edu as a case that should have been included.

Of course. I sort of suspected I missed one when sending this :-(
Well it's the idea that counts...

To avoid false positives on mail adresses (and other stuff), we could require
the regexp to start with a space (or else it should have http:// in front),
and not include the space in the button.

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> Jaap-Henk Hoepman <hoepman@cs.utwente.nl>:

> How many false positives would you get if you match
> <word>.<word>.[a-z][a-z] or <word>.<word>.("com"|"net"|"org"|"mil")?

I would like it to match "no" at the end, as well.  You would like it
to match "nl", presumably.  If we add all legal top level domains, it
will be one _major_ regexp.

Too big maybe?

Also I would only match if the character preceeding the first <word>
was whitespace.

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> stromme@mi.uib.no (Stein A. Strømme):

> [Hrvoje Niksic]
>> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>> 
>> > Could we please remove the "<word>.<word>.<word> is a http address"
>> > heuristic?  It is embarrassing.
>> 
>> I agree.  The number of false positives is astounding.

> If this is turning into a vote:  count me in too!

Count me in for a vote to _keep_ it.  I rather like it.

Re: The <word>.<word>.<word> rule

[Stainless Steel Rat]

* Steinar Bang <sb@metis.no>  on Fri, 12 May 2000
| Count me in for a vote to _keep_ it.  I rather like it.

Well, we now know who our resident Imp(udite) of the Perverse is :).
-- 
Rat <ratinox@peorth.gweep.net>    \ When not in use, Happy Fun Ball should be
Minion of Nathan - Nathan says Hi! \ returned to its special container and
PGP Key: at a key server near you!  \ kept under refrigeration.

Re: The <word>.<word>.<word> rule

[Kai Großjohann]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Well, we now know who our resident Imp(udite) of the Perverse is :).

The inhabitants of Perv are called Pervects, not Perverts!

www.dict.org does not know about `impudite', only `impedite'.  What
does `impudite' mean?

kai
-- 
Beware of flying birch trees.

Re: The <word>.<word>.<word> rule

[Stainless Steel Rat]

* Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)  on Sat, 13 May 2000
| www.dict.org does not know about `impudite', only `impedite'.  What
| does `impudite' mean?

It's an In Nomine reference.
-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann):

> www.dict.org does not know about `impudite',...

Kewl!  I can click on that address and open it in Netscape!

Re: The <word>.<word>.<word> rule

[Andi Hechtbauer]

Steinar Bang <sb@metis.no> writes:

> >>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann):
                          ^    ^       ^ 
Un-Kewl, I can click on   ^this^address^ and get an error in Netscape!

> > www.dict.org does not know about `impudite',...
> 
> Kewl!  I can click on that address and open it in Netscape!

-- 
Andi Hechtbauer                                           anti@spin.de 
System Administration                         voice: +49 941 94 65 937
SPiN GmbH               http://www.spin.de/     fax: +49 941 94 65 938  
------- web design - java chats - guestbooks - java/cgi coding -------

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> Andi Hechtbauer <anti@spin.de>:

> Steinar Bang <sb@metis.no> writes:
>> >>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann):
>                           ^    ^       ^ 
> Un-Kewl, I can click on   ^this^address^ and get an error in Netscape!

Somehow I never pick the wrong non-URL to click.

And should I do so, what's the big deal?

Re: The <word>.<word>.<word> rule

[Karl Kleinpaste]

Steinar Bang <sb@metis.no> writes:
> Somehow I never pick the wrong non-URL to click.
> And should I do so, what's the big deal?

Because the bold-facing of URLs draws the eye.  That's part of what
it's intended for.  If it weren't in bold type, you wouldn't know it's
there, so you wouldn't know you could click on it.  And that, in turn,
is what's really wrong: Excessive (and pointless) bold text on the
screen makes for atrociously unreadable text overall.  When I read
messages in xemacs-beta, and in just one message see 2 filenames and 4
XEmacs version numbers all in bold type, plus the usual selection of
mis-clickable mail addresses and news host references, it becomes more
and more painful to read the actual content, my eye being dragged
around willy-nilly by useless fontification.

It seems pretty clear to me that naked URL buttonizing is liked by
only a few.  I for one would appreciate it if the previous, non-naked
default regexp were reinstated, and some doc comments were given on
how to customize the regexp for those who really want a 90+% false
positive rate.

Re: The <word>.<word>.<word> rule

[Felix Lee]

Karl Kleinpaste <karl@charcoal.com>:
> Because the bold-facing of URLs draws the eye.  That's part of what

what about hover-type highlighting.  don't highlight URLs
unless the mouse is over them.  really, when reading I don't
need things like URLs to stand out at all.
--

Re: The <word>.<word>.<word> rule

[Toby Speight]

Karl> Karl Kleinpaste <URL:mailto:karl@charcoal.com>

0> In article <vxksnvlj5a2.fsf@mesquite.charcoal.com>, Karl wrote:

Karl> Steinar Bang <sb@metis.no> writes:
>> Somehow I never pick the wrong non-URL to click.  And should I do
>> so, what's the big deal?

Karl> Because the bold-facing of URLs draws the eye.

Not only that; it draws the TAB.  If there are a couple of URLs in a
message, I don't want to have to tab 10 times through the false
positives to get to them.

Re: The <word>.<word>.<word> rule

[Bjørn Mork]

Steinar Bang <sb@metis.no> writes:

> Somehow I never pick the wrong non-URL to click.

I do. I klick the right hand side of message-IDs like 
<whvh0hlysq.fsf@viffer.metis.no> all the time, causing Netscape to try
to connect to viffer.metis.no:80.


Bjørn

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> "Bjørn Mork" <bmork@dod.no>:

> I do. I klick the right hand side of message-IDs like
> <whvh0hlysq.fsf@viffer.metis.no> all the time, causing Netscape to
> try to connect to viffer.metis.no:80.

I guess that beats repeatedly running headfirst into brick walls as a
hobby. 

Not as painful, and nearly just as fun.

Re: The <word>.<word>.<word> rule

[Bjørn Mork]

Steinar Bang <sb@metis.no> writes:
> >>>>> "Bjørn Mork" <bmork@dod.no>:
> 
> > I do. I klick the right hand side of message-IDs like
> > <whvh0hlysq.fsf@viffer.metis.no> all the time, causing Netscape to
> > try to connect to viffer.metis.no:80.
> 
> I guess that beats repeatedly running headfirst into brick walls as a
> hobby. 
> 
> Not as painful, and nearly just as fun.

I am not used to the difference between the left and right side of
message-IDs yet, and the current URL regexp causes URL-buttonizing
of the right hand side even in the references header. I find that
extremely confusing. I click on a reference and wonder why Gnus 
doesn't fetch the article until a message from Netscape pops up
telling me that it can't connect to viffer.metis.no. Well that's OK, 
but I didn't want it to try either.

People rarely give out "URLs" without the "http://" if the machine
name doesn't start with "www.". I believe matching on scheme or
"www.|ftp." would be sufficient to catch most URLs.


Bjørn

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> "Bjørn Mork" <bmork@dod.no>:

> People rarely give out "URLs" without the "http://" if the machine
> name doesn't start with "www.". I believe matching on scheme or
> "www.|ftp." would be sufficient to catch most URLs.

What about dodrt.dod.no?  Also halfdome.holdit.com, which was in Karl
Kleinpaste's list.

But nits aside, I agree that www will match enough incomplete URLs to
be useful, and the regexp should be simple and efficient.

(but I still like that predicate idea)

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> "Bjørn Mork" <bmork@dod.no>:

> I am not used to the difference between the left and right side of
> message-IDs yet, and the current URL regexp causes URL-buttonizing
> of the right hand side even in the references header. I find that
> extremely confusing. I click on a reference and wonder why Gnus
> doesn't fetch the article until a message from Netscape pops up
> telling me that it can't connect to viffer.metis.no. Well that's OK,
> but I didn't want it to try either.

Ah... I see.  Of course this could have been avoided by disallowing @
before the match.

New URL button rule (was: Re: The <word>.<word>.<word> rule)

[Per Abrahamsen]

Steinar Bang <sb@metis.no> writes:

> >>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann):
> 
> > www.dict.org does not know about `impudite',...
> 
> Kewl!  I can click on that address and open it in Netscape!

Yep.  And there is a sane heuristic that cathes it, without generating
zillions of false positives.  Words that start with "www." can be
considered URL's.

Try this, it even catches local parts (unlike the dot.dot.dot rule):

(setq gnus-button-url-regexp
      "\\b\\(\\(www\\.\\|\\(s?https?\\|ftp\\|file\\|gopher\\|news\\|telnet\\|wais\\|mailto\\):\\)\\(//[-a-zA-Z0-9_.]+:[0-9]*\\)?\\([-a-zA-Z0-9_=!?#$@~`%&*+|\\/:;.,]\\|\\w\\)+\\([-a-zA-Z0-9_=#$@~`%&*+|\\/]\\|\\w\\)\\)")

Unless someone protests, I'll commit this change to CVS.

Re: New URL button rule (was: Re: The <word>.<word>.<word> rule)

[Steinar Bang]

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

> Yep.  And there is a sane heuristic that cathes it, without
> generating zillions of false positives.  Words that start with
> "www." can be considered URL's.

I thought of suggesting that, until I found that the only two real
URLs that survived my paring down of Karl Kleinpaste's examples, did
_not_ in fact, start with www...:-)

> Try this, it even catches local parts (unlike the dot.dot.dot rule):

> (setq gnus-button-url-regexp
>       "\\b\\(\\(www\\.\\|\\(s?https?\\|ftp\\|file\\|gopher\\|news\\|telnet\\|wais\\|mailto\\):\\)\\(//[-a-zA-Z0-9_.]+:[0-9]*\\)?\\([-a-zA-Z0-9_=!?#$@~`%&*+|\\/:;.,]\\|\\w\\)+\\([-a-zA-Z0-9_=#$@~`%&*+|\\/]\\|\\w\\)\\)")

> Unless someone protests, I'll commit this change to CVS.

I can live with this, it catches most of the ones I would like to
catch, and should avoid the false matches that drives people nuts.

(But I really liked that predicate idea)

Re: New URL button rule (was: Re: The <word>.<word>.<word> rule)

[Stainless Steel Rat]

* Per Abrahamsen <abraham@dina.kvl.dk>  on Mon, 15 May 2000
| Yep.  And there is a sane heuristic that cathes it, without generating
| zillions of false positives.  Words that start with "www." can be
| considered URL's.

That is a *very* bad assumption.  Not all web servers are called "www", and 
many web servers are also FTP servers.  Making assumptions about what a
non-URL FQDN might be is almost as bad as turning FQDNs into buttons.  I am 
not saying that your change is a bad thing, just that you should be sure of 
what you are doing before you make it.
-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.

Re: New URL button rule (was: Re: The <word>.<word>.<word> rule)

[Per Abrahamsen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> I am not saying that your change is a bad thing, just that you
> should be sure of what you are doing before you make it.

I believe it will match the users expectations, which is the most one
can demand from a heuristic.  Users will expect a www.dict.com button
to connect to a http server.

Re: New URL button rule (was: Re: The <word>.<word>.<word> rule)

[Steinar Bang]

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

> Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
>> I am not saying that your change is a bad thing, just that you
>> should be sure of what you are doing before you make it.

> I believe it will match the users expectations, which is the most one
> can demand from a heuristic. 

Agreed.

> Users will expect a www.dict.com button to connect to a http server.

Agreed.

(a pity about dodrt.dod.no, though...;-) )

Re: New URL button rule (was: Re: The <word>.<word>.<word> rule)

[Bjørn Mork]

Steinar Bang <sb@metis.no> writes:

> (a pity about dodrt.dod.no, though...;-) )

Add a bookmark :-)


Bjørn

Re: New URL button rule (was: Re: The <word>.<word>.<word> rule)

[Kai Großjohann]

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

> I believe it will match the users expectations, which is the most one
> can demand from a heuristic.  Users will expect a www.dict.com button
> to connect to a http server.

Maybe we should do the Netscape heuristic.  I guess this is what most
people are used to.  So, an ftp.uu.net button should open a dired
buffer or use W3 to do the ftp thing.

Whatcha think?

kai
-- 
Beware of flying birch trees.

Re: New URL button rule (was: Re: The <word>.<word>.<word> rule)

[Hrvoje Niksic]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> > I believe it will match the users expectations, which is the most one
> > can demand from a heuristic.  Users will expect a www.dict.com button
> > to connect to a http server.
> 
> Maybe we should do the Netscape heuristic.  I guess this is what
> most people are used to.  So, an ftp.uu.net button should open a
> dired buffer or use W3 to do the ftp thing.

For the record, I've always *hated* that about netscape.  When I wrote
Wget, I deliberately chose not to implement that part.

Think ftpsearch.ntnu.no.

Re: New URL button rule (was: Re: The <word>.<word>.<word> rule)

[Per Abrahamsen]

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

> Unless someone protests, I'll commit this change to CVS.

I have commited it now.

Re: The <word>.<word>.<word> rule

[Steinar Bang]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

> * Steinar Bang <sb@metis.no>  on Fri, 12 May 2000
>> Count me in for a vote to _keep_ it.  I rather like it.

> Well, we now know who our resident Imp(udite) of the Perverse is :).

What I would like to do away with is all the "nice" colours and
italicizing of the quoted text.  I've turned off all that I've found,
but some stuff still insists on popping up.

That's useless noise to me, but making dodrt.dod.no into a clickable
URL saves me the work of cut and paste.

Ie. one saves me a work operation, one doesn't.  See the difference?

Re: The <word>.<word>.<word> rule

[Karl Eichwalder]

Steinar Bang <sb@metis.no> writes:

> That's useless noise to me, but making dodrt.dod.no into a clickable
> URL saves me the work of cut and paste.

I'm mainly interested in reading messages; the <word>.<word>.<word> rule
makes it hard to read messages.  Maybe I wouldn't mind to have all
things clickable but I don't want to see this mess (I don't need it).

> Ie. one saves me a work operation, one doesn't.  See the difference?

Du you? ;-)

-- 
work : ke@suse.de                          |
     : http://www.suse.de/~ke/             |          ------    ,__o
home : ke@gnu.franken.de                   |         ------   _-\_<,
     : http://www.franken.de/users/gnu/ke/ |        ------   (*)/'(*)

Re: The <word>.<word>.<word> rule

[Stainless Steel Rat]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

* Steinar Bang <sb@metis.no>  on Sat, 13 May 2000
| What I would like to do away with is all the "nice" colours and
| italicizing of the quoted text.  I've turned off all that I've found,
| but some stuff still insists on popping up.

Oh, well, that's mostly easilly remedied with a patch that I stopped
bothering to promote but still use myself.


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


| That's useless noise to me, but making dodrt.dod.no into a clickable
| URL saves me the work of cut and paste.

| Ie. one saves me a work operation, one doesn't.  See the difference?

Well, thing is, a lot of us feel that the numerous false positives the
regexp currently generates makes reading messages more difficult than it
should be.  There is also the issue that foo.bar.com is not a URL and
should not be turned into a URL button, but that is secondary.
-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.

Re: The <word>.<word>.<word> rule

[Per Abrahamsen]

Steinar Bang <sb@metis.no> writes:

> What I would like to do away with is all the "nice" colours and
> italicizing of the quoted text.  I've turned off all that I've found,
> but some stuff still insists on popping up.

If you have turned off all highligting it may explain why you cannot
see how annoying the <word>.<word>.<word> rule is in the default
setup.

Which also means that the <word>.<word>.<word> rule makes sense for
your setup, but not for the default setup.