Hey Nightfox!
I've been using SLYEDIT - as my prefered editor and I've noticed something that I'm not sure if you can fix (or I need to fix).
I'm toggling a lot between using SyncTerm and my normal terminal window (on a MAC) to access Synchronet. (And I love how it just works seemlessly between the two different client UIs - the MAC terminal window gives me more screen real estate.)
I've noticed when I'm on the MAC terminal - my "Delete" key (backspace) is not working in SLYEDIT - whereas it does in SyncTERM. To verify, it works
no problem with any SyncTerm input, as well as using deuces FSEditor - so I'm thinking there is a parameter that is missing (or needs to be passed from Synchronet).
Any ideas?
There's a terminal setting in Synchronet to treat DEL as Backspace (left-delete) and that settings needs to be enabled (in user [D]efaults) for terminals that send 0x7F (DEL) when pressing the backspace/left-delete key.
That said, fseditor treats the DEL (0x7F) character the same as the backspace (0x08) character when the cursor is already at the end of the current line. Synchronet does the same (e.g. with the internal line editor). So perhaps slyedit could use that same logic.
Re: SLYEDIT and backspace
By: Digital Man to Alterego on Mon Aug 12 2019 07:15 pm
There's a terminal setting in Synchronet to treat DEL as Backspace (left-delete) and that settings needs to be enabled (in user [D]efaults) for terminals that send 0x7F (DEL) when pressing the backspace/left-delete key.
Where is this? Once logged in right, on the main menu [D] defaults? (In the Synchronet Class Shell?)
I dont see a Treat DEL as Backspace option?
That said, fseditor treats the DEL (0x7F) character the same as the backspace (0x08) character when the cursor is already at the end of the current line. Synchronet does the same (e.g. with the internal line editor). So perhaps slyedit could use that same logic.
I was hoping for this outcome :-P
I've been using SLYEDIT - as my prefered editor and I've noticed something that I'm not sure if you can fix (or I need to fix).
That said, fseditor treats the DEL (0x7F) character the same as the backspace (0x08) character when the cursor is already at the end of the current line. Synchronet does the same (e.g. with the internal line editor). So perhaps slyedit could use that same logic.
Re: SLYEDIT and backspace
By: Digital Man to Alterego on Mon Aug 12 2019 07:15 pm
That said, fseditor treats the DEL (0x7F) character the same as the backspace (0x08) character when the cursor is already at the end of the current line. Synchronet does the same (e.g. with the internal line editor). So perhaps slyedit could use that same logic.
Normally, delete and backspace are 2 somewhat different things though: Backspace normally deletes the previous character, and the 'delete' key normally deletes the next character. That's how SlyEdit currently behaves, and sometimes I use the delete key to delete the next character. I'm not sure I'd want to lose that functionality. I'm curious why some editors would treat the delete key the same as the backspace key?
Normally, delete and backspace are 2 somewhat different things though:
Backspace normally deletes the previous character, and the 'delete'
key normally deletes the next character. That's how SlyEdit currently
behaves, and sometimes I use the delete key to delete the next
character. I'm not sure I'd want to lose that functionality. I'm
curious why some editors would treat the delete key the same as the
backspace key?
If the cursor is at the end of the last line, what does the delete key do in SlyEdit? If nothing, it could possibly instead, perform the same operation as backspace. That's what Synchronet and fseditor.js do.
Re: SLYEDIT and backspace
By: Digital Man to Nightfox on Tue Aug 13 2019 01:13 pm
Normally, delete and backspace are 2 somewhat different things though:
Backspace normally deletes the previous character, and the 'delete'
key normally deletes the next character. That's how SlyEdit currently
behaves, and sometimes I use the delete key to delete the next
character. I'm not sure I'd want to lose that functionality. I'm
curious why some editors would treat the delete key the same as the
backspace key?
If the cursor is at the end of the last line, what does the delete key do in SlyEdit? If nothing, it could possibly instead, perform the same operation as backspace. That's what Synchronet and fseditor.js do.
At the end of the last line, it wouldn't do anything. I suppose it could do a backspace in that instance.
I haven't seen any other program behave like that though.. It seems inconsistent with what I'd expect. I actually haven't even noticed Synchronet behave like that (though, I tend to use the backspace key when I want to do a backspace).
Right, but you would notice it if you used a terminal that sends 0x7F when the backspace key is hit (or the key that's normally in the position of backspace key, as in a mac keyboard). *nix terminals tend to do this.
Like I said, it's not a complete fix for the issue, but it helps with the majority use case (hitting the backspace key at the end of a line of input).
Re: SLYEDIT and backspace
By: Digital Man to Nightfox on Tue Aug 13 2019 03:06 pm
Right, but you would notice it if you used a terminal that sends 0x7F when the backspace key is hit (or the key that's normally in the position of backspace key, as in a mac keyboard). *nix terminals tend to do this.
Like I said, it's not a complete fix for the issue, but it helps with the majority use case (hitting the backspace key at the end of a line of input).
I suppose there's a historical reason *nix terminals behave that way?
It seems odd for a modern computer to lack a proper backspace key..
It seems odd for a modern computer to lack a proper backspace key..
Normally, delete and backspace are 2 somewhat different things though: Backspace normally deletes the previous character, and the 'delete' key normally deletes the next character. That's how SlyEdit currently behaves, and sometimes I use the delete key to delete the next character. I'm not sure I'd want to lose that functionality. I'm curious why some editors would treat the delete key the same as the backspace key?
Re: SLYEDIT and backspace
By: Nightfox to Digital Man on Tue Aug 13 2019 09:46 am
Normally, delete and backspace are 2 somewhat different things though: Backspace normally deletes the previous character, and the 'delete' key normally deletes the next character. That's how SlyEdit currently behaves, and sometimes I use the delete key to delete the next character. I'm not sure I'd want to lose that functionality. I'm curious why some editors would treat the delete key the same as the backspace key?
The issue comes about, because on a MAC, you only have a DELETE key (not a backspace key).
When I first logged into Synchronet, it asked me to press the backspace key, and recorded what that was - so going forward, whenever I press it does what I expect.
I was hoping that knowledge could be past to SLYEDIT. It seems it is past to FSeditor, because it does behave appropriately.
It seems odd for a modern computer to lack a proper backspace key..
He's using a mac. Apple likes to be different.
The issue comes about, because on a MAC, you only have a DELETE key (not a backspace key).
When I first logged into Synchronet, it asked me to press the backspace key, and recorded what that was - so going forward, whenever I press it does what I expect.
I was hoping that knowledge could be past to SLYEDIT. It seems it is past to FSeditor, because it does behave appropriately. ...ëîå*
Ah, good point. fseditor.js uses console.inkey() to capture keyboard input from the remote user. The underlying C function (sbbs_t::inkey()) recognizes the user terminal setting to swap the DEL and Bkspc keys and can return 0x7F when it gets a 0x08 from the terminal when that setting is enabled.
Maybe SlyEdit is using some other lower-level method of capturing keyboard input.
Ah, good point. fseditor.js uses console.inkey() to capture keyboard input from the remote user. The underlying C function (sbbs_t::inkey()) recognizes the user terminal setting to swap the DEL and Bkspc keys and can return 0x7F when it gets a 0x08 from the terminal when that setting is enabled.
Maybe SlyEdit is using some other lower-level method of capturing keyboard input.
The issue comes about, because on a MAC, you only have a DELETE key (not a backspace key).
When I first logged into Synchronet, it asked me to press the backspace key, and recorded what that was - so going forward, whenever I press it does what I expect.
I was hoping that knowledge could be past to SLYEDIT. It seems it is past to FSeditor, because it does behave appropriately. ...ëîå*
@MSGID: <5D543E20.40467.dove_sync@digitaldistortionbbs.com>
@REPLY: <5D536732.5881.sync@vert.synchro.net>
@TZ: c1e0
Re: SLYEDIT and backspace
By: Digital Man to Alterego on Tue Aug 13 2019 06:43 pm
Ah, good point. fseditor.js uses console.inkey() to capture keyboard input from the remote user. The underlying C function (sbbs_t::inkey()) recognizes the user terminal setting to swap the DEL and Bkspc keys and can return 0x7F when it gets a 0x08 from the terminal when that setting is enabled.
Maybe SlyEdit is using some other lower-level method of capturing keyboard input.
Looking at the user input code in SlyEdit (which is one of its oldest functions and may need to be re-written), it's using console.inkey() for non-sysop users, and console.getkey() for the sysop. I think I was doing that because SlyEdit uses a customizable input timeout with console.inkey() but I didn't want an input timeout for the sysop - and perhaps the input timeout is optional with console.inkey() and I didn't know at the time?
Does console.getkey() swap the DEL and backspace keys?
Maybe I should
update SlyEdit to just use console.inkey() for all user input.
@MSGID: <5D5463C4.40474.dove_sync@digitaldistortionbbs.com>
@REPLY: <5D536732.5881.sync@vert.synchro.net>
@TZ: c1e0
Re: SLYEDIT and backspace
By: Digital Man to Alterego on Tue Aug 13 2019 06:43 pm
Ah, good point. fseditor.js uses console.inkey() to capture keyboard input from the remote user. The underlying C function (sbbs_t::inkey()) recognizes the user terminal setting to swap the DEL and Bkspc keys and can return 0x7F when it gets a 0x08 from the terminal when that setting is enabled.
Maybe SlyEdit is using some other lower-level method of capturing keyboard input.
I tried going into my user preferences and when it asked me to press my delete-back key, I pressed delete (instead of backspace), and then tried typing a message with SlyEdit, and the delete key worked as backsapce. So I'm not sure if SlyEdit is actually working properly or if there's another scenerio where it might not work properly?
Looking at the user input code in SlyEdit (which is one of its oldest
functions and may need to be re-written), it's using console.inkey()
for non-sysop users, and console.getkey() for the sysop. I think I
was doing that because SlyEdit uses a customizable input timeout with
console.inkey() but I didn't want an input timeout for the sysop - and
perhaps the input timeout is optional with console.inkey() and I
didn't know at the time?
I would recommend using hte same input method for both sysops and non-sysops. console.getkey() does a bunch of stuff that inkey() doesn't.
Does console.getkey() swap the DEL and backspace keys?
It does.
Re: SLYEDIT and backspace
By: Digital Man to Nightfox on Wed Aug 14 2019 02:24 pm
Looking at the user input code in SlyEdit (which is one of its oldest
functions and may need to be re-written), it's using console.inkey()
for non-sysop users, and console.getkey() for the sysop. I think I
was doing that because SlyEdit uses a customizable input timeout with
console.inkey() but I didn't want an input timeout for the sysop - and
perhaps the input timeout is optional with console.inkey() and I
didn't know at the time?
I would recommend using hte same input method for both sysops and non-sysops. console.getkey() does a bunch of stuff that inkey() doesn't.
Does console.getkey() swap the DEL and backspace keys?
It does.
If console.getkey() does stuff that inkey() doesn't, would you recommend using getkey()? Or does it matter?
So I'm wondering where the problem might actually be. SlyEdit has been around for about 10 years and this is the first time I'm hearing of this issue. I imagine there have been other Mac users too.. I've also briefly used BBSes on a Mac (using SyncTerm, I believe), but I don't remember if this was an issue I noticed or not.
delete as backspace. But I'll probably implement a change in SlyEdit as Digital Man mentioned, where if the cursor is at the end of the last line, to treat delete as backspace.
I tried going into my user preferences and when it asked me to press my delete-back key, I pressed delete (instead of backspace), and then tried typing a message with SlyEdit, and the delete key worked as
backsapce. So I'm not sure if SlyEdit is actually working properly or if there's another scenerio where it might not work properly?
I think SyncTERM on a Mac is fine, it's using the included ssh client (OpenSSH) from the Mac OS-X terminal that's the issue (where the key labeled "Delete" that is located where the Backspace key normally is, sends 0x7F).
Re: SLYEDIT and backspace
By: Nightfox to Digital Man on Wed Aug 14 2019 03:49 pm
Re: SLYEDIT and backspace
By: Digital Man to Nightfox on Wed Aug 14 2019 02:24 pm
Looking at the user input code in SlyEdit (which is one of its oldest
functions and may need to be re-written), it's using console.inkey()
for non-sysop users, and console.getkey() for the sysop. I think I
was doing that because SlyEdit uses a customizable input timeout with
console.inkey() but I didn't want an input timeout for the sysop - and
perhaps the input timeout is optional with console.inkey() and I
didn't know at the time?
I would recommend using hte same input method for both sysops and non-sysops. console.getkey() does a bunch of stuff that inkey()
doesn't.
Does console.getkey() swap the DEL and backspace keys?
It does.
If console.getkey() does stuff that inkey() doesn't, would you recommend using getkey()? Or does it matter?
console.getkey() doesn't return until the user either sends a keystroke or disconnects. So if you want to implement your own inactivity
timer/alert, then getkey() is probably not what you want to use. In any full-screen style module, I would recommend using inkey() as
getkey() can send lines of text to the terminal (e.g. upon user inactivity) thus messing up your user's full-screen experience.
So I'm wondering where the problem might actually be. SlyEdit has been around for about 10 years and this is the first time I'm
hearing
of this issue. I imagine there have been other Mac users too.. I've also briefly used BBSes on a Mac (using SyncTerm, I believe),
but I
don't remember if this was an issue I noticed or not.
I think SyncTERM on a Mac is fine, it's using the included ssh client (OpenSSH) from the Mac OS-X terminal that's the issue (where the
key
labeled "Delete" that is located where the Backspace key normally is, sends 0x7F).
digital man
Synchronet "Real Fact" #37:
Synchronet's Windows Control Panel is built with Borland C++ Builder.
Norco, CA WX: 93.9øF, 19.0% humidity, 10 mph E wind, 0.00 inches rain/24hrs
delete as backspace. But I'll probably implement a change in
SlyEdit as Digital Man mentioned, where if the cursor is at the end
of the last line, to treat delete as backspace.
Actually, that probably addresses the most common use case (in my case anyway) - ie: typing a realising that your brain and fingers were disconnected.
I just committed a change to SlyEdit that does that. When you're at the end of the last line, DEL will be treated as a backspace.
I just committed a change to SlyEdit that does that. When you're at the end of the last line, DEL will be treated as a backspace.
Just think it looks odd ;)
Re: SLYEDIT and backspace
By: Alterego to Nightfox on Thu Aug 15 2019 04:09 pm
Just think it looks odd ;)
BTW: When I see my post after I sent it, my quoted text is not wrapped unusually...
I also wanted to ask...
So I often use my MAC's iTERM2 window to access Synch, since it gives me more realestate. My screen size is much wider than 80 chars.
BTW: When I see my post after I sent it, my quoted text is not wrapped unusually...
Re: SLYEDIT and backspace
By: Alterego to Nightfox on Thu Aug 15 2019 04:09 pm
I also wanted to ask...
So I often use my MAC's iTERM2 window to access Synch, since it gives me more realestate. My screen size is much wider than 80 chars.
Other BBS terminals support wide modes. SyncTerm, for instance, supports some wide terminal modes beyond 80 characters.
That's by design. Historically, 80 characters has been a very common terminal width, and I think by default, Synchronet wraps the lines to be quoted to 80 characters. There's even an option in SCFG for message editors to tell it to wrap quote lines at 80 characters or terminal width (Synchronet is doing that when it writes the message quote lines, which SlyEdit then reads).
80 characters is a recommended width for quote lines in order for the message to look good in other readers (including online and offline readers) which are likely to use a width of 80 characters. The reason is that quoted lines are prefixed with some characters (usually " > ", or it may include author's initials in some cases). So if the quote lines were longer and re-wrapped, the line prefixes might be messed up in some readers. In SCFG, I would recommend keeping it to wrap quote lines at 80 characters for the message editor.
80 characters is a recommended width for quote lines in order for the
message to look good in other readers (including online and offline
readers) which are likely to use a width of 80 characters. The reason
is that quoted lines are prefixed with some characters (usually " > ",
or it may include author's initials in some cases). So if the quote
lines were longer and re-wrapped, the line prefixes might be messed up
in some readers. In SCFG, I would recommend keeping it to wrap quote
lines at 80 characters for the message editor.
Synchronet re-flows messages, including quoted text, to display nicely on the user's terminal, regardless of width (40, 80, 132, 192, whatever columns). fseditor.js does the same. So it would be possible for SlyEdit to do that too. <shrug>
Re: SLYEDIT and backspace
By: Digital Man to Nightfox on Thu Aug 15 2019 11:18 am
80 characters is a recommended width for quote lines in order for the
message to look good in other readers (including online and offline
readers) which are likely to use a width of 80 characters. The reason
is that quoted lines are prefixed with some characters (usually " > ",
or it may include author's initials in some cases). So if the quote
lines were longer and re-wrapped, the line prefixes might be messed up
in some readers. In SCFG, I would recommend keeping it to wrap quote
lines at 80 characters for the message editor.
Synchronet re-flows messages, including quoted text, to display nicely on the user's terminal, regardless of width (40, 80, 132, 192, whatever columns). fseditor.js does the same. So it would be possible for SlyEdit to do that too. <shrug>
I'm a little confused now.. Recently we were discussing re-flowing text in messages, and I thought you had said 80 characters is recommended for quote lines, but new text entered can be re-flowed?
I'd think the issue with quote lines is that quote lines have a prefix in front of them, so if the quote lines are re-flowed for a different width, the quote prefixes might end up in the middle of the lines. Even if Synchronet can intelligently re-flow quote lines with the prefixes, some users use offline readers that might not be so intelligent about re-flowing quote lines.
I'm a little confused now.. Recently we were discussing re-flowing
text in messages, and I thought you had said 80 characters is
recommended for quote lines, but new text entered can be re-flowed?
I may have said that at one time, but that's not the current thinking.
I'm not saying SlyEdit should support long-quote lines, I'm just saying that fseditor.js does and it seems to be working fine. No complaints... yet.
Re: SLYEDIT and backspace
By: Digital Man to Nightfox on Thu Aug 15 2019 01:37 pm
I'm a little confused now.. Recently we were discussing re-flowing
text in messages, and I thought you had said 80 characters is
recommended for quote lines, but new text entered can be re-flowed?
I may have said that at one time, but that's not the current thinking.
I think it was just a couple weeks ago when you said that.. Has the current thinking changed in that short of time? ;)
I'm wondering how many modern BBS offline message readers are being maintained these days though. I think MultiMail is still being maintained, and there's also GoldEd, though I'm not sure if that or any others are still being maintained.
I'm not saying SlyEdit should support long-quote lines, I'm just saying that fseditor.js does and it seems to be working fine. No complaints... yet.
For SlyEdit, I wonder if I could go to the editor settings in SCFG and have it wrap quote lines to the terminal width instead of 80 characters. I may need to modify SlyEdit slightly to support that, as I think it's hard-coded to wrap quote lines (including room for the quote prefix) at 80 characters.
I'd just like to make the best compromise to make messages look good for everyone.
I'm not sure what you mean by "not wrapped unusually"? What is wrapped usually vs. unusually?
I'm a little confused now.. Recently we were discussing re-flowing
text in messages, and I thought you had said 80 characters is
recommended for quote lines, but new text entered can be re-flowed?
I may have said that at one time, but that's not the current
thinking.
I think it was just a couple weeks ago when you said that.. Has the
current thinking changed in that short of time? ;)
No. I don't think we've discussed the length of quote lines recently.
Yeah, I thought it might be a bit difficult to understand (I'm a pictures guy).
So my suggestions is why is the text wrapped at 80 chars when composing a reply? - it would be great if it was "quoted" but using the available
Also, wanted to comment where my signature is placed on screen capture #3 - it was put on a new line - but it has been quoted as being on the end of the original text. (And I do NOT have "Trim spaces from quoted text" selected in settings.). In fact, I always leave a additional blank line after I complete my message so that there is a blank line between my signature and the last paragraph. But that blank line seems to evaporate :) (Or it might be me pressing send too quickly sometimes too - I'll leave a blank line on this message to confirm...)
Now I get that these is probably not an issue with somebody using a normal 80 char display (like syncterm) but I thought it would be a nice fix for those who are using a UTF8 terminal, since synchronet is working so well with one (while also accommodating CP437 users). ...ëîå*
I'm not sure I see the relation between terminal width and character encoding (CP437/UTF8)?
I'm not sure I see the relation between terminal width and character
encoding (CP437/UTF8)?
Cool, hopefully not.
So my suggestions is why is the text wrapped at 80 chars when composing a reply? - it would be great if it was "quoted" but using the available terminal width
Re: SLYEDIT and backspace
By: Digital Man to Nightfox on Thu Aug 15 2019 03:38 pm
I'm a little confused now.. Recently we were discussing re-flowing >>> text in messages, and I thought you had said 80 characters is
recommended for quote lines, but new text entered can be re-flowed?
I may have said that at one time, but that's not the current
thinking.
I think it was just a couple weeks ago when you said that.. Has the
current thinking changed in that short of time? ;)
No. I don't think we've discussed the length of quote lines recently.
There's a message in the Synchronet Discussion sub-board you wrote to me on August 5th (my BBS says the timestamp is 17:34:30 PDT) where you said:
The Synchronet built-in word-wrap logic (and JS word_wrap() function) supports the automatic detection and re-wrapping/flowing of quoted text. It need to be limited to 80 characters.
It was there where you said it needs to be limited to 80 characters. Or did you mean "doesn't need to be"?
Also, when you say "quoted text", do you mean text that already includes a prefix (such as " > " or " Ni> ")?
You mentioned something about an 80 character terminal vs. those using a UTF8 terminal though? I wasn't quite sure what you were saying about the character encoding.
I did some testing, and it seems the issue I was concerned about is probably not as big of an issue as I thought. I just committed another update for SlyEdit which uses the whole width of the terminal for quoted lines.
I did some testing, and it seems the issue I was concerned about is
probably not as big of an issue as I thought. I just committed
another update for SlyEdit which uses the whole width of the
terminal for quoted lines.
Awesome, thanks - I'll rebuild and try it out...
I'd think the issue with quote lines is that quote lines have a prefix in front of them, so if the quote lines are re-flowed for a different width, the quote prefixes might end up in the middle of the lines.
Even if Synchronet can intelligently re-flow quote lines with the prefixes, some users use offline readers that might not be so
intelligent about re-flowing quote lines.
Now I get that these is probably not an issue with somebody using a
normal 80 char display (like syncterm) but I thought it would be a
nice fix for those who are using a UTF8 terminal, since synchronet is
working so well with one (while also accommodating CP437 users).
...ëîå*
I'm not sure I see the relation between terminal width and character encoding (CP437/UTF8)?
On 2019 Aug 15 17:08:44, you wrote to Alterego:
Now I get that these is probably not an issue with somebody using a
normal 80 char display (like syncterm) but I thought it would be a
nice fix for those who are using a UTF8 terminal, since synchronet is
working so well with one (while also accommodating CP437 users).
...ëîå*
I'm not sure I see the relation between terminal width and character encoding (CP437/UTF8)?
the difference is in counting...
CP437 is always one character == one byte == one terminal column
UTF8 characters (better called glyphs) may be one, two, three or four bytes
so with UTF8, you have to count the glyphs and not the bytes...
I did some testing, and it seems the issue I was concerned about is probably not as big of an issue as I thought. I just committed another update for
SlyEdit which uses the whole width of the terminal for quoted lines.
I did some testing, and it seems the issue I was concerned about is
probably not as big of an issue as I thought. I just committed
another update for SlyEdit which uses the whole width of the
terminal for quoted lines.
So I forgot to mention - yay, thank you it works well.
I've been typing away and I just released that it was fix - kudos, it works really well. :) ...ëîå*
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 325 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 159:07:22 |
| Calls: | 507 |
| Messages: | 219708 |