jedit-devel Mailing List for jEdit

Plugin Feature Requests item #3539135, was opened at 2012-06-30 04:07
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3539135&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console: possibility to run the process in the background

Initial Comment:
At the moment ( r21890 ) Console ignores the parameter "&" at the end of the command line: this feature is blocked.
See Plugin Bug #3539123.

Is it the necessary feature for somebody?

----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2012-06-30 15:32

Message:
The possibility to run processes in the background existed before you made
any changes. NPEs were only thrown when you ran processes that were
short-lived and also had output. 

I don't know what your feature request is for.
Is it to see the errors of the bg processes? That's ok with me.
I don't really want/care about stdout of bg processes sent to the jedit
console.


----------------------------------------------------------------------

Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 14:36

Message:
OK, but I do not want see any outputs except errors. And you?

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-30 12:45

Message:
I think what your feature request should read is "possiblity to see output
of background processes in console".


----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-30 12:43

Message:
It works still for me, and I do use it.
What seems to have changed with your recent commit is that if I run "xeyes
&", i see the "i'm working" spinner go, whereas before I did not. But if I
hit return, I get the prompt as I expect, and I can run other commands. So
the option is not disabled (yet).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3539135&group_id=588

W dniu 06/30/2012 10:22 PM, Marcelo Vanzin pisze:
> On Sat, Jun 30, 2012 at 1:14 PM, Dale Anson <da...@gr...> wrote:
>> I agree with Vampire - there doesn't seem to be a problem with the current
>> system. He's been a part of jEdit for as long as I can remember and I trust
>> him to do the right thing with the project and the money.
> +1. Don't fix what is not broken.
>

Marcelo, Dale. If you speak in the subject of donations, please also 
give your opinion about the real issue. Choose one:
1) we should collect the money infinitely, just in case
2) we should stop donations, because we don't see any goal for them

And more:
3) we should talk about money in small group of people, because ...
4) we don't have any secrets about money, let's talk publicly about them

In oss project everything should be public, unless there is a reason to 
keep it secret. I don't see any serious argument against talking about 
money on this forum.

Vampire is afraid about possible voices: "hey, there you could have 
something similar for less money". I am not afraid of that. I would be 
glad if someone told me that I could spend the public money better. I am 
glad if anyone tells me that I could do anything better than I did. I am 
here to learn, not to stay wrong forever.

Why did I started talking about money? Because there were tendencies to 
speak about money in admin group. No-one could however explain why these 
things must stay secret. Probably we tend to treat money as taboo.

Jarek

Plugin Feature Requests item #3539135, was opened at 2012-06-30 04:07
Message generated for change (Comment added) made by synh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3539135&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console: possibility to run the process in the background

Initial Comment:
At the moment ( r21890 ) Console ignores the parameter "&" at the end of the command line: this feature is blocked.
See Plugin Bug #3539123.

Is it the necessary feature for somebody?

----------------------------------------------------------------------

>Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 14:36

Message:
OK, but I do not want see any outputs except errors. And you?

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-30 12:45

Message:
I think what your feature request should read is "possiblity to see output
of background processes in console".


----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-30 12:43

Message:
It works still for me, and I do use it.
What seems to have changed with your recent commit is that if I run "xeyes
&", i see the "i'm working" spinner go, whereas before I did not. But if I
hit return, I get the prompt as I expect, and I can run other commands. So
the option is not disabled (yet).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3539135&group_id=588

Plugin Bugs item #3539123, was opened at 2012-06-30 02:49
Message generated for change (Comment added) made by synh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Later
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Artem Bryantsev (synh)
Summary: Console: NPE when command starts in background

Initial Comment:
Execution "some_command &" or "some_command&" leads to NPE:

[Thread-7] [error] Thread-7: Exception in thread "Thread-7" 
[Thread-7] [error] Thread-7: java.lang.NullPointerException
[Thread-7] [error] Thread-7:  at console.ConsoleProcess.showExit(ConsoleProcess.java:156)
[Thread-7] [error] Thread-7:  at console.ConsoleProcess$1.run(ConsoleProcess.java:111)
[Thread-8] [error] StreamThread: Can't Flush:
[Thread-8] [error] StreamThread: java.lang.NullPointerException
[Thread-8] [error] StreamThread:  at console.StreamThread.flushLine(StreamThread.java:217)
[Thread-8] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:130)

- Linux 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
- java version "1.6.0_24"
  OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu3)
  OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
- jEdit 04.05.99.02, Console 4.5 + "-nosettings"

and...

[Thread-6] [error] StreamThread: Can't Flush:
[Thread-6] [error] StreamThread: java.lang.NullPointerException
[Thread-6] [error] StreamThread:  at console.StreamThread.printString(StreamThread.java:332)
[Thread-6] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:212)
             
- jEdit 05.01.01.00, Console 5.0

The problem is that there is no implementation for processes running in the background, in the module ConsoleProcess.java.
If the process starts in the background - Console does not establish Output for such process, and then prints the output from it as from the usual process.

----------------------------------------------------------------------

>Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 14:35

Message:
I did not suppose that can run interactive (gui) apps in this way. To my
mind "run in the background" equals "create a daemon-process".
But I still get NPE when _close_ gui app (if there is not my changes in the
code).

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-30 12:32

Message:
Actually, I can still run gui apps in the background with console, so it's
ok.


----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-30 11:33

Message:
Running some processes in the background, such as GUI apps (I run okular or
xeyes from Console, for example), it works fine. The only issue is when the
background process writes to stdout immediately and exits, and that's when
you get that NPE. Since nobody ever would run such a program in the
background (because we can't see the output anyway), your use case is quite
unusual.  Mine is more common and worked before you made your change.


----------------------------------------------------------------------

Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 04:10

Message:
Opened the ticket for the implementation of this feature. See Plugin
Feature Requests #3539135.

----------------------------------------------------------------------

Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 03:16

Message:
Blocked the possibility to run the process in the background - r21890

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

In my opinion initial code was not safe, because this is not completed and  
invokes NullPointer Exceptions.

I could not remove this functionality: probably somebody uses it (I did  
not know how).
I did not want to fix this code: it seems old and probably nobody uses it.
And I only disabled this functionality and created tickets at the tracker.


Kazutoshi Satoda <k_s...@f2...> писал(а) в своём письме Sat, 30  
Jun 2012 20:56:19 +0300:

> sy...@us... wrote:
>> Revision: 21890
>>            http://jedit.svn.sourceforge.net/jedit/?rev=21890&view=rev
>> Author:   synh
>> Date:     2012-06-30 10:03:36 +0000 (Sat, 30 Jun 2012)
>> Log Message:
>> -----------
>> #3539123 - Console: NPE when command starts in background.
>
>> -		if (foreground)
>> -		{
>> +		//if (foreground)
>> +		//{
>>   			this.output = output;
>>   			this.error = new ErrorOutput(console);
>>   			this.consoleState = consoleState;
>> -		}
>> +		//}
>
> Please remove them, or leave more comment why the code should be left as
> such.
>

-- 
Best regards, Artem Bryantsev

On Sat, Jun 30, 2012 at 1:14 PM, Dale Anson <da...@gr...> wrote:
> I agree with Vampire - there doesn't seem to be a problem with the current
> system. He's been a part of jEdit for as long as I can remember and I trust
> him to do the right thing with the project and the money.

+1. Don't fix what is not broken.

-- 
Marcelo Vanzin
mmv...@gm...
"Life's too short to drink cheap beer."

I agree with Vampire - there doesn't seem to be a problem with the current
system. He's been a part of jEdit for as long as I can remember and I trust
him to do the right thing with the project and the money.

I particularly agree with this:

"I really like jEdit to be driven solely by idealists and maniacs and want
to keep it like that. :-)"

Yeah, that's the spirit!

Dale
On Jun 30, 2012 10:46 AM, "Vampire" <Va...@je...> wrote:

>
> 2012/6/18 Jarek Czekalski <jar...@po...>
>
>> First I think there should be the least possible money affairs involved
>> in the project, as it is likely to conflict people and draw their
>> attention to things that are against the spirit of voluntarity.
>>
>
> How do you define this?
> Up to now there was no conflict because of money.
> I am the "treasurer", collecting and managing the donations.
> If there would be expenses like for domain, server, ... I would pay them
> from the donation money and if contracts need to be made e. g. some domain
> or server rental, I would close that contract and up to a certain level
> even bridge money shortages if donations are too low, just because I love
> jEdit. That was also the reason I revived the project together with Alan
> and some more.
> That is how it is currently and there were no problems at all up to now.
>
>
>> 1. Project's money should be public as with public money belonging to
>> governments, cities, etc. I suggest google spreadsheet in which yearly
>> incomes and incomes would be put.
>>
>
> I'm not sure this is really a good idea. Does really the whole world need
> to know what money we have and what we do with it?
> With governments, cities and so on it is something completely different.
> There you are forced to pay taxes which have to be spent again for the
> people that had to give the money and thus also have a right to know what
> happened to the money you were forced to give.
> If you like someone or something and because of that donate money to him /
> it so that he can use it for whatever he / it does is in my opinion
> something compeltely different. If someone wants to control what happened
> to her money, she can donate the money with some usage restrictions which
> would force us to use that money only for the designated purpose. Money
> donated to some person or project, can be used by the receiver in any way
> he wants. It can be used to by some ice, or to pay some bills, further
> donated to some great other thing like FSF or EFF, or used for the project
> that caused the donation to happen which is how we plan to use the money. I
> don't think that this should be really made public, because then you may
> also use time that could be used to bring forward jEdit, instead to justify
> the decisions and deals you made like "hey, there you could have something
> similar for less money" and stuff like that. In my opinion this is a topic
> that should stay inside the main project members.
>
>
>> 2.
>> Project needs for each year should be calculated and money for the needs
>> collected. It would be good to have some reserve in case we need
>> dedicated hosting or whatever.
>> I suggest:
>> reserve_limit = 5 x (one year expenses)
>> After the reserve limit is reached, donations are suspended. If after an
>> expense, or due to other reasons, the reserve is less then this limit,
>> donations are switched back on.
>>
>
> I don't think this is a good idea.
> What would this be good for?
> Just to not have a too high reserve?
> Sorry, but I think that does not make too much sense.
> A reserve is good, the higher the better.
> If we e. g. need some lawyer because whatever, maybe some copyright
> infringement accuses, it would maybe be good to have some reserve to be
> able to pay this, or whatever. But to switch off donations, just because
> the stack is too high does make no sense at all in my opinion.
> Also as far as I remember, each project admin has to opt-in manually to
> re-activate donations which is an unnecessary administration overhead.
> If we really all together think at some point in time that our stack is
> too high, we still have the option to donate the money further to some
> related organization like FSF or EFF to support these.
> But preventing people that want to donate from donating, just because the
> stack is too high does not make sense for me.
>
>
>> 3. In periods when the project does not accept donations (reserves are
>> fulfilled), donators may donate only individually to developers
>> accepting donations.
>>
>
> If I as user want to donate to a project to support that project, I want
> to donate to that project and not to some indiviual developer of that
> project. As user I don't know to which member of the project I want to
> donate the money. If there is some special function that makes me donate,
> I'd first have to find out who made the most work for that feature and
> maybe donate to that project member. But I as user wouldn't put that effort
> in. Or maybe I just like the whole picture and don't want to donate just to
> one developer, but also not to each individually, but to the project, to
> support the project. If the project then tells me "hey, we have enough
> money, go away and come back when we need some more money" I'd say f*** you
> project, I love you but I will never consider donating again as you are
> rich enough to deny my 5 USD I was willing to spend to you. Or that user
> starts a big disussion why donations are not activated and how he can
> donate which again draws resources away from the real work that brings
> jEdit forwards.
>
> 4. No sharing of the money between admins, devs as a reward.
>>
>
> I fully agree and always also represented this opinion when this topic
> came up.
> I like the project to stay driven by people that just do it because they
> love jEdit and not because they get some money for it.
> I really like jEdit to be driven solely by idealists and maniacs and want
> to keep it like that. :-)
>
> 5. If there is excess money relatively to needs, anyone is welcome to
>> suggest a way of spending the money, that would encourage gifted
>> programmers to join open source projects, with the focus on our project.
>>
>
> I'm not sure what you mean by this. Do you want to set out bountys for
> work on jEdit to make people aware of jEdit and hope they keep working on
> it even if they don't get any more money for it?
> I don't think things like that will work and am strictly against such
> thing as it would also draw as away from being driven by idealists and
> maniacs like desribed above. ;-)
>
> In my opinion there will never be excess money, but just a reserve that is
> higher or not so high and that may be used for unexpected expenses or
> additional services.
>
> Best Regards
> Björn "Vampire" Kautler
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

Plugin Feature Requests item #3539135, was opened at 2012-06-30 04:07
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3539135&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console: possibility to run the process in the background

Initial Comment:
At the moment ( r21890 ) Console ignores the parameter "&" at the end of the command line: this feature is blocked.
See Plugin Bug #3539123.

Is it the necessary feature for somebody?

----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2012-06-30 12:45

Message:
I think what your feature request should read is "possiblity to see output
of background processes in console".


----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-30 12:43

Message:
It works still for me, and I do use it.
What seems to have changed with your recent commit is that if I run "xeyes
&", i see the "i'm working" spinner go, whereas before I did not. But if I
hit return, I get the prompt as I expect, and I can run other commands. So
the option is not disabled (yet).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3539135&group_id=588

Plugin Feature Requests item #3539135, was opened at 2012-06-30 04:07
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3539135&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console: possibility to run the process in the background

Initial Comment:
At the moment ( r21890 ) Console ignores the parameter "&" at the end of the command line: this feature is blocked.
See Plugin Bug #3539123.

Is it the necessary feature for somebody?

----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2012-06-30 12:43

Message:
It works still for me, and I do use it.
What seems to have changed with your recent commit is that if I run "xeyes
&", i see the "i'm working" spinner go, whereas before I did not. But if I
hit return, I get the prompt as I expect, and I can run other commands. So
the option is not disabled (yet).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3539135&group_id=588

Plugin Bugs item #3539123, was opened at 2012-06-30 02:49
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Later
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Artem Bryantsev (synh)
Summary: Console: NPE when command starts in background

Initial Comment:
Execution "some_command &" or "some_command&" leads to NPE:

[Thread-7] [error] Thread-7: Exception in thread "Thread-7" 
[Thread-7] [error] Thread-7: java.lang.NullPointerException
[Thread-7] [error] Thread-7:  at console.ConsoleProcess.showExit(ConsoleProcess.java:156)
[Thread-7] [error] Thread-7:  at console.ConsoleProcess$1.run(ConsoleProcess.java:111)
[Thread-8] [error] StreamThread: Can't Flush:
[Thread-8] [error] StreamThread: java.lang.NullPointerException
[Thread-8] [error] StreamThread:  at console.StreamThread.flushLine(StreamThread.java:217)
[Thread-8] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:130)

- Linux 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
- java version "1.6.0_24"
  OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu3)
  OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
- jEdit 04.05.99.02, Console 4.5 + "-nosettings"

and...

[Thread-6] [error] StreamThread: Can't Flush:
[Thread-6] [error] StreamThread: java.lang.NullPointerException
[Thread-6] [error] StreamThread:  at console.StreamThread.printString(StreamThread.java:332)
[Thread-6] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:212)
             
- jEdit 05.01.01.00, Console 5.0

The problem is that there is no implementation for processes running in the background, in the module ConsoleProcess.java.
If the process starts in the background - Console does not establish Output for such process, and then prints the output from it as from the usual process.

----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2012-06-30 12:32

Message:
Actually, I can still run gui apps in the background with console, so it's
ok.


----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-30 11:33

Message:
Running some processes in the background, such as GUI apps (I run okular or
xeyes from Console, for example), it works fine. The only issue is when the
background process writes to stdout immediately and exits, and that's when
you get that NPE. Since nobody ever would run such a program in the
background (because we can't see the output anyway), your use case is quite
unusual.  Mine is more common and worked before you made your change.


----------------------------------------------------------------------

Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 04:10

Message:
Opened the ticket for the implementation of this feature. See Plugin
Feature Requests #3539135.

----------------------------------------------------------------------

Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 03:16

Message:
Blocked the possibility to run the process in the background - r21890

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

Bugs item #3539186, was opened at 2012-06-30 12:24
Message generated for change (Tracker Item Submitted) made by vanza
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3539186&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marcelo Vanzin (vanza)
Assigned to: Nobody/Anonymous (nobody)
Summary: Shortcuts to Console Commando scripts don't work at startup

Initial Comment:
I'm not sure whether this is a bug in jEdit or Console, so starting with jEdit.

I have some shortcuts assigned to Console Commando scripts. Just for the sake of illustration, I assigned "CTRL-m a" to run the "ant" script.

When I start jEdit, that shortcut does not work. Other shortcuts work fine (e.g., in my configuration, hitting "CTRL-m s" brings ProjectViewer's search dialog just fine).

If I go into the jEdit Options dialog and just click OK, not changing anything, then the Command shortcut starts working.

I wonder if there's a race during initialization; since Commandos are a dynamic list, I wonder if jEdit is setting up the shortcuts before Console has had a chance to initialize. Or something.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3539186&group_id=588

Plugin Bugs item #3539123, was opened at 2012-06-30 02:49
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Later
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Artem Bryantsev (synh)
Summary: Console: NPE when command starts in background

Initial Comment:
Execution "some_command &" or "some_command&" leads to NPE:

[Thread-7] [error] Thread-7: Exception in thread "Thread-7" 
[Thread-7] [error] Thread-7: java.lang.NullPointerException
[Thread-7] [error] Thread-7:  at console.ConsoleProcess.showExit(ConsoleProcess.java:156)
[Thread-7] [error] Thread-7:  at console.ConsoleProcess$1.run(ConsoleProcess.java:111)
[Thread-8] [error] StreamThread: Can't Flush:
[Thread-8] [error] StreamThread: java.lang.NullPointerException
[Thread-8] [error] StreamThread:  at console.StreamThread.flushLine(StreamThread.java:217)
[Thread-8] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:130)

- Linux 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
- java version "1.6.0_24"
  OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu3)
  OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
- jEdit 04.05.99.02, Console 4.5 + "-nosettings"

and...

[Thread-6] [error] StreamThread: Can't Flush:
[Thread-6] [error] StreamThread: java.lang.NullPointerException
[Thread-6] [error] StreamThread:  at console.StreamThread.printString(StreamThread.java:332)
[Thread-6] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:212)
             
- jEdit 05.01.01.00, Console 5.0

The problem is that there is no implementation for processes running in the background, in the module ConsoleProcess.java.
If the process starts in the background - Console does not establish Output for such process, and then prints the output from it as from the usual process.

----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2012-06-30 11:33

Message:
Running some processes in the background, such as GUI apps (I run okular or
xeyes from Console, for example), it works fine. The only issue is when the
background process writes to stdout immediately and exits, and that's when
you get that NPE. Since nobody ever would run such a program in the
background (because we can't see the output anyway), your use case is quite
unusual.  Mine is more common and worked before you made your change.


----------------------------------------------------------------------

Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 04:10

Message:
Opened the ticket for the implementation of this feature. See Plugin
Feature Requests #3539135.

----------------------------------------------------------------------

Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 03:16

Message:
Blocked the possibility to run the process in the background - r21890

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

(Resending for Artem, since the mail alias sy...@us...
seems not enabled to accept mails from outside of sourceforge.net)

sy...@us... wrote:
> Revision: 21890
>            http://jedit.svn.sourceforge.net/jedit/?rev=21890&view=rev
> Author:   synh
> Date:     2012-06-30 10:03:36 +0000 (Sat, 30 Jun 2012)
> Log Message:
> -----------
> #3539123 - Console: NPE when command starts in background.

> -		if (foreground)
> -		{
> +		//if (foreground)
> +		//{
>   			this.output = output;
>   			this.error = new ErrorOutput(console);
>   			this.consoleState = consoleState;
> -		}
> +		//}

Please remove them, or leave more comment why the code should be left as
such.

-- 
k_satoda

sy...@us... wrote:
> Revision: 21890
>            http://jedit.svn.sourceforge.net/jedit/?rev=21890&view=rev
> Author:   synh
> Date:     2012-06-30 10:03:36 +0000 (Sat, 30 Jun 2012)
> Log Message:
> -----------
> #3539123 - Console: NPE when command starts in background.

> -		if (foreground)
> -		{
> +		//if (foreground)
> +		//{
>   			this.output = output;
>   			this.error = new ErrorOutput(console);
>   			this.consoleState = consoleState;
> -		}
> +		//}

Please remove them, or leave more comment why the code should be left as
such.

-- 
k_satoda

Patches item #3531515, was opened at 2012-06-02 04:51
Message generated for change (Comment added) made by k_satoda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=3531515&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Meyer (thomasmey)
Assigned to: Kazutoshi Satoda (k_satoda)
Summary: Compact Remove&Insert Edits into a Replace Edit

Initial Comment:
This helps to save some memory for the search&replace-all case as only one instead of two objects are stored in memory.

----------------------------------------------------------------------

>Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-30 10:51

Message:
Your new approach (v5) assumes that the most of offsets of occurrences
are in a equal distance. But I don't see any reason to assume that
happens to be.

In contrast, many replace with same contents on arbitrary offsets likely
happens with replace-all. So compressing them into an array of offsets
sounds reasonable.

I think we should finish v4 as a certain step, and separate further
compression as another patch.

Could you please update v4 for the latest trunk, and give a measure,
change entry, and log message?

----------------------------------------------------------------------

Comment By: Thomas Meyer (thomasmey)
Date: 2012-06-28 14:41

Message:
Another approach to compress n Replace into a CompressedReplace. It works
great for my test case... But I don't know how this will scale in general
case. what do you think. Measurements, log message and change entry to
follow.


----------------------------------------------------------------------

Comment By: Thomas Meyer (thomasmey)
Date: 2012-06-10 01:59

Message:
Updated patch attached. Please have a look at it and tell me what do you
think of it?

with kind regards
thomas

----------------------------------------------------------------------

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-09 03:36

Message:
Please consider to describe the purpose (optimize the memory usage for
large number of replace) of the folding as appropriate comments.

Same type checks and casts are repeated at caller and inside of
getReplaceFromRemoveInsert(). They should not be repeated for both code
quality and performance.

----------------------------------------------------------------------

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-09 03:21

Message:
>> As long as only the sequence Remove+Insert is compacted into a replace,
>> this is not necessary.
>
> With the current implementation, I'm afraid of every contentInserted()
> after a folding will create a new instance of Insert and increase memory
> usage.

Sorry I just realized that I was wrong. The waste will be merely one
Insert not merged. Now I agree it is not necessary in favor of code
simplicity.

----------------------------------------------------------------------

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-09 03:16

Message:
> 1.) "The folding should be delayed until ..."
> As long as only the sequence Remove+Insert is compacted into a replace,
> this is not necessary.

With the current implementation, I'm afraid of every contentInserted()
after a folding will create a new instance of Insert and increase memory
usage.

Now I found the problem can be solved by an easier way; considering
Replace as a merge target in contentInserted() as same as Insert.

> 2.) ... we should check more; lastElement == redoClearDirty,
> These other conditions cannot happen.

Ah, I understood. Then some comments and/or assertions will be enough to
connect the code and the comment just above it.

> 3.) "Replace can't be undoClearDirty nor redoClearDirty.
> Replace can become a redoClearFirst candidate:

Thank you for the steps to hit the assertion. I understood.

Now I wonder why every Edit has to do the check in it. If the check can
be moved into UndoManager.undo/redo(), it seems more straightforward. If
you or someone find problems to do that, I'll move them as another
separate commit so that this patch won't be bothered by this issue.

----------------------------------------------------------------------

Comment By: Thomas Meyer (thomasmey)
Date: 2012-06-07 08:56

Message:
Hi,

1.) "The folding should be delayed until ..." in my previous comment still
apply."

As long as only the sequence Remove+Insert is compacted into a replace,
this is not necessary.

2.) "At if(lastElement == undoClearDirty) in checkIfReplacement(), we
should
check more; lastElement == redoClearDirty, newElement == ..."

These other conditions cannot happen.

3.) "Replace can't be undoClearDirty nor redoClearDirty. Thus the check in
undo() and redo() is unnecessary. Putting assert() may be reasonable."

Replace can become a redoClearFirst candidate:
1. Create a new File
2. Enter "1234567890123"
3. Save
4. Replace "123" -> "abc"
5. Save -> Replace becomes redosClearDirty
6. Undo
7. Redo -> Assertion hit.

4.) "The return value of Replace.undo() and redo() looks wrong. Please
verify
that they return the same value with the case not folded."

Fixed.

5.) "The added field mgr in CompoundEdit is redundant. You can get
UndoManager after casting the folding Edits."

Fixed

6.) "The semantics of the return value of checkIfReplacement() is vague.
How about returning null if it can't fold? In that case the name can
be getReplaceFromRemoveInsert() and the type can be just Replace.
This change will also remove rcEdit which looks unnecessary."

Fixed.

7.) "Inconsistent spacing: edit=replacement;"

Fixed.

8.) "Strange empty line at the beginning of dropLastElement() body."

Fixed.

----------------------------------------------------------------------

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-06 11:28

Message:
I have looked through the patch. Please revise the patch for the
following comments. Please assume "It looks like ..." for each comment.

"The folding should be delayed until ..." in my previous comment still
apply.

At if(lastElement == undoClearDirty) in checkIfReplacement(), we should
check more; lastElement == redoClearDirty, newElement == ...

Replace can't be undoClearDirty nor redoClearDirty. Thus the check in
undo() and redo() is unnecessary. Putting assert() may be reasonable.

The return value of Replace.undo() and redo() looks wrong. Please verify
that they return the same value with the case not folded.

The added field mgr in CompoundEdit is redundant. You can get
UndoManager after casting the folding Edits.

The semantics of the return value of checkIfReplacement() is vague.
How about returning null if it can't fold? In that case the name can
be getReplaceFromRemoveInsert() and the type can be just Replace.
This change will also remove rcEdit which looks unnecessary.

Inconsistent spacing: edit=replacement;

Strange empty line at the beginning of dropLastElement() body.


----------------------------------------------------------------------

Comment By: Thomas Meyer (thomasmey)
Date: 2012-06-06 08:16

Message:
New patch on top of 3528619

----------------------------------------------------------------------

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-02 06:22

Message:
The folding shouldn't be done outside compound edits because such edits
should be undo/redoable individually.

Also, if a candidate Edit is undoClearDirty or redoClearDirty, it
shouldn't be folded since the identity is significant.

The folding should be delayed until the candidates become not last one
since the last Edit maybe updated via getMergeEdit().

Would you please revise the patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=3531515&group_id=588

2012/6/18 Jarek Czekalski <jar...@po...>

> First I think there should be the least possible money affairs involved
> in the project, as it is likely to conflict people and draw their
> attention to things that are against the spirit of voluntarity.
>

How do you define this?
Up to now there was no conflict because of money.
I am the "treasurer", collecting and managing the donations.
If there would be expenses like for domain, server, ... I would pay them
from the donation money and if contracts need to be made e. g. some domain
or server rental, I would close that contract and up to a certain level
even bridge money shortages if donations are too low, just because I love
jEdit. That was also the reason I revived the project together with Alan
and some more.
That is how it is currently and there were no problems at all up to now.


> 1. Project's money should be public as with public money belonging to
> governments, cities, etc. I suggest google spreadsheet in which yearly
> incomes and incomes would be put.
>

I'm not sure this is really a good idea. Does really the whole world need
to know what money we have and what we do with it?
With governments, cities and so on it is something completely different.
There you are forced to pay taxes which have to be spent again for the
people that had to give the money and thus also have a right to know what
happened to the money you were forced to give.
If you like someone or something and because of that donate money to him /
it so that he can use it for whatever he / it does is in my opinion
something compeltely different. If someone wants to control what happened
to her money, she can donate the money with some usage restrictions which
would force us to use that money only for the designated purpose. Money
donated to some person or project, can be used by the receiver in any way
he wants. It can be used to by some ice, or to pay some bills, further
donated to some great other thing like FSF or EFF, or used for the project
that caused the donation to happen which is how we plan to use the money. I
don't think that this should be really made public, because then you may
also use time that could be used to bring forward jEdit, instead to justify
the decisions and deals you made like "hey, there you could have something
similar for less money" and stuff like that. In my opinion this is a topic
that should stay inside the main project members.


> 2.
> Project needs for each year should be calculated and money for the needs
> collected. It would be good to have some reserve in case we need
> dedicated hosting or whatever.
> I suggest:
> reserve_limit = 5 x (one year expenses)
> After the reserve limit is reached, donations are suspended. If after an
> expense, or due to other reasons, the reserve is less then this limit,
> donations are switched back on.
>

I don't think this is a good idea.
What would this be good for?
Just to not have a too high reserve?
Sorry, but I think that does not make too much sense.
A reserve is good, the higher the better.
If we e. g. need some lawyer because whatever, maybe some copyright
infringement accuses, it would maybe be good to have some reserve to be
able to pay this, or whatever. But to switch off donations, just because
the stack is too high does make no sense at all in my opinion.
Also as far as I remember, each project admin has to opt-in manually to
re-activate donations which is an unnecessary administration overhead.
If we really all together think at some point in time that our stack is too
high, we still have the option to donate the money further to some related
organization like FSF or EFF to support these.
But preventing people that want to donate from donating, just because the
stack is too high does not make sense for me.


> 3. In periods when the project does not accept donations (reserves are
> fulfilled), donators may donate only individually to developers
> accepting donations.
>

If I as user want to donate to a project to support that project, I want to
donate to that project and not to some indiviual developer of that project.
As user I don't know to which member of the project I want to donate the
money. If there is some special function that makes me donate, I'd first
have to find out who made the most work for that feature and maybe donate
to that project member. But I as user wouldn't put that effort in. Or maybe
I just like the whole picture and don't want to donate just to one
developer, but also not to each individually, but to the project, to
support the project. If the project then tells me "hey, we have enough
money, go away and come back when we need some more money" I'd say f*** you
project, I love you but I will never consider donating again as you are
rich enough to deny my 5 USD I was willing to spend to you. Or that user
starts a big disussion why donations are not activated and how he can
donate which again draws resources away from the real work that brings
jEdit forwards.

4. No sharing of the money between admins, devs as a reward.
>

I fully agree and always also represented this opinion when this topic came
up.
I like the project to stay driven by people that just do it because they
love jEdit and not because they get some money for it.
I really like jEdit to be driven solely by idealists and maniacs and want
to keep it like that. :-)

5. If there is excess money relatively to needs, anyone is welcome to
> suggest a way of spending the money, that would encourage gifted
> programmers to join open source projects, with the focus on our project.
>

I'm not sure what you mean by this. Do you want to set out bountys for work
on jEdit to make people aware of jEdit and hope they keep working on it
even if they don't get any more money for it?
I don't think things like that will work and am strictly against such thing
as it would also draw as away from being driven by idealists and maniacs
like desribed above. ;-)

In my opinion there will never be excess money, but just a reserve that is
higher or not so high and that may be used for unexpected expenses or
additional services.

Best Regards
Björn "Vampire" Kautler

Plugin Bugs item #3539123, was opened at 2012-06-30 02:49
Message generated for change (Comment added) made by synh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Later
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Artem Bryantsev (synh)
Summary: Console: NPE when command starts in background

Initial Comment:
Execution "some_command &" or "some_command&" leads to NPE:

[Thread-7] [error] Thread-7: Exception in thread "Thread-7" 
[Thread-7] [error] Thread-7: java.lang.NullPointerException
[Thread-7] [error] Thread-7:  at console.ConsoleProcess.showExit(ConsoleProcess.java:156)
[Thread-7] [error] Thread-7:  at console.ConsoleProcess$1.run(ConsoleProcess.java:111)
[Thread-8] [error] StreamThread: Can't Flush:
[Thread-8] [error] StreamThread: java.lang.NullPointerException
[Thread-8] [error] StreamThread:  at console.StreamThread.flushLine(StreamThread.java:217)
[Thread-8] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:130)

- Linux 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
- java version "1.6.0_24"
  OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu3)
  OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
- jEdit 04.05.99.02, Console 4.5 + "-nosettings"

and...

[Thread-6] [error] StreamThread: Can't Flush:
[Thread-6] [error] StreamThread: java.lang.NullPointerException
[Thread-6] [error] StreamThread:  at console.StreamThread.printString(StreamThread.java:332)
[Thread-6] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:212)
             
- jEdit 05.01.01.00, Console 5.0

The problem is that there is no implementation for processes running in the background, in the module ConsoleProcess.java.
If the process starts in the background - Console does not establish Output for such process, and then prints the output from it as from the usual process.

----------------------------------------------------------------------

>Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 04:10

Message:
Opened the ticket for the implementation of this feature. See Plugin
Feature Requests #3539135.

----------------------------------------------------------------------

Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 03:16

Message:
Blocked the possibility to run the process in the background - r21890

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

Plugin Feature Requests item #3539135, was opened at 2012-06-30 04:07
Message generated for change (Tracker Item Submitted) made by synh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3539135&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console: possibility to run the process in the background

Initial Comment:
At the moment ( r21890 ) Console ignores the parameter "&" at the end of the command line: this feature is blocked.
See Plugin Bug #3539123.

Is it the necessary feature for somebody?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3539135&group_id=588

Plugin Bugs item #3539123, was opened at 2012-06-30 02:49
Message generated for change (Comment added) made by synh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
>Resolution: Later
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Artem Bryantsev (synh)
Summary: Console: NPE when command starts in background

Initial Comment:
Execution "some_command &" or "some_command&" leads to NPE:

[Thread-7] [error] Thread-7: Exception in thread "Thread-7" 
[Thread-7] [error] Thread-7: java.lang.NullPointerException
[Thread-7] [error] Thread-7:  at console.ConsoleProcess.showExit(ConsoleProcess.java:156)
[Thread-7] [error] Thread-7:  at console.ConsoleProcess$1.run(ConsoleProcess.java:111)
[Thread-8] [error] StreamThread: Can't Flush:
[Thread-8] [error] StreamThread: java.lang.NullPointerException
[Thread-8] [error] StreamThread:  at console.StreamThread.flushLine(StreamThread.java:217)
[Thread-8] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:130)

- Linux 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
- java version "1.6.0_24"
  OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu3)
  OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
- jEdit 04.05.99.02, Console 4.5 + "-nosettings"

and...

[Thread-6] [error] StreamThread: Can't Flush:
[Thread-6] [error] StreamThread: java.lang.NullPointerException
[Thread-6] [error] StreamThread:  at console.StreamThread.printString(StreamThread.java:332)
[Thread-6] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:212)
             
- jEdit 05.01.01.00, Console 5.0

The problem is that there is no implementation for processes running in the background, in the module ConsoleProcess.java.
If the process starts in the background - Console does not establish Output for such process, and then prints the output from it as from the usual process.

----------------------------------------------------------------------

>Comment By: Artem Bryantsev (synh)
Date: 2012-06-30 03:16

Message:
Blocked the possibility to run the process in the background - r21890

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

Plugin Bugs item #3539123, was opened at 2012-06-30 02:49
Message generated for change (Tracker Item Submitted) made by synh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Artem Bryantsev (synh)
Assigned to: Artem Bryantsev (synh)
Summary: Console: NPE when command starts in background

Initial Comment:
Execution "some_command &" or "some_command&" leads to NPE:

[Thread-7] [error] Thread-7: Exception in thread "Thread-7" 
[Thread-7] [error] Thread-7: java.lang.NullPointerException
[Thread-7] [error] Thread-7:  at console.ConsoleProcess.showExit(ConsoleProcess.java:156)
[Thread-7] [error] Thread-7:  at console.ConsoleProcess$1.run(ConsoleProcess.java:111)
[Thread-8] [error] StreamThread: Can't Flush:
[Thread-8] [error] StreamThread: java.lang.NullPointerException
[Thread-8] [error] StreamThread:  at console.StreamThread.flushLine(StreamThread.java:217)
[Thread-8] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:130)

- Linux 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
- java version "1.6.0_24"
  OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu3)
  OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
- jEdit 04.05.99.02, Console 4.5 + "-nosettings"

and...

[Thread-6] [error] StreamThread: Can't Flush:
[Thread-6] [error] StreamThread: java.lang.NullPointerException
[Thread-6] [error] StreamThread:  at console.StreamThread.printString(StreamThread.java:332)
[Thread-6] [error] StreamThread:  at console.StreamThread.run(StreamThread.java:212)
             
- jEdit 05.01.01.00, Console 5.0

The problem is that there is no implementation for processes running in the background, in the module ConsoleProcess.java.
If the process starts in the background - Console does not establish Output for such process, and then prints the output from it as from the usual process.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3539123&group_id=588

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Proyecto<br>
    <br>
    You should try to create a new directory, clone your svn repository
    to it and run "ant build". Then you'll notice that it does not
    compile.<br>
    <br>
    BUILD FAILED<br>
    C:\Temp\src\jedit\plugins\Synonyms\build.xml:12:
    C:\Temp\src\jedit\plugins\Synonyms\bin does not exist.<br>
    <br>
    Also distributing jedit.jar with the plugin is unacceptable. I again
    suggest you analyze how QuickNotepad is build, otherwise we'll have
    a lot of obstacles ahead. One of them is the place where plugin jar
    should be placed after build. Details in QuickNotepad and
    plugin-build.xml.<br>
    <br>
    Jarek<br>
    <br>
    <div class="moz-cite-prefix">W dniu 2012-06-28 18:10, Proyecto
      Sistemas Inform&aacute;ticos pisze:<br>
    </div>
    <blockquote
cite="mid:CAM...@ma..."
      type="cite">Hello, now the plugin can be compiled with "ant build"
      as you want.
      <div>You can download it in:&nbsp;
        <span
style="color:rgb(85,85,85);font-family:monospace;font-size:13px;line-height:13px;text-align:left;background-color:rgb(221,221,221)"><a
            moz-do-not-send="true"
            href="https://synonymsp.svn.sourceforge.net/svnroot/synonymsp">https://synonymsp.svn.sourceforge.net/svnroot/synonymsp</a>&nbsp;</span>&nbsp;</div>
      <div><br>
      </div>
      <div>Thanks.<br>
        <br>
        <div class="gmail_quote">2012/6/28 Jarek Czekalski <span
            dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:jar...@po..." target="_blank">jar...@po...</a>&gt;</span><br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000"> W dniu 2012-06-27
              19:59, Marta Rodriguez pisze:<br>
              <blockquote type="cite"><br>
                <blockquote class="gmail_quote" style="margin:0px 0px
                  0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">but

                  first I would like to be able<br>
                  to compile it as the rest of plugins, with "ant build"
                  or "ant dist".</blockquote>
                <div>We use Eclipse with Ant, and for compile the plugin
                  we use the build.xml file with Ant.</div>
              </blockquote>
              <br>
              We don't use Eclipse. Plugin must be compilable without
              Eclipse. Otherwise you need to distribute it using other
              ways, not jedit plugin manager.<span class="HOEnZb"><font
                  color="#888888"><br>
                  <br>
                  Jarek<br>
                  <br>
                </font></span></div>
            <br>
------------------------------------------------------------------------------<br>
            Live Security Virtual Conference<br>
            Exclusive live event will cover all the ways today's
            security and<br>
            threat landscape has changed and how IT managers can
            respond. Discussions<br>
            will include endpoint security, mobile security and the
            latest in malware<br>
            threats. <a moz-do-not-send="true"
              href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/"
              target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>
            --<br>
            -----------------------------------------------<br>
            jEdit Developers' List<br>
            <a moz-do-not-send="true"
              href="mailto:jEd...@li...">jEd...@li...</a><br>
            <a moz-do-not-send="true"
              href="https://lists.sourceforge.net/lists/listinfo/jedit-devel"
              target="_blank">https://lists.sourceforge.net/lists/listinfo/jedit-devel</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <br>
  </body>
</html>

Bugs item #3535370, was opened at 2012-06-15 00:53
Message generated for change (Comment added) made by przemo_w
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3535370&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Przemek Wesolek (przemo_w)
Assigned to: Nobody/Anonymous (nobody)
Summary: Keyboard not working after refocus, Linux+Compiz

Initial Comment:
After I upgraded to Java 7, jEdit stopped to respond to key events after re-gaining window focus.

After selecting View-New view, in the opened view everything works fine (until refocusing again, of course), in the old view the problems persist.

What doesn't work:
- entering text in text area
- shortcuts
- navigating menus after mouse-clicking on menubar

What works:
- text entering and keyboard navigation in dialogs

Steps to reproduce
1. Start jEdit cleanly
  $ rm new.settings
  $ mkdir new.settings
  $ jedit -settings=new.settings
2. Focus on text area by clicking inside (don't close "jEdit Help" window!)
3. Try typing (new characters appear in text area) or hit any shortcut (works)
4. Lose focus (either Alt-TAB to other window, or click with a mouse on other window or desktop)
5. Gain focus (either Alt-TAB to jEdit window, or click with a mouse on jEdit's text area)


----------------------------------------------------------------------

>Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-29 00:26

Message:
Oh, please...

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-28 15:40

Message:
closing as invalid. Resolution: don't use compiz.


----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-28 08:00

Message:
KDE 4.2 does not use compiz. It has its own compositing system.


----------------------------------------------------------------------

Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-28 01:32

Message:
Alan, do you use Compiz? My investigations show it's probably a Java-Compiz
issue.

Moreover, I noticed the same problems yesterday with JabRef (also a Java
app).

I propose to mark as invalid.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-27 23:06

Message:
Can not reproduce in current Debian Testing with KDE 4.8.3, java version
"1.7.0_03"
OpenJDK Runtime Environment (IcedTea7 2.1.1) (7~u3-2.1.1-1)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)


----------------------------------------------------------------------

Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-27 08:43

Message:
Maybe related to #2676950?

----------------------------------------------------------------------

Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-27 08:34

Message:
I think this has something in common with Compiz running.

There are numerous bugs filled for JRE, Netbeans or Compiz considering
cooperation between Java and Compiz. What makes me think that this bug is
belonging to the same family of problems is that I can workaround the
problem by restarting Compiz *after* jEdit is running:

  $ jedit
  $ compiz --replace



----------------------------------------------------------------------

Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-20 01:37

Message:
Also confirmed on SVN trunk as of today.

----------------------------------------------------------------------

Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-15 00:57

Message:
Environment information:

Linux Ubuntu 10.04 with GNOME 2

jEdit 4.5.1 installed from DEB file

09:51:06 [main] [message] Log: java.version=1.7.0_05
09:51:06 [main] [message] Log: java.vm.version=23.1-b03
09:51:06 [main] [message] Log: java.vm.name=Java HotSpot(TM) Server VM
09:51:06 [main] [message] Log: java.runtime.version=1.7.0_05-b05
09:51:06 [main] [message] Log: java.runtime.name=Java(TM) SE Runtime
Environment
09:51:06 [main] [message] Log: java.vendor=Oracle Corporation
09:51:06 [main] [message] Log: java.compiler=null
09:51:06 [main] [message] Log: os.name=Linux
09:51:06 [main] [message] Log: os.version=3.0.0-21-generic-pae
09:51:06 [main] [message] Log: os.arch=i386
09:51:06 [main] [message] Log: user.home=/home/jest
09:51:06 [main] [message] Log: java.home=/usr/lib/jvm/java-7-oracle/jre
09:51:06 [main] [message] Log: java.class.path=/usr/share/jEdit/jedit.jar
09:51:06 [main] [message] jEdit: starting with command line arguments:
-reuseview -reusev
iew -settings=new.settings
09:51:06 [main] [notice] jEdit: jEdit version 4.5.1
09:51:06 [main] [message] jEdit: Settings directory is
/home/jest/new.settings
09:51:06 [main] [message] jEdit: jEdit home directory is /usr/share/jEdit


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3535370&group_id=588

Plugin Bugs item #3533666, was opened at 2012-06-08 15:52
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3533666&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
>Assigned to: Alan Ezust (ezust)
Summary: XML: Completion popup for attributes after self-closed tag

Initial Comment:
Rev# 21773 contains a new test case for attribute completion.
Completion popups appear after a self-closed <tag/> when they should not.

The test case is: no popup should appear on line 24 of test_data/attributes_completion/attributes.xml,
and yet, one does.


----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2012-06-28 17:56

Message:
Committed 21888.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3533666&group_id=588

Bugs item #3535370, was opened at 2012-06-15 00:53
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3535370&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Przemek Wesolek (przemo_w)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Keyboard not working after refocus, Linux+Compiz

Initial Comment:
After I upgraded to Java 7, jEdit stopped to respond to key events after re-gaining window focus.

After selecting View-New view, in the opened view everything works fine (until refocusing again, of course), in the old view the problems persist.

What doesn't work:
- entering text in text area
- shortcuts
- navigating menus after mouse-clicking on menubar

What works:
- text entering and keyboard navigation in dialogs

Steps to reproduce
1. Start jEdit cleanly
  $ rm new.settings
  $ mkdir new.settings
  $ jedit -settings=new.settings
2. Focus on text area by clicking inside (don't close "jEdit Help" window!)
3. Try typing (new characters appear in text area) or hit any shortcut (works)
4. Lose focus (either Alt-TAB to other window, or click with a mouse on other window or desktop)
5. Gain focus (either Alt-TAB to jEdit window, or click with a mouse on jEdit's text area)


----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2012-06-28 15:40

Message:
closing as invalid. Resolution: don't use compiz.


----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-28 08:00

Message:
KDE 4.2 does not use compiz. It has its own compositing system.


----------------------------------------------------------------------

Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-28 01:32

Message:
Alan, do you use Compiz? My investigations show it's probably a Java-Compiz
issue.

Moreover, I noticed the same problems yesterday with JabRef (also a Java
app).

I propose to mark as invalid.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2012-06-27 23:06

Message:
Can not reproduce in current Debian Testing with KDE 4.8.3, java version
"1.7.0_03"
OpenJDK Runtime Environment (IcedTea7 2.1.1) (7~u3-2.1.1-1)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)


----------------------------------------------------------------------

Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-27 08:43

Message:
Maybe related to #2676950?

----------------------------------------------------------------------

Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-27 08:34

Message:
I think this has something in common with Compiz running.

There are numerous bugs filled for JRE, Netbeans or Compiz considering
cooperation between Java and Compiz. What makes me think that this bug is
belonging to the same family of problems is that I can workaround the
problem by restarting Compiz *after* jEdit is running:

  $ jedit
  $ compiz --replace



----------------------------------------------------------------------

Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-20 01:37

Message:
Also confirmed on SVN trunk as of today.

----------------------------------------------------------------------

Comment By: Przemek Wesolek (przemo_w)
Date: 2012-06-15 00:57

Message:
Environment information:

Linux Ubuntu 10.04 with GNOME 2

jEdit 4.5.1 installed from DEB file

09:51:06 [main] [message] Log: java.version=1.7.0_05
09:51:06 [main] [message] Log: java.vm.version=23.1-b03
09:51:06 [main] [message] Log: java.vm.name=Java HotSpot(TM) Server VM
09:51:06 [main] [message] Log: java.runtime.version=1.7.0_05-b05
09:51:06 [main] [message] Log: java.runtime.name=Java(TM) SE Runtime
Environment
09:51:06 [main] [message] Log: java.vendor=Oracle Corporation
09:51:06 [main] [message] Log: java.compiler=null
09:51:06 [main] [message] Log: os.name=Linux
09:51:06 [main] [message] Log: os.version=3.0.0-21-generic-pae
09:51:06 [main] [message] Log: os.arch=i386
09:51:06 [main] [message] Log: user.home=/home/jest
09:51:06 [main] [message] Log: java.home=/usr/lib/jvm/java-7-oracle/jre
09:51:06 [main] [message] Log: java.class.path=/usr/share/jEdit/jedit.jar
09:51:06 [main] [message] jEdit: starting with command line arguments:
-reuseview -reusev
iew -settings=new.settings
09:51:06 [main] [notice] jEdit: jEdit version 4.5.1
09:51:06 [main] [message] jEdit: Settings directory is
/home/jest/new.settings
09:51:06 [main] [message] jEdit: jEdit home directory is /usr/share/jEdit


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3535370&group_id=588

Patches item #3531515, was opened at 2012-06-02 04:51
Message generated for change (Comment added) made by thomasmey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=3531515&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Meyer (thomasmey)
Assigned to: Kazutoshi Satoda (k_satoda)
Summary: Compact Remove&Insert Edits into a Replace Edit

Initial Comment:
This helps to save some memory for the search&replace-all case as only one instead of two objects are stored in memory.

----------------------------------------------------------------------

>Comment By: Thomas Meyer (thomasmey)
Date: 2012-06-28 14:41

Message:
Another approach to compress n Replace into a CompressedReplace. It works
great for my test case... But I don't know how this will scale in general
case. what do you think. Measurements, log message and change entry to
follow.


----------------------------------------------------------------------

Comment By: Thomas Meyer (thomasmey)
Date: 2012-06-10 01:59

Message:
Updated patch attached. Please have a look at it and tell me what do you
think of it?

with kind regards
thomas

----------------------------------------------------------------------

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-09 03:36

Message:
Please consider to describe the purpose (optimize the memory usage for
large number of replace) of the folding as appropriate comments.

Same type checks and casts are repeated at caller and inside of
getReplaceFromRemoveInsert(). They should not be repeated for both code
quality and performance.

----------------------------------------------------------------------

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-09 03:21

Message:
>> As long as only the sequence Remove+Insert is compacted into a replace,
>> this is not necessary.
>
> With the current implementation, I'm afraid of every contentInserted()
> after a folding will create a new instance of Insert and increase memory
> usage.

Sorry I just realized that I was wrong. The waste will be merely one
Insert not merged. Now I agree it is not necessary in favor of code
simplicity.

----------------------------------------------------------------------

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-09 03:16

Message:
> 1.) "The folding should be delayed until ..."
> As long as only the sequence Remove+Insert is compacted into a replace,
> this is not necessary.

With the current implementation, I'm afraid of every contentInserted()
after a folding will create a new instance of Insert and increase memory
usage.

Now I found the problem can be solved by an easier way; considering
Replace as a merge target in contentInserted() as same as Insert.

> 2.) ... we should check more; lastElement == redoClearDirty,
> These other conditions cannot happen.

Ah, I understood. Then some comments and/or assertions will be enough to
connect the code and the comment just above it.

> 3.) "Replace can't be undoClearDirty nor redoClearDirty.
> Replace can become a redoClearFirst candidate:

Thank you for the steps to hit the assertion. I understood.

Now I wonder why every Edit has to do the check in it. If the check can
be moved into UndoManager.undo/redo(), it seems more straightforward. If
you or someone find problems to do that, I'll move them as another
separate commit so that this patch won't be bothered by this issue.

----------------------------------------------------------------------

Comment By: Thomas Meyer (thomasmey)
Date: 2012-06-07 08:56

Message:
Hi,

1.) "The folding should be delayed until ..." in my previous comment still
apply."

As long as only the sequence Remove+Insert is compacted into a replace,
this is not necessary.

2.) "At if(lastElement == undoClearDirty) in checkIfReplacement(), we
should
check more; lastElement == redoClearDirty, newElement == ..."

These other conditions cannot happen.

3.) "Replace can't be undoClearDirty nor redoClearDirty. Thus the check in
undo() and redo() is unnecessary. Putting assert() may be reasonable."

Replace can become a redoClearFirst candidate:
1. Create a new File
2. Enter "1234567890123"
3. Save
4. Replace "123" -> "abc"
5. Save -> Replace becomes redosClearDirty
6. Undo
7. Redo -> Assertion hit.

4.) "The return value of Replace.undo() and redo() looks wrong. Please
verify
that they return the same value with the case not folded."

Fixed.

5.) "The added field mgr in CompoundEdit is redundant. You can get
UndoManager after casting the folding Edits."

Fixed

6.) "The semantics of the return value of checkIfReplacement() is vague.
How about returning null if it can't fold? In that case the name can
be getReplaceFromRemoveInsert() and the type can be just Replace.
This change will also remove rcEdit which looks unnecessary."

Fixed.

7.) "Inconsistent spacing: edit=replacement;"

Fixed.

8.) "Strange empty line at the beginning of dropLastElement() body."

Fixed.

----------------------------------------------------------------------

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-06 11:28

Message:
I have looked through the patch. Please revise the patch for the
following comments. Please assume "It looks like ..." for each comment.

"The folding should be delayed until ..." in my previous comment still
apply.

At if(lastElement == undoClearDirty) in checkIfReplacement(), we should
check more; lastElement == redoClearDirty, newElement == ...

Replace can't be undoClearDirty nor redoClearDirty. Thus the check in
undo() and redo() is unnecessary. Putting assert() may be reasonable.

The return value of Replace.undo() and redo() looks wrong. Please verify
that they return the same value with the case not folded.

The added field mgr in CompoundEdit is redundant. You can get
UndoManager after casting the folding Edits.

The semantics of the return value of checkIfReplacement() is vague.
How about returning null if it can't fold? In that case the name can
be getReplaceFromRemoveInsert() and the type can be just Replace.
This change will also remove rcEdit which looks unnecessary.

Inconsistent spacing: edit=replacement;

Strange empty line at the beginning of dropLastElement() body.


----------------------------------------------------------------------

Comment By: Thomas Meyer (thomasmey)
Date: 2012-06-06 08:16

Message:
New patch on top of 3528619

----------------------------------------------------------------------

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2012-06-02 06:22

Message:
The folding shouldn't be done outside compound edits because such edits
should be undo/redoable individually.

Also, if a candidate Edit is undoClearDirty or redoClearDirty, it
shouldn't be folded since the identity is significant.

The folding should be delayed until the candidates become not last one
since the last Edit maybe updated via getMergeEdit().

Would you please revise the patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=3531515&group_id=588