On 2013-03-05 22:19, Brian Schenkenberger, VAXman- wrote:
Clem Cole <clemc at ccc.com> writes:
try xterm.vt100.decTerminalID: 220
Which was my memory, I'd check to the sources for sure.
Also, don't forget to restart X. The .Xresource stuff was always hokey
and if things are not perfect, bad things happen. I've spent way more time
than I want to think dealing with Xresource crap over the years (and
b*tching at authors).
Clem
Doesn't make a bit of difference. Still doesn't give me DECDWL or DECDHL,
and the debugger issue still persists.
So, DECDWL and DECHDL are noted in the xterm documentation that it depends on your fonts. So unless you have an old version, or bad fonts, it should work. Does it work if you have it set to vt100?
Not sure what the debugger issues were.
Anyway, we might be beating on a dead horse here. It might that you're actually not that interested in getting this working, if you have another solution that do work for you.
All I can say is that at my place, xterm do handle DECDWL and DECDHL just fine.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-03-05 22:05, Clem Cole wrote:
try xterm.vt100.decTerminalID: 220
Which was my memory, I'd check to the sources for sure.
No, that is right. It should be 220, and not 200.
Also, don't forget to restart X. The .Xresource stuff was always hokey
and if things are not perfect, bad things happen. I've spent way more
time than I want to think dealing with Xresource crap over the years
(and b*tching at authors).
Uh. Xresources are really not that hard. You can always query the current values. No need to ever restart because of it. But you do need to make sure you have loaded the values. But with xrdb you can either merge new values in, or remove all the old values. I'd say you have pretty good control over this aspect.
Figuring out the names of the keys in the xresources is another story, however.
Johnny
Clem
On Tue, Mar 5, 2013 at 3:56 PM, Brian Schenkenberger, VAXman-
<system at tmesis.com <mailto:system at tmesis.com>> wrote:
Johnny Billquist <bqt at softjar.se <mailto:bqt at softjar.se>> writes:
>On 2013-03-05 21:33, Johnny Billquist wrote:
>> On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
>>> Clem Cole <clemc at ccc.com <mailto:clemc at ccc.com>> writes:
>>>
>>>> Yep. From the FAQ:
>>>>
>>>> The emulation level for xterm is set via the resource
decTerminalID,
>>>> *e.g.*,
>>>> to 220 for a VT220. Once set, applications can set the emulation
>>>> level up
>>>> or down within that limit. DEC's terminals are configured in
much the
>>>> same
>>>> way by a setup option.
>>>
>>> Yup... .Xresources has "decTerminalID: vt200" but that still
doesn't
>>> excuse
>>> it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL
>>> when it's
>>> set for vt200.
>>
>> Note that the value should be set to "220", not "vt220", nor
"vt200".
>
>
>And I should correct myself. Leading letters are ignored in
>decTerminalID, so vt220 works just as well as 220. However, vt200 will
>probably still not create the desired result.
>
>And you need the resource class or resource name in there as well, so
>just a plain decTerminalID in your x resources will not work right.
I'll have to stop postin shorthand for you...
XTerm.vt100.decTerminalID: vt200
--
VAXman- A Bored Certified VMS Kernel Mode Hacker
VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-03-05 21:56, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
On 2013-03-05 21:33, Johnny Billquist wrote:
On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
Clem Cole <clemc at ccc.com> writes:
Yep. From the FAQ:
The emulation level for xterm is set via the resource decTerminalID,
*e.g.*,
to 220 for a VT220. Once set, applications can set the emulation
level up
or down within that limit. DEC's terminals are configured in much the
same
way by a setup option.
Yup... .Xresources has "decTerminalID: vt200" but that still doesn't
excuse
it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL
when it's
set for vt200.
Note that the value should be set to "220", not "vt220", nor "vt200".
And I should correct myself. Leading letters are ignored in
decTerminalID, so vt220 works just as well as 220. However, vt200 will
probably still not create the desired result.
And you need the resource class or resource name in there as well, so
just a plain decTerminalID in your x resources will not work right.
I'll have to stop postin shorthand for you...
:-)
XTerm.vt100.decTerminalID: vt200
Now change that to "vt220". :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Interesting - really love to see the sources. I wonder what is different / has changed. By the early 2000s (pre compaq-tion) many/most of the systems developers on my team in MRO and ZKO, used xterms to get the vms systems for development (i.e we tended to use Alpha workstations but still needed to support some systems functions that ran on VMS). I supposed some must have used a PC for some of that work, but many of us just used our DS100's or the like running Tru64.
Hmm = you tests are interesting data - maybe more of them used DECterms than I thought and we never noticed.
Clem
On Tue, Mar 5, 2013 at 4:19 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
Clem Cole <clemc at ccc.com> writes:
>try xterm.vt100.decTerminalID: 220
>Which was my memory, I'd check to the sources for sure.
>
>Also, don't forget to restart X. The .Xresource stuff was always hokey
>and if things are not perfect, bad things happen. I've spent way more time
>than I want to think dealing with Xresource crap over the years (and
>b*tching at authors).
>
>Clem
Doesn't make a bit of difference. Still doesn't give me DECDWL or DECDHL,
and the debugger issue still persists.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Clem Cole <clemc at ccc.com> writes:
try xterm.vt100.decTerminalID: 220
Which was my memory, I'd check to the sources for sure.
Also, don't forget to restart X. The .Xresource stuff was always hokey
and if things are not perfect, bad things happen. I've spent way more time
than I want to think dealing with Xresource crap over the years (and
b*tching at authors).
Clem
Doesn't make a bit of difference. Still doesn't give me DECDWL or DECDHL,
and the debugger issue still persists.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
try xterm.vt100.decTerminalID: 220
Which was my memory, I'd check to the sources for sure.
Also, don't forget to restart X. The .Xresource stuff was always hokey and if things are not perfect, bad things happen. I've spent way more time than I want to think dealing with Xresource crap over the years (and b*tching at authors).
Clem
On Tue, Mar 5, 2013 at 3:56 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
Johnny Billquist <bqt at softjar.se> writes:
>On 2013-03-05 21:33, Johnny Billquist wrote:
>> On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
>>> Clem Cole <clemc at ccc.com> writes:
>>>
>>>> Yep. From the FAQ:
>>>>
>>>> The emulation level for xterm is set via the resource decTerminalID,
>>>> *e.g.*,
>>>> to 220 for a VT220. Once set, applications can set the emulation
>>>> level up
>>>> or down within that limit. DEC's terminals are configured in much the
>>>> same
>>>> way by a setup option.
>>>
>>> Yup... .Xresources has "decTerminalID: vt200" but that still doesn't
>>> excuse
>>> it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL
>>> when it's
>>> set for vt200.
>>
>> Note that the value should be set to "220", not "vt220", nor "vt200".
>
>
>And I should correct myself. Leading letters are ignored in
>decTerminalID, so vt220 works just as well as 220. However, vt200 will
>probably still not create the desired result.
>
>And you need the resource class or resource name in there as well, so
>just a plain decTerminalID in your x resources will not work right.
I'll have to stop postin shorthand for you...
XTerm.vt100.decTerminalID: vt200
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Johnny Billquist <bqt at softjar.se> writes:
On 2013-03-05 21:33, Johnny Billquist wrote:
On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
Clem Cole <clemc at ccc.com> writes:
Yep. From the FAQ:
The emulation level for xterm is set via the resource decTerminalID,
*e.g.*,
to 220 for a VT220. Once set, applications can set the emulation
level up
or down within that limit. DEC's terminals are configured in much the
same
way by a setup option.
Yup... .Xresources has "decTerminalID: vt200" but that still doesn't
excuse
it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL
when it's
set for vt200.
Note that the value should be set to "220", not "vt220", nor "vt200".
And I should correct myself. Leading letters are ignored in
decTerminalID, so vt220 works just as well as 220. However, vt200 will
probably still not create the desired result.
And you need the resource class or resource name in there as well, so
just a plain decTerminalID in your x resources will not work right.
I'll have to stop postin shorthand for you...
XTerm.vt100.decTerminalID: vt200
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
It's pretty much done except for the IPSec stuff, but that's just getting the right config options loaded in and is trivial.
It's here if anyone is interested in seeing how it works.
http://bart.4amlunch.net/misc/tunnels/
-brian
On 2013-03-05 21:33, Johnny Billquist wrote:
On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
Clem Cole <clemc at ccc.com> writes:
Yep. From the FAQ:
The emulation level for xterm is set via the resource decTerminalID,
*e.g.*,
to 220 for a VT220. Once set, applications can set the emulation
level up
or down within that limit. DEC's terminals are configured in much the
same
way by a setup option.
Yup... .Xresources has "decTerminalID: vt200" but that still doesn't
excuse
it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL
when it's
set for vt200.
Note that the value should be set to "220", not "vt220", nor "vt200".
And I should correct myself. Leading letters are ignored in decTerminalID, so vt220 works just as well as 220. However, vt200 will probably still not create the desired result.
And you need the resource class or resource name in there as well, so just a plain decTerminalID in your x resources will not work right.
Johnny
On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
Clem Cole <clemc at ccc.com> writes:
Yep. From the FAQ:
The emulation level for xterm is set via the resource decTerminalID, *e.g.*,
to 220 for a VT220. Once set, applications can set the emulation level up
or down within that limit. DEC's terminals are configured in much the same
way by a setup option.
Yup... .Xresources has "decTerminalID: vt200" but that still doesn't excuse
it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL when it's
set for vt200.
Note that the value should be set to "220", not "vt220", nor "vt200".
Actually, for me:
xrdb -query | grep decTerminalID
gives
*.vt100.decTerminalID: 220
Check that you have things actually set correctly... If you just have decTerminalID, it will not even be associated with xterm. (Xresources are often a somewhat obscure thing.)
DECDWL and DECDHL works just fine for me. That could be a font issue in your environment.
Johnny
