Checked in and tagged "Templates-5_1_0" after OK from Steve Jakob.
Templates plugin 5.1.0
Tagging for release 5.1.0
Bug fixes and improvements for release 5.1.0
Templates plugin
Display_Shortcuts.bsh_utils.patch
Build failing due to JavaDoc linting under recent OpenJDK 19+ (except Ubuntu)
Yes, I think so.
Can confirm. Would be better to do nothing or say something like "Directory deleted".
deleting an expanded directory in VFSBrowser results in IO error dialog
VFSManager.error is called by a lot of VFS code but I haven't reproduced the error in other cases. Running: - jEdit trunk 25703 - openjdk version "11.0.22" 2024-01-16 - ArchLinux
Fix #4132 freeze when deleting a directory and some children (race condition)
freeze when deleting a directory and some children (race condition)
@ezust is ok to close?
Good work! Seems to work now. Thank you very much for all your time and assistance, have a great day.
My mistake! It's not normal: I didn't check that the downloaded libs were correctly copied. I've made a PR with a fix. Please take it and re-tag (same number or preferably a new one if somebody has downloaded the bad release already).
Hi, it seems it's available now, but that dependency libraries didn't get included in plugin zip file. Could you please check? Or is it normal / I'm missing something?
BinEd 0.2.1
Thanks, version 0.2.1.1 has been released. It should appear on plugin central (http://plugins.jedit.org/list.php) soon. Please let me know if something doesn't look right there.
build-support: configurable extra and package file location
build-support: specify source and target when compiling
pjo/ant was using bad property to find PLUGIN.props
pjo/ant copy ivy donwnloaded libs before view; remove splash
pjo/ant don't copy to clipboard, doesn't play nice in a container
pjo/ant java 8 and 11
pjo/ant fix jedit repo url
pjo/ant more restrictive props file finding pattern
Well, the complete entry for the catalog file is <MODE NAME="SPARQL" FILE="sparql.xml" FILE_NAME_GLOB="*.{rq,sparql}" />
Mode for SPARQL file
Plugin was using merged jar (fat-jar) before, so there were no jar dependencies before... I tried to create build.xml in https://github.com/exbin/bined-jedit-plugin but it seems I have some issues with paths or something. I have only limited experiences with ant, so I would be grateful for any advice how to pass jars into target jar. Thanks.
Beauty 1.1
Dale, do you still intend to release a new version with a new tag? Cheers,
Hi, I see 2 issues with packaging the plugin: It is mandatory that you list libraries bundled with the plugin in src/main/resources/BinEd.props: plugin.className.jars Contains a whitespace-separated list of JAR file names. Without this property, the plugin manager will leave behind the external JAR files when removing the plugin. See http://jedit.org/api/org/gjt/sp/jedit/EditPlugin.html I prefer that you use ant and the build-support project so that I can build against chosen of jEdit, create the...
JEdit Displaying Unicode characters ans Empty/Blank Boxes
Thanks, The additional fonts settings seems to have fixed this. Thanks Dennis On Wed, 31 Jan 2024 at 13:17, Marcelo Vanzin vanza@users.sourceforge.net wrote: Works for me. Maybe the font you have for your text area doesn't have that glyph. Also try enabling "Additional fonst with font substitution" in the Global Options -> Text Area pane. [bugs:#4131] https://sourceforge.net/p/jedit/bugs/4131/ JEdit Displaying Unicode characters ans Empty/Blank Boxes Status: open Group: normal bug Labels: unicode...
Works for me. Maybe the font you have for your text area doesn't have that glyph. Also try enabling "Additional fonst with font substitution" in the Global Options -> Text Area pane.
JEdit Displaying Unicode characters ans Empty/Blank Boxes
BinEd 0.2.1
Hi, thank you for the plugin. I'll take a look next week at the earliest. Cheers,
BinEd 0.2.1
There is no problem with the red frame in the left window of the attached image. The red frame in the right window is extra space. jEdit Version: 5.6.0
There is no problem with the red frame in the left window of the attached image. The red frame in the right window is extra space.
Extra space appears around dockable button
Can conform. JEdit can not find Java 21, either. Mac OS: 14.1.1
Can conform. JEdit can not find Java 21, either.
jEdit full-screen lies under Windows task bar
JEdit.app starts a different Java app
Should hopefully work fine by now. If not, please reopen or leave a comment.
NoSuchMethodException in OSXAdapter.java
This should long be fixed already in the newer Mac OS Support 1.5 plugin, which will also be shipped with jEdit 5.7.0, but can also manually be installed through the plugin manager.
Mac OS X Support plugin exception with Java 9-ea+157
This should long be fixed already in the newer Mac OS Support 1.5 plugin, which will also be shipped with jEdit 5.7.0, but can also manually be installed through the plugin manager.
This should long be fixed already.
Cannot launch jEdit when installed with OS X package installer
Replace bundled MacOSX plugin by successor MacOS plugin
Fix NullPointerException during saving autosave settings if no previous autosave directory was set
Never mark empty untitled buffers dirty, independent of settings
Update launch4j to version 3.50 and also search in PATH environment variable for a Java runtime from the EXE launcher
Update macOS app bundler to version 1.2.0
Revert jsr305 removal
Just an FYI, this is fixed in beanshell 2.1.1, which requires moving jedit to GPL 3 before we can use it.
Hi, yy, this one is correct one from my understanding: 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Actually here is fsf_wrong_address_regex in rpmlint. :) List of affected files is in bugzilla (search for incorrect-fsf-address).
BeanShell error: module java.base does not "opens java.lang" to unnamed module
Ok, I slept over it and looked through the code again. I feel confident enough to do it still for 5.7.0, so this should hopefully be fixed now.
Make BeanShell behave consistent and remove the need for reflection when defining classes (#4118)
I had a quick look through the code, and I don't think something should really break by doing this, except accessing inaccessible fields that worked before after a class was defined somewhere. I'll sleep it over and maybe we can even put it in 5.7.0.
Actually, we might be more lucky than we should be. :-D You can easily reproduce with this snippet: class Foo { } StringBuilder sb = new StringBuilder(); sb.append("test"); The good thing is, I felt brave and just commented out the Capabilities.setAccessibility( true ); call. And what should I say, it worked. :-) So maybe that comment is not up-to-date anymore actually. I wouldn't do this change now shortly before the 5.7.0 release, but after that, we can maybe just do it and see how it works out....
The point why the snippet first works and then not anymore, is the usage of classes in a macro suddenly changes configuration. By default Capabilities#accessibility is false. This means BeanShell does not try to do setAccessible and alike. There is exactly one place where this is set to true, which is when a class (named or anonymous) is found in a BeanShell code that is executed. The current implementation in ClassGeneratorImpl#generateClassImpl has the comment // Scripting classes currently requires...
Besides that jsr305 would not be any problem as I wrote on the mailing list, how do you think would making jEdit a JPMS module change anything? That would not magically make BeanShell be able to do that reflection. You would still need the --add-opens either way. And you can also use the --add-opens fine without making jEdit a JPMS module. As we build the jedit.jar as executable jar and only start it like that, we can even put those as Add-Opens attribute to the manifest of jedit.jar and it would...
Increase max warnings amount for JavaDoc generation
Remove unnecessary BSF dependency for scripting
Fix JavaDoc generation
Fix unchecked and deprecated compiler warnings
Add missing contributor information
removed jsr305 which is incompatible with Java module system
I deleted my previous comment. I was still running an older build. The issue seems to be fixed to me, but I will test it some more.
Fix bug #4125 delete at the end of the line does not delete newline on java 20, 21
Ok, maybe if we start using modules in jEdit we could fix that, however to do that we have to remove the jsr305 lib as it was never confirmed it uses packages of JRE which is forbidden
Yes, with these java command line args the StringBuilderTest.bsh runs fine (in my step 5).
Hey Robert, can you try to add --add-opens java.desktop/java.awt=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED to the java args in your command line ? I agree even if it works it is not ideal.
OK, let's restart with this issue: My system is: jEdit 5.6 (virgin install and settings) Adoptium jdk-20.0.2+9-jre Windows 11 Pro 22H2 Steps to reproduce: 1. Startup jEdit 2. Run StringBuilderTest.bsh => works fine. 3. Run one of these bundled macros: - Editing/Mode_Switcher - Properties/Create_Plugin_Announcement - Text/Insert_Tag - Misc/Debug_BufferSets 5. Run StringBuilderTest.bsh => Now an error raises as described above The error will raise with Java 17 and later, but not with Java 11 . I have...
Hey, you mean our header files states Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. instead of Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. which seems to be the new address (found it here https://www.gnu.org/licenses/old-licenses/gpl-2.0.html ) ?
Add some unit test for #4125
The fix by Dale seems good: we always want to delete at least a char. But I would prefer we put it in the TextArea.nextOf() method, with a detailed comment, because with the new GraphemeBreakIterator the logic to detect an end of line is broken and the existing comment would mislead people in this already complicated area of the code. diff --git a/org/gjt/sp/jedit/textarea/TextArea.java b/org/gjt/sp/jedit/textarea/TextArea.java index 9ce126e49..2f98a897a 100644 --- a/org/gjt/sp/jedit/textarea/TextArea.java...
Fix whitespace in CHANGES.txt
refactor plugin list loading and use new JRE http client
Delete at the end of the line does not delete newline (java20, java21)
matthieu can you look at this before jedit gets released please?
Introduce a SystemManager to encapsulate environment manipulation and make unit tests possible.
Hey, I feel github much more efficient to navigate and use in git repositories, bugtrackers. Github is centered on the developper while sourceforge is on the project. For example if jEdit was on github, then I think we should not commit directly to the project. Just I would do a fork in my user space (that is public), you would do the same, Alan too and any developper who is interested in jEdit's development too. Then I would create a branch for my changes, and when I am satisfied I would submit...
use Matcher.quoteReplacement() instead of a simple replace
some cleanup
patch for FR #554 add match index to beanshell replace context
committed in r25683
add match index to beanshell replace context
implemented in r25683
fix FR#554 add match index to beanshell replace context
No special key handling in the Errors dialog
Fixed in r25682