469,271 Members | 1,466 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,271 developers. It's quick & easy.

Leo + Python: the ultimate scripting tool

I would like to say a few (actually more than a few) words here about some
recent discoveries I have made concerning the interaction of Leo and Python.
If you don't want to hear an inventor enthuse about his work, please feel
free not to read further :-)

There are at least three, no four, no five, no six, no seven reasons why Leo
and Python work so well together. Most are new (in my mind) with the 4.1
release of Leo. The first several reasons may not seem like much. As you
will see, this appearance is completely misleading: the combination of
features is incredibly powerful.

To keep the individual posts shorter I shall list these 7 reasons and a
conclusion in "replies" to this posting.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #1
50 5099
Reasons why Leo and Python work so well together:

1. You can execute Python scripts directly from anywhere in a Leo outline.

The body text of any node in Leo outline may contain any Python script. The
Execute Script commands executes this script in a pristine environment.
However, it is trivial to get access, _from within any script_, to all the
data in the present outline. For example: the following script prints all
the headlines in the outline in which the script is embedded.

from leoGlobals import c # Get access to all data in the present outline.
c = top() # Get the "commander" associated with the topmost outline.
v = c.rootVnode() # Get the root node of the outline.
while v:
...print v.headString()
...v.threadNext() # Move to the next node in "threading" order.

For that matter, scripts can access any data anywhere on your hard drive, or
all the data available on the web, for that matter. You knew that, of
course, but this "innocent" fact will be important later.

As a result, it becomes very easy to experiment with new scripts from within
Leo.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #2
Reasons why Leo and Python work so well together:

2. Leo's outlines are the perfect tool for organizing scripts.

This is an immediate result of the organizational power of Leo's outline.
However, it continues to surprise me how powerful this really is. For
example, at present, Leo has a "Scripts" menu that also organizes scripts.
It may well be that Leo's outlines alone, combined with features that I
shall shortly discuss, will make the scripts menu redundant.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #3
Reasons why Leo and Python work so well together:

3. Scripts may use the structure of Leo's outlines.

This is a first "big" reason why the combination of Python & Leo is
spectacular. As shown in the example above, scripts may get access to the
headline or body text of any node in a Leo outline. Therefore, scripts may
use the _structure_ of the outline to gain access to a) other scripts, b)
fragments of code for exec or eval or c) other data.

It gets better...

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #4
Reasons why Leo and Python work so well together:

4. Leo's nodes naturally separate data from meta-data.

The body text of a node is the perfect place data itself (including other
scripts). The headline of the node is the perfect place to _describe_ the
data. That is, headlines are a natural place for meta-data. Scripts can
use this meta-data in many creative ways.

I first saw the power of points 2, 3 and 4 when devising regression tests
for Leo. This leads us to...

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #5
Reasons why Leo and Python work so well together:

5. Leo is the ultimate platform on which to run regression tests.

The body text of a node is the perfect place for putting regression test
data. Headlines describe the data, which is exactly what is needed for
organizing tests. Indeed, I use a script to create regression tests based
on the structure of the outline of the children of the node containing the
script (!)

For example, I run the following script to create and run unit tests of
Leo's colorizer.

import unittest,leoTest
suite = leoTest.makeColorSuite("colorizerTests","tempNode" )
runner = unittest.TextTestRunner()
runner.run(suite)

This works as follows: the arguments to makeColorSuite tell it to look up
the tree for of an ancestor of the present node (the node containing this
script) for a node whose headline is "colorizerTests". makeColorSuite then
looks for children of _that_ node for nodes containing test data. The node
whose headline is "tempNode" is used by the colorizer during the tests.
Here is the actual code of makeColorSuite:

def makeColorSuite(testParentHeadline,tempHeadline):
..."""Create a colorizer test for every descendant of testParentHeadline.."""
...u = testUtils() ; c = top() ; v = c.currentVnode()
...root = u.findRootNode(v)
...temp_v = u.findNodeInTree(root,tempHeadline)
...vList = u.findSubnodesOf(testParentHeadline)
...# Create the suite and add all test cases.
...suite = unittest.makeSuite(unittest.TestCase)
...for v in vList:
.....test = colorTestCase(c,v,temp_v)
.....suite.addTest(test)
...return suite

The power and simplicity of this code is breathtaking. All that is required
are two utility routines, findNodeInTree and findSubnodesOf that find
various nodes in an outline based on the outline structure and the headlines
of the nodes:

- findNodeInTree(root,tempHeadline) returns the node in the entire tree
contain the current node whose headline is tempHeadline.

- u.findSubnodesOf(testParentHeadline) returns a list of all children of the
node whose name is testParentHeadline.

In short, it is absolutely trivial for a script embedded in a Leo outline to
generate unit tests based on the data in the outline in which the script is
embedded!!

Notice, please, what does _not_ have to be done:

A. No unit tests are created statically: everything is driven by data (the
outline itself)
B. No Python test data is created _at all_. Before I saw this approach, I
was putting text for the syntax-coloring text in Python strings and passing
those strings to the regression tests. Now, the _unchanged_ data in the
body text of nodes becomes the regression test data.
C. There is no need to mark meta-data as separate from test data: headlines
are naturally distinct from body text.

We see now that Reasons 2, 3 and 4 are a lot more potent than they might
appear at first. Indeed, Leo plus Python is the ultimate merging of code,
structure and data. Scripts can use data organized in outlines. Outlines
organize scripts. Outlines (particularly their structure) are _data_ for
scripts. Outlines contains metadata for scripts. Outlines naturally keep
data and meta-data separate.

Please notice, this discussion merely hints at all the games that scripts
could play with outline structure. Just for example, scripts can easily
insert, delete and reorganize nodes. And the uses to which outline
structure may be put are practically unlimited, as we shall see later...

Let's turn now to a completely separate topic...

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #6
Reasons why Leo and Python work so well together:

6. Leo is the ultimate platform for finding and changing text.

A few days ago I have added a script-based option to Leo's Find/Change
panel. For more than 30 years I have been disgusted with tools like regular
expressions. Calling re powerful is an utter joke; it's way too complex and
way too wimpy. Script-based find-change is infinitely more powerful.
Instead of containing find text or change _text_, Leo's Find/Change panel
may contains find or change _scripts. This becomes possible because scripts
have complete access to both the structure of the outline and all of Leo's
code.

It all works so smoothly: The find script is responsible for traversing
the tree and for highlighting the found text or otherwise indicating to the
change script what the found text was. Leo dedicates a Python dict called
app.searchDict for communication between the search script and the change
script. The change script is responsible for:

- changing the text, typically by using v.setBodyStringOrPane(newText), and

- implementing undo, typically by calling
c.frame.onBodyChanged(v,"Change",oldText=oldText).

Some details:

- When executing the search and change scripts when the user selects the
Find All or Change All commands, Leo executes the find or change scripts
repeatedly only if app.searchDict.get("continue") evaluates to True.
Otherwise these scripts are only executed once. Otherwise, scripts can use
app.searchDict as they please.

- For simplicity, most find and change scripts will ignore settings in the
Find Panel like "whole word", "pattern match", and "reverse": the scripts
know what to do! However, these settings are available to the scripts via
ivars such as c.whole_word_flag, etc. if desired.

- Either the find and change scripts may use Python's re module. For
example, the find script could set app.searchDict["m"] to the match object
returned by re's match method. The change script would then compute the
result, change the text and set the undo info as usual.

In effect, Leo's Find/Change panel becomes a new platform for running
scripts interactively. Leo now has all the find/change capability of
pattern matching languages like Snobol and Icon, using the capabilities of
the plain Python language. Moreover, Leo can deliver these capabilities
interactively or not depending which buttons you push in Leo's Find/Change
panel.

One last point. As I mentioned much earlier, there is no reason to confine
the find and change scripts to operate on data only within a Leo outline.
These scripts could as easily traverse your file system as the Leo outline.
But notice: scripts could pull data from the file system into the outline so
that you can see the effects of changes as the scripts operate. Again, this
can all happen interactively if you like.

No, one more last point. It's convenient to defined an initScriptFind
utility very similar to the makeColorSuite utility, used like this:

# Initialize Leo's find panel using the named children of this node.
from leoGlobals import *
initScriptFind("Find script","Change script")
# Start searching at the top.
top().selectVnode(c.rootVnode())

Put the search script in a child node called "Find script" (no quotes), put
the change script in a child node called "Change script", execute this
script and the following happens:

- The body text of "Find script" node gets put in the find text of Leo's
Find/Change dialog.

- The body text of "Change script" node gets put in the find text of Leo's
Find/Change dialog.

- The Script Find radio buttons gets selected, as does the Script Change
checkbox.

- The root of the outline becomes the selected node.

Presto! Leo is ready for a script search.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #7
Reasons why Leo and Python work so well together:

7. Leo outlines are the ultimate filing cabinet.

One more feature new in Leo 4.0 greatly expands the generality and power of
Leo's outlines combined with Python. Plugins may now attach arbitrary data
to any node of a Leo outline. This is done merely by "injecting" an ivar
called unknownAttributes ivar into Leo's fundamental vnode or tnode objects
(or adding items to the unknownAttributes dict if it already exists). The
unknownAttributes ivar should be a Python dictionary whose keys are xml
attribute names and whose values are the values of those attributes.

When writing a file, Leo will write "foreign" attributes in the <v> or <t>
xml elements of Leo's .leo file if the corresponding vnode or tnode contains
this unknownAttributes ivar. Similarly, Leo will create an
unknownAttributes ivar for a vnode or tnode if the corresponding <v> or <t>
element contains an attribute not normally used by Leo. Leo performs the
standard xml escapes when writing unknown attributes, so plugins can put
_anything_ in the unknownAttributes dictionary. In particular, plugins may
put xml in v.unknownAttributes or t.unknownAttributes.

This means, for example, that plugins may add anything that can be
represented by xml (and that is _everything_) in any node of a Leo outline.
In effect, Leo's file format is now completely extensible. BTW, plugins can
override any aspect of Leo's behavior, so not only can Leo passively accept
the data in "extended" .leo files, but plugins can extend Leo to _use_ this
data!

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #8
Conclusion

All the power of Leo derives directly from the power, flexibility and
dynamism of Python. But making structure explicit as Leo outlines do adds
an important new dimension, literally and figuratively, to Python.
Moreover, Leo's Find/Change dialog creates a new environment from which to
run Python scripts. At long last the full power of the unification of code
and data is becoming apparent.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #9
In article <vq************@corp.supernews.com>,
Edward K. Ream <ed*******@charter.net> wrote:

All the power of Leo derives directly from the power, flexibility and
dynamism of Python. But making structure explicit as Leo outlines do
adds an important new dimension, literally and figuratively, to Python.
Moreover, Leo's Find/Change dialog creates a new environment from which
to run Python scripts. At long last the full power of the unification
of code and data is becoming apparent.


Sounds good. However, I won't try it until there's a shell-based mode;
I do too much of my work remotely.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
Jul 18 '05 #10
> Sounds good. However, I won't try it until there's a shell-based mode;
I do too much of my work remotely.


Could you be more-specific about what you mean by "shell-based" mode? What
would have to be different in Leo?

Are you talking about a version of Leo that doesn't put up a gui? If so, a
null-gui plugin might suffice. If Leo can't do what you want already, I
suspect that adding this feature would be easy.

Edward

BTW, a null-gui plugin might only have to override the oops() method in
various gui base classes.

EKR
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #11
aa**@pythoncraft.com (Aahz) writes:
Sounds good. However, I won't try it until there's a shell-based mode;
I do too much of my work remotely.


That's what TightVNC is for.

|>oug
Jul 18 '05 #12
In article <lc************@gaffa.mit.edu>,
Douglas Alan <ne****@mit.edu> wrote:
aa**@pythoncraft.com (Aahz) writes:

Sounds good. However, I won't try it until there's a shell-based mode;
I do too much of my work remotely.


That's what TightVNC is for.


Ugh. While I love what my new DSL can do, I don't think that running GUI
applications remotely is one of the things it *should* do, especially not
when text works so much better.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
Jul 18 '05 #13
val
Ed,
Thanx so much for your thought-provoking,
stimulating and clarifying ideas/comments. It certainly
takes time to digest all you said. But the very first
comment is about significance of putting a *programming
activity* in the *structured* context. Until now,
a command line/shell and a self-centric (or process-centric)
program model was all your assets when you need to interact
and flexibly control the highly structured, multi-tier
(exploration) activities.
Say, in a model building environment, first you dream about
some fuzzy things, then begin chaotic actions and hopefully build
or generate a *trial* model (doc, design, etc); you then need
to run the model and evaluate its results against a certain reference
data/criteria, and based on that to modify the model (or switch
to a new one), and keep this cycle on and on in your multi-tier
automated, partially interactive exploration. It is like
a unit-testing activity (plus optional automatic mismatch-driven
debugging) with all necessary automation support at all tiers/domains.
For that one needs a sort of *structured* and flexible Explorer
with building, running, evaluating (including pattern recognition),
and powerful reconfiguration capabilities.
I guess you are moving in great direction offering
the unique tool/framework for exploration of complex systems.
Biology and bioinformatics (among many other domains) might gain
a lot using the Leo/Python great combo, a powerful expansion
of Python interpreting capabilities into exploration domain which
makes Python a dynamic exploration tool with structured and flexible
control/command capabilities.
explorative-ly y'rs,
val
"Edward K. Ream" <ed*******@charter.net> wrote in message
news:vq************@corp.supernews.com...
Conclusion

All the power of Leo derives directly from the power, flexibility and
dynamism of Python. But making structure explicit as Leo outlines do adds
an important new dimension, literally and figuratively, to Python.
Moreover, Leo's Find/Change dialog creates a new environment from which to
run Python scripts. At long last the full power of the unification of code
and data is becoming apparent.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

Jul 18 '05 #14
I mistakenly first replied to Aahz privately, so some of our conversation
has been off-line. I'd like to repeat it here publicly.

EKR> Could you be more-specific about what you mean by "shell-based" mode?
What would have to be different in Leo?

Aahz> It'd have to support a curses interface or something like it.

EKR> Are you talking about a version of Leo that doesn't put up a gui? If
so, a null-gui plugin might suffice. If Leo can't do what you want already,
I suspect that adding this feature would be easy.

Aahz> Well, I do want it to be screen-oriented. I just want it to be
text/console-based and keyboard-driven. You might be able to use anygui
to do that; haven't played with it.

EKR> Leo is being reorganized to support more than one gui. The work is
well along. I don't believe anygui is ready for prime time, and anyway the
new organization will suffice.

EKR> BTW, a null-gui plugin might only have to override the oops() method in
various gui base classes.

Aahz> Could be, but I don't want it enough to muck around with it. ;-)

EKR> Oh, I wasn't suggesting that you do that. I was mostly thinking out
loud, and maybe bragging that something that might be difficult in other
contexts has already been handled mostly in Leo's code base.

EKR> Thanks for this request. It is something I've never considered, and in
the big picture it will probably be easy enough to do. I'll put it on the
list and keep it in the back of my mind.

EKR> P.S. It might be good also to have an option that fires up Leo in
"script mode", something like:
python leo.py -script script.py <options>


which would open Leo, execute script.py and exit. Should be easy to do.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #15

Edward K. Ream <ed*******@charter.net> wrote in message
news:vq************@corp.supernews.com...
Sounds good. However, I won't try it until there's a shell-based mode;
I do too much of my work remotely.
Could you be more-specific about what you mean by "shell-based" mode?

What would have to be different in Leo?

Are you talking about a version of Leo that doesn't put up a gui? If so, a null-gui plugin might suffice. If Leo can't do what you want already, I
suspect that adding this feature would be easy.

Edward


No, I think he means using Leo with a text terminal a la browsing the web
with lynx.
Btw, a web based interface would be absolutely cool.. Do you see chance to
integrate Leo with, say, Zope?

Miklós

--
PRISZNYÁK Miklós
---
Jegenye 2001 Bt. ( je*********@parkhosting.moc ... to send mail increment
the number and reverse the domainname.. )
Egyedi szoftverkészítés, tanácsadás
Custom software development, consulting
http://jegenye2001.parkhosting.com

Jul 18 '05 #16
> Thanx so much for your thought-provoking, stimulating and clarifying
ideas/comments.

You are welcome. This is an exciting time for me.
Say, in a model building environment, first you dream about some fuzzy things...

I'm glad you mentioned this. It's so important to be able to explore
_easily_ while still being confused about what it is one is trying to do.
On Leo's SF Forum I described how I ended up creating the script-find and
script-change commands. I'll repeat it here, because it illustrates
something crucial about executing Python scripts in Leo.

[quote]
As late as yesterday I wasn't sure how this would work, or if these new
options were even necessary. Here is a summary of what I did yesterday.

1. As usual, just being able to begin this project was very important. It
turned out that the ability to execute test scripts rapidly without leaving
Leo was crucial. I was able to run through many ideas quickly so that no
intellectual momentum got wasted.

2. I was quite confused about what was needed. After all, there are already
a lot of find/change scripts in scripts/leoFindScript.py. But these scripts
are not interactive. I wanted to see if I could write an interactive find
script without using Leo's Find panel. If I could, I might simplify the
entire process: no changes required to Leo's find/change code.

I soon discovered, however, exactly why Leo's Find panel is necessary. The
problem is that interactive scripts need a _nonmodal_ dialog always present
so that the user can choose "yes", "no" or "cancel". However, interacting
with that non-modal dialog would be quite a problem for the script. Rather
than reinventing the wheel, it is _so_ much easier just to use the Find
panel that already exists. And of course, it makes sense to do this.

3. So ok, we do, in fact, need Script Search and Script Change options in
Leo's Find panel. The next big big question was: how to do this? Always
present in my awareness was the fact the present find/change code is
complex. A few experiments with hacking into this code made me leery of
messing with this code. For one thing, the code is all Tk based.

4. I messed around with some more test scripts. Don't remember how it
happened, but finally a huge Aha happened: the Find/Change scripts in the
Find panel don't need any help at all from Leo! They can essentially do
everything on their own! Here is how I entered this Aha in my diary:

- Leo doesn't clear app.searchDict. However, a _script_ can a) init itself
and b) bring up the find window (Eureka!)

- The find script is responsible for traversing the tree.

- The find script is responsible for highlighting the found text or
otherwise indicating to the change script what the found text was. For
example, the re find script can set app.searchDict["m"] to the match object.

- The find script must communicate with the change script. Leo does
nothing.

- The change script must change the text, usually by using
v.setBodyStringOrPane.

BTW, the first Eureka seems almost irrelevant now, but somehow it was really
important at the time. Anyway, you can see that these notes clearly
indicate that Leo need not get intimately involved in "managing" the
search/change scripts. This basic principle is the real Aha, and it made
the rest of the work routine.

5. With this clear vision in mind, it became routine to add support for
find/change scripts. What I did:

a) Added support for new c.pattern_match_flag and c.pattern_search_flag
ivars. There was a digression until a fixed a config bug that was blocking
initing of these ivars.

b) Changed the top-level find/change code so that it simply calls code to
execute the scripts in the find/change text area if the corresponding ivars
were set.

That's all!!
[end quote]

The point is this: I did _not_ have a clear picture of how script-find and
script-change would work when I started, and moreover what picture I had was
confused and wrong. Yet somehow it was easy to noodle around until the
creative unconscious created an initial Aha. After that, it was smooth
sailing.
Biology and bioinformatics (among many other domains) might gain a lot

using the Leo/Python great combo.

I've thought so too. One thing I didn't mention in my "seven reasons" is
that Leo's outlines are isomorphic to dags (directed acyclic graphs). Dags
are much _more_ powerful than completely general graphs. Indeed, the
transitive closure of a general graph is just the entire graph again, so
Leo's clones would not be possible (would not be well-defined) in a general
graph.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #17
> No, I think he means using Leo with a text terminal a la browsing the web
with lynx.

Whatever Aahz means, this idea has merit.
Btw, a web based interface would be absolutely cool..
Do you see chance to integrate Leo with, say, Zope?


There is some great work being done on Leo. I've been very interested in a
Leo + Zope combination, though I still don't understand what it means. Leo
as a "web app" would indeed be cool. There have been discussion of using
Flash plugins to host Leo as well...

One thing I mustn't forget to mention: Rodrigo B. is working on "Leo on the
Net" (LeoN for short). This will allow collaborative editing over the net
of a single .leo file. This is based on recent computer science research
and is leading-edge stuff. This is real. See the screen shots at:
http://ryalias.freezope.org/souvenirs/leon/et2003 I would like Rodrigo to
present his work at PyCon 2004. We shall see :-) For more details search on
LeoN on Leo's SourceForge forums.

Much of the reason for the 4.x code base is to support such things.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #18
aa**@pythoncraft.com (Aahz) writes:
Sounds good. However, I won't try it until there's a shell-based mode;
I do too much of my work remotely.
That's what TightVNC is for.
Ugh. While I love what my new DSL can do, I don't think that running GUI
applications remotely is one of the things it *should* do, especially not
when text works so much better.


I do so for hours every day with no problem.

That's not to say that an ascii-only version of Leo might not be a
good thing, but rather that in this day and age, not having one should
hardly be a show-stopper.

|>oug
Jul 18 '05 #19
This may be a really off-the-wall question, but how different would Leo be
if the outline were just directories and text files? Would it be a set of
file utilities and a kind of super-editor?

It seems to me that a lot of Leo features can be found in standard
directories and files.

"Edward K. Ream" <ed*******@charter.net> wrote in message
news:vq************@corp.supernews.com...
Conclusion

All the power of Leo derives directly from the power, flexibility and
dynamism of Python. But making structure explicit as Leo outlines do adds
an important new dimension, literally and figuratively, to Python.
Moreover, Leo's Find/Change dialog creates a new environment from which to
run Python scripts. At long last the full power of the unification of code
and data is becoming apparent.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

Jul 18 '05 #20
> how different would Leo be if the outline were just directories and text
files? Would it be a set of file utilities and a kind of super-editor?

I'm glad you asked this question. There are several kinds of replies. I
suspect point 3 answers your question most directly, but points 1 and 2 seem
like necessary background:

1. Yes, you could simulate the effects I talk about in various ways.
Because directories are hierarchical, one can no doubt simulate almost any
kind of hierarchical operation using files and directories. Whether that
simulation is easy, safe, powerful and natural is another matter. It is
vastly easier (and safer) to create, delete and reorganize nodes in Leo
outlines than it would be to do the corresponding operations on files and
directories.

The main topic of my postings has been the happy interaction between Leo
outlines and scripts. These interactions would not be nearly so strong if
all hierarchies had to simulated via the file system. I used the term
"momentum" in one of the postings. Intellectual momentum is really
important, and we don't want to slow that momentum by simulating things
indirectly that can much more easily be done directly.

For example, I presume unit test would typically be organized in folders to
make it possible to create unit tests dynamically. And yes, you could use
something like grep to organize search and replace operations. However,
grep is just another wimpy re tool, so the simulation is weak.

2. Leo itself has many file-oriented features. In particular, Leo provides
a way of associating parts of outlines with so-called "derived files". Leo
can change derived files based on changes to Leo outlines. Very
importantly, Leo can do the reverse: Leo can change outlines based on
changes to derived files.

3. I have devoted a _huge_ amount of wondering, over a period of at least 10
years, about whether one could eliminate .leo files entirely, somehow
replacing .leo files with the union of all derived files. It turns out that
the answer must be "no". Without going into details, trying to organize
derived files without a .leo file would be like trying to work in an IDE
without a project file. The analogy isn't exact, but the conclusion is
inescapable: Leo needs .leo files. Moreover, Leo needs information _not_
contained in derived files in order to make derived files friendly to cvs.
In the 4.0 code base this extra information is the tnodeList attribute of
<v> elements of .leo files. Finally, it is just plain more convenient to
squirrel away information in an outline than it would be to create separate
files. In other words, we wouldn't want to give up .leo files even if it
were possible.

In short, there are extremely strong reasons why Leo works the way it does.
If you want more details, look at the detailed design discussions that have
appeared on Leo's SF forums over the past year or so. I'm always glad to
talk about Leo, so feel free to ask more questions if you like.

Edward

P.S. You question got me thinking along a new and amusing line: .leo files
simulate (in quite a few ways) a file system, with clones, for example,
acting much like shortcuts or links. Actually, implementing Leo's outline
operations is quite a bit more complex than implementing the core of a
unix-like file system. I can say this because I've done both.

EKR
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #21
In article <lc************@gaffa.mit.edu>,
Douglas Alan <ne****@mit.edu> wrote:
aa**@pythoncraft.com (Aahz) writes:
Douglas Alan removed one attribution:
Douglas Alan removed Aahz's attribution:

Sounds good. However, I won't try it until there's a shell-based mode;
I do too much of my work remotely.

That's what TightVNC is for.
Ugh. While I love what my new DSL can do, I don't think that running GUI
applications remotely is one of the things it *should* do, especially not
when text works so much better.


I do so for hours every day with no problem.


That's not what I said.
That's not to say that an ascii-only version of Leo might not be a
good thing, but rather that in this day and age, not having one should
hardly be a show-stopper.


That's your opinion. I disagree, at least to the extent that I won't
use any editing environment that doesn't have a text-only version.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
Jul 18 '05 #22
> I won't use any editing environment that doesn't have a text-only version.

Your call, of course.

I just found the following at:

http://www.amk.ca/python/howto/curses/

[quote]
In a world of X displays, one might ask ``why bother''? It's true that
character-cell display terminals are an obsolete technology, but there are
niches in which being able to do fancy things with them are still valuable.
One is on small-footprint or embedded Unixes that don't carry an X server.
Another is for tools like OS installers and kernel configurators that may
have to run before X is available.
[end quote]

It seems to me that simulating Leo on a character-cell display is going to
be all work and no gain. I have no interest in designing a dumbed-down
model for Leo that would work in paleolithic environments. Besides, Emacs
probably has a curses mode. Why would I want to compete with that?

So I am not going to do a text-only mode for Leo unless somebody comes up
with a pretty good reason why Leo would be an appropriate tool in
non-windowing environments. Starting up Leo in script mode is still on the
to-do list.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #23
In article <vq************@corp.supernews.com>,
Edward K. Ream <ed*******@charter.net> wrote:

It seems to me that simulating Leo on a character-cell display is
going to be all work and no gain. I have no interest in designing a
dumbed-down model for Leo that would work in paleolithic environments.
Besides, Emacs probably has a curses mode. Why would I want to compete
with that?


That's fine, although for me you're competing with vi[m]. There are two
reasons why I stick with my requirement for text-only systems:

* As I said earlier, I do much of my work from text consoles, and much of
that is also remote. I think trying to run GUIs over Net connections is
poor use of bandwidth. Not to mention the fact that until a month ago,
my only Net access was still direct-dial shell (yes, vt100 emulator, no
PPP). Even now that I do have DSL, I still do much of my GUI browsing
(when forced to use JavaScript) with images turned off.

* Requiring a text-only system is a reasonable proxy for requiring a
keyboard-centric system, because text-only systems by definition have to
work with a keyboard. Too many GUI-based systems have at least one
oddball corner that just doesn't work well with the keyboard, and it's
invariably one of those corners that I need to be productive.

This is an old argument, of course. I've been using the .sig I'm
including below for more than five years.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

I surf faster than you do, monkey boy. (My take on Netscape vs. Lynx)
Jul 18 '05 #24

Edward K. Ream <ed*******@charter.net> wrote in message
news:vq************@corp.supernews.com...
One thing I mustn't forget to mention: Rodrigo B. is working on "Leo on the Net" (LeoN for short). This will allow collaborative editing over the net
of a single .leo file. This is based on recent computer science research
and is leading-edge stuff. This is real. See the screen shots at:
http://ryalias.freezope.org/souvenirs/leon/et2003 I would like Rodrigo to
present his work at PyCon 2004. We shall see :-) For more details search on LeoN on Leo's SourceForge forums.

Much of the reason for the 4.x code base is to support such things.

Edward


Thanks, Edward, I'll check out this. But before that a little ranting..
Speaking of a multi-user version, security comes to mind.
Like you described, the scripts are omnipotent within the .leo files and
itself Leo.. and this is no problem if I use my own outlines.
However when it comes to collaborating and sharing outlines... well, you
know. (You just cannot check each and every line in that way cool outline
someone wrote.)
Then we have the Microsoft (macro virus) symptom.
So I wonder how this is going to be addressed with LeoN... This is not
easy, say, the Bastion/rexec thing was removed from Python...
Zope has its own access right management and that could be perhaps used
somehow and most importantly in a transparent way..

Best,
Miklós
Jul 18 '05 #25
> Speaking of a multi-user version, security comes to mind.

Thanks for mentioning this. Security has been discussed at length on Leo's
SF forums. It is a _really_ serious problem for an environment as powerful
as Leo and Python. The general principle is: you (or your scripts) must
NEVER execute a script blindly. As you say, that is not so easy to do.
Certainly rexec would not help at all: a Leo script could create a time-bomb
and still be legal as far as rexec is concerned. The only solution is a)
know what scripts you are executing and b) know who you are working with.
Using Leo + Python is like using a chain saw: you had best keep it under
control, and you had best know what you are doing.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #26
> Such a request is *NOT* a legitimate 'anti-junk-mail' measure.

Yes, it is. If you aren't willing to take 20 sec. to talk to me, then I'm
not willing to talk to you. Bye.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #27
Several responses mentioned gui issues, which have little to do with
scripting. However, gui issues are near and dear to my heart, so I thought
I would summarize how things stand with Leo and guis:

1. Leo is in the midst of a global reorg that will separate gui-dependent
code from a gui-independent "core". This is going well, and will be
completed in about a week. This reorg is the basis for the 4.1 code base.
4.1 final is due out in December; there will be a lengthy period of testing
(including many new unit tests) while the code settles down.

A prototype plugin for Leo already exists that replaces Leo's default
Tk/tkinter gui with a wxPython gui. The original version of the prototype
had to duplicate a large amount of Leo's core to be even partly functional.
With the new code base the wxPython gui only needs to know how to do generic
wxPython kinds of stuff. All knowledge of Leo's core is handled by base
classes that are in Leo's core.

In another reply I misspoke: I said that anygui probably wasn't up to the
job. In fact, with the new organization it would be dead easy to create a
plugin to support anygui instead of, say, wxPython. Experimenting with
anygui would be virtually risk free: it would take an hour or so of time.
N.B. Gui plugins are _completely_ responsible for handling all gui-related
events. In particular, the interface between Leo's core and gui plugins
ignores event handling completely. This greatly simplifies the interface
and ensures that no assumptions at all about event handling "infect" Leo's
core. I was originally dubious about matching anygui's model of events.
Now I see the fear was unfounded.

2. One of my hopes in writing the original series of postings was that
there would be some discussion of integrating Leo with Emacs using pymacs.
This may have started to happen. I would really like help with this
project, and I'll support anyone working on such a project in any way I can.
I think running some kind of Leo window on Emacs would be totally cool.

3. Several people have mentioned that it would be good to start up Leo in
scripting mode. There are several easy ways to do this. It will happen
eventually: don't know when. Right now it seems more like a cute feature
than something vital...In any event, there will eventually be a way of
running Leo without any gui at all: a null-gui plugin probably could do this
with about 10 lines of code.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #28
I forgot to mention that Leo already has plugins that allow fairly easy
integration with vim, xemacs and word. Another plugin allows full
customization of Leo's Open With menu. These plugins aren't perfect, and
they are a real good start.

These plugins were easy to write. For example, the guts of the xemacs
plugin is:

def open_in_emacs (tag,keywords):
if top():
top().frame.OnOpenWith(("os.spawnl",path,None),)

Tighter integration with emacs/xemacs would take more work, and it would be
well worth it. I hope that it will happen soon. The Aha for me came when I
saw tetris in an xemacs window. xemacs probably can host Leo and make Leo
look good. I see hints about "foreign" windows in the emacs docs, and I
haven't followed up on that yet...

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Jul 18 '05 #29
"Edward K. Ream" <ed*******@charter.net> schreef:
Such a request is *NOT* a legitimate 'anti-junk-mail' measure.


Yes, it is. If you aren't willing to take 20 sec. to talk to me, then
I'm not willing to talk to you. Bye.


One question: why not let people do this "confirmation" through email
instead of requiring them to start a separate program? Something like a
mailing list confirmation mail?

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Jul 18 '05 #30

"JanC" <us*********@janc.invalid> wrote in message
news:Xn******************@213.118.46.22...
"Edward K. Ream" <ed*******@charter.net> schreef:
Such a request is *NOT* a legitimate 'anti-junk-mail' measure.
Yes, it is. If you aren't willing to take 20 sec. to talk to me, then I'm not willing to talk to you. Bye.


One question: why not let people do this "confirmation" through

email instead of requiring them to start a separate program? Something like a mailing list confirmation mail?


That is exactly what legitimate whitelist programs do. Click reply
and send. I have gotten such and answered such.

Terry J. Reedy
Jul 18 '05 #31

"Edward K. Ream" <ed*******@charter.net> wrote in message
news:vq************@corp.supernews.com...
Such a request is *NOT* a legitimate 'anti-junk-mail' measure.
Yes, it is.


Your request is unnecessary to the purported purpose and, to at least
three people, obnoxious. Furthermore, I believe universal
implementation of that system would be terrible, both socially and
technically.
If you aren't willing to take 20 sec. to talk to me,
I spent much more than 20 seconds writing you a polite note for your
benefit. You are the one refusing to take even 5 seconds to look it.
Or to use a decent, unobstrusive or miminal imposition filtering
system.
then I'm not willing to talk to you. Bye.
That is your right, and mine, and probably our mutual loss is some
respects.
.... Edward K. Ream email: ed*******@charter.net


By posting your email address over and over, you are still inviting
responses that you will not read. Not nice. At least warn people
that they will have to fire up a browser a few days later and beg you
to read their original message. Or simply give the URL of your
'correspondant registration' service and suggest that people register
(or not) *before* writing.

Terry J. Reedy
Jul 18 '05 #32
"Terry Reedy" <tj*****@udel.edu> writes:
"Edward K. Ream" <ed*******@charter.net> wrote in message
> Such a request is *NOT* a legitimate 'anti-junk-mail' measure.
Yes, it is.

Your request is unnecessary to the purported purpose and, to at least
three people, obnoxious. Furthermore, I believe universal
implementation of that system would be terrible, both socially and
technically.


Although I agree with you that requiring people to fire up a browser
to get yourself on their whitelist is a bit annoying, I also think you
make much ado about nothing. Even if you had to spend 30 seconds
authorizing yourself to everyone you ever needed to contact, it could
hardly take all that much time.

For now, the technique of just asking people to reply to a message is
sufficient as an anti-spam filter, but you have to realize that such a
convenience won't last forever. The spammers will eventually get
smart enough to auto-reply to such messages.

In the long run, the sorts of techniques that Yahoo, and other web
sites, where you have to look at a distorted image and identify it (a
task that cannot easily be automated), in order to put yourself on the
list, will be required, so you should probably get used to it now.

|>oug
Jul 18 '05 #33
"Terry Reedy" <tj*****@udel.edu> writes:
Your request is unnecessary to the purported purpose and, to at least
three people, obnoxious.
At least four people.
Furthermore, I believe universal implementation of that system would
be terrible, both socially and technically.


Exactly, this is the root of why this spam-prevention tactic is
awful. It turns people who want to communicate with each other into
supplicants for for the other's time.

There are several ways to communicate as the leader of an open-source
project. One is of condescending arrogance, to wit, "My time is so
important that you must jump through hoops to speak to me." The other
is one of helpful cooperation. "Thanks, I'm really busy right now,
I'll address the issue you raised as soon as I can."

It's left as an excercise to the reader which category I see Edward's
tactic falling into. :^)

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Jul 18 '05 #34
"Edward K. Ream" <ed*******@charter.net> writes:
2. One of my hopes in writing the original series of postings was that
there would be some discussion of integrating Leo with Emacs using pymacs.
This may have started to happen. I would really like help with this project,
and I'll support anyone working on such a project in any way I can. I think
running some kind of Leo window on Emacs would be totally cool.


Have you come across allout.el and speedbar.el (a seperate tree browser
window)? Emacs has several outlining facilities amongst which allout is the
best IMO (I already use it for some of my python code) -- integrated with
speedbar this would supply quite a bit of the core functionality that leo
offers (plus, of course plenty additional functionality, most importantly good
editing and search facilities).

'as
Jul 18 '05 #35
_
"Nick Vargish" <na*******@bandersnatch.org> wrote in message
news:m3************@tanelorn.bandersnatch.org...
"Terry Reedy" <tj*****@udel.edu> writes: There are several ways to communicate as the leader of an open-source
project.
Including posting in the source forge forum that was setup for that purpose,
rather than emailing the author directly, or posting in c.l.p
One is of condescending arrogance, to wit, "My time is so
important that you must jump through hoops to speak to me." The other
is one of helpful cooperation. "Thanks, I'm really busy right now,
I'll address the issue you raised as soon as I can."
Nick,

While I don't know you, I've read your posts in this forum and found them
all to be reasonable. I'm surprised that you expressed your opinion in such
harsh terms this time.
It's left as an excercise to the reader which category I see Edward's
tactic falling into. :^)


Some time ago I sent email to Edward and I received the "you must confirm
you're a human" thing. True, I thought it was annoying and in fact did not
immediately do anything about it. However we all have Spam issues and while
I wouldn't have taken Edwards approach to solving my spam problems, I
eventually expended 30 seconds to "suplicate myself to his spam software"
and get my message through.

I don't think it's supplication to the author, just his anti-spam guard dog.
I don't see Edwards statement (paraphrased) "if you want me to take time to
solve your problem, take a moment to confirm your a human" as arrogance,
just a fact of life.

Rather than writing to the author, you could just post in the Leo specific
forum, where your post could be answered by Edward or other users, and the
ensuing thread would be archived for other folks to later benefit from.

Jul 18 '05 #36
I see that allout.el is supplied with xemacs for windows. How does it
get activated?

Stephen

Alexander Schmolck wrote:
Have you come across allout.el and speedbar.el (a seperate tree browser
window)? Emacs has several outlining facilities amongst which allout is the
best IMO (I already use it for some of my python code) -- integrated with
speedbar this would supply quite a bit of the core functionality that leo
offers (plus, of course plenty additional functionality, most importantly good
editing and search facilities).

'as


Jul 18 '05 #37
"Brad Clements" <bk*@Murkworks.com> writes:
While I don't know you, I've read your posts in this forum and found them
all to be reasonable.
I'm pretty sure that's the nicest thing anyone's said to me all day. :^)
I'm surprised that you expressed your opinion in such harsh terms
this time.
Me too, actually. I should have just typed my message and then
killed the buffer without sending it, which is how I usually handle
irritations like this.
Rather than writing to the author, you could just post in the Leo specific
forum, where your post could be answered by Edward or other users, and the
ensuing thread would be archived for other folks to later benefit from.


I completely agree. It's too bad that Edward's automated reply did not
refer the supplicant to the appropriate sourceforge forum, which would
have been both non-arrogant, and of benefit to the community at large.

Only rarely have I been in situations where the appropriate face-to-
face response to a question was, "Talk to the hand until you've proved
your question is worth my time."

Anyway, I'm sorry I chimed in on this thread. It's diverged pretty far
from the topic I really care about, which is becoming a better Python
programmer (with a little advocacy thrown in for spice).

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Jul 18 '05 #38
I would also like to see people that use confirmation-request software
qualify their addresses in a similar way to the qualification done for
registration-required web sites: us**@python.org (confirmation required).
This allows potential respondents to make an informed decision on whether to
respond.

Worse than using confirmation-request for individuals is using it on an
account subscribed to a mailing list such that every poster is asked to
confirm for every confirmation-request subscriber. This recently occurred on
a list I manage so I unsubscribed the confirmation-request account. The
subscriber has since promised not to use confirmation-request for that
account.

Neil
Jul 18 '05 #39
In article <lc************@gaffa.mit.edu>,
Douglas Alan <ne****@mit.edu> wrote:

In the long run, the sorts of techniques that Yahoo, and other web
sites, where you have to look at a distorted image and identify it (a
task that cannot easily be automated), in order to put yourself on the
list, will be required, so you should probably get used to it now.


No, they won't. They'll be challenged under the ADA (Americans with
Disabilities Act) and judged illegal.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
Jul 18 '05 #40
aa**@pythoncraft.com (Aahz) writes:
No, they won't. They'll be challenged under the ADA (Americans with
Disabilities Act) and judged illegal.


I'm amazed it hasn't been challenged yet. I can't see how the tactic
doesn't violate Section 508, which means the US goverment can't employ
it on any of their sites.

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Jul 18 '05 #41
aa**@pythoncraft.com (Aahz) writes:
In the long run, the sorts of techniques that Yahoo, and other web
sites, where you have to look at a distorted image and identify it (a
task that cannot easily be automated), in order to put yourself on the
list, will be required, so you should probably get used to it now.
No, they won't. They'll be challenged under the ADA (Americans with
Disabilities Act) and judged illegal.


C'mon -- you're pulling my leg, right? That's just silly. The
alternative is to give up on email because 99% of it will eventually
be spam.

Besides, there could be alternate distorted "images" for the disabled:
A distorted braille image could be formed, or a sound could be played
and the person could be asked to identify it. Or a question could be
asked that an automated program wouldn't be able to easily answer.

|>oug
Jul 18 '05 #42
On Sun, 9 Nov 2003 21:29:35 -0500, "Terry Reedy" <tj*****@udel.edu>
wrote:
I will not beg you to read my bug report. Such a request is *NOT* a
legitimate 'anti-junk-mail' measure.


Is using that approval thing 'begging you to read...' to any greater
degree than sending the e-mail in the first place?

My impression is that the 'reason' thing could just be 'Leo support
request' or similar, for instance - enough to demonstrate that your
e-mail is legitimate but hardly a chore.

There would be a practical issue, of course, if you have access to
e-mail but not to the web. But that has nothing to do with whether you
are being asked to 'beg' or not.

Basically, I think you are overreacting to this. I don't use
ChoiceMail or anything similar, but with the huge volume of spam,
virus's and incorrect 'you sent us a virus' messages these days, I
certainly see the attraction and I can say that - while I don't use
Leo ATM - this authorisation thing certainly wouldn't worry me.

Actually, compare it with Web support request pages where you
carefully type in all the details of your problem, only to be told
"request failed - 'problem description' exceeded limit of 100
characters" or whatever.

Yes, I seriously wish one company used ChoiceMail instead of the
stupid system they are using, and ended up posting a support request
of 'please send me an e-mail address so I can describe the problem
properly'. Actually, the problem relates to interaction with another
product I'm trialing, and odds are they've already lost the sale to be
honest. The product seems very good and easily worth the money, but it
has enough fiddly aspects that I strongly suspect I'll need to fight
their support system again.

It would be nice if we could just fire-and-forget e-mails, but those
days seem to be coming to an end - the e-mail system is just too open
to abuse.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
Jul 18 '05 #43
On Mon, 10 Nov 2003 21:59:20 GMT, JanC <us*********@janc.invalid>
wrote:
"Edward K. Ream" <ed*******@charter.net> schreef:
Such a request is *NOT* a legitimate 'anti-junk-mail' measure.


Yes, it is. If you aren't willing to take 20 sec. to talk to me, then
I'm not willing to talk to you. Bye.


One question: why not let people do this "confirmation" through email
instead of requiring them to start a separate program? Something like a
mailing list confirmation mail?


If the approval is via e-mail then you have to accept e-mail from
unknown people in order to recieve the approval requests in the first
place. That means you still recieve the spam.

Of course you could make up some scheme with a standard subject line
that is recognised as an authorisation request.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
Jul 18 '05 #44

"Stephen Horne" <st***@ninereeds.fsnet.co.uk> wrote in message
news:q9********************************@4ax.com...
On Sun, 9 Nov 2003 21:29:35 -0500, "Terry Reedy" <tj*****@udel.edu>
wrote:
I will not beg you to read my bug report. Such a request is *NOT* alegitimate 'anti-junk-mail' measure.
Is using that approval thing 'begging you to read...' to any greater
degree than sending the e-mail in the first place?


To me, yes, most definitely, and especially for a short, two sentence
message.
My impression is that the 'reason' thing could just be 'Leo support
request' or similar, for instance - enough to demonstrate that your
e-mail is legitimate but hardly a chore.
But I do literally do not know what 'reason' thing any particular
person might want, or what an unknown person would even consider to be
a reason. Given my communication philosophy (choice, not reason) and
writing ability, I could find writing anything other that what I
originally wrote, already the best I could do, a paralyzing chore.
"What will Mr/Ms Recipient find acceptible? Will s/he even read what
I write or is this just a joke?" Etcetera.

I am somewhat flabbergasted that more people do not see the oddity of
"I will not read your first message (yet) but I will read a second
message from you in which you attempt to give me a reason that I find
'acceptible', according to my unknown-to-you whims, that I do read
your first message."

If someone is willing to read and evaluate message 2 to judge whether
the person is a suitable correspondant, then s/he could just as well
read (or just glance at) message 1 and make the same decision from the
better information of actual content.

In this case, the best 'reason' I could have given would have been to
repeat the self-justifying message itself. But that strikes me as
sort of somewhat dumb. Sort of like telling a secretary what I want
to say to his boss, except that the secretary is the boss. (Hmm.
Could be a funny sketch for a certain comedic troop.)

My objection is not just for email. I would find a
double-message-thru-a-third-party procedure just as odd for physical
letters or phone calls, even if under the guise of blocking junk mail
or junk phone calls, which I also get too many of.
There would be a practical issue, of course, if you have access to
e-mail but not to the web.
There are numerous people around the world with email-only accounts,
or email-only devices. There are also people who have web access but
pay by the byte. While not applicable to me personally, these
anti-universality practical issues *are* one of the reasons I will not
encourage such a system. Call it altruism if you will.
Basically, I think you are overreacting to this.
'Beg' may have been a little strong, but otherwise I still don't
agree. Given that I hope to use Leo, I did not lightly or
thoughtlessly decide to openly fuss. My reasons goes far beyound a
mere 30-second annoyance (and have nothing to do with Leo or ER per
se). Discuss or even disagree if you will, but I think this
particular 'solution' is both socially and technically flawed.

To continue: I do not want any company to compile a list of *my*
correspondants. The US Post Office needs a court order (or at least
used to) to do the same. I am not about to give same to an unknown
entity I do not trust for free, especially when the procedure is
unnecessary and even counter to the supposed purpose.

As to the last. Decent filtering or automated verification by email
response to the challenge email, as other programs do, does not
require the intended
recipient to read anything but the original message, after
verification, and does *not* involve a third party to collect data
about senders.

In another post, you wrote: If the approval is via e-mail then you have to accept e-mail from
unknown people in order to recieve the approval requests in the first place. That means you still recieve the spam.
No. As an alternative to rule/statistical filtering (which have
become quite effective), a whitelist program on your machine (or
corporate server) sets the message aside and sends a reply with a
coded subject line: "Hi new correspondant. Please confirm that you
are human and that you are the actual sender of the following". When,
and only when it gets the response, does it put it in your inbox.
Of course you could make up some scheme with a standard subject line
that is recognised as an authorisation request.
The program does this for you. All automated. Much easier, I think,
than reading 'please read me' requests.

A spam program could learn to respond to such challenge email, but
that would require an actual, persistent-for-a-few-hours and
potentially trackable mailbox rather than the fake or forged headers
now used. Such a program might just as well go to a site and enter a
reason like "I need your help', 'I have info for you', or even 'Viagra
at pharmo.tu'. In other words, any alternate message-to-human channel
could become an alternate spam channel!

In the reverse direction, if the verification site has ads on the
referred-to-page, then it would be a spam-to-original-sender channel
itself. Or the site could secretly sell the verified
active-and-correct addresses (market value, I've read, at least $20
each). Or a legitimate site could be hacked for its list. Or a site
could be set up by a spammer acting through a front. Run it
legitimately for a month, and then the deluge. Things like this are
easily predictable from past events. (For similar reasons, I would
also be wary of closed-source mail/spam software from unknowns.)

So I think any serious attack on junk email should aim at improving
local machine automated systems with minimal bother for human senders.
To foil better spam programs if/when deploed, something like the
following might work: "To verify sentience, click reply, enter on the
first line the number of legs that has a snake [or parrot, cat, ant,
or spider], and press send." in thousands of variations, and perhaps
misspellings, misspacings, and even anti-robot locutions like the
following:
steve at ninereeds dot fsnet dot co dot uk


Terry J. Reedy
Jul 18 '05 #45
Stephen Boulet <stephendotboulet@motorola_._com> writes:
I see that allout.el is supplied with xemacs for windows. How does it get
activated?


First try adding this to your .emacs :

(require 'allout)
(outline-init t)

Then try opening either a file with the ending .outl (for "traditional"
outlined text) or the allout.el file (for source code that contains outline
comments).

Once you opened allout.el, try typing this to get a quick feel:

C-cC-a C-cC-a
n n n n p s n h h h

Not so bad for navigating, is it?

'as
Jul 18 '05 #46
Stephen Horne <st***@ninereeds.fsnet.co.uk> schreef:
On Mon, 10 Nov 2003 21:59:20 GMT, JanC <us*********@janc.invalid>
wrote:
One question: why not let people do this "confirmation" through email
instead of requiring them to start a separate program? Something like a
mailing list confirmation mail?


If the approval is via e-mail then you have to accept e-mail from
unknown people in order to recieve the approval requests in the first
place. That means you still recieve the spam.

Of course you could make up some scheme with a standard subject line
that is recognised as an authorisation request.


You can use pseudo-random codes, just like mailing lists do...

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Jul 18 '05 #47
Terry Reedy wrote:

I am somewhat flabbergasted that more people do not see the oddity of
"I will not read your first message (yet) but I will read a second
message from you in which you attempt to give me a reason that I find
'acceptible', according to my unknown-to-you whims, that I do read
your first message."


I completely agree with you on this subject Terry. The whole approach
is extremely misguided and discourteous, especially in the light of this
being about information that should have been welcomed by Edward.

I'm using TMDA right now, which is remotely similar but doesn't
require the "reason", just a real mailbox and a living person or
an autoresponder... even so, this whole thing is starting to make
me rethink even that approach.

-Peter
Jul 18 '05 #48

"Peter Hansen" <pe***@engcorp.com> wrote in message
news:3F***************@engcorp.com...
Terry Reedy wrote:

I am somewhat flabbergasted that more people do not see the oddity of
"I will not read your first message (yet) but I will read a second
message from you in which you attempt to give me a reason that I find
'acceptible', according to my unknown-to-you whims, that I do read
your first message."

Where did his message say this? I went through the web confirmation thingy
and I don't recall the original response message saying what you quoted
above, or even anything remotely close to that at all.
I'm using TMDA right now, which is remotely similar but doesn't
require the "reason", just a real mailbox and a living person or
an autoresponder... even so, this whole thing is starting to make
me rethink even that approach.

-Peter


What's the difference between TMDA and what Edward is using? Email vs. a Web
confirmation. While I prefer simply replying to an email message, I don't
see *that* much difference between the two.

Jul 18 '05 #49
Brad Clements wrote:

"Peter Hansen" <pe***@engcorp.com> wrote:
I'm using TMDA right now, which is remotely similar but doesn't
require the "reason", just a real mailbox and a living person or
an autoresponder... even so, this whole thing is starting to make
me rethink even that approach.


What's the difference between TMDA and what Edward is using? Email vs. a Web
confirmation. While I prefer simply replying to an email message, I don't
see *that* much difference between the two.


TMDA does not ask for justification (as in a written explanation of why
I should read your mail). It is merely a means of verifying that you
sent me the email with a real reply address (i.e. one capable of getting
mail back to something which is capable of replying back again...) In
other words, there is a real email account associated with the email,
and if it's spam I can complain to your service provider and have your
account pulled.

The difference is at least one of degree of convenience: with TMDA you
just hit "Reply" to the confirmation request, *ONCE ONLY*, and after
that you are free to send as many emails as you like (until I get upset
and blacklist you, perhaps :-). You never have to justify why you
think I should spend my time reading your email. Sure, I might not
actually read it anyway, but at least it's a token amount of your
time, once ever, to confirm to my server that you really exist.

(Not sure about EK's web-based tool: does it require justification
for each message, or only once, the first time you send him one?)

And if you are about to make the point that yes, it's just a matter
of degree, but that I'm still imposing on those trying to communicate
with me: well, I did say I was starting to rethink even TMDA, didn't I?

My rethinking so far has been to check the stats: yesterday I received
182 messages for which confirmation requests were sent out. So far, none
have received replies. I have also received about 50 real emails, none of
which required confirmations because they were all long since added
to my "confirmed" list. Yesterday was a little exceptional, in that I
received only one spam. Normally about three or four slip through, but
I haven't been diligent about keeping my blacklist up to date so that
those spammers (who actually use real accounts) are blocked.

I think that might be as far as my rethinking gets me, for now. :-(

-Peter
Jul 18 '05 #50

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Martin Maney | last post: by
40 posts views Thread by Shufen | last post: by
63 posts views Thread by Davor | last post: by
68 posts views Thread by Lad | last post: by
20 posts views Thread by xeys_00 | last post: by
1 post views Thread by Josiah Carlson | last post: by
17 posts views Thread by chewie54 | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.