|
|
| Author |
Message |
| 25 new of 115 responses total. |
remmers
|
|
response 18 of 115:
| 
Jan 26 12:54 UTC 2005 |
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.)
|
gelinas
|
|
response 19 of 115:
|
Jan 26 13:43 UTC 2005 |
"display conference" works at the RFP prompt, too. :)
|
janc
|
|
response 20 of 115:
|
Jan 26 14:22 UTC 2005 |
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.
|
davel
|
|
response 21 of 115:
|
Jan 26 14:31 UTC 2005 |
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.
|
janc
|
|
response 22 of 115:
|
Jan 26 14:38 UTC 2005 |
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.
|
janc
|
|
response 23 of 115:
|
Jan 26 14:39 UTC 2005 |
Which abbreviations don't work? Theoretically they all should.
|
gelinas
|
|
response 24 of 115:
|
Jan 26 15:14 UTC 2005 |
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. :)
|
gelinas
|
|
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
|
janc
|
|
response 26 of 115:
|
Jan 26 15:47 UTC 2005 |
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".
|
remmers
|
|
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.
|
janc
|
|
response 28 of 115:
|
Jan 26 16:19 UTC 2005 |
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.
|
janc
|
|
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.
|
gelinas
|
|
response 30 of 115:
|
Jan 26 18:20 UTC 2005 |
My macros now work. :)
Thank you, Jan. :)
|
gelinas
|
|
response 31 of 115:
|
Jan 26 18:22 UTC 2005 |
As noted, "jpu" hangs. I wonder if it's a problem with the conference?
|
gelinas
|
|
response 32 of 115:
|
Jan 26 18:43 UTC 2005 |
Why is "SET SAVESEEN ignored in Fronttalk"?
|
janc
|
|
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
|
janc
|
|
response 34 of 115:
|
Jan 26 20:17 UTC 2005 |
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.
|
cross
|
|
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.
|
gelinas
|
|
response 36 of 115:
|
Jan 26 21:53 UTC 2005 |
Thank you for the explanation, Jan. I no longer need to "cs" when I finish
reading. :)
|
gelinas
|
|
response 37 of 115:
|
Jan 26 22:13 UTC 2005 |
(Can we change the error message to "SET SAVESEEN is not needed in
Fronttalk"?)
|
gull
|
|
response 38 of 115:
|
Jan 26 23:44 UTC 2005 |
Or perhaps, since fronttalk effectively always has saveseen set, it
should silently ignore 'SET SAVESEEN' and give an error on 'SET
NOSAVESEEN'.
|
remmers
|
|
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.
|
janc
|
|
response 40 of 115:
|
Jan 27 02:18 UTC 2005 |
Oops, I had things a bit mixed up in my description above.
SET SAVESEEN or SET SEEN or CHANGE SAVESEEN or CHANGE SEEN
These do a one time save of the participation file. It's the "cs"
command Joe was talking about doing occasionally as he reads the
conferences. In "Fronttalk" they all give the message "ignored
in Fronttalk".
SET AUTOSAVE or CHANGE AUTOSAVE
Causes Picospan to do a save after each item is read automatically.
This is what I was talking about above. In Fronttalk, this option
is silently ignored.
SET NOAUTOSAVE or CHANGE NOAUTOSAVE
This turns off the autosave mode. In Fronttalk, this gives the
"ignored" message.
SET RELOAD or CHANGE RELOAD
Causes Picospan to reload the participation file, effectively
removing all record of what you saw since the last time you
loaded the participation file. In Fronttalk, this gives the
"ignored" message.
So, it already does pretty much what gull suggested it should do.
These options are all not very easy to implement in Fronttalk. What I
could do to get sort of the same effect is to have a SET NORECORD option.
If you set that, future reads would not be recorded in your participation
file, until you did SET RECORD again. This would be easy to implement, but
I'm not sure this is really a functionality anyone would care to use.
|
janc
|
|
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.
|
janc
|
|
response 42 of 115:
|
Jan 27 03:05 UTC 2005 |
Hmmm. There is some weird Picospan semantics that I hadn't understood.
Suppose items 1 through 4 contain no new responses. Then
read 1-4 new - "No New Items Matched"
read 1,2,3,4 new - prompts for all four items.
read 1,2-4 new - prompts for item one only.
These were all equivalent in Fronttalk. I can't exactly duplicate this
functionality without significant changes deep inside Backtalk. I'm faking
it a bit. If there are any ranges (like 2-4) in the item list, then it
won't prompt for any items that have no new responses. Otherwise it will.
So the first two examples above would be the same in Fronttalk as Backtalk,
but in the last example Fronttalk will not prompt for any items. Of course,
an explicit "skip" or "noskip" on the read command will override the default,
but it's still all or nothing - can skip for some items and not for others
like Picospan can.
|