Term and JNA-based pty demo code is here

[Ivan Soleimanipour]

http://wiki.netbeans.org/TerminalEmulator

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[David Van Couvering]

Wow, this is very very interesting.  I'd like to see if I can get the
mysql command line to work inside it!

If I get this to work, is this something I can blog about?

David

Ivan Soleimanipour wrote:
> http://wiki.netbeans.org/TerminalEmulator

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ivan Soleimanipour]

> From David.Vancouvering@... Tue Jun  3 13:59:10 2008
>
> Wow, this is very very interesting.  I'd like to see if I can get the
> mysql command line to work inside it!
>
> If I get this to work, is this something I can blog about?
>

I guess ... it's in a public repository.

However, read the list of caveats first.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Peter Williams-4]

Hi Ivan,

I notice it says "Get it working on Solaris" at the bottom... so I tried
it anyway

I tried the term example on x86 and got the following bad news... is
this what you mean?  Or is there more that is broken?

-Peter

INSTALLDIR=/space/ins/tools/termapp
os.name: 'sunos'
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error looking
up function 'getpt': ld.so.1: java: fatal: getpt: can't find symbol
        at com.sun.jna.Function.<init>(Function.java:126)
        at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:219)
        at com.sun.jna.Library$Handler.invoke(Library.java:191)
        at pty.$Proxy0.getpt(Unknown Source)
        at pty.Pty.setup(Pty.java:81)
        at termsupport.TermProcess.run(TermProcess.java:94)
        at termapp.Main.main(Main.java:164)
Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException:
Not running yet
        at termsupport.TermProcess.error(TermProcess.java:40)
        at termsupport.TermProcess.hangup(TermProcess.java:195)
        at termapp.Main$1.windowClosing(Main.java:156)
        at
java.awt.AWTEventMulticaster.windowClosing(AWTEventMulticaster.java:332)
        at
java.awt.AWTEventMulticaster.windowClosing(AWTEventMulticaster.java:332)
        at java.awt.Window.processWindowEvent(Window.java:1827)
        at javax.swing.JFrame.processWindowEvent(JFrame.java:279)
        at java.awt.Window.processEvent(Window.java:1785)
        at java.awt.Component.dispatchEventImpl(Component.java:4413)
        at java.awt.Container.dispatchEventImpl(Container.java:2116)
        at java.awt.Window.dispatchEventImpl(Window.java:2440)
        at java.awt.Component.dispatchEvent(Component.java:4243)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
        at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
        at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
        at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)


Ivan Soleimanipour wrote:
> http://wiki.netbeans.org/TerminalEmulator
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Martin Krauskopf]

Peter Williams wrote:
> Hi Ivan,
>
> I notice it says "Get it working on Solaris" at the bottom... so I tried
> it anyway
>
> I tried the term example on x86 and got the following bad news... is
> this what you mean?  Or is there more that is broken?

Hi Peter,

likely you already know the answer. If not, I think that Ivan is not
subscribed to this list, so best to ask him directly wrt. Terminal Emulator.

        m.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Martin Krauskopf]

Ivan Soleimanipour wrote:
> http://wiki.netbeans.org/TerminalEmulator

Hi Ivan,

I've tried Terminal Emulator (TE) as NetBeans module on Ubuntu and just
work out-of-the-box. Quite impressive. Once tried, this it's just must
have feature ;)

So are there any specific plans about the way it will be released for
6.5. Likely it depends on the multi-platform availability/stability.

If it will be release as a stable module we would harness it from the
Ruby on several places:

- irb (Ruby console)
- jirb (no more pain for handling those two separately)
- Rails console
- debugger console once it is implemented
- like standard 'shell' - this feature would be likely provided as
   general module on official NetBeans Update Center. It would add action
   to the NetBeans menu as your TermModule[0] does. It would be enhanced
   to be invoked in the current context (project, edited file's dir,
   ...). We would bundle it within the Ruby IDE out-of-the-box so Ruby
   users do not need to download it separately. Could be then
   conveniently utilized by users for invoking:
   - gem tool if they prefer CLI
   - miscellaneous scripts in rails_app/script
   - ...

Above counts on the stable Terminal Emulator. If you think it is
feasible, I would start to work on transition to TE immediately. If not
it would be still great to have it available as module on AU for 6.5 so
users could utilize it as a shell (build-in support for Ruby tools, like
irb, rail console would have to stick with the current ugly textarea
kind of way).

Not sure what resources are available e.g. for testing, I would be
volunteer for QA on Linux ;)
I believe the NetBeans Ruby community would also give a feedback.

So depending on the main question above, I'll start to work on the
transition.

Now to some issue I've encountered:
- terminal emulator was utilized so far only from 'cnd2' cluster, so it
   resides there. Should be moved, likely to 'platform' cluster?
- DEL works like BS (backspace), BS does not work. Likely known issue,
   just can't find anything in the wiki. Any hint?

Other comments:
- terminal emulator vs. output window
   - this is not issue for me at all. TE tabs in the separate windows is
     minor issue, almost no issue at all from the user's point of view.

I see that to utilize TE in our IRB Action I will need to move wrapper
for TermSupport to some platform cluster or likely copy-paste
TermSupport classes directly. Better solution will be probably available
after you provide APIs for this as you mentioned in:

 
http://wiki.netbeans.org/TerminalEmulator#section-TerminalEmulator-ThingsIDLikeToDoInTheNearFuture

Just start to play with it wrt. to from-Ruby utilization, will do more.
Kind of limited internet connection these days so writing before I
leave, to provide feedback and get answers sooner then later.

Thanks,
   m.

[0] lib.terminalemulator/demosrc/TermModule

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Martin Krauskopf]

Ivan Soleimanipour wrote:
> http://wiki.netbeans.org/TerminalEmulator

Hi Ivan,

I've tried Terminal Emulator (TE) as NetBeans module on Ubuntu and just
work out-of-the-box. Quite impressive. Once tried, this it's just must
have feature ;)

So are there any specific plans about the way it will be released for
6.5. Likely it depends on the multi-platform availability/stability.

If it will be release as a stable module we would harness it from the
Ruby on several places:

- irb (Ruby console)
- jirb (no more pain for handling those two separately)
- Rails console
- debugger console once it is implemented
- like standard 'shell' - this feature would be likely provided as
   general module on official NetBeans Update Center. It would add action
   to the NetBeans menu as your TermModule[0] does. It would be enhanced
   to be invoked in the current context (project, edited file's dir,
   ...). We would bundle it within the Ruby IDE out-of-the-box so Ruby
   users do not need to download it separately. Could be then
   conveniently utilized by users for invoking:
   - gem tool if they prefer CLI
   - miscellaneous scripts in rails_app/script
   - ...

Above counts on the stable Terminal Emulator. If you think it is
feasible, I would start to work on transition to TE immediately. If not
it would be still great to have it available as module on AU for 6.5 so
users could utilize it as a shell (build-in support for Ruby tools, like
irb, rail console would have to stick with the current ugly textarea
kind of way).

Not sure what resources are available e.g. for testing, I would be
volunteer for QA on Linux ;)
I believe the NetBeans Ruby community would also give a feedback.

So depending on the main question above, I'll start to work on the
transition.

Now to some issue I've encountered:
- terminal emulator was utilized so far only from 'cnd2' cluster, so it
   resides there. Should be moved, likely to 'platform' cluster?
- DEL works like BS (backspace), BS does not work. Likely known issue,
   just can't find anything in the wiki. Any hint?

Other comments:
- terminal emulator vs. output window
   - this is not issue for me at all. TE tabs in the separate windows is
     minor issue, almost no issue at all from the user's point of view.

I see that to utilize TE in our IRB Action I will need to move wrapper
for TermSupport to some platform cluster or likely copy-paste
TermSupport classes directly. Better solution will be probably available
after you provide APIs for this as you mentioned in:


http://wiki.netbeans.org/TerminalEmulator#section-TerminalEmulator-ThingsIDLikeToDoInTheNearFuture

Just start to play with it wrt. to from-Ruby utilization, will do more.
Kind of limited internet connection these days so writing before I
leave, to provide feedback and get answers sooner then later.

Thanks,
   m.

[0] lib.terminalemulator/demosrc/TermModule


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[David Van Couvering-2]

Yes, this looks very promising.  We could also use it for running command-line database tools like mysql and mysqladmin.

I hope to work with Ivan on testing support on the Mac.  We'll see if we can squeeze it in.

David

On Wed, Jun 25, 2008 at 7:20 AM, Martin Krauskopf <Martin.Krauskopf@...> wrote:

Ivan Soleimanipour wrote:

http://wiki.netbeans.org/TerminalEmulator

Hi Ivan,

I've tried Terminal Emulator (TE) as NetBeans module on Ubuntu and just
work out-of-the-box. Quite impressive. Once tried, this it's just must
have feature ;)

So are there any specific plans about the way it will be released for
6.5. Likely it depends on the multi-platform availability/stability.

If it will be release as a stable module we would harness it from the
Ruby on several places:

- irb (Ruby console)
- jirb (no more pain for handling those two separately)
- Rails console
- debugger console once it is implemented
- like standard 'shell' - this feature would be likely provided as
 general module on official NetBeans Update Center. It would add action
 to the NetBeans menu as your TermModule[0] does. It would be enhanced
 to be invoked in the current context (project, edited file's dir,
 ...). We would bundle it within the Ruby IDE out-of-the-box so Ruby
 users do not need to download it separately. Could be then
 conveniently utilized by users for invoking:
 - gem tool if they prefer CLI
 - miscellaneous scripts in rails_app/script
 - ...

Above counts on the stable Terminal Emulator. If you think it is
feasible, I would start to work on transition to TE immediately. If not
it would be still great to have it available as module on AU for 6.5 so
users could utilize it as a shell (build-in support for Ruby tools, like
irb, rail console would have to stick with the current ugly textarea
kind of way).

Not sure what resources are available e.g. for testing, I would be
volunteer for QA on Linux ;)
I believe the NetBeans Ruby community would also give a feedback.

So depending on the main question above, I'll start to work on the
transition.

Now to some issue I've encountered:
- terminal emulator was utilized so far only from 'cnd2' cluster, so it
 resides there. Should be moved, likely to 'platform' cluster?
- DEL works like BS (backspace), BS does not work. Likely known issue,
 just can't find anything in the wiki. Any hint?

Other comments:
- terminal emulator vs. output window
 - this is not issue for me at all. TE tabs in the separate windows is
   minor issue, almost no issue at all from the user's point of view.

I see that to utilize TE in our IRB Action I will need to move wrapper
for TermSupport to some platform cluster or likely copy-paste
TermSupport classes directly. Better solution will be probably available
after you provide APIs for this as you mentioned in:


http://wiki.netbeans.org/TerminalEmulator#section-TerminalEmulator-ThingsIDLikeToDoInTheNearFuture

Just start to play with it wrt. to from-Ruby utilization, will do more.
Kind of limited internet connection these days so writing before I
leave, to provide feedback and get answers sooner then later.

Thanks,
 m.

[0] lib.terminalemulator/demosrc/TermModule

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

--
David W. Van Couvering
http://davidvancouvering.blogspot.com

[Ivan Soleimanipour]

> From Martin.Krauskopf@... Wed Jun 25 07:32:33 2008
>
> Ivan Soleimanipour wrote:
> > http://wiki.netbeans.org/TerminalEmulator
>
> Hi Ivan,
>
> I've tried Terminal Emulator (TE) as NetBeans module on Ubuntu and just
> work out-of-the-box. Quite impressive. Once tried, this it's just must
> have feature ;)
>
> So are there any specific plans about the way it will be released for
> 6.5. Likely it depends on the multi-platform availability/stability.
>

I had made no plans. I was waiting a for some sort of thumbs-up
and you seem to have just raised yours.

As for platforms:
- David V. and I are going to get together on Thu and try and get
  it working on the Mac.
- JNA is not available on Solaris 9. When I contacted the JNA folks
  they said "scratch your own itch".
  The main reason is that JNA uses gmake and gcc whichis available
  on Solaris10 but I had trouble installing them on Solaris9.


> If it will be release as a stable module

There are several layers to this thing.
- plain dumb terminal emulator, and existing NB module.
- pty library. Only gives access to pty's and helps start processes
  under them. One could in principle use this layer to start a process
  with a pty and then connect it to an output2 I/O tab.
  The thing to do with this is to make it be a service with a JNA
  base provider and a JNI based provider. I'd have to adapt sunstudio's
  JNI code to work with this.
- A "convenience" way of starting as shell (termsupport.TermShell)
- A "terminwal window" analogous, and for the time being separate, from
  the I/O window with all the condiments: options, search, redirect to file
  ...
 
So there's a lot of stuff still to be designed, API-reviewed and so on.

It would help to know in more detail exactly what the following
applications are ...

I'll see if I can grill David tomorrow.
Otherwise, if someone in the ruby team is in MPK, please come and
give me a demo of all these items Martin mentions:

> - irb (Ruby console)
> - jirb (no more pain for handling those two separately)
> - Rails console
> - debugger console once it is implemented
> - like standard 'shell'
 
> So depending on the main question above, I'll start to work on the
> transition.

I can't answer you yet .. I need to gauge the work, it's impedance
match to it's usage, compare against 6.5 calendar and see if my manager
(on the cc list :-) will let me focus on this %100.

>
> Now to some issue I've encountered:
> - terminal emulator was utilized so far only from 'cnd2' cluster, so it
>    resides there. Should be moved, likely to 'platform' cluster?

That's the genral consensus (I think)
But we have to have real and reviewed API's for that to go through.

> - DEL works like BS (backspace), BS does not work. Likely known issue,
>    just can't find anything in the wiki. Any hint?

My first guess ...
Believe it or not the default unix key binding is as above.
Most of us put something like this into out .logins:
        stty sane erase ^H kill ^U intr ^C susp ^Z werase ^? eof ^D
                        ^^
                        BS
                       
Issue "stty -a" and see what's bound to 'erase'.


>
> Other comments:
> - terminal emulator vs. output window
>    - this is not issue for me at all. TE tabs in the separate windows is
>      minor issue, almost no issue at all from the user's point of view.


I tend to agree.
The existing output window has catered overtly to "output", it
can handle lots of it, it ignored input etc.
Perhaps separating "output" from "interactive" makes more sense for
the time being.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tor Norbye]

On Jun 25, 2008, at 7:31 AM, Martin Krauskopf wrote:

> If it will be release as a stable module we would harness it from the
> Ruby on several places:
>
> - irb (Ruby console)
> - jirb (no more pain for handling those two separately)
> - Rails console
> - debugger console once it is implemented

In addition to this list, I think we should also run the output from:
- Test execution, especially RSpec
- Rails Server output, especially Mongrel
through the terminal emulator.

The reason for that is that both of these emit terminal escape  
sequences to colorize the output.  In the case of the Rails Server, it  
will colorize all the activerecord database SQL calls in the log. In  
the case of RSpec, it uses colors to distinguish failed (red) from  
succeeding error summaries.

-- Tor


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ivan Soleimanipour]

How important ic ^C in all of these?

See http://wiki.netbeans.org/NetbeansStartupAndCtlC

> From tor.norbye@... Thu Jun 26 09:33:32 2008
> Date: Thu, 26 Jun 2008 09:33:22 -0700
> From: Tor Norbye <tor.norbye@...>
> Subject: Re: Term and JNA-based pty demo code is here
> To: dev@...
> Cc: Ivan Soleimanipour <ivan@...>, Jiri.Kovalsky@...,
>         Mark.Dey@..., ankur@...,
>         David Van Couvering <David.Vancouvering@...>
>
> On Jun 25, 2008, at 7:31 AM, Martin Krauskopf wrote:
>
> > If it will be release as a stable module we would harness it from the
> > Ruby on several places:
> >
> > - irb (Ruby console)
> > - jirb (no more pain for handling those two separately)
> > - Rails console
> > - debugger console once it is implemented
>
> In addition to this list, I think we should also run the output from:
> - Test execution, especially RSpec
> - Rails Server output, especially Mongrel
> through the terminal emulator.
>
> The reason for that is that both of these emit terminal escape  
> sequences to colorize the output.  In the case of the Rails Server, it  
> will colorize all the activerecord database SQL calls in the log. In  
> the case of RSpec, it uses colors to distinguish failed (red) from  
> succeeding error summaries.
>
> -- Tor
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Martin Krauskopf]

Ivan Soleimanipour wrote:
 >> From Martin.Krauskopf@... Wed Jun 25 07:32:33 2008
 >>
 >> Ivan Soleimanipour wrote:
 >>> http://wiki.netbeans.org/TerminalEmulator
 >> Hi Ivan,
 >>
 >> I've tried Terminal Emulator (TE) as NetBeans module on Ubuntu and
 >> just work out-of-the-box. Quite impressive. Once tried, this it's
 >> just must have feature ;)
 >>
 >> So are there any specific plans about the way it will be released for
 >> 6.5. Likely it depends on the multi-platform availability/stability.
 >>
 >
 >   I had made no plans. I was waiting a for some sort of thumbs-up and
 >   you seem to have just raised yours.
 >
 >   As for platforms:
 >   - David V. and I are going to get together on Thu and try and get it
 >     working on the Mac.
 >   - JNA is not available on Solaris 9. When I contacted the JNA folks
 >     they said "scratch your own itch".

I believe that it would not be a big issue, if Solaris 9 is not
supported since the first version. Likely 1/100 of NetBeans users are on
Solaris 9 (my optimistic guess).

 >> If it will be release as a stable module
 >
 >   There are several layers to this thing.
 >   - plain dumb terminal emulator, and existing NB module.
 >   - pty library. Only gives access to pty's and helps start processes
 >     under them. One could in principle use this layer to start a
 >     process with a pty and then connect it to an output2 I/O tab. The
 >     thing to do with this is to make it be a service with a JNA base
 >     provider and a JNI based provider. I'd have to adapt sunstudio's
 >     JNI code to work with this.
 >   - A "convenience" way of starting as shell (termsupport.TermShell)
 >   - A "terminwal window" analogous, and for the time being separate,
 >     from the I/O window with all the condiments: options, search,
 >     redirect to file ...
 >
 >    So there's a lot of stuff still to be designed, API-reviewed and so
 >    on.

What about to start with Friend API. You can choose your friends ;) Ruby
would be one. Then no big API review is needed in the beginning. As
starting point this would be enough:

- API for:
   - running 'normal' Shell as your demo shows. Client would call e.g.:

       TermShell shell = new TermShell("/home/joe");
       shell.start(); // or #open, would open and start a shell in new
                      // tab in Terminal Emulator Window

   - running "terminal window" as you described above, e.g.:

       TermWindow cat = new TermWindow();
       cat.run("/bin/cat /proc/cpuinfo");

   - hyper-linking capability as Output Window have (rather nice to have
     in the beginning)

   - likely more, would appear on the way as Friend are using it.

 >    It would help to know in more detail exactly what the following
 >    applications are ...

I'm not sure why. But if you install Ruby for your OS, just run 'irb'.
But they are normal tools using readline, so any readline tool is enough
for simulation of what we need.

 >    I'll see if I can grill David tomorrow. Otherwise, if someone in
 >    the ruby team is in MPK, please come and give me a demo of all
 >    these items Martin mentions:

Again those are just specific cases. I think that e.g. gdb is good tool
to test on or whatever tool you are familiar with. The bellow are not
specific in anything, I believe.

--%<--
 >    I can't answer you yet .. I need to gauge the work, it's impedance
 >    match to it's usage, compare against 6.5 calendar and see if my
 >    manager (on the cc list :-) will let me focus on this %100.

I hope so ;)

 >> Now to some issue I've encountered:
 >> - terminal emulator was utilized so far only from 'cnd2' cluster, so
 >>   it resides there. Should be moved, likely to 'platform' cluster?
 >
 > That's the genral consensus (I think)
 > But we have to have real and reviewed API's for that to go through.

Again I don't think the public API is needed for 6.5. Let's start with
Friend one, than stabilize it during 7.0 (or whatever next release will
be) development and when we feel that it is good enough, being harnessed
by Ruby (and other joined Friend) for sometime, let's do the full API
review.

Until then just tell your Friends, I'm going to changed this API, be
ready to change your client code. That's Friend contract.

 >> - DEL works like BS (backspace), BS does not work. Likely known
 >>   issue, just can't find anything in the wiki. Any hint?
 >
 > My first guess ...
 > Believe it or not the default unix key binding is as above.
 > Most of us put something like this into out .logins:
 > stty sane erase ^H kill ^U intr ^C susp ^Z werase ^? eof ^D
 >                ^^
 >                BS
 >
 > Issue "stty -a" and see what's bound to 'erase'.

Ah, thanks, that helped. I've in all terms (rxvt-unicode, xterm, asni
(in Terminal Emulator)):

   erase = ^?

If I set it to:

   stty erase \^H

In xterm and rxvt-unicode, ^H started to work, but BS stoped to work
(something I want to solve my self).

But in the 'ansi' in TE, BS and ^H both works then after 'erase' is set
as above.
Would be bad if everybody with Ubuntu has to do so. But might be my
weird setup, not using 'bundled' Gnome, using Fluxbox with rxvt, kind of
'imported' configuration from my before-ubuntu-distro Slackware, so
default Ubuntu setup might work.

   m.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Martin Krauskopf]

Ivan Soleimanipour wrote:
> How important ic ^C in all of these?
>
> See http://wiki.netbeans.org/NetbeansStartupAndCtlC

I tend to say it is important, but do not want it to be blocker if it is
not feasible to implement it :)

 From time to time I run something, immediately the 'ouch' moment came,
^C^C^C^C follows :) But usually nothing dangerous, just e.g. 'find' in
large directory tree and similar long-running, resources-consuming
tasks. So would be great to have ^C issue solved.

But YMMV and I can live without it, I think, using 'kill' in other term.

        m.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ivan Soleimanipour]

> From Martin.Krauskopf@... Fri Jun 27 02:15:51 2008


TE should now reasonably limp along on Mac OS.
See http://wiki.netbeans.org/TerminalEmulatorOnMac for issues.
       

>  >   - JNA is not available on Solaris 9. When I contacted the JNA folks
>  >     they said "scratch your own itch".
>
> I believe that it would not be a big issue, if Solaris 9 is not
> supported since the first version. Likely 1/100 of NetBeans users are on
> Solaris 9 (my optimistic guess).

The way it becomes an issue is as follows.
I'd like to wean SunStudio off of JNI, but since SunStudio has to run on
Solaris9 I have three options:
- get JNA to work on S9 ... and convince the release tzars that depending
  on JNA is OK (I'm not quite sure of that).
- get TermSupport to become a service with two providers:
  - JNA-based satisfied by TermSupport itself.
  - JNI-based satisfied by SunStudio modules.
  The fact that TermSupport is aimed to be a non-module library will
  complicate this.
- Have SunStudio continue as it does today and do the above fancy stuff later.

I guess we'll have to proceed with the last version.

>
> What about to start with Friend API. You can choose your friends ;) Ruby
> would be one. Then no big API review is needed in the beginning.

OK.

I remember you had asked me earlier whetehr you should start switching
your code to use the TE.

I recommend keeping both variations around and dynamically switchable.
Until TE proves itself in actual use.


> As
> starting point this would be enough:
>
> - API for:
>    - hyper-linking capability as Output Window have (rather nice to have
>      in the beginning)

Well, i've had some thoughts on this.
The .../lib.terminalemulator/demosrc/buildtool demo, and the way Term
was integrated into output[1] all work by calling the ActiveTerm API's
directly. See BuildTool.process_line().

I also remember seeing some api reviews going by to improve output
handling and such.

However, I'd like to do hyperlinks in a way that differs from the above.
It will require these parts:

- Extend the ANSI escape sequence interpreter to understand a specialized
  sequence like this:
  <HB>Click on me!<HM>cookie-for-click-on-me<HE>
  where
  <HB> is an ANSI-like espace sequence to note hyperlink beginning.
       Such sequences usually begin with  (aka ESC).
  <HM> is ... to note middle of hyperlink
  <HE> is ... to note end of hyperlink.
  "cookie-for-click-on-me" is a "URL"
  This will render "Click on me!" in a hyperlink rendition.
 
- Register a listener such that when the above hyperlink is clicked
  the listener is called with "cookie-for-click-on-me" as a parameter
  and can dispatch as it needs to.
 
- Install a filter to recognize "error messages" or whatever and
  pass the text on but surrounded with the abovementioned <HB>, <HM> and
  <HE>.
 

>  >> - DEL works like BS (backspace), BS does not work. Likely known
>  >>   issue, just can't find anything in the wiki. Any hint?
>  >
>  > My first guess ...
>  > Believe it or not the default unix key binding is as above.
>  > Most of us put something like this into out .logins:
>  > stty sane erase ^H kill ^U intr ^C susp ^Z werase ^? eof ^D
>  >                ^^
>  >                BS
>  >
>  > Issue "stty -a" and see what's bound to 'erase'.
>
> Ah, thanks, that helped. I've in all terms (rxvt-unicode, xterm, asni
> (in Terminal Emulator)):
>
>    erase = ^?

This doesn't have to do with you terminals but your systems
default shell setup and/or login processes.

>
> If I set it to:
>
>    stty erase \^H
>
> In xterm and rxvt-unicode, ^H started to work, but BS stoped to work
> (something I want to solve my self).
>
> But in the 'ansi' in TE, BS and ^H both works then after 'erase' is set
> as above.

When you talk about rxvt-unicode vs xterm vs ansi ...
Are you just setting your $TERM in your shell?
        unless you're using some fancy tset-dependent macro this shouldn't
        affect things.
        TE thinks it's ansi and that's that.
        It set $TERM when it starts and if you change $TERM then you'll
        be having apples talking to oranges.
Or are you setting the terminal type using the TE API?
        In this case if you set it to something it doesn't recognize
        you'll get a "dumb" terminal with reduced features.
        Although even this one should take BS


> > How important ic ^C in all of these?
> >
> > See http://wiki.netbeans.org/NetbeansStartupAndCtlC
>
> I tend to say it is important, but do not want it to be blocker if it is
> not feasible to implement it :)
>

A havun't spent time on how one can rearrange NB startup to make this
problem go away.
Another way to solve this is to have pty_bind, the helper shell
application, be a native application and restore the SIGINT handler.

        There's another reason to have a native version of pty_bind
        and that is that Mac OS doesn't have shell commands to help with
        process groups and such. (W/o these you can't do ^Z).

> But YMMV and I can live without it, I think, using 'kill' in other term.

I think you'll find that yo depend on ^C more often than you think.

Note that "kill -s sigint" won't work. Not that anyone insist on
using -s sigint :-)
It's not that processing of the ^C character is broken, it's that
"any child process of NB will ignore SIGINT".

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...