From: Sarah C. <cra...@gm...> - 2011-06-01 14:14:08
|
Hi all, I love jEdit, but from time to time I have to edit a very large ( > 1 MB) JS or XSL file, and jEdit completely freezes up as Sidekick desperately attempts to parse the file for me. Usually by the time I realize what I've done, it's too late to stop Sidekick, and I have to kill javaw.exe from the task manager and use a different editor. Would it be feasible to add a setting to Sidekick so that it doesn't parse files over a given size unless parsing is explicitly triggered by the user? Thanks, Sarah |
From: Shlomy R. <sre...@gm...> - 2011-06-01 14:26:25
|
Hi Sarah, The parsing takes place in the background, so jEdit should not freeze because of it. However, if the tree itself is very large, it may take a long time create the GUI elements when the parsing is over. Can you point me to a sample file that causes this? The request is certainly feasible. Can you add a feature request for this in the SourceForge tracker? Thanks, Shlomy 2011/6/1 Sarah Cranston <cra...@gm...> > Hi all, > I love jEdit, but from time to time I have to edit a very large ( > 1 MB) > JS or XSL file, and jEdit completely freezes up as Sidekick desperately > attempts to parse the file for me. Usually by the time I realize what I've > done, it's too late to stop Sidekick, and I have to kill javaw.exe from the > task manager and use a different editor. Would it be feasible to add a > setting to Sidekick so that it doesn't parse files over a given size unless > parsing is explicitly triggered by the user? > Thanks, > Sarah > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is > safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > > |
From: Dale A. <da...@gr...> - 2011-06-01 15:31:00
|
There is also a known issue (1610416) with the ecmascript parser and certain files, so if you have sidekick set to use it for js files, that might be your problem. 2011/6/1 Shlomy Reinstein <sre...@gm...> > Hi Sarah, > > The parsing takes place in the background, so jEdit should not freeze > because of it. However, if the tree itself is very large, it may take a long > time create the GUI elements when the parsing is over. Can you point me to a > sample file that causes this? > The request is certainly feasible. Can you add a feature request for this > in the SourceForge tracker? > > Thanks, > Shlomy > > 2011/6/1 Sarah Cranston <cra...@gm...> > >> Hi all, >> I love jEdit, but from time to time I have to edit a very large ( > 1 MB) >> JS or XSL file, and jEdit completely freezes up as Sidekick desperately >> attempts to parse the file for me. Usually by the time I realize what I've >> done, it's too late to stop Sidekick, and I have to kill javaw.exe from the >> task manager and use a different editor. Would it be feasible to add a >> setting to Sidekick so that it doesn't parse files over a given size unless >> parsing is explicitly triggered by the user? >> Thanks, >> Sarah >> >> >> ------------------------------------------------------------------------------ >> Simplify data backup and recovery for your virtual environment with >> vRanger. >> Installation's a snap, and flexible recovery options mean your data is >> safe, >> secure and there when you need it. Data protection magic? >> Nope - It's vRanger. Get your free trial download today. >> http://p.sf.net/sfu/quest-sfdev2dev >> -- >> ----------------------------------------------- >> jEdit Users' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-users >> >> > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is > safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > > |
From: maxwell <ma...@um...> - 2011-06-01 19:39:52
|
On Wed, 1 Jun 2011 17:26:18 +0300, Shlomy Reinstein <sre...@gm...> wrote: > The parsing takes place in the background, so jEdit should not freeze > because of it. However, if the tree itself is very large, it may take a > long time create the GUI elements when the parsing is over. Can you point > me to a sample file that causes this? > The request is certainly feasible. Can you add a feature request for this > in the SourceForge tracker? Is this related to the discussion we had a year or two ago to slow parsing of XML files? I think it's bug 3016753. (2962965 and 1814403 seem a little different; 3033210 seems similar, but is marked "closed".) I tried loading a large XML file (a dictionary, 545k lines) just now; initially, jEdit seems ok, and you can see it's parsed at least the first screenful. But if you try to scroll down very far, or jump to the end of the file ("go to end of buffer", not find the matching open bracket), jEdit freezes. My guess is it's sequentially parsing the file, and until it parses up to the end it won't jump there. Preferred behavior: that it would immediately jump to another place in the file, regardless of whether it's parsed up to that point yet. Obviously it wouldn't show the bracketing at that point. I'm also not asking it to jump to the close XML tag that matches the root open tag; I guess if I try that, I should accept the consequences, although *really* nice behavior would be to refuse to even attempt to find matching tags until the file is completely tagged (put up a warning, or beep, or...). Mike Maxwell |
From: Sarah C. <cra...@gm...> - 2011-06-01 19:47:20
|
@Shlomy, @Dale: Now that you mention it, jEdit doesn't freeze for js files, just chugs hard. I can only recall it freezing for XML files. @Mike: Yes, this is the same discussion, and it sounds like you're seeing the same behavior I am. I'm just now finally thinking of how this could be addressed. My thought is that if I know I don't need parsing on a particular file, I'd rather not have jEdit try to start, because it won't ever quit. Even if I close the large file (in the case of JS, where I can do that - can't for XML because it's frozen) jEdit continues to take up 50% CPU. I like your discussion of preferred behavior. Maybe a configurable size limit could be a "quick n dirty fix" for the near future? On Wed, Jun 1, 2011 at 2:39 PM, maxwell <ma...@um...> wrote: > On Wed, 1 Jun 2011 17:26:18 +0300, Shlomy Reinstein <sre...@gm...> > wrote: > > The parsing takes place in the background, so jEdit should not freeze > > because of it. However, if the tree itself is very large, it may take a > > long time create the GUI elements when the parsing is over. Can you > point > > me to a sample file that causes this? > > The request is certainly feasible. Can you add a feature request for > this > > in the SourceForge tracker? > > Is this related to the discussion we had a year or two ago to slow parsing > of XML files? I think it's bug 3016753. (2962965 and 1814403 seem a > little different; 3033210 seems similar, but is marked "closed".) > > I tried loading a large XML file (a dictionary, 545k lines) just now; > initially, jEdit seems ok, and you can see it's parsed at least the first > screenful. But if you try to scroll down very far, or jump to the end of > the file ("go to end of buffer", not find the matching open bracket), jEdit > freezes. My guess is it's sequentially parsing the file, and until it > parses up to the end it won't jump there. > > Preferred behavior: that it would immediately jump to another place in the > file, regardless of whether it's parsed up to that point yet. Obviously it > wouldn't show the bracketing at that point. I'm also not asking it to jump > to the close XML tag that matches the root open tag; I guess if I try that, > I should accept the consequences, although *really* nice behavior would be > to refuse to even attempt to find matching tags until the file is > completely tagged (put up a warning, or beep, or...). > > Mike Maxwell > |
From: Shlomy R. <sre...@gm...> - 2011-06-01 19:58:51
|
You might want to try out one of the latest daily builds, contributed by Eric Berry: http://www.tellurianring.com/projects/jedit-daily/index.php?dir=jEdit%2F <http://www.tellurianring.com/projects/jedit-daily/index.php?dir=jEdit%2F>Matthieu has recently implemented some features for handling large buffers, which I believe are not in the released version yet. For example, when you open large files, jEdit will ask you if you want to disable syntax highlighting or make it less accurate (so that the syntax highlighting of each line is independent of the preceding lines) - both options reduce delays when handling large buffers. Maybe these options are all you need. Can you check a recent daily build and reply if it fixed the issue? Thanks, Shlomy 2011/6/1 Sarah Cranston <cra...@gm...> > @Shlomy, @Dale: Now that you mention it, jEdit doesn't freeze for js files, > just chugs hard. I can only recall it freezing for XML files. > > @Mike: Yes, this is the same discussion, and it sounds like you're seeing > the same behavior I am. I'm just now finally thinking of how this could be > addressed. My thought is that if I know I don't need parsing on a particular > file, I'd rather not have jEdit try to start, because it won't ever quit. > Even if I close the large file (in the case of JS, where I can do that - > can't for XML because it's frozen) jEdit continues to take up 50% CPU. I > like your discussion of preferred behavior. Maybe a configurable size limit > could be a "quick n dirty fix" for the near future? > On Wed, Jun 1, 2011 at 2:39 PM, maxwell <ma...@um...> wrote: > >> On Wed, 1 Jun 2011 17:26:18 +0300, Shlomy Reinstein <sre...@gm...> >> wrote: >> > The parsing takes place in the background, so jEdit should not freeze >> > because of it. However, if the tree itself is very large, it may take a >> > long time create the GUI elements when the parsing is over. Can you >> point >> > me to a sample file that causes this? >> > The request is certainly feasible. Can you add a feature request for >> this >> > in the SourceForge tracker? >> >> Is this related to the discussion we had a year or two ago to slow parsing >> of XML files? I think it's bug 3016753. (2962965 and 1814403 seem a >> little different; 3033210 seems similar, but is marked "closed".) >> >> I tried loading a large XML file (a dictionary, 545k lines) just now; >> initially, jEdit seems ok, and you can see it's parsed at least the first >> screenful. But if you try to scroll down very far, or jump to the end of >> the file ("go to end of buffer", not find the matching open bracket), >> jEdit >> freezes. My guess is it's sequentially parsing the file, and until it >> parses up to the end it won't jump there. >> >> Preferred behavior: that it would immediately jump to another place in the >> file, regardless of whether it's parsed up to that point yet. Obviously >> it >> wouldn't show the bracketing at that point. I'm also not asking it to >> jump >> to the close XML tag that matches the root open tag; I guess if I try >> that, >> I should accept the consequences, although *really* nice behavior would be >> to refuse to even attempt to find matching tags until the file is >> completely tagged (put up a warning, or beep, or...). >> >> Mike Maxwell >> > > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is > safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > > |
From: Sarah C. <cra...@gm...> - 2011-06-01 20:56:53
|
Unfortunately I can't make the file available because it's proprietary. But I can tell you that if I go into the Plugin Manager, and unselect the Sidekick, XML, and XSLT plugins, I can jump to the bottom with only a brief delay. Is there anything else I should try? On Wed, Jun 1, 2011 at 2:58 PM, Shlomy Reinstein <sre...@gm...> wrote: > You might want to try out one of the latest daily builds, contributed by > Eric Berry: > http://www.tellurianring.com/projects/jedit-daily/index.php?dir=jEdit%2F > <http://www.tellurianring.com/projects/jedit-daily/index.php?dir=jEdit%2F>Matthieu > has recently implemented some features for handling large buffers, which I > believe are not in the released version yet. For example, when you open > large files, jEdit will ask you if you want to disable syntax highlighting > or make it less accurate (so that the syntax highlighting of each line is > independent of the preceding lines) - both options reduce delays when > handling large buffers. Maybe these options are all you need. Can you check > a recent daily build and reply if it fixed the issue? > > Thanks, > Shlomy > > 2011/6/1 Sarah Cranston <cra...@gm...> > >> @Shlomy, @Dale: Now that you mention it, jEdit doesn't freeze for js >> files, just chugs hard. I can only recall it freezing for XML files. >> >> @Mike: Yes, this is the same discussion, and it sounds like you're seeing >> the same behavior I am. I'm just now finally thinking of how this could be >> addressed. My thought is that if I know I don't need parsing on a particular >> file, I'd rather not have jEdit try to start, because it won't ever quit. >> Even if I close the large file (in the case of JS, where I can do that - >> can't for XML because it's frozen) jEdit continues to take up 50% CPU. I >> like your discussion of preferred behavior. Maybe a configurable size limit >> could be a "quick n dirty fix" for the near future? >> On Wed, Jun 1, 2011 at 2:39 PM, maxwell <ma...@um...> wrote: >> >>> On Wed, 1 Jun 2011 17:26:18 +0300, Shlomy Reinstein <sre...@gm...> >>> wrote: >>> > The parsing takes place in the background, so jEdit should not freeze >>> > because of it. However, if the tree itself is very large, it may take a >>> > long time create the GUI elements when the parsing is over. Can you >>> point >>> > me to a sample file that causes this? >>> > The request is certainly feasible. Can you add a feature request for >>> this >>> > in the SourceForge tracker? >>> >>> Is this related to the discussion we had a year or two ago to slow >>> parsing >>> of XML files? I think it's bug 3016753. (2962965 and 1814403 seem a >>> little different; 3033210 seems similar, but is marked "closed".) >>> >>> I tried loading a large XML file (a dictionary, 545k lines) just now; >>> initially, jEdit seems ok, and you can see it's parsed at least the first >>> screenful. But if you try to scroll down very far, or jump to the end of >>> the file ("go to end of buffer", not find the matching open bracket), >>> jEdit >>> freezes. My guess is it's sequentially parsing the file, and until it >>> parses up to the end it won't jump there. >>> >>> Preferred behavior: that it would immediately jump to another place in >>> the >>> file, regardless of whether it's parsed up to that point yet. Obviously >>> it >>> wouldn't show the bracketing at that point. I'm also not asking it to >>> jump >>> to the close XML tag that matches the root open tag; I guess if I try >>> that, >>> I should accept the consequences, although *really* nice behavior would >>> be >>> to refuse to even attempt to find matching tags until the file is >>> completely tagged (put up a warning, or beep, or...). >>> >>> Mike Maxwell >>> >> >> >> >> ------------------------------------------------------------------------------ >> Simplify data backup and recovery for your virtual environment with >> vRanger. >> Installation's a snap, and flexible recovery options mean your data is >> safe, >> secure and there when you need it. Data protection magic? >> Nope - It's vRanger. Get your free trial download today. >> http://p.sf.net/sfu/quest-sfdev2dev >> -- >> ----------------------------------------------- >> jEdit Users' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-users >> >> > |
From: Sarah C. <cra...@gm...> - 2011-06-03 14:57:29
|
Silly question, but how do I disable syntax highlighting? I looked through the Global Options and the Buffer Options but didn't find any checkbox for turning it on/off. On Thu, Jun 2, 2011 at 7:28 AM, Eric Le Lay <ker...@so...>wrote: > Hi, > > Matthieu's change (introduced in r19497) is very nice. > If the user chooses to disable syntax hightlighting, the buffer's mode is > switched to text and Sidekick won't parse it at all. > XML plugin could test for the degraded syntax highlighting mode and : > - limit matching tag highlighting to 10k characters around the caret ? > - limit the sidekick tree to 1k elements and not parse the end of the file > ? > - not parse at all ? > - prompt again for the behaviour (might be cumbersome for users...) > > However, the size limit of 4MB may already be too big for XML. > The 500k imdb file included in #3016753 already displays bad performance. > > Cheers, > > Le 01/06/2011 21:58, Shlomy Reinstein a écrit : > > You might want to try out one of the latest daily builds, contributed by > Eric Berry: > http://www.tellurianring.com/projects/jedit-daily/index.php?dir=jEdit%2F > Matthieu has recently implemented some features for handling large > buffers, which I believe are not in the released version yet. For example, > when you open large files, jEdit will ask you if you want to disable syntax > highlighting or make it less accurate (so that the syntax highlighting of > each line is independent of the preceding lines) - both options reduce > delays when handling large buffers. Maybe these options are all you need. > Can you check a recent daily build and reply if it fixed the issue? > > Thanks, > Shlomy > > 2011/6/1 Sarah Cranston <cra...@gm...> > >> @Shlomy, @Dale: Now that you mention it, jEdit doesn't freeze for js >> files, just chugs hard. I can only recall it freezing for XML files. >> >> @Mike: Yes, this is the same discussion, and it sounds like you're seeing >> the same behavior I am. I'm just now finally thinking of how this could be >> addressed. My thought is that if I know I don't need parsing on a particular >> file, I'd rather not have jEdit try to start, because it won't ever quit. >> Even if I close the large file (in the case of JS, where I can do that - >> can't for XML because it's frozen) jEdit continues to take up 50% CPU. I >> like your discussion of preferred behavior. Maybe a configurable size limit >> could be a "quick n dirty fix" for the near future? >> On Wed, Jun 1, 2011 at 2:39 PM, maxwell <ma...@um...> wrote: >> >>> On Wed, 1 Jun 2011 17:26:18 +0300, Shlomy Reinstein <sre...@gm...> >>> wrote: >>> > The parsing takes place in the background, so jEdit should not freeze >>> > because of it. However, if the tree itself is very large, it may take a >>> > long time create the GUI elements when the parsing is over. Can you >>> point >>> > me to a sample file that causes this? >>> > The request is certainly feasible. Can you add a feature request for >>> this >>> > in the SourceForge tracker? >>> >>> Is this related to the discussion we had a year or two ago to slow >>> parsing >>> of XML files? I think it's bug 3016753. (2962965 and 1814403 seem a >>> little different; 3033210 seems similar, but is marked "closed".) >>> >>> I tried loading a large XML file (a dictionary, 545k lines) just now; >>> initially, jEdit seems ok, and you can see it's parsed at least the first >>> screenful. But if you try to scroll down very far, or jump to the end of >>> the file ("go to end of buffer", not find the matching open bracket), >>> jEdit >>> freezes. My guess is it's sequentially parsing the file, and until it >>> parses up to the end it won't jump there. >>> >>> Preferred behavior: that it would immediately jump to another place in >>> the >>> file, regardless of whether it's parsed up to that point yet. Obviously >>> it >>> wouldn't show the bracketing at that point. I'm also not asking it to >>> jump >>> to the close XML tag that matches the root open tag; I guess if I try >>> that, >>> I should accept the consequences, although *really* nice behavior would >>> be >>> to refuse to even attempt to find matching tags until the file is >>> completely tagged (put up a warning, or beep, or...). >>> >>> Mike Maxwell >>> >> >> > > |
From: maxwell <ma...@um...> - 2011-06-03 16:15:15
|
On Fri, 3 Jun 2011 09:57:22 -0500, Sarah Cranston <cra...@gm...> wrote: > Silly question, but how do I disable syntax highlighting? I looked through > the Global Options and the Buffer Options but didn't find any checkbox for > turning it on/off. I don't believe there's a way to turn off syntax highlighting per se, in fact I don't think that's the issue--the issue is with the marking of potential folds based on the parsing of the file. What appears to work for me is to do Options | Plugin Options, choose Sidekick>General, and under "Auto parsing Settings" un-check "Parse on buffer switch", "Parse on buffer save", and "Parse on keystroke." I think un-checking one of those boxes (the third one?) will cause another (the second one?) to get re-checked, so when you're done, before clicking on the OK or Apply button, make sure all three buttons under "Auto parsing Settings" are un-checked. Mike Maxwell |
From: Eric Le L. <ker...@us...> - 2011-06-03 16:22:15
|
You can switch the buffer's mode to text (Utilities > buffer options). Then, to make it permanent for your big XML file, you place the caret at the beginning of the file and go to "Macros > Properties > Insert Buffer Properties" and then check "mode". See http://jedit.org/users-guide/buffer-local.html for details. You could also choose not to do syntax highlighting for all *.xml files. To do this, go to Utilities > Global Options > Editing, select the XML mode and remove *.xml from the file name glob. (sorry for re-posting : I have troubles with my mail) Le 03/06/2011 16:57, Sarah Cranston a écrit : > Silly question, but how do I disable syntax highlighting? I looked > through the Global Options and the Buffer Options but didn't find any > checkbox for turning it on/off. > > On Thu, Jun 2, 2011 at 7:28 AM, Eric Le Laywrote: > > Hi, > > Matthieu's change (introduced in r19497) is very nice. > If the user chooses to disable syntax hightlighting, the buffer's > mode is switched to text and Sidekick won't parse it at all. > XML plugin could test for the degraded syntax highlighting mode and : > - limit matching tag highlighting to 10k characters around the > caret ? > - limit the sidekick tree to 1k elements and not parse the end of > the file ? > - not parse at all ? > - prompt again for the behaviour (might be cumbersome for users...) > > However, the size limit of 4MB may already be too big for XML. > The 500k imdb file included in #3016753 already displays bad > performance. > > Cheers, > > Le 01/06/2011 21:58, Shlomy Reinstein a écrit : >> You might want to try out one of the latest daily builds, >> contributed by Eric Berry: >> http://www.tellurianring.com/projects/jedit-daily/index.php?dir=jEdit%2F >> >> Matthieu has recently implemented some features for handling >> large buffers, which I believe are not in the released version >> yet. For example, when you open large files, jEdit will ask you >> if you want to disable syntax highlighting or make it less >> accurate (so that the syntax highlighting of each line is >> independent of the preceding lines) - both options reduce delays >> when handling large buffers. Maybe these options are all you >> need. Can you check a recent daily build and reply if it fixed >> the issue? >> >> Thanks, >> Shlomy >> >> 2011/6/1 Sarah Cranston <cra...@gm... >> <mailto:cra...@gm...>> >> >> @Shlomy, @Dale: Now that you mention it, jEdit doesn't freeze >> for js files, just chugs hard. I can only recall it freezing >> for XML files. >> >> @Mike: Yes, this is the same discussion, and it sounds like >> you're seeing the same behavior I am. I'm just now finally >> thinking of how this could be addressed. My thought is that >> if I know I don't need parsing on a particular file, I'd >> rather not have jEdit try to start, because it won't ever >> quit. Even if I close the large file (in the case of JS, >> where I can do that - can't for XML because it's frozen) >> jEdit continues to take up 50% CPU. I like your discussion of >> preferred behavior. Maybe a configurable size limit could be >> a "quick n dirty fix" for the near future? >> On Wed, Jun 1, 2011 at 2:39 PM, maxwell >> <ma...@um... <mailto:ma...@um...>> wrote: >> >> On Wed, 1 Jun 2011 17:26:18 +0300, Shlomy Reinstein >> <sre...@gm... <mailto:sre...@gm...>> >> wrote: >> > The parsing takes place in the background, so jEdit >> should not freeze >> > because of it. However, if the tree itself is very >> large, it may take a >> > long time create the GUI elements when the parsing is >> over. Can you >> point >> > me to a sample file that causes this? >> > The request is certainly feasible. Can you add a >> feature request for >> this >> > in the SourceForge tracker? >> >> Is this related to the discussion we had a year or two >> ago to slow parsing >> of XML files? I think it's bug 3016753. (2962965 and >> 1814403 seem a >> little different; 3033210 seems similar, but is marked >> "closed".) >> >> I tried loading a large XML file (a dictionary, 545k >> lines) just now; >> initially, jEdit seems ok, and you can see it's parsed at >> least the first >> screenful. But if you try to scroll down very far, or >> jump to the end of >> the file ("go to end of buffer", not find the matching >> open bracket), jEdit >> freezes. My guess is it's sequentially parsing the file, >> and until it >> parses up to the end it won't jump there. >> >> Preferred behavior: that it would immediately jump to >> another place in the >> file, regardless of whether it's parsed up to that point >> yet. Obviously it >> wouldn't show the bracketing at that point. I'm also not >> asking it to jump >> to the close XML tag that matches the root open tag; I >> guess if I try that, >> I should accept the consequences, although *really* nice >> behavior would be >> to refuse to even attempt to find matching tags until the >> file is >> completely tagged (put up a warning, or beep, or...). >> >> Mike Maxwell >> >> > > > |
From: maxwell <ma...@um...> - 2011-06-03 18:03:39
|
On Fri, 03 Jun 2011 18:22:02 +0200, Eric Le Lay <ker...@us...> wrote: > ... > You could also choose not to do syntax highlighting for all *.xml files. I think the original poster's comment (and if not, then mine :-)) was that highlighting, open/close tag matching, etc. is very useful: if we have to turn it off, we only want to do so on a per-file basis where necessary, i.e. where jEdit gets too slow. The idea was that we might be able to do so automatically based on the file size (size being an approximate proxy for the number of tags, which is probably the ideal if impractical measure). Manually turning it off on a per-buffer basis, as I think you suggested, is at least a temporary work-around. Mike Maxwell |
From: Eric Le L. <ker...@us...> - 2011-06-03 19:44:45
|
Le 03/06/2011 20:03, maxwell a écrit : > On Fri, 03 Jun 2011 18:22:02 +0200, Eric Le Lay > <ker...@us...> wrote: >> ... >> You could also choose not to do syntax highlighting for all *.xml files. > I think the original poster's comment (and if not, then mine :-)) was that > highlighting, open/close tag matching, etc. is very useful: if we have to > turn it off, we only want to do so on a per-file basis where necessary, > i.e. where jEdit gets too slow. The idea was that we might be able to do > so automatically based on the file size (size being an approximate proxy > for the number of tags, which is probably the ideal if impractical > measure). > > Manually turning it off on a per-buffer basis, as I think you suggested, > is at least a temporary work-around. > > Mike Maxwell OK, got it :-) . Depending on the proportion of big XML files wrt manageable XML files, though, you may find acceptable to disable automatic XML syntax highlighting for *.xml and switch to XML mode only when you have opened the file and seen it's not too big. |
From: Shlomy R. <sre...@gm...> - 2011-06-01 19:51:40
|
Many things can cause the delay when jumping to the end of the buffer - for example, syntax highlighting, SideKick folding mode, etc. It's impossible to say without additional information. Can you make this xml file available, together with the list of plugins you have and the properties file? Thanks, Shlomy On Wed, Jun 1, 2011 at 10:39 PM, maxwell <ma...@um...> wrote: > On Wed, 1 Jun 2011 17:26:18 +0300, Shlomy Reinstein <sre...@gm...> > wrote: > > The parsing takes place in the background, so jEdit should not freeze > > because of it. However, if the tree itself is very large, it may take a > > long time create the GUI elements when the parsing is over. Can you > point > > me to a sample file that causes this? > > The request is certainly feasible. Can you add a feature request for > this > > in the SourceForge tracker? > > Is this related to the discussion we had a year or two ago to slow parsing > of XML files? I think it's bug 3016753. (2962965 and 1814403 seem a > little different; 3033210 seems similar, but is marked "closed".) > > I tried loading a large XML file (a dictionary, 545k lines) just now; > initially, jEdit seems ok, and you can see it's parsed at least the first > screenful. But if you try to scroll down very far, or jump to the end of > the file ("go to end of buffer", not find the matching open bracket), jEdit > freezes. My guess is it's sequentially parsing the file, and until it > parses up to the end it won't jump there. > > Preferred behavior: that it would immediately jump to another place in the > file, regardless of whether it's parsed up to that point yet. Obviously it > wouldn't show the bracketing at that point. I'm also not asking it to jump > to the close XML tag that matches the root open tag; I guess if I try that, > I should accept the consequences, although *really* nice behavior would be > to refuse to even attempt to find matching tags until the file is > completely tagged (put up a warning, or beep, or...). > > Mike Maxwell > |
From: maxwell <ma...@um...> - 2011-06-01 21:45:36
|
On Wed, 1 Jun 2011 22:51:33 +0300, Shlomy Reinstein <sre...@gm...> wrote: > Many things can cause the delay when jumping to the end of the buffer - for > example, syntax highlighting, SideKick folding mode, etc. It's impossible > to say without additional information. Can you make this xml file available, > together with the list of plugins you have and the properties file? > ... > On Wed, Jun 1, 2011 at 10:39 PM, maxwell <ma...@um...> wrote: >> ... >> I tried loading a large XML file (a dictionary, 545k lines) just now I can't, send the original file, because it's proprietary. But I stripped out all the data in the elements, leaving only the tags, and reproduced the problem. The resulting file is about 12 megs. Do you want me to ftp it somewhere? BTW, the problem is not limited to jumping around in the file, it also happens with search-and-replace. S&R with sidekick parsing turned on hung; without it, it takes a couple-three seconds. The regex's I was using were like <gloss>[^<]*</gloss> --> <gloss></gloss> i.e. omitting the text contents of the <gloss> element. I do not have any active folding. My plugins are Beauty Check jEdit version ErrorList FTP Highlight Info Viewer JDiff plugin (not turned on) ProjectViewer (not in use) QuickNotepad Sessions Sidekick Tags Texttools Whitespace XML I can send my properties file, probably easiest if I send it wherever you want the XML file. Mike Maxwell |
From: Shlomy R. <sre...@gm...> - 2011-06-02 06:54:11
|
Hi, I don't have any ftp of my own. Can you compress it and put it on the jEdit community site? Shlomy On Thu, Jun 2, 2011 at 12:45 AM, maxwell <ma...@um...> wrote: > On Wed, 1 Jun 2011 22:51:33 +0300, Shlomy Reinstein <sre...@gm...> > wrote: > > Many things can cause the delay when jumping to the end of the buffer - > for > > example, syntax highlighting, SideKick folding mode, etc. It's > impossible > > to say without additional information. Can you make this xml file > available, > > together with the list of plugins you have and the properties file? > > ... > > On Wed, Jun 1, 2011 at 10:39 PM, maxwell <ma...@um...> wrote: > >> ... > >> I tried loading a large XML file (a dictionary, 545k lines) just now > > I can't, send the original file, because it's proprietary. But I stripped > out all the data in the elements, leaving only the tags, and reproduced the > problem. The resulting file is about 12 megs. Do you want me to ftp it > somewhere? > > BTW, the problem is not limited to jumping around in the file, it also > happens with search-and-replace. S&R with sidekick parsing turned on hung; > without it, it takes a couple-three seconds. The regex's I was using were > like > <gloss>[^<]*</gloss> --> <gloss></gloss> > i.e. omitting the text contents of the <gloss> element. I do not have any > active folding. My plugins are > Beauty > Check jEdit version > ErrorList > FTP > Highlight > Info Viewer > JDiff plugin (not turned on) > ProjectViewer (not in use) > QuickNotepad > Sessions > Sidekick > Tags > Texttools > Whitespace > XML > I can send my properties file, probably easiest if I send it wherever you > want the XML file. > > Mike Maxwell > |
From: Eric Le L. <ker...@us...> - 2011-06-03 16:25:18
|
Hi, for instance, matching tag highlighting is a component of XML plugin which continuously re-parses the buffer. And it's overriding the standard bracket matching mechanism, which may not be prepared to accomodate long delays (it's only an hypothesis). This is a reason why it may still hang jEdit after the buffer is parsed : it will re-parse a large part of the file every time you'll move the caret, basically. You could try to disable "Highlight matching elements" in the Text Area pane of global options and see if it reduces the load... I've implemented a version of tag-matching based on the already available sidekick information. It's performing better for big XML files but it's less accurate than the original version when you are editing the buffer, since the sidekick tree becomes outdated so I haven't committed it yet. (sorry if re-posting I had troubles with my mail account) Le 01/06/2011 23:45, maxwell a écrit : > On Wed, 1 Jun 2011 22:51:33 +0300, Shlomy Reinstein <sre...@gm...> > wrote: >> Many things can cause the delay when jumping to the end of the buffer - > for >> example, syntax highlighting, SideKick folding mode, etc. It's > impossible >> to say without additional information. Can you make this xml file > available, >> together with the list of plugins you have and the properties file? >> ... >> On Wed, Jun 1, 2011 at 10:39 PM, maxwell <ma...@um...> wrote: >>> ... >>> I tried loading a large XML file (a dictionary, 545k lines) just now > I can't, send the original file, because it's proprietary. But I stripped > out all the data in the elements, leaving only the tags, and reproduced the > problem. The resulting file is about 12 megs. Do you want me to ftp it > somewhere? > > BTW, the problem is not limited to jumping around in the file, it also > happens with search-and-replace. S&R with sidekick parsing turned on hung; > without it, it takes a couple-three seconds. The regex's I was using were > like > <gloss>[^<]*</gloss> --> <gloss></gloss> > i.e. omitting the text contents of the <gloss> element. I do not have any > active folding. My plugins are > Beauty > Check jEdit version > ErrorList > FTP > Highlight > Info Viewer > JDiff plugin (not turned on) > ProjectViewer (not in use) > QuickNotepad > Sessions > Sidekick > Tags > Texttools > Whitespace > XML > I can send my properties file, probably easiest if I send it wherever you > want the XML file. > > Mike Maxwell |
From: Mike M. <ma...@um...> - 2011-06-04 19:00:47
|
On 6/3/2011 12:25 PM, Eric Le Lay wrote: > I've implemented a version of tag-matching based on the already > available sidekick information. It's performing better for big XML > files but it's less accurate than the original version when you are > editing the buffer, since the sidekick tree becomes outdated so I > haven't committed it yet. Clearly there's a trade-off, but for me at least it would be an acceptable trade-off when editing large files. Especially if there were a way to tell it to re-parse the file while I made my coffee :-) On 6/4/2011 12:18 AM, Shlomy Reinstein wrote: > the feature of disabling SideKick for large files can be implemented > by SideKick alone, it can simply not trigger the parsing. If I'm understanding what you're saying here, SideKick could examine the file's size, and if it was above a certain limit, it would not automatically trigger parsing. If that's the case, could it be made to instead invoke Eric's parser? I realize things are getting complex here, so maybe my idea isn't so good because of the UI that would be involved. > If manually aborting the parsing is a suitable solution, we can go > one step forward and do something like Firefox does with scripting: > If it finds that a script takes too much time, it asks the user > whether to abort it. As long as everything works in reasonable time, > the user does not have to see / do anything special. Yes, IMO this would be another (even better) way to handle it. I assume this would be thread-driven, i.e. the parser would be one thread, and the parser-watcher would be another, so that the watcher would still run even if the parser was hogging its own resources. (As you may be able to tell, I've never done thread programming...) -- Mike Maxwell ma...@um... "My definition of an interesting universe is one that has the capacity to study itself." --Stephen Eastmond |
From: Shlomy R. <sre...@gm...> - 2011-06-04 19:27:25
|
Hi, On Sat, Jun 4, 2011 at 10:00 PM, Mike Maxwell <ma...@um...>wrote: > On 6/3/2011 12:25 PM, Eric Le Lay wrote: > > I've implemented a version of tag-matching based on the already > > available sidekick information. It's performing better for big XML > > files but it's less accurate than the original version when you are > > editing the buffer, since the sidekick tree becomes outdated so I > > haven't committed it yet. > > Clearly there's a trade-off, but for me at least it would be an > acceptable trade-off when editing large files. Especially if there were > a way to tell it to re-parse the file while I made my coffee :-) > > On 6/4/2011 12:18 AM, Shlomy Reinstein wrote: > > the feature of disabling SideKick for large files can be implemented > > by SideKick alone, it can simply not trigger the parsing. > > If I'm understanding what you're saying here, SideKick could examine the > file's size, and if it was above a certain limit, it would not > automatically trigger parsing. If that's the case, could it be made to > instead invoke Eric's parser? I realize things are getting complex > here, so maybe my idea isn't so good because of the UI that would be > involved. > > I don't understand what you're suggesting. SideKick invokes the parser that is registered for the edit mode of the buffer. Are you suggesting to configure two separate parsers for an edit mode - one for large files and one for small files? I think the simplest is that the parser checks the file size and operates accordingly. > > If manually aborting the parsing is a suitable solution, we can go > > one step forward and do something like Firefox does with scripting: > > If it finds that a script takes too much time, it asks the user > > whether to abort it. As long as everything works in reasonable time, > > the user does not have to see / do anything special. > > Yes, IMO this would be another (even better) way to handle it. I assume > this would be thread-driven, i.e. the parser would be one thread, and > the parser-watcher would be another, so that the watcher would still run > even if the parser was hogging its own resources. (As you may be able > to tell, I've never done thread programming...) > That was the intention, though for the problem of tag (or bracket) matching as Eric wrote, as far as I understand SideKick is not involved, it's something completely internal to the SideKick parser. > -- > Mike Maxwell > ma...@um... > "My definition of an interesting universe is > one that has the capacity to study itself." > --Stephen Eastmond > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is > safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > Regards, Shlomy |
From: Dale A. <da...@gr...> - 2011-06-04 21:35:05
|
Shlomy, I like your idea of asking the user if it should give up if it takes too long. It would also be good to couple that with the file size check -- if the file is over some size, ask the user before parsing. Along with this, though, I wonder if the xml sidekick needs to be revised? It was one of the first (perhaps the very first) sidekick plugins written. Dale 2011/6/4 Shlomy Reinstein <sre...@gm...> > Hi, > > On Sat, Jun 4, 2011 at 10:00 PM, Mike Maxwell <ma...@um...>wrote: > >> On 6/3/2011 12:25 PM, Eric Le Lay wrote: >> > I've implemented a version of tag-matching based on the already >> > available sidekick information. It's performing better for big XML >> > files but it's less accurate than the original version when you are >> > editing the buffer, since the sidekick tree becomes outdated so I >> > haven't committed it yet. >> >> Clearly there's a trade-off, but for me at least it would be an >> acceptable trade-off when editing large files. Especially if there were >> a way to tell it to re-parse the file while I made my coffee :-) >> >> On 6/4/2011 12:18 AM, Shlomy Reinstein wrote: >> > the feature of disabling SideKick for large files can be implemented >> > by SideKick alone, it can simply not trigger the parsing. >> >> If I'm understanding what you're saying here, SideKick could examine the >> file's size, and if it was above a certain limit, it would not >> automatically trigger parsing. If that's the case, could it be made to >> instead invoke Eric's parser? I realize things are getting complex >> here, so maybe my idea isn't so good because of the UI that would be >> involved. >> >> I don't understand what you're suggesting. SideKick invokes the parser > that is registered for the edit mode of the buffer. Are you suggesting to > configure two separate parsers for an edit mode - one for large files and > one for small files? I think the simplest is that the parser checks the file > size and operates accordingly. > > >> > If manually aborting the parsing is a suitable solution, we can go >> > one step forward and do something like Firefox does with scripting: >> > If it finds that a script takes too much time, it asks the user >> > whether to abort it. As long as everything works in reasonable time, >> > the user does not have to see / do anything special. >> >> Yes, IMO this would be another (even better) way to handle it. I assume >> this would be thread-driven, i.e. the parser would be one thread, and >> the parser-watcher would be another, so that the watcher would still run >> even if the parser was hogging its own resources. (As you may be able >> to tell, I've never done thread programming...) >> > > That was the intention, though for the problem of tag (or bracket) matching > as Eric wrote, as far as I understand SideKick is not involved, it's > something completely internal to the SideKick parser. > > >> -- >> Mike Maxwell >> ma...@um... >> "My definition of an interesting universe is >> one that has the capacity to study itself." >> --Stephen Eastmond >> >> >> ------------------------------------------------------------------------------ >> Simplify data backup and recovery for your virtual environment with >> vRanger. >> Installation's a snap, and flexible recovery options mean your data is >> safe, >> secure and there when you need it. Discover what all the cheering's about. >> Get your free trial download today. >> http://p.sf.net/sfu/quest-dev2dev2 >> -- >> ----------------------------------------------- >> jEdit Users' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-users >> > > Regards, > Shlomy > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is > safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > > |
From: Eric Le L. <ker...@us...> - 2011-06-05 19:33:39
|
Le 04/06/2011 23:09, Dale Anson a écrit : > Shlomy, I like your idea of asking the user if it should give up if it > takes too long. It would also be good to couple that with the file > size check -- if the file is over some size, ask the user before parsing. > > Along with this, though, I wonder if the xml sidekick needs to be > revised? It was one of the first (perhaps the very first) sidekick > plugins written. > I would appreciate help with that ! Especially from you Dale, as you did nice work on parsing in background for the JavaSidekick plugin. > Dale > > > 2011/6/4 Shlomy Reinstein <sre...@gm... <mailto:sre...@gm...>> > > Hi, > > On Sat, Jun 4, 2011 at 10:00 PM, Mike Maxwell > <ma...@um... <mailto:ma...@um...>> wrote: > > On 6/3/2011 12:25 PM, Eric Le Lay wrote: > > I've implemented a version of tag-matching based on the already > > available sidekick information. It's performing better for > big XML > > files but it's less accurate than the original version when > you are > > editing the buffer, since the sidekick tree becomes outdated > so I > > haven't committed it yet. > > Clearly there's a trade-off, but for me at least it would be an > acceptable trade-off when editing large files. Especially if > there were > a way to tell it to re-parse the file while I made my coffee :-) > > On 6/4/2011 12:18 AM, Shlomy Reinstein wrote: > > the feature of disabling SideKick for large files can be > implemented > > by SideKick alone, it can simply not trigger the parsing. > > If I'm understanding what you're saying here, SideKick could > examine the > file's size, and if it was above a certain limit, it would not > automatically trigger parsing. If that's the case, could it > be made to > instead invoke Eric's parser? I realize things are getting > complex > here, so maybe my idea isn't so good because of the UI that > would be > involved. > > I don't understand what you're suggesting. SideKick invokes the > parser that is registered for the edit mode of the buffer. Are you > suggesting to configure two separate parsers for an edit mode - > one for large files and one for small files? I think the simplest > is that the parser checks the file size and operates accordingly. > > I confirm : there is only one parser for XML. > > > If manually aborting the parsing is a suitable solution, we > can go > > one step forward and do something like Firefox does with > scripting: > > If it finds that a script takes too much time, it asks the user > > whether to abort it. As long as everything works in > reasonable time, > > the user does not have to see / do anything special. > > Yes, IMO this would be another (even better) way to handle it. > I assume > this would be thread-driven, i.e. the parser would be one > thread, and > the parser-watcher would be another, so that the watcher would > still run > even if the parser was hogging its own resources. (As you may > be able > to tell, I've never done thread programming...) > > If the parser is frantically allocating memory, this will affect every part of jEdit. Aborting parsing can be done: there is already a stop() method in the Sidekick API, that the XML parser honours. > That was the intention, though for the problem of tag (or bracket) > matching as Eric wrote, as far as I understand SideKick is not > involved, it's something completely internal to the SideKick parser. > > Yes, it's an implementation of StructureMatcher and has nothing to do with Sidekick. What I did, however, is to try to replace custom parsing each time the StructureMatcher is invoked with walking the Sidekick tree. This resulted in a performance boost with big files but reduced accuracy when editing the buffer. It also requires that the file is actually parsed once. I'll try to commit tomorrow night (with a boolean option to switch between the 2 versions so that you can experiment). > > -- > Mike Maxwell > ma...@um... <mailto:ma...@um...> > "My definition of an interesting universe is > one that has the capacity to study itself." > --Stephen Eastmond > > > Regards, > Shlomy > Regards, Eric |
From: Eric Le L. <ker...@us...> - 2011-06-20 20:37:57
|
Le 04/06/2011 21:00, Mike Maxwell a écrit : > On 6/3/2011 12:25 PM, Eric Le Lay wrote: >> I've implemented a version of tag-matching based on the already >> available sidekick information. It's performing better for big XML >> files but it's less accurate than the original version when you are >> editing the buffer, since the sidekick tree becomes outdated so I >> haven't committed it yet. > > Clearly there's a trade-off, but for me at least it would be an > acceptable trade-off when editing large files. Especially if there were > a way to tell it to re-parse the file while I made my coffee :-) > Hi Mike, you can try the latest (2011-06-21 http://www.tellurianring.com/projects/jedit-daily/index.php?dir=XML%2F2011-06-20_12-02-05%2F) XMLPlugin build : I hope it will be much faster at navigating through the file, once parsing has been done, since has the new tag-matching mechanism on by default. To get the old tag-matching back, go to Utilities > Evaluate Beanshell and type jEdit.setProperty("xml.structure-matcher","old"). It should also be a bit faster... Cheers, Eric |
From: Dale A. <da...@gr...> - 2011-06-24 06:12:47
|
Hi Eric, I updated XML plugin to the latest from svn. It looks like there is an issue at XMLParsedData.java in the sort() method. I think the contents of this method needs wrapped in a SwingWorker. I was testing some changes I made in SideKick and was using the big movie xml file that Eric Berry has posted a link to a few times. I wanted the file to be bigger since it was parsing fairly fast for me, so I copied all of the "movie" nodes and tried to paste them at the bottom of the file after the last "movie" node. This causes jEdit to hang. A thread dump shows it's stuck in the sort() method. Also, I've done some work on the threading in SideKick, so the "Stop" button that Shlomy added works well -- or at least, it seems to work well for me. I'd appreciate if you could grab the latest SideKick code and test it out. Thanks, Dale On Mon, Jun 20, 2011 at 2:37 PM, Eric Le Lay <ker...@us... > wrote: > Le 04/06/2011 21:00, Mike Maxwell a écrit : > > On 6/3/2011 12:25 PM, Eric Le Lay wrote: > >> I've implemented a version of tag-matching based on the already > >> available sidekick information. It's performing better for big XML > >> files but it's less accurate than the original version when you are > >> editing the buffer, since the sidekick tree becomes outdated so I > >> haven't committed it yet. > > > > Clearly there's a trade-off, but for me at least it would be an > > acceptable trade-off when editing large files. Especially if there were > > a way to tell it to re-parse the file while I made my coffee :-) > > > Hi Mike, > > you can try the latest (2011-06-21 > > http://www.tellurianring.com/projects/jedit-daily/index.php?dir=XML%2F2011-06-20_12-02-05%2F > ) > XMLPlugin build : > I hope it will be much faster at navigating through the file, once > parsing has been done, > since has the new tag-matching mechanism on by default. > > To get the old tag-matching back, go to Utilities > Evaluate Beanshell > and type > jEdit.setProperty("xml.structure-matcher","old"). It should also be a > bit faster... > > Cheers, > Eric > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > |
From: Shlomy R. <sre...@gm...> - 2011-06-24 09:09:50
|
Thanks, Dale, for doing this change in SideKick. Do the parser threads have a way of terminating cleanly? (e.g. by catching an interrupted exception) Shlomy 2011/6/24 Dale Anson <da...@gr...> > Hi Eric, > > I updated XML plugin to the latest from svn. It looks like there is an > issue at XMLParsedData.java in the sort() method. I think the contents of > this method needs wrapped in a SwingWorker. I was testing some changes I > made in SideKick and was using the big movie xml file that Eric Berry has > posted a link to a few times. I wanted the file to be bigger since it was > parsing fairly fast for me, so I copied all of the "movie" nodes and tried > to paste them at the bottom of the file after the last "movie" node. This > causes jEdit to hang. A thread dump shows it's stuck in the sort() method. > > Also, I've done some work on the threading in SideKick, so the "Stop" > button that Shlomy added works well -- or at least, it seems to work well > for me. I'd appreciate if you could grab the latest SideKick code and test > it out. > > Thanks, > > Dale > > > > On Mon, Jun 20, 2011 at 2:37 PM, Eric Le Lay < > ker...@us...> wrote: > >> Le 04/06/2011 21:00, Mike Maxwell a écrit : >> > On 6/3/2011 12:25 PM, Eric Le Lay wrote: >> >> I've implemented a version of tag-matching based on the already >> >> available sidekick information. It's performing better for big XML >> >> files but it's less accurate than the original version when you are >> >> editing the buffer, since the sidekick tree becomes outdated so I >> >> haven't committed it yet. >> > >> > Clearly there's a trade-off, but for me at least it would be an >> > acceptable trade-off when editing large files. Especially if there were >> > a way to tell it to re-parse the file while I made my coffee :-) >> > >> Hi Mike, >> >> you can try the latest (2011-06-21 >> >> http://www.tellurianring.com/projects/jedit-daily/index.php?dir=XML%2F2011-06-20_12-02-05%2F >> ) >> XMLPlugin build : >> I hope it will be much faster at navigating through the file, once >> parsing has been done, >> since has the new tag-matching mechanism on by default. >> >> To get the old tag-matching back, go to Utilities > Evaluate Beanshell >> and type >> jEdit.setProperty("xml.structure-matcher","old"). It should also be a >> bit faster... >> >> Cheers, >> Eric >> >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking. >> http://p.sf.net/sfu/ephox-dev2dev >> -- >> ----------------------------------------------- >> jEdit Users' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-users >> > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > > |
From: Dale A. <da...@gr...> - 2011-06-24 16:32:12
|
Oops. Apparently I didn't actually check in my changes in SideKick, so getting the latest won't let you see what I've done so far. Shlomy, yes, the threads terminate cleanly -- mostly. I'm using SwingWorker, which has a cancel method. In the case of a cancel, 'stop' is called on the parser. I did notice that the XML plugin throws an interrupted exception when it is cancelled and I haven't looked into it yet. It could be there are other SideKick plugins with similar issues. Dale On Fri, Jun 24, 2011 at 3:09 AM, Shlomy Reinstein <sre...@gm...>wrote: > Thanks, Dale, for doing this change in SideKick. Do the parser threads have > a way of terminating cleanly? (e.g. by catching an interrupted exception) > > Shlomy > > 2011/6/24 Dale Anson <da...@gr...> > >> Hi Eric, >> >> I updated XML plugin to the latest from svn. It looks like there is an >> issue at XMLParsedData.java in the sort() method. I think the contents of >> this method needs wrapped in a SwingWorker. I was testing some changes I >> made in SideKick and was using the big movie xml file that Eric Berry has >> posted a link to a few times. I wanted the file to be bigger since it was >> parsing fairly fast for me, so I copied all of the "movie" nodes and tried >> to paste them at the bottom of the file after the last "movie" node. This >> causes jEdit to hang. A thread dump shows it's stuck in the sort() method. >> >> Also, I've done some work on the threading in SideKick, so the "Stop" >> button that Shlomy added works well -- or at least, it seems to work well >> for me. I'd appreciate if you could grab the latest SideKick code and test >> it out. >> >> Thanks, >> >> Dale >> >> >> >> On Mon, Jun 20, 2011 at 2:37 PM, Eric Le Lay < >> ker...@us...> wrote: >> >>> Le 04/06/2011 21:00, Mike Maxwell a écrit : >>> > On 6/3/2011 12:25 PM, Eric Le Lay wrote: >>> >> I've implemented a version of tag-matching based on the already >>> >> available sidekick information. It's performing better for big XML >>> >> files but it's less accurate than the original version when you are >>> >> editing the buffer, since the sidekick tree becomes outdated so I >>> >> haven't committed it yet. >>> > >>> > Clearly there's a trade-off, but for me at least it would be an >>> > acceptable trade-off when editing large files. Especially if there >>> were >>> > a way to tell it to re-parse the file while I made my coffee :-) >>> > >>> Hi Mike, >>> >>> you can try the latest (2011-06-21 >>> >>> http://www.tellurianring.com/projects/jedit-daily/index.php?dir=XML%2F2011-06-20_12-02-05%2F >>> ) >>> XMLPlugin build : >>> I hope it will be much faster at navigating through the file, once >>> parsing has been done, >>> since has the new tag-matching mechanism on by default. >>> >>> To get the old tag-matching back, go to Utilities > Evaluate Beanshell >>> and type >>> jEdit.setProperty("xml.structure-matcher","old"). It should also be a >>> bit faster... >>> >>> Cheers, >>> Eric >>> >>> >>> ------------------------------------------------------------------------------ >>> EditLive Enterprise is the world's most technically advanced content >>> authoring tool. Experience the power of Track Changes, Inline Image >>> Editing and ensure content is compliant with Accessibility Checking. >>> http://p.sf.net/sfu/ephox-dev2dev >>> -- >>> ----------------------------------------------- >>> jEdit Users' List >>> jEd...@li... >>> https://lists.sourceforge.net/lists/listinfo/jedit-users >>> >> >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense.. >> http://p.sf.net/sfu/splunk-d2d-c1 >> >> -- >> ----------------------------------------------- >> jEdit Users' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-users >> >> > |
From: Dale A. <da...@gr...> - 2011-06-24 20:19:35
|
I have checked in my changes for SideKick. I'm still seeing issues in the XML plugin, but the others I've tested all seem fine. Using the 1 MB movie xml file as a test, it loads very fast, like in 2 or 3 seconds. I did a few copy and pastes and made it a 10 MB file, it still loads and parses in XML SideKick in less than a minute on my laptop. The problems I'm seeing are a combination of out of memory errors from testing with large files and some things in XML sidekick getting run on the EVT that shouldn't be. Eric, if you don't mind, I'll look into those next. Dale On Fri, Jun 24, 2011 at 10:32 AM, Dale Anson <da...@gr...> wrote: > Oops. Apparently I didn't actually check in my changes in SideKick, so > getting the latest won't let you see what I've done so far. > > Shlomy, yes, the threads terminate cleanly -- mostly. I'm using > SwingWorker, which has a cancel method. In the case of a cancel, 'stop' is > called on the parser. I did notice that the XML plugin throws an interrupted > exception when it is cancelled and I haven't looked into it yet. It could be > there are other SideKick plugins with similar issues. > > Dale > > > > On Fri, Jun 24, 2011 at 3:09 AM, Shlomy Reinstein <sre...@gm...>wrote: > >> Thanks, Dale, for doing this change in SideKick. Do the parser threads >> have a way of terminating cleanly? (e.g. by catching an interrupted >> exception) >> >> Shlomy >> >> 2011/6/24 Dale Anson <da...@gr...> >> >>> Hi Eric, >>> >>> I updated XML plugin to the latest from svn. It looks like there is an >>> issue at XMLParsedData.java in the sort() method. I think the contents of >>> this method needs wrapped in a SwingWorker. I was testing some changes I >>> made in SideKick and was using the big movie xml file that Eric Berry has >>> posted a link to a few times. I wanted the file to be bigger since it was >>> parsing fairly fast for me, so I copied all of the "movie" nodes and tried >>> to paste them at the bottom of the file after the last "movie" node. This >>> causes jEdit to hang. A thread dump shows it's stuck in the sort() method. >>> >>> Also, I've done some work on the threading in SideKick, so the "Stop" >>> button that Shlomy added works well -- or at least, it seems to work well >>> for me. I'd appreciate if you could grab the latest SideKick code and test >>> it out. >>> >>> Thanks, >>> >>> Dale >>> >>> >>> >>> On Mon, Jun 20, 2011 at 2:37 PM, Eric Le Lay < >>> ker...@us...> wrote: >>> >>>> Le 04/06/2011 21:00, Mike Maxwell a écrit : >>>> > On 6/3/2011 12:25 PM, Eric Le Lay wrote: >>>> >> I've implemented a version of tag-matching based on the already >>>> >> available sidekick information. It's performing better for big XML >>>> >> files but it's less accurate than the original version when you are >>>> >> editing the buffer, since the sidekick tree becomes outdated so I >>>> >> haven't committed it yet. >>>> > >>>> > Clearly there's a trade-off, but for me at least it would be an >>>> > acceptable trade-off when editing large files. Especially if there >>>> were >>>> > a way to tell it to re-parse the file while I made my coffee :-) >>>> > >>>> Hi Mike, >>>> >>>> you can try the latest (2011-06-21 >>>> >>>> http://www.tellurianring.com/projects/jedit-daily/index.php?dir=XML%2F2011-06-20_12-02-05%2F >>>> ) >>>> XMLPlugin build : >>>> I hope it will be much faster at navigating through the file, once >>>> parsing has been done, >>>> since has the new tag-matching mechanism on by default. >>>> >>>> To get the old tag-matching back, go to Utilities > Evaluate Beanshell >>>> and type >>>> jEdit.setProperty("xml.structure-matcher","old"). It should also be a >>>> bit faster... >>>> >>>> Cheers, >>>> Eric >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> EditLive Enterprise is the world's most technically advanced content >>>> authoring tool. Experience the power of Track Changes, Inline Image >>>> Editing and ensure content is compliant with Accessibility Checking. >>>> http://p.sf.net/sfu/ephox-dev2dev >>>> -- >>>> ----------------------------------------------- >>>> jEdit Users' List >>>> jEd...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jedit-users >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure contains a >>> definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and makes >>> sense of it. Business sense. IT sense. Common sense.. >>> http://p.sf.net/sfu/splunk-d2d-c1 >>> >>> -- >>> ----------------------------------------------- >>> jEdit Users' List >>> jEd...@li... >>> https://lists.sourceforge.net/lists/listinfo/jedit-users >>> >>> >> > |