This item is for reporting and discussing bugs in fronttalk.

115 responses total.

Fronttalk doesn't seem able to deal with being backgrounded using, e.g., ^Z.
Just FYI.

I'm currently doing some work on Fronttalk.  Version 0.3.7 will have many
fixes to the "read since" logic.  It will also use "readline" to enable
command-line editing.  There is fix to a bug that caused "slipped in" messages
to be printed inappropriately sometimes.  Better error messages for bad shell
escapes.

There was an item someplace on Grex where various people entered Fronttalk
bug reports, but I can't remember where it was.  I tried to do some searching,
but Grex was being too slow to make this possible.  I should probably try
again now that things are working better.

I tried ^Z in three places:
  - Ok prompt
  - Reponse or Pass prompt
  - Response text entry
In the first two, it worked OK, but didn't redisplay the prompt when
returning, so it wasn't obvious where you were.

In the third case I had to do "fg" twice to get back in.

OK, needs a bit of work here.

I guess that if we are a login shell, control-Z should be handled differently.
Looks like when picospan is a login shell, control-Z doesn't terminate it,
but it doesn't  work right in sub processes either.  You really don't have
job control when you use the bbs shell.  Dunno if I can (or want to) do
better.

The only report I can find right now that you've not addressed above is from
Kent Nassen:

  Putting literal ANSI escape codes in picospan rsep/isep/ishort (via
  .cfonce) doesn't work for changing colors in bbs any longer.  All I get are
  the raw codes.  My terminal can show colors just fine otherwise.

Scott mentioned not getting certain characters (Norwegian, I think they
were), too.  

The failure to show escape does is a function of the "more" pager on the
new machine.  It expands out those escape sequences.  There is an option
someone described that causes it to not do this.

Norwegian characters are a research problem.

This response has been erased.

Good to hear about readline; that was on my list of things to ask about.

It was me who figured out the trick with `more' and ANSI color escapes.

I remember that there was an item for discussing fronttalk bugs, but I
can't remember what it was now, either, so I entered this one.

Well, it's not in garage1, which is where I expected it to be.  Might have
been in agora.

At least part of the problem with suspending fronttalk was actually a problem
with suspending 'gate'.  I've updated the signal-handling in gate to work with
modern BSD signal semantics (sigaction and whatnot).  That has been installed
on Grex.  Fronttalk's signal handling has also gotten better, but that hasn't
been installed here yet.

Adding readline to fronttalk has the sad side effect of making gate look
rather shabby.  Now we have more powerful text editing when you are in command
mode than when you are entering responses!  Arrow keys work in command mode,
but not in text entry mode!

I did once have a plan for a successor to be called 'sue' (Scroll Up Editor)
that would have given you full editing without clearing the screen.  Wrote
some notes on how to do it, but never started coding it.  It'd be easier today
than it would have been then, since the variety of different terminals has
been much reduced, but it would still be a fairly large programming project
and the demand for novice-friendly command-line text-entry tools isn't what
it used to be, so I don't think it will ever happen.

Is this item just for bugs, or can we talk about features too?

I don't see why it can't be about features as well.
Maybe I should have titled the item, `fronttalk discussion'.  Whoops.

(I believe that the person who entered an item can change its title,
using backtalk.)

(But maybe it would be more convenient for Jan to have features discussion
in a separate place...)

I retitled the item, using the Fronttalk "retitle" command.

I've installed Fronttalk 0.3.7, which fixes a number of bugs including many
"read since" bugs, and some job control bugs.  It adds readline support while
in command mode.

Awesome!  Readline support is definitely cool.  Thanks, Jan!

My macros for joining other conferences don't work.  Is this because of the
"set sane" in my .cfonce?  If so, it seems counter-productive to override
the macros defined in that same file.

A couple of things that Picospan does that are on my wish list for
Fronttalk:

(1) At the "Ok" prompt, the "read" command takes both "new" and an
item number (probably an item range, too) as arguments -- as in
"read new 156", for example -- and leaves you at the "Respond or pass"
prompt.  I use that quite a bit when I want to post a response to an
item that I'm caught up on and don't want to see the previous responses.

(2) At the the "Respond or pass" prompt, "enter" works.  It lets
you enter a new item, then returns you to "Respond or pass" in the
old item.  Handy if you're reading new material in a conference, get
an idea for a new item, and then want to resume reading where you left
off.

(3) At the "Ok" prompt (maybe "rp" too), "display conference" gives you
particulars about the current conference (item directory, number of items,
etc).  (In fronttalk, it currently just lists all the conferences.)

"display conference" works at the RFP prompt, too. :)

resp:17 -

  I recently grabbed a copy of your .cfonce and found it worked perfectly.
  However, there wasn't a "set sane" in there.  Maybe you took it out?  Where
  was it?  Theoretically it is supposed to be first.

resp:18 -

  (1) Hmmm...looks like picospan does that only in the special case where
      only one item is given in the range.  Should be easy enough to
      make that happen.

  (2) This is a trivial change to make in fronttalk.

  (3) This is a deliberate change, having to do with architectural
      differences between Backtalk and Picospan.  In Picospan, to get
      a list of conferences, you do "help conferences".  This is weird,
      since the help command normally shows you manual pages, not anything
      about the configuration of the conferencing system.  But it makes a
      kind of backwards sense because in Picospan there really is no
      computer readable list of conferences, just a manually maintained
      text file that is printed out when you type "help conferences".

      Backtalk needs to be able to parse conference lists, so it can
      display them in pretty tables and stuff.  On Grex it uses a set of
      regular expressions tuned to the format of the manually maintained
      conference file, but on most installs it has a rigidly structured
      confmenu file that is maintained via some administrative web pages.
      Displaying the contents of this with the "help" command instead of
      the "display" command makes even less sense than it did before.

      So, in Fronttalk, to get a list of all conferences on the current
      server, you do:

            display conferences

      This can be abbreviated a lot, like to

            d c

      For backwards compatibility there is a kludge that makes "help conf"
      do the same thing.  However, this means that "disp conf" can no longer
      display information about the current conference.  My solution to this
      was to create a new command:

            display thisconf

      Which gives similar information to the old Picospan "disp conf"
      command.  I figured renaming this relatively uncommon and obscure
      command to make a common and important command more sensible was
      a fair tradeoff, but I was never all that happy with the "thisconf"
      keyword.  Just haven't thought of anything better.

      Incidentally, there are some similar commands for servers.  You can
      do "display servers" to get a list of all the servers Fronttalk knows
      about (rather few, I should at least add M-Net to that list), and
      "display thisserver" gives info about the server you are currently
      connected to.

John, "read 53 nor" [for "noresponses" I think] takes you directly to the
respond-or-pass prompt.  Seems to work in ft too.

Fronttalk seems to require a lot more typing than picospan - fewer
abbreviations work.

Hmmm...I'm noticing accessing remote conferencing systems (like hvcn) is being
slow and broken.  I wonder if that is just because the proxy is still in the
pumpkin, so http connections out of Grex are going through the bad old DSL
twice.

Hmmm...M-Net accepts connections to backtalk only with "https".  Fronttalk
doesn't talk https.  Probably that is something I should look into.

Which abbreviations don't work?  Theoretically they all should.

Here are the first eight lines of my .cfonce:

} # here is where you can put PicoSpan customization
} 
} ## Stuff suggested in staff
} set nosource
} set sane
} set supersane
} 
} ## Stuff . . . borrowed . . . from valerie

I use "read n1, n2, n3, n4 new" regularly.  If I repeat an item number or
include an item that has no new responses, I get the RFP prompt for that
item, and the new responses for the other items.

Odd that my .cfonce works for you but not for me. :)

} 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

I've implemented fixes for John's comments (1) and (2).  They'll be in the
0.3.8 release.

I added a "skip"/"noskip" option to the "read new" command.  If you do
"read new noskip 1-34" then it will do an ordinary "read new" but it will
also stop with a "Respond or Pass?" prompt at items with no new responses.
The default is "skip", unless a range is given with only one item in it, in
which case it defaults to "noskip".

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.

Looks like I had somehow grabbed only half Joe's .cfonce file.

Permission shouldn't matter.  With Fronttalk, you might theoretically have
two .cfonce files - one on the server and one on your local system.  In the
Grex case they are the same, so Fronttalk has the brains to execute only the
local .cfonce.  That means it is being accessed by the Perl program, which
is running as you, not by Backtalk which is running as cfadm.  Should be OK.

Hmmm...looks like the "set sane" and "set supersae" command were incorrectly
terminating execution of the .cfonce file.  I think I fixed that (on Grex
too).

Joining the puzzle conference with Joe's .cfonce file instead of mine seems
to hang.

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.

My macros now work. :)

Thank you, Jan. :)

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

Why is "SET SAVESEEN ignored in Fronttalk"?

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

I've made some (fairly simple) changes so that the 0.3.8 release will support
the "https" protocol.  Once that is installed, here and on M-Net, Fronttalk
will again be able to access M-Net conferences from Grex.

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.

Thank you for the explanation, Jan.  I no longer need to "cs" when I finish
reading. :)

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

Or perhaps, since fronttalk effectively always has saveseen set, it 
should silently ignore 'SET SAVESEEN' and give an error on 'SET 
NOSAVESEEN'. 
 

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.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss