response 25 of 115:

Jan 26 15:23 UTC 2005

} Ok: jh
} I don't understand "jh" - type HELP for help
} 
} Ok: !grep jh .cfdir/.cfonce
} define  jh      1       "join helpers"
} 
} Ok: r 5 n
} No items found in range

I've already determined, by experimentation, that either sane or supersane,
and I don't remember which, disables my iseps and rseps.  Maybe file
permissions are the problem?  Right now, it's:

} -rw-------  1 gelinas  people  3224 Jan 10 08:09 .cfdir/.cfonce

response 27 of 115:

Jan 26 16:09 UTC 2005

Re #21: Thanks for the tip on "nor", Dave.

The semantics of the keyword "this" seems to be different in ft.  In pico,
one can use "this" as an argument to various commands, and it applies it to
the most recent item looked at - e.g. "read new this" or "forget this".
I tend to use this fairly often.  When I tried "read this" in ft after 
having just read this item, it showed me item 1.

response 29 of 115:

Jan 26 16:41 UTC 2005

Oops, the current item number was being set to 1 when you joined a conference,
and then never changed.  Fix will be in 0.3.8.

response 31 of 115:

Jan 26 18:22 UTC 2005

As noted, "jpu" hangs.  I wonder if it's a problem with the conference?

response 33 of 115:

Jan 26 20:15 UTC 2005

SAVESEEN is what Fronttalk *always* done.  NOSAVESEEN would be extremely hard
to do in Fronttalk.

Picospan's default behavior is NOSAVESEEN.  That means that it reads in your
participation file when you join the conference, and does not write anything
back out until you exit the conference.  The Fronttalk client can't do this
because it doesn't read your participation file.  It's the Backtalk server
that does that.  But the Backtalk server just displays one item, then exits.
Since it isn't persistant, it can't keep your participation file in memory
until you exit the conference.  So with Fronttalk we always update the
participation file after each item you read.

If I wanted to implement NOSAVESEEN in Fronttalk, I'd have to modify the
server not to update the participation files, and instead have the client
remember what you've seen since you joined and have the client make an
explicit call to the server when you exit the conference giving it the new
data to write out to the participation file.  I'd also no longer be able to
have the server do the job of finding the next new item, because it doesn't
have the current participation file data, so it can't.  Many other
complexities would be introduced, all to support a mode of operation that is
pretty much undesirable anyway.

So Fronttalk is going to keep ignoring SET SAVESEEN

response 35 of 115:

Jan 26 21:47 UTC 2005

The only slightly annoying thing I've noticed about fronttalk is that
when I do a `forget' at the `RFP' prompt, I get returned to the `RFP'
prompt, whereas with Picospan, I got bummed to the next item or to the
`Ok' prompt.  The picospan behavior made a little more sense to me,
but it's not a huge deal.

response 37 of 115:

Jan 26 22:13 UTC 2005

(Can we change the error message to "SET SAVESEEN is not needed in
Fronttalk"?)

response 39 of 115:

Jan 27 01:36 UTC 2005

Re #35: That behavior is a settable option in Picospan; "set stay" will
cause you to be returned to the RFP.  Since that behavior is what I
prefer, I hadn't noticed that ft's default is different from pico's.
I wouldn't mind if ft's default behavior was the same as pico's, as
long as I could do "set stay" to change it.

response 41 of 115:

Jan 27 02:36 UTC 2005

SET STAY is another place I deviated from Picospan.  Picospan had just the
STAY setting, Fronttalk has STAY and MODESTAY.  In Fronttalk, SET STAY and
SET NOSTAY control whether you move to the next item after a RESPOND command.
SET MODESTAY controls whether you move to the next item after all other
commands:  FORGET, REMEMBER, RETIRE, UNRETIRE, FREEZE, THAW, MARK SEEN, FAVOR,
DISFAVOR.

The default in Fronttalk is STAY off, MODESTAY on.

So what Dan wants is SET NOMODESTAY.  Except that if he sticks that in his
.cfonce, then Picospan will probably complain every time he runs Picospan.
I really ought to have some mechanism by which you can put commands in rc
files that will be seen by Fronttalk but no by Picospan.  The obvious option
would be a .fronttalkrc file.  I'm not to enthusiastic about that.  Fronttalk
already reads six RC files:

 - remote system rc
 - remote .cfonce
 - local .cfonce
 - remote conference rc file
 - remote .cfrc file
 - local .cfrc file

Do I want to add a local and remote .fronttalkrc file to that?  No, I do
not.  Maybe I could support a syntax where lines starting with '#ft#' are
not comments, like:

    #ft# set nomodestay

I dunno.

response 43 of 115:

Jan 27 03:32 UTC 2005

OK,  a few more clues on the problems with Joe's .cfonce file.

First, he does "set nosource" before "set supersane".  SUPERSANE is supposed
to reset all options to compiled-in defaults.  Which means that it turns the
SOURCE option on. Makes perfect sense.  Except that that doesn't seem to
happen in Picospan.  So I guess SUPERSANE should set ald
options to their
default except for SOURCE.  I wonder if there are any other exceptions?

So the reason I wasn't having problems in "puzzle" and Joe was, had to do
with the fact that he was sourcing the puzzle conferences RC file, I wasn't.
Now one of the problems I was having when I was using his .cfonce file was
with this pager, which is set to "less -ME".  My terminal is one that uses
an alternate screen when it goes into editors like "vi" and then restores
the original screen when you exit.  The "less -ME" pager seems to display
on the alternate screen and then exit without prompting, so any output that
was going through the page would cause a barely noticable flicker of my
screen, as it switched briefly to the alternate screen to display something
an then returned to the main screen, with nothing displayed.  Ick.

Getting rid of that, I see that Fronttalk isn't really hanging on entry to
the puzzle conference.  It just seems to have set the prompt to a null string.
That's evidently some kind of bug in the parsing of the prompt setting
command that is in the puzzle conference rc file.

response 45 of 115:

Jan 27 04:29 UTC 2005

The person who was depending upon that esoterica cares, obviously. ;)

response 47 of 115:

Jan 27 04:55 UTC 2005

The problem with the puzzle conference rc files looks like a much bigger bug
than any other I've seen recently in Fronttalk.  When you join a conference,
things like prompts can be set by the system RC file.  When you leave the
conference, they are supposed to revert to the previous definition.  Fronttalk
isn't reverting them right.  When the revert they go blank.  I don't think
Fronttalk is even remembering the previous definitions.  I'm going to have
to do some slightly more complex programming to get this working right.  At
the moment I don't even really remember how that code works.

response 49 of 115:

Jan 27 13:44 UTC 2005

This is a pretty minor bug - if "bug" is the right word.  It's certainly a
difference from picospan's behavior.  I normally do "n;r" to go from one
conference to the next (in my .cflist).  In ft, this results in:

> Ok: n;r
> I don't understand "n;r" - type HELP for help

Is there a reason ft understands that "n" is "next" and "r" is "read [new]",
but that it doesn't understand them together?  (Um.  A *good* reason, I mean.)