From: mike d. <md...@je...> - 2001-05-06 18:03:55
|
hey- this morning, over a lovely piece of toast, i uploaded version 0.3 of the OraclePlugin by Sergey Udaltsov. * OraclePlugin 0.3: added the ability to download the source for a procedure, package, function, or trigger from the database into a jEdit buffer; requires jEdit 2.7pre2, EditBus 0.9.4, and JDK 1.1 -md |
From: mike d. <md...@je...> - 2001-05-14 02:07:55
|
howdy- today, i have uploaded a new version of Oliver Rutherfurd's EditorScheme plugin to Plugin Central. * EditorScheme 0.3: fixed JDK 1.1 compatibility problems; added two new schemes; now stores color settings for Console, ErrorList, jDiffPlugin, and WhiteSpace plugins; requires jEdit 2.6final and JDK 1.1 -md |
From: mike d. <md...@je...> - 2001-05-17 15:25:39
|
hey- this morning, i put a new version of Slava's FTP plugin up on Plugin Central. this release is a recommended upgrade for all FTP plugin users, as it is a fair bit faster than previous versions. * FTP 0.2.7: no longer prints each line of LIST output to the activity log, which was a cause of slowdowns in previous releases; requires jEdit 2.7pre2 and JDK 1.1 -md |
From: Rodolfo R. <rr...@ne...> - 2001-05-17 16:42:21
|
mike dillon wrote: > hey- > > this morning, i put a new version of Slava's FTP plugin up on Plugin > Central. this release is a recommended upgrade for all FTP plugin users, > as it is a fair bit faster than previous versions. > > * FTP 0.2.7: no longer prints each line of LIST output to the activity > log, which was a cause of slowdowns in previous releases; requires > jEdit 2.7pre2 and JDK 1.1 > > -md > Is jedit3.2pre with a bug in Plugin manager ? Rodolfo Ricci |
From: mike d. <md...@je...> - 2001-05-17 16:59:42
|
begin Rodolfo Ricci quotation: > mike dillon wrote: > > > hey- > > > > this morning, i put a new version of Slava's FTP plugin up on Plugin > > Central. this release is a recommended upgrade for all FTP plugin users, > > as it is a fair bit faster than previous versions. > > > > * FTP 0.2.7: no longer prints each line of LIST output to the activity > > log, which was a cause of slowdowns in previous releases; requires > > jEdit 2.7pre2 and JDK 1.1 > > > > -md > > > Is jedit3.2pre with a bug in Plugin manager ? the Plugin Manager is being moved into the core and update and install are not yet re-implemented (cf. http://www.gjt.org/servlets/JCVSlet/show/gjt/org/gjt/sp/jedit/pluginmgr/PluginManager.java/1.3). i suppose that means that jEdit 3.2pre1 users need to download the FTP plugin from Plugin Central and install it by hand. -md |
From: Slava P. <sl...@je...> - 2001-05-18 07:00:49
|
On Thu, May 17, 2001 at 01:42:27PM -0300, Rodolfo Ricci wrote: > Is jedit3.2pre with a bug in Plugin manager ? I released 3.2pre1 without a functional plugin manager so that users could test the other new features quicker. I am going to release 3.2pre2 soon, which will have a working plugin manager (supporting automatic dependency resolution!), among other things. Slava |
From: mike d. <md...@je...> - 2001-05-23 02:18:42
|
howdy- this afternoon, a new version of the Console plugin by Slava Pestov made its way to Plugin Central. all you Ant-heads and .NET-heads are going to want this one. stragglers not yet running jEdit 3.1 need not apply. * Console 2.4.7: Microsoft .net error pattern added (Ollie Rutherfurd) (2.4.6); removed deprecated API usage (2.4.6); fixed broken Ant error pattern; requires jEdit 3.1final, EditBus 1.0, ErroList 1.0, and JDK 1.1 -md |
From: mike d. <md...@je...> - 2001-06-14 02:22:32
|
hi- this morning, i released an updated version of Slava's Console plugin on Plugin Central. * Console 2.6: Windows built-in commands should now work; Console now tries running commands from the current directory, and only then falls back to the system's default directory; requires jEdit 3.1final, EditBus 1.0, ErrorList 1.0, and JDK 1.1 -md |
From: mike d. <md...@je...> - 2001-08-21 05:52:09
|
howdy- this evening, i packaged and released the latest version of the XML plugin, updated with recently contributed code by David Walend as well as new stuff from Slava Pestov. * XML 0.3: now uses Xerces (included), instead of microstar.xml; on-the-fly parsing can be disabled (its disabled by default); display of attributes can be configured, attributes shown in status bar if XML tree docked; option pane for changing various settings; code cleanup and reorganization; includes the start of a configurable system ID/public ID resolver; optionally validates against a DTD or schema (when available); requires jEdit 3.2pre9, EditBus 1.0.1, ErrorList 1.1, and JDK 1.1. -md -- "Unvalidated documents: your gun, your bullet, your foot." -- Norm Walsh |
From: Joe P. <jpo...@cd...> - 2001-08-21 13:05:42
|
I'm happy to see that the ALT + key mnemonic problem has been resolved, but there are some other issues that I, at least, would like to see resolved before 3.2 final comes out. In no particular order: 1. jEdit's plugin manager apparently installed two jar files, crimson.jar and jaxp.jar, that are obsolete. Each time I load it suggests I remove them. Would I be disabling a plugin by doing so, (and, just out of curiosity, which ones)? 2. The code in the source distribution is older (by a few weeks or, in some cases, a few months) than identically named files that came with the installer. Most of the macro and mode directories are in this category. 3. jEdit is hanging an embarrassing number of times. This is frequently associated with trying to open a .txt file by double clicking the filename in Windows Explorer. 4. Loss of focus after closing a file with CRTL + W. After closing a buffer, I'd expect the next buffer that I see to also get focus so that I can hit CRTL + W again and close it too. Instead I have to click the screen with the mouse and then hit CRTL + W. This problem is sporadic but it fairly consistent in the following situation: With jEdit loaded and several buffers open, exit without first closing each buffer. Now reload jEdit. Now, before doing anything else, try to close each buffer using only CRTL + W. 5. jEdit has taken to inserting a line of underscores where there would otherwise be a blank line. The line is not commented but doesn't interfere with compilation. It just looks weird. [These next two might be feature requests instead of problems] 6. Settings (global and buffer options) sometimes (but not always) govern the buffer rather than the file loaded into it. Normally my margin is set to screen width (97) in global options. If set the buffer options differently (say 72 for something destined for email) then save the file, upon reopening the file, the text appears formatted as it was when saved, but the margin setting itself has reverted to the setting in global options. I'd like to have an option to set buffer options to 'Sticky', by which I mean that the jEdit would remember those settings and restore the buffer options upon reloading. 7. Conversely, I'd like an option to set the Default Line Ending to 'Set in Granite' by which I mean that the setting in global options should not be reset by the file being loaded. (Which happens regularly as I open for the first time in jEdit files previously saved with Mac line separators). Or perhaps there ought to be 4 options. DOS, Mac, Unix and 'as loaded', with only the last making it possible for the contents of the file to reset the global option setting. Finally, 8. I'd like to second the suggestion that the user should be able able to position the cursor beyond the end of a line. Past experience with an editor where this was possible indicates that it would simplify writing macros if we knew that upArrow() and downArrow() would not change the cursor's column position. Thanks for listening, Joe (NT4/sp6, jEdit 3.2pre9, Sun's jdk 1.4) |
From: John G. <jge...@ny...> - 2001-08-21 13:40:06
|
> 3. jEdit is hanging an embarrassing number of times. This is frequently > associated with trying to open a .txt file by double clicking the > filename > in Windows Explorer. What command line are you using for "open" with a .txt file? In what other circumstances does it hang? John |
From: Joe P. <jpo...@cd...> - 2001-08-21 16:38:39
|
> > 3. jEdit is hanging an embarrassing number of times. This is frequently > > associated with trying to open a .txt file by double clicking the > > filename > > in Windows Explorer. > >What command line are you using for "open" with a .txt file? In what other >circumstances does it hang? The command for opening .txt files: E:\JPackages\jEdit\jedit.exe "%1" After further attempts to recreate the "phenomenon" (I'm leaving open the possibility that I am the "problem"), here's what I've found: With jEdit already loaded, I double click on a .txt (non zero length) file in windoze explorer and it opens. The screen shifts to jEdit and I see the text and use the scrollbar. Without doing anything else I go back to windows explorer and I doubleclick on a zero length .txt file. This causes jEdit to "popup" a dialog box telling me that the 'file' is really a directory and cannot be edited. Actually, there are two. One refers to the jEdit home directory and the other refers to the directory containing the file I doubleclicked. Neither mentions the file I clicked on. Unfortunately, these dialog box act like they are modal, so the jEdit screen doesn't accept user input, but they aren't visible. So I concluded that jEdit was hung. I just chanced to notice Sun's trademark "Cup" of Java while alt tabbing to another app. After selecting it I got the dialog box and after clicking ok on both boxes, jEdit resumed accepting user input. |
From: John G. <jge...@ny...> - 2001-08-21 18:28:50
|
> > > 3. jEdit is hanging an embarrassing number of times. This is > frequently > > > associated with trying to open a .txt file by double clicking the > > > filename > > > in Windows Explorer. > > > >What command line are you using for "open" with a .txt file? In > what other > >circumstances does it hang? > > The command for opening .txt files: E:\JPackages\jEdit\jedit.exe "%1" > > After further attempts to recreate the "phenomenon" (I'm leaving open the > possibility that I am the "problem"), here's what I've found: > > With jEdit already loaded, I double click on a .txt (non zero > length) file > in windoze explorer and it opens. The screen shifts to jEdit and > I see the > text and use the scrollbar. > > Without doing anything else I go back to windows explorer and I > doubleclick > on a zero length .txt file. > > This causes jEdit to "popup" a dialog box telling me that the 'file' is > really a directory and cannot be edited. Actually, there are two. One > refers to the jEdit home directory and the other refers to the directory > containing the file I doubleclicked. Neither mentions the file I > clicked on. > > Unfortunately, these dialog box act like they are modal, so the jEdit > screen doesn't accept user input, but they aren't visible. So I concluded > that jEdit was hung. > > I just chanced to notice Sun's trademark "Cup" of Java while alt > tabbing to > another app. After selecting it I got the dialog box and after > clicking ok > on both boxes, jEdit resumed accepting user input. > I tried this procedure using jEdit3.2pre9, Window 2000 SP2 and both JDK1.3.1 and JDK1.4-beta. Under JDK 1.3.1, I had none of the problems you described. Under JDK1.4, jEdit hung at startup until I removed the WheelMouse plugin. Then the files loaded properly. However, the text area was not being painted properly. Lines below the editing caret were either hidden or displayed in incorrect colors until I scrolled down past them. They reverted to incorrect colors when I scrolled up above them. This also occurred when no plugins were loaded. On your installation, you might want to confirm that your classpath points to Java runtime files corresponding to the JDK you are using. You should also make sure your plugins are current. John |
From: Joe P. <jpo...@cd...> - 2001-08-21 21:30:39
|
>I tried this procedure using jEdit3.2pre9, Window 2000 SP2 and both JDK1.3.1 >and JDK1.4-beta. > >Under JDK 1.3.1, I had none of the problems you described. > >Under JDK1.4, jEdit hung at startup until I removed the WheelMouse plugin. >Then the files loaded properly. However, the text area was not being >painted properly. Lines below the editing caret were either hidden or >displayed in incorrect colors until I scrolled down past them. They >reverted to incorrect colors when I scrolled up above them. This also >occurred when no plugins were loaded. > >On your installation, you might want to confirm that your classpath points >to Java runtime files corresponding to the JDK you are using. You should >also make sure your plugins are current. I don't have the WheelMouse plugin and the Plugin Manager indicated I have the latest versions of all plugins that I have. I don't keep a system classpath and the system path statement doesn't refer to java at all. (I usually launch apps from .bat files). The command line from the launcher: "C:\Program Files\JavaSoft\JRE\1.4\bin\javaw.exe" -mx64m -classpath %CLASSPATH%;"C:\Program Files\JavaSoft\JRE\1.4\lib\rt.jar;E:\JPackages\jEdit\jedit.jar" org.gjt.sp.jedit.jEdit When reverting to java 1.3.1 I changed the version numbers in both places above. Putting equivalent commands in a .bat file made no difference. With this configuration, I noted the same behavior with 1.3.1 as with 1.4. But I think I can explain it better now and restrict the scope of the issue: When I double clicked on a .txt file containing text in windows explorer jEdit got focus and I saw the contents of the file in the current buffer. When I doubleclicked on a zero length .txt file, jEdit pops up the dialog boxes I described earlier, but I don't see them as I'm still seeing the windows explorer screen. If (using the mouse) I minimize windows explorer, I see the jEdit screen and the first dialog box. After clearing the two boxes jEdit accepts user input. If (using the mouse) I click on the jEdit icon on the task bar, jEdit comes up but the first dialog box is hidden. I see only the current buffer, but no user input is possible until I find and clear the two dialog boxes. So, the issue has been narrowed to: Is jEdit having a problem opening zero length files? If this is a design limitation instead of a bug, I'd ask for a more informative message in the dialog box. Should I see something different on screen depending on whether I click to minimize windows explorer or click on the taskbar to maximize jEdit? If not, this might be a problem with windows NT rather than jEdit. I'm still seeing something different than you are, John, but I notice that we have different versions of windows (NT vs 2000). Perhaps other users could help establish what jEdit is doing and what the OS and its configuration are doing. Joe |
From: John G. <jge...@ny...> - 2001-08-21 22:40:32
|
> I don't keep a system classpath and the system path statement > doesn't refer > to java at all. (I usually launch apps from .bat files). > > The command line from the launcher: > > "C:\Program Files\JavaSoft\JRE\1.4\bin\javaw.exe" -mx64m -classpath > %CLASSPATH%;"C:\Program > Files\JavaSoft\JRE\1.4\lib\rt.jar;E:\JPackages\jEdit\jedit.jar" > org.gjt.sp.jedit.jEdit I'm sorry, I wasn't being clear. I was referring to the contents of your CLASSPATH variable. If it points to class files from other JDK's they could shadow the ones you want in 1.4. > > When reverting to java 1.3.1 I changed the version numbers in both places > above. Putting equivalent commands in a .bat file made no difference. > > With this configuration, I noted the same behavior with 1.3.1 as > with 1.4. > But I think I can explain it better now and restrict the scope of > the issue: > > When I double clicked on a .txt file containing text in windows explorer > jEdit got focus and I saw the contents of the file in the current buffer. > When I doubleclicked on a zero length .txt file, jEdit pops up the dialog > boxes I described earlier, but I don't see them as I'm still seeing the > windows explorer screen. > > If (using the mouse) I minimize windows explorer, I see the jEdit screen > and the first dialog box. After clearing the two boxes jEdit accepts user > input. > > If (using the mouse) I click on the jEdit icon on the task bar, > jEdit comes > up but the first dialog box is hidden. I see only the current buffer, but > no user input is possible until I find and clear the two dialog boxes. > > So, the issue has been narrowed to: > > Is jEdit having a problem opening zero length files? If this is a design > limitation instead of a bug, I'd ask for a more informative > message in the > dialog box. I routinely open zero-length files on my installation, and I was able to do so under both JDK 1.3.1 and 1.4. The dialog is coming out of a method called FileVFS.load() deep in the buffer loading routine which tests whether the File object created from the path name you supply is a directory. Apparently it is happening twice. If I can get you to supply once more piece of data, after you try to open a zero-length file by double-clicking, get the BeanShell script that the EditServer gets from jEditLauncher. It should be dumped to the Activity Log. Look for lines beginning "[debug] EditServer". Thanks for your patience. John |
From: Joe P. <jpo...@cd...> - 2001-08-22 12:58:38
|
> > I don't keep a system classpath and the system path statement > > doesn't refer > > to java at all. (I usually launch apps from .bat files). > > > > The command line from the launcher: > > > > "C:\Program Files\JavaSoft\JRE\1.4\bin\javaw.exe" -mx64m -classpath > > %CLASSPATH%;"C:\Program > > Files\JavaSoft\JRE\1.4\lib\rt.jar;E:\JPackages\jEdit\jedit.jar" > > org.gjt.sp.jedit.jEdit > >I'm sorry, I wasn't being clear. I was referring to the contents of your >CLASSPATH variable. If it points to class files from other JDK's they could >shadow the ones you want in 1.4. CLASSPATH is empty > When reverting to java 1.3.1 I changed the version numbers in both places > > above. Putting equivalent commands in a .bat file made no difference. > > > > Is jEdit having a problem opening zero length files? If this is a design > > limitation instead of a bug, I'd ask for a more informative > > message in the > > dialog box. > >I routinely open zero-length files on my installation, and I was able to do >so under both JDK 1.3.1 and 1.4. > >The dialog is coming out of a method called FileVFS.load() deep in the >buffer loading routine which tests whether the File object created from the >path name you supply is a directory. Apparently it is happening twice. > >If I can get you to supply once more piece of data, after you try to open a >zero-length file by double-clicking, get the BeanShell script that the >EditServer gets from jEditLauncher. It should be dumped to the Activity >Log. Look for lines beginning "[debug] EditServer". I'm sending you two files copied from activity.log as sending them to the list exceeded the 40K size limit on posts. The list moderator can delete that post. (Upon request, I'll send these files to other detectives on the list as well.) Thanks for your help, Joe |
From: John G. <jge...@ny...> - 2001-08-22 13:54:07
|
> I'm sending you two files copied from activity.log as sending them to the > list exceeded the 40K size limit on posts. The list moderator can delete > that post. > > (Upon request, I'll send these files to other detectives on the > list as well.) > > Thanks for your help, > > Joe > Well, here's the problem (I've edited the log for clarity): [message] EditServer: connected [debug] EditServer: authenticated successfully [debug] EditServer$1: Script received by edit server: v = new java.util.Vector(8); // here it is: an empty file name v.addElement(""); s = v.size(); args = new String[s]; v.copyInto(args); EditServer.handleClient(true, null, args); jEdit.openFile(jEdit.getFirstView(), args[s - 1]); [debug] EditBus: [source=jEdit (E:\JPackages\), what=LOAD_STARTED,view=null] When you double click, the Windows shell should grab the name of the file and substitute it as %1 in the command line you associated with .txt files in Windows Explorer. That's not happenning. I think %1 gets replaced by a zero-length string and the system sends a pair of double-quotes as a parameter to jedit.exe. That program sends a zero-length string to the launcher's BeanShell script writer, and the rest you already know. The bug seems to be that the Windows shell isn't seeing a zero-length file correctly. There are three regression tests for that: (1) go to a command line and run "jedit.exe [name of zero-length file]" (adding paths as appropriate); (2) take the quotes away from "%1" and double-click a zero-length text file without blank spaces in in its full path; (3) change your "open" verb for .txt files to Windows Notepad and see if you can open a zero-length file (with the file name in the title bar as confirmation). The other bit of relevant information is the version of your Windows shell. Go to C:\WINNT\System32 in Explorer, right-click shell32.dll, select "Properties" and then the "Version" tab and tell us the version number. In the meantime, I'll look around for reports of shell problems with zero-length files. John |
From: Joe P. <jpo...@cd...> - 2001-08-22 15:09:38
|
>Well, here's the problem (I've edited the log for clarity): > >[message] EditServer: connected >[debug] EditServer: authenticated successfully >[debug] EditServer$1: Script received by edit server: > v = new java.util.Vector(8); > > // here it is: an empty file name > v.addElement(""); > > s = v.size(); > args = new String[s]; > v.copyInto(args); > EditServer.handleClient(true, null, args); > jEdit.openFile(jEdit.getFirstView(), args[s - 1]); > >[debug] EditBus: [source=jEdit (E:\JPackages\), >what=LOAD_STARTED,view=null] > >When you double click, the Windows shell should grab the name of the file >and substitute it as %1 in the command line you associated with .txt files >in Windows Explorer. That's not happenning. I think %1 gets replaced by a >zero-length string and the system sends a pair of double-quotes as a >parameter to jedit.exe. >That program sends a zero-length string to the launcher's BeanShell script >writer, and the rest you already know. > >The bug seems to be that the Windows shell isn't seeing a zero-length file >correctly. There are three regression tests for that: Mixed results: >(1) go to a command line and run "jedit.exe [name of zero-length file]" >(adding paths as appropriate); Result: As before, two dialog boxes, etc. >(2) take the quotes away from "%1" and double-click a zero-length text file >without blank spaces in in its full path; Open Action: E:\JPackages\jEdit\jedit.exe %1 Result: As before, two dialog boxes, etc. (Note: This open action is unstable. It had changed itself to E:\JPackages\jEdit\jedit.exe when I went back to reset it. Repeating the above with E:\JPackages\jEdit\jedit.exe produced the same results) >(3) change your "open" verb for .txt files to Windows Notepad and see if you >can open a zero-length file (with the file name in the title bar as >confirmation). Open Action: C:\WINNT\System32\Notepad.exe "%1" Result: Notepad pops up with the correct filename in the title bar. No content in the file. (I used the same zero length file I was using with jEdit above. There are no spaces in the path/filename). >The other bit of relevant information is the version of your Windows shell. >Go to C:\WINNT\System32 in Explorer, right-click shell32.dll, select >"Properties" and then the "Version" tab and tell us the version number. Version 4.00 Joe |
From: John G. <jge...@ny...> - 2001-08-22 22:34:13
|
> Mixed results: > > >(1) go to a command line and run "jedit.exe [name of zero-length file]" > >(adding paths as appropriate); > > Result: As before, two dialog boxes, etc. > > >(2) take the quotes away from "%1" and double-click a > zero-length text file > >without blank spaces in in its full path; > > Open Action: E:\JPackages\jEdit\jedit.exe %1 > Result: As before, two dialog boxes, etc. > > (Note: This open action is unstable. It had changed itself to > E:\JPackages\jEdit\jedit.exe when I went back to reset it. Repeating the > above with E:\JPackages\jEdit\jedit.exe produced the same results) > > >(3) change your "open" verb for .txt files to Windows Notepad > and see if you > >can open a zero-length file (with the file name in the title bar as > >confirmation). > > Open Action: C:\WINNT\System32\Notepad.exe "%1" > Result: Notepad pops up with the correct filename in the title bar. No > content in the file. (I used the same zero length file I was using with > jEdit above. There are no spaces in the path/filename). > > >The other bit of relevant information is the version of your > Windows shell. > >Go to C:\WINNT\System32 in Explorer, right-click shell32.dll, select > >"Properties" and then the "Version" tab and tell us the version number. > > Version 4.00 > > Joe Your version of shell32.dll is the original NT4.0 version. Later versions would have been installed along with Windows Internet Explorer version 4x if you elected to have the Active Desktop. Just a point of information; none of the Win32 API calls in jedit.exe require later versions of shell32.dll, and it's not officially deprecated. But most folks probably have a later version; maybe that's why no one else has reported the bug. It looks like the problem is somewhere inside of jedit.exe. The only thing I can think of right now is this: jedit.exe uses WinMain() as the entry point, which provides the command line in a single unparsed string. The runtime makes a conventional pair of argc and argv available as "built-in variables". They may not be working correctly in version 4.00 of shell32.dll. I am sending to you directly a archive containing a "special build" of jedit.exe that uses main(int, char**) as the entry point. It is otherwise identical to the release version and it performs identically to the current release on my installation. Rename your existing version of jedit.exe and try this one. John John |
From: Joe P. <jpo...@cd...> - 2001-08-23 13:36:37
|
At 06:34 PM 8/22/01 -0400, you wrote: > > Mixed results: > > > > >(1) go to a command line and run "jedit.exe [name of zero-length file]" > > >(adding paths as appropriate); > > > > Result: As before, two dialog boxes, etc. > > > > >(2) take the quotes away from "%1" and double-click a > > zero-length text file > > >without blank spaces in in its full path; > > > > Open Action: E:\JPackages\jEdit\jedit.exe %1 > > Result: As before, two dialog boxes, etc. > > > > (Note: This open action is unstable. It had changed itself to > > E:\JPackages\jEdit\jedit.exe when I went back to reset it. Repeating the > > above with E:\JPackages\jEdit\jedit.exe produced the same results) > > > > >(3) change your "open" verb for .txt files to Windows Notepad > > and see if you > > >can open a zero-length file (with the file name in the title bar as > > >confirmation). > > > > Open Action: C:\WINNT\System32\Notepad.exe "%1" > > Result: Notepad pops up with the correct filename in the title bar. No > > content in the file. (I used the same zero length file I was using with > > jEdit above. There are no spaces in the path/filename). > > > > >The other bit of relevant information is the version of your > > Windows shell. > > >Go to C:\WINNT\System32 in Explorer, right-click shell32.dll, select > > >"Properties" and then the "Version" tab and tell us the version number. > > > > Version 4.00 > > > > Joe > >Your version of shell32.dll is the original NT4.0 version. Later versions >would have been installed along with Windows Internet Explorer version 4x if >you elected to have the Active Desktop. Just a point of information; none >of the Win32 API calls in jedit.exe require later versions of shell32.dll, >and it's not officially deprecated. But most folks probably have a later >version; maybe that's why no one else has reported the bug. > >It looks like the problem is somewhere inside of jedit.exe. The only thing >I can think of right now is this: jedit.exe uses WinMain() as the entry >point, which provides the command line in a single unparsed string. The >runtime makes a conventional pair of argc and argv available as "built-in >variables". They may not be working correctly in version 4.00 of >shell32.dll. I am sending to you directly a archive containing a "special >build" of jedit.exe that uses main(int, char**) as the entry point. It is >otherwise identical to the release version and it performs identically to >the current release on my installation. Rename your existing version of >jedit.exe and try this one. (Note: the following took place after uninstalling BufferTabs to resolve other issues). I copied my existing jedit.exe to a safe place and overwrote it with this new version. There was no difference in jEdit's behavior. I also repeated the first two regression tests and got the same results. The portion of the activity log isolated earlier: [message] EditServer: Socket[addr=/127.0.0.1,port=1252,localport=1251]: connected [debug] EditServer: Socket[addr=/127.0.0.1,port=1252,localport=1251]: authenticated successfully [debug] EditServer$1: v = new java.util.Vector(8); v.addElement(""); s = v.size(); args = new String[s]; v.copyInto(args); EditServer.handleClient(true, null, args); jEdit.openFile(jEdit.getFirstView(), args[s - 1]); At this point I wouldn't rule out a problem with the windows shell since the problem only occurs when doubleclicking a filename in windows explorer. jEdit by itself can open a zero length file when using the File | Open menu, navigating to the file and selecting it in the filechooser. On the other hand jEdit may be getting confused by input from the shell. Somehow it concludes that the file is a directory and not even the correct directory. The two dialog boxes mention jEdit's home directory and the directory containing the file in the current buffer even when neither of these contains the target file. Meanwhile, I'm going to see if I can get an updated shell32.dll without completely re-installing IE. I currently have 5.5. Thanks for looking into this. Joe |
From: John G. <jge...@ny...> - 2001-08-23 14:03:48
|
> I copied my existing jedit.exe to a safe place and overwrote it with this > new version. There was no difference in jEdit's behavior. I also repeated > the first two regression tests and got the same results. > > The portion of the activity log isolated earlier: > [message] EditServer: Socket[addr=/127.0.0.1,port=1252,localport=1251]: > connected > [debug] EditServer: Socket[addr=/127.0.0.1,port=1252,localport=1251]: > authenticated successfully > [debug] EditServer$1: v = new java.util.Vector(8); v.addElement(""); s = > v.size(); args = new String[s]; v.copyInto(args); > EditServer.handleClient(true, null, args); > jEdit.openFile(jEdit.getFirstView(), args[s - 1]); > > > At this point I wouldn't rule out a problem with the windows shell since > the problem only occurs when doubleclicking a filename in windows > explorer. > jEdit by itself can open a zero length file when using the File | Open > menu, navigating to the file and selecting it in the filechooser. > > On the other hand jEdit may be getting confused by input from the shell. > Somehow it concludes that the file is a directory and not even > the correct > directory. The two dialog boxes mention jEdit's home directory and the > directory containing the file in the current buffer even when neither of > these contains the target file. > > Meanwhile, I'm going to see if I can get an updated shell32.dll without > completely re-installing IE. I currently have 5.5. > > Thanks for looking into this. > > Joe > Because shell32.dll is usually loaded in memory, you'll probably have trouble swapping it yourself without installing or reinstalling a version of IE with Active Desktop enabled. If you're stymied I can hack a small executable from my installer code. It's the least I can do. Would you be willing to try another "special build" that dumps some command data to stderr? As I recall, you have the problem running "jedit [zero-length file]" from a command line. John |
From: Joe P. <jpo...@cd...> - 2001-08-23 14:47:37
|
>Because shell32.dll is usually loaded in memory, you'll probably have >trouble swapping it yourself without installing or reinstalling a version of >IE with Active Desktop enabled. If you're stymied I can hack a small >executable from my installer code. It's the least I can do. If you build it, they will install. Sure, I'll try it. >Would you be willing to try another "special build" that dumps some command >data to stderr? As I recall, you have the problem running "jedit >[zero-length file]" from a command line. Yes. Glad to help. Joe |
From: Rick O. <ric...@ya...> - 2001-08-22 15:22:51
|
Greetings, I would like to write a simple macro to bind to a key. The purpose of the macro would be to make the current line (i.e. the line on which the cursor sits) become the top line of the screen, preserving any selection that has been started (preferrably). I have looked in the users guide in section 20.6.3.1, but I haven't been able to find the right combination of methods that will do what I want. I have a macro (2 lines but it works!) that positions the cursor to the top of the screen, but it doesn't reposition the textarea, it just moves the cursor. The emacs command that does what I would like to do is "show-point-at-top-of-window". Thanks, Rick PS The second part would be to bind the macro to a key. A pointer to the section in the manual or the help file where that is described would be appreciated. ===== "Don't ever take a fence down until you know why it was put up." (G.K. Chesterton) __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ |
From: Slava P. <sl...@je...> - 2001-08-23 04:00:34
|
Hi, Try using the textArea.setFirstLine() method. It scrolls the text area without moving the caret or affecting the selection. To bind a macro to a key, see Utilities->Global Options->Shortcuts. Slava On Wed, Aug 22, 2001 at 08:22:50AM -0700, Rick Owen wrote: > Greetings, > > I would like to write a simple macro to bind to a key. The purpose of the macro would be to make > the current line (i.e. the line on which the cursor sits) become the top line of the screen, > preserving any selection that has been started (preferrably). I have looked in the users guide in > section 20.6.3.1, but I haven't been able to find the right combination of methods that will do > what I want. I have a macro (2 lines but it works!) that positions the cursor to the top of the > screen, but it doesn't reposition the textarea, it just moves the cursor. The emacs command that > does what I would like to do is "show-point-at-top-of-window". > > Thanks, > Rick > > PS > The second part would be to bind the macro to a key. A pointer to the section in the manual or > the help file where that is described would be appreciated. > > ===== > "Don't ever take a fence down until you know why it was put up." (G.K. Chesterton) > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ |
From: Rick O. <ric...@ya...> - 2001-08-23 12:40:21
|
Thanks Slava, I didn't find setFirstLine() in the documentation, but just guessing, I tried textArea.setFirstLine(textArea.getCaretLine()); and it did the trick. Thanks, Rick --- Slava Pestov <sl...@je...> wrote: > Hi, > > Try using the textArea.setFirstLine() method. It scrolls the text area > without moving the caret or affecting the selection. > > To bind a macro to a key, see Utilities->Global Options->Shortcuts. > > Slava > > On Wed, Aug 22, 2001 at 08:22:50AM -0700, Rick Owen wrote: > > Greetings, > > > > I would like to write a simple macro to bind to a key. The purpose of the macro would be to > make > > the current line (i.e. the line on which the cursor sits) become the top line of the screen, > > preserving any selection that has been started (preferrably). I have looked in the users > guide in > > section 20.6.3.1, but I haven't been able to find the right combination of methods that will > do > > what I want. I have a macro (2 lines but it works!) that positions the cursor to the top of > the > > screen, but it doesn't reposition the textarea, it just moves the cursor. The emacs command > that > > does what I would like to do is "show-point-at-top-of-window". > > > > Thanks, > > Rick > > > > PS > > The second part would be to bind the macro to a key. A pointer to the section in the manual > or > > the help file where that is described would be appreciated. > > ===== "Don't ever take a fence down until you know why it was put up." (G.K. Chesterton) __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ |