The "custom" textfield could (maybe) be done in such a way that perl custom brackets are supported. In perl the "m" and "s" regex operators can accept any character as delimiter. So if the custom field would split the entered text on whitespace and take each pair as the "brackets" to use, one could for example use: m# # s# ## m: : s: :: To have auto brackets for stuff like: m#text# s:text:replace: …just thinking loud… ;)
ssh_config edit mode - need help
ssh_config edit mode - need help
ssh_config edit mode - need help
Additional Info: After checking out another branch, the setting about automatically adding the branch name is lost. Update: Seems it's a per-branch setting ;) I had the setting switch on on "master" I switched to "staging" -> Setting lost I swiched it on on "staging" and checked out "master" Setting was there.
Additional Info: After checking out another branch, the setting about automatically adding the branch name is lost.
FYI: Plugins > Git Plugin > Checkout Branch does not send a message on the EditBus, so the branch isn't updated in the view.
How will the branch be updated? Re-import of files didn't do that.
phpparser fails to parse project correctly
System Information Macro - useful for reporting bugs
On 17-11-24 22:11, Roman Tsourick via jEdit-devel wrote: I personally have no idea. I was just asking to make the one usable. It is usable. It is just that you prefer to use it in a different way than I. I do not see an issue with copying everything in the format I require and then deleting those lines I do not want. But feel free to adjust it to your needs. After all: It seems the macro will never become a part of the core jEdit. I will keep it anyway.
Fix for #1891 and #1892
I do not see "Zweig" for "Branch" a proper german translation in Git context
Seems to work except for the creation of a project. I created a project and choose my GitPlugin repo. I selected the new option but the branch name was not added. I went to the fresh roject's properties and the option (Automatically add branch name to project name) was unchecked. Upon setting the checkbox everything seems to work. I even added the german translation for the option and submitted a merge request for it.
German Translation for new option
I've tested by deactivating the storing of the property and the exception is gone. So we either need to have the autorename be a global GIT option (I'd vote for that). Or find a way to store it per project without having to deal with the problem that the property contains the project's name. I also tried it by changing the "getProjectName" method in GitPVOptopnPane to private String getProjectName() { VPTProject project = ProjectViewer.getActiveProject( jEdit.getActiveView() ); return project ==...
Update: There must be a fundamental difference between what you did and what my Macro does. I think it could be due to that my macro renames the project and you test whether or not to rename it by checking GitPVOptionPane.INTERNAL_NAME + '.' + projectName + ".autoRename" But if you renamed it, the name changed. Could it be there is a mismatch between the name and the INTERNAL_NAME? Or that there is none and so the setting is still stored under the old name and so you cannot find it? Maybe it's better...
If I'm not mistaken you already added it, right? Unfortunately I get issues having the rename active. You cannot reimport a project and the troubleshoot utility shows exceptions. 08:25:30 [AWT-EventQueue-0] [error] AWT-EventQueue-0: Exception in thread "AWT-EventQueue-0" 08:25:30 [AWT-EventQueue-0] [error] AWT-EventQueue-0: java.lang.NullPointerException 08:25:30 [AWT-EventQueue-0] [error] AWT-EventQueue-0: at projectviewer.ProjectManager.saveProject(ProjectManager.java:282) 08:25:30 [AWT-EventQueue-0]...
I think I got it… I need to set build.properties…
I need a bit of guidance. I always get /Users/skeeve/Library/jEdit/jars/GitPlugin/git/GitCommand.java:24: error: package common.io does not exist and I cannot figure out how to solve this except by changing the build.xml. I thought it should be solvable by changing the buildsupport, right? But what do I need to change?
I've created a macro that helps (me) remedy the situation a bit: import git.command.BranchList; import projectviewer.vpt.VPTProject; import projectviewer.ProjectViewer; import projectviewer.vpt.VPTNode; import projectviewer.ProjectManager; // Do we have Projct Plugin? EditPlugin ep = jEdit.getPlugin("projectviewer.ProjectPlugin", false); if (ep == null) { return; } ProjectViewer pv = ProjectViewer.getViewer(view); VPTNode node= ProjectViewer.getActiveProject(view); // Retrieve all branches BranchList...
Git-Plugin show branch in tree
I wrote a macro to achieve this. I think it currently has an issue, so I wrote to the devel mailing list. Hope someone can have a look. If it works, I'll append it here. It will automatically open 2, 3, 4, 6 or 9 textareas in a split view configuration, depending on the number of open files.
Final version I honestly hope. I can't believe what kind of beast my small ad-hoc-macro became… Regarding "new to Java": I know Java quite a while but I am not a Java programmer which any Java programmer will be able to tell from my below code. If I can I try to avoid Java. // import statement import javax.swing.border.*; int maxK= 9; int maxV= 7; StringBuilder result= new StringBuilder(1024); void appendResult( String k, String v ) { result.append(k); result.append(": "); result.append(v); result.append("\n");...
Oops… Completely misunderstood. In theory, this should make a buffer readonly: buffer.setReadOnly(true); In practice it didn't work on my Mac. I still can edit the file.
Keyboard shortcuts to go to the beginning/end of the fold
I already checkeked whether the selection is on just one line. But there was a bug in the macro indenting the current line when all selections were just one-liners. Fixed now with nbelow code: os=textArea.getSelection(); om=textArea.isMultipleSelectionEnabled(); if (! om) { textArea.toggleMultipleSelectionEnabled(); } int[] sl= new int[os.length]; int[] el= new int[os.length]; boolean[] ol= new boolean[os.length]; String[] in= new String[os.length]; boolean appendLine= false; boolean oneLine= false;...
I absolutely and 100% support this request! I cannot tell how often I end up in Print dialog when testing macros (Cmd-M Cmd-P ending up in only Cmd-P seen by jEdit)
Final version I honestly hope. I can't believe what kind of beast my small ad-hoc-macro became… Regarding "new to Java": I know Java quite a while but I am not a Java programmer which any Java programmer will be able to tell from my below code. If I can I try to avoid Java. // import statement import javax.swing.border.*; int maxK= 9; int maxV= 7; StringBuilder result= new StringBuilder(1024); void appendResult( String k, String v ) { result.append(k); result.append(": "); result.append(v); result.append("\n");...
Okay... Using jEdit's help as a guideline I came up with this: // import statement import javax.swing.border.*; StringBuilder result= new StringBuilder(1024); result.append("jEdit: "); result.append(jEdit.getBuild()); result.append("\n"); result.append("Java: "); result.append(System.getProperty("java.vendor")); result.append(" "); result.append(System.getProperty("java.version")); result.append("\n"); result.append("OS: "); result.append(System.getProperty("os.name")); result.append(" "); result.append(System.getProperty("os.version"));...
Personally I cannot (yet) as my experience with Java isn't the best. Maybe you can enhance the macro? I'm just using standard Macros-provided methods to display the text. Everything beyond that is above my current capabilities :(
I did and the file is not valid XML. It's not even valid HTML as https://validator.w3.org/check says. Anyways. Even with valid HTML the auto-close feature wrongly determines the wrong close tag. I wouldn't put any effort into solving these small nuisances. The auto-close has to be fast to be helpful. You would require a full html parser to correctly determine the correct tag to close.
If you use ProjectViewer, it has a "Search in Projct Root" and "Search in Directory". Project Viewer can show different projects per View. Does this help? Or would a macro help which sets the current directory as the search base? Search in current directory: import org.gjt.sp.jedit.search.SearchDialog; import org.gjt.sp.jedit.search.DirectoryListSet; File path= new File(buffer.getPath()); DirectoryListSet searchIn= new DirectoryListSet((path.getParentFile()).toString(), "*", true); String selected...
I thought it's not a good idea and wanted to object. But now I tested and agree now that it IS a good idea because the current behaviour eels wrong. What I did: Opened 2 views. Opened Search in first view and set a directory to search in Opened Search in second view and set another directory to search in Closed the first view's search Opened the first view's search -> It has the second view's directory -> BAD! If it were just one search dialog, I think it's okay. But as we have a new search dialog...
You have more experience with jEdit I assume, but I see that the feature request is older than a year and no one took care. I also do not think that it's a good idea to put features into the core which can easily be achieved with a small macro seem of not too much interest. After all: Folding is in for more than 10 years and only last yoear one person asked. I do not think the macros are workarounds. They use the existing fold-related functionality to select a fold. So no need to reinvent how to...
You have more experience with jEdit I assume, but I see that the feature request is older than a year and no one took care. I also do not think that it's a good idea to put features into the core which can easily be achieved with a small macro seem of not too much interest. After all: Folding is in for more than 10 years and only last yoear one person asked.
Hmmm… I just tested with jEdit 05.04.99.00 on Mac OS X 10.12.6 (x86_64) I opened a read-only file and had no issues editing it. No need to change a read-only mode. But when I tried to save, I was asked whether or not I want to reset the read-only mode of the file. So I think it can be closed as fixed.
What for if a macro can do? And after all: It's just a three-key workflow (besides naming the file): After Marking the selection: Copy - New Buffer - Paste
adds unecessary tab before selection I do not think the tab is unneccessary. The content should be indented a level more than the tag - but this is my personal preference. Remove the shiftIndentRight(). does not turn off multiple selection after I fixed the multiple selection "issue". If it was off before it will be off after the macro call. See the last 3 lines of the macro [ if ( ! om ) … ] seems like there is no way to just enclose single word on a line, encloses the whole text It is. If you have...
adds unecessary tab before selection I do not think the tab is unneccessary. The content should be indented a level more than the tag - but this is my personal preference. Remove the shiftIndentRight(). does not turn off multiple selection after I fixed the multiple selection "issue". If it was off before it will be off after the macro call. See the last 3 lines of the macro [ if ( ! om ) … ] seems like there is no way to just enclose single word on a line, encloses the whole text It is. If you have...
One more iteration without a video this time. This version will put the tags on the same line the text is in, if the selection is just a single line. os=textArea.getSelection(); om=textArea.isMultipleSelectionEnabled(); if (! om) { textArea.toggleMultipleSelectionEnabled(); } int[] sl= new int[os.length]; int[] el= new int[os.length]; boolean[] ol= new boolean[os.length]; String[] in= new String[os.length]; boolean appendLine= false; boolean oneLine= false; for (i=os.length; i-->0; ) { sl[i]= os[i].getStartLine();...
One more iteration without a video this time. This version will put the tags on the same line the text is in, if the selection is just a single line. os=textArea.getSelection(); om=textArea.isMultipleSelectionEnabled(); if (! om) { textArea.toggleMultipleSelectionEnabled(); } int[] sl= new int[os.length]; int[] el= new int[os.length]; boolean[] ol= new boolean[os.length]; String[] in= new String[os.length]; boolean appendLine= false; boolean oneLine= false; for (i=os.length; i-->0; ) { sl[i]= os[i].getStartLine();...
Does this Macro help? (Small bug fixed 2017-11-02) os=textArea.getSelection(); om=textArea.isMultipleSelectionEnabled(); if (! om) { textArea.toggleMultipleSelectionEnabled(); } int[] sl= new int[os.length]; int[] el= new int[os.length]; String[] in= new String[os.length]; boolean appendLine= false; for (i=os.length; i-->0; ) { sl[i]= os[i].getStartLine(); el[i]= os[i].getEndLine(); if ( textArea.getLineStartOffset(el[i]) == os[i].getEnd() ) { --el[i]; } appendLine= el[i]+1 == textArea.getLineCount();...
Does this Macro help? (Small bug fixed 2017-11-02) os=textArea.getSelection(); om=textArea.isMultipleSelectionEnabled(); if (! om) { textArea.toggleMultipleSelectionEnabled(); } int[] sl= new int[os.length]; int[] el= new int[os.length]; String[] in= new String[os.length]; boolean appendLine= false; for (i=os.length; i-->0; ) { sl[i]= os[i].getStartLine(); el[i]= os[i].getEndLine(); if ( textArea.getLineStartOffset(el[i]) == os[i].getEnd() ) { --el[i]; } appendLine= el[i]+1 == textArea.getLineCount();...
Does this Macro help? os=textArea.getSelection(); om=textArea.isMultipleSelectionEnabled(); if (! om) { textArea.toggleMultipleSelectionEnabled(); } int[] sl= new int[os.length]; int[] el= new int[os.length]; String[] in= new String[os.length]; for (i=os.length; i-->0; ) { sl[i]= os[i].getStartLine(); el[i]= os[i].getEndLine(); in[i]= textArea.getLineText(sl[i]).replaceFirst("\\S.*$",""); } textArea.shiftIndentRight(); textArea.selectNone(); la= 0; for (i=0; i<os.length; ++i) { textArea.setCaretPosition(textArea.getLineStartOffset(sl[i]+la));...
Highlight: one-letter words are not highlighted
Is jEdit 4.4.2 still supported? So is it required to fic OpenIt? Or is OpenIt something worth updating to newest jEdit compatibility?
TextTools: Toggle Line Comment case sensitive
MacroManager and macros with / in their name
Attached patch file will replace every file.separator occuring in a macro's filename with a "-". Additionally I've replaced the deprecated Dialog.show() with setVisible(true). I couldn't replace the deprecated thread.stop() which is used 4 times. Please someone else take over to get rid of those 4 warnings.
Attached patch file will replace every file.separator with a "-". Additionally I've replaced the deprecated Dialog.show() with setVisible(true). I couldn't replace the deprecated thread.stop() which is used 4 times. Please someone else take over to get rid of those 4 warnings.
Cannot reproduce with jEdit: 05.04.99.00 Java: Oracle Corporation 1.8.0_152 OS: Mac OS X 10.12.6 (x86_64) QuickNotepad: 5.0 Antlr: 4.5.1 BufferList: 1.5 Buffer Selector: 1.9 Common Controls: 1.7.4 Console: 5.1.4 EclipseIcons: 1.0 ErrorList: 2.3 Git Plugin: 0.8 GnuRegexp: 1.0.1 Highlight: 2.2 Info Viewer: 1.6.3 JDiff Plugin: 3.3.0 JNAPlugin: 3.5.2 JSLint: 1.0 MacroManager: 1.3.1 Project Viewer: 3.5.3 RhinoPlugin: 1.7R4 SideKick: 1.8 SVNPlugin: 1.8.12 WhiteSpace: 1.0.2 XercesPlugin: 2.11.0_1 XML: 3.0.6...
The problem here is that "lineComment" is defined in PROPS while case-sensitivity is defined per ruleset. So there is no way (currently) to define that the lineComment string is case insensitive. My proposal would be to simply treat EVERY lineComment as being case-insensitive. For this, change in TextToolComments.java Line 126 from if(line.length() > 0 && !line.startsWith(lineComment)) to if(line.length() > 0 && !line.toLowerCase().startsWith(lineComment.toLowerCase())) and line 172 from if(line.trim().startsWith(lineComment)...
The problem here is that "lineComment" is defined in PROPS while case-sensifitvity is defined per ruleset. So there is no way (currently) to define that the lineComment string is case insensitive. My proposal would be to simply treat EVERY lineComment as being case-insensitive. For this, change in TextToolComments.java Line 126 from if(line.length() > 0 && !line.startsWith(lineComment)) to if(line.length() > 0 && !line.toLowerCase().startsWith(lineComment.toLowerCase())) and line 172 from if(line.trim().startsWith(lineComment)...
System Information Macro - useful for reporting bugs
Works with OS: Mac OS X 10.12.6 (x86_64) jEdit: 05.04.99.00 Java: Oracle Corporation 1.8.0_152 XML: 3.0.6
Works with OS: Mac OS X 10.12.6 (x86_64) Java: Oracle Corporation 1.8.0_152 XML: 3.0.6
Works with jEdit Version Information OS: Mac OS X 10.12.6 (x86_64) Java: Oracle Corporation 1.8.0_152 XML: 3.0.6
What's the status of this? From what I understood, everything's fine as long as we deal with valid XML? So can this be closed?
I wanted to check this, but my Plugin Manager does not show OpenIt. Is OpenIt still available? FWIW: I also do not see Mac OS Plugin. Just the Mac OS X Plugin.
Yes, the File -> Exit is redundant but I wouldn't remove it. It is not part of the Plugin so the Plugin would have to remove a standard jEdit menu entry. It might be useful for users used to jEdit on other platforms, just "visiting" jEdit.
If you replace the 2 in line 666 of HighlightManagerTableModel.java with a 1, you get highlight of one-letter words. So to answer your doubts: It seems to be intentional that a word for Highlight has to have at least 2 letters. I almost forgot. This is the line: if (wordEnd - wordStart < 2)
If you replace the 2 in line 666 of HighlightManagerTableModel.java with a 1, you get highlight of one-letter words. So to answer your doubts: It seems to be intentional that a word for Highlight has to have at least 2 letters,
I think this is done with the latest pull request I submitted. It just has to be merged into v0.8.
Does this Macro felp? os=textArea.getSelection(); om=textArea.isMultipleSelectionEnabled(); if (! om) { textArea.toggleMultipleSelectionEnabled(); } int[] sl= new int[os.length]; int[] el= new int[os.length]; String[] in= new String[os.length]; for (i=os.length; i-->0; ) { sl[i]= os[i].getStartLine(); el[i]= os[i].getEndLine(); in[i]= textArea.getLineText(sl[i]).replaceFirst("\\S.*$",""); } textArea.shiftIndentRight(); textArea.selectNone(); la= 0; for (i=0; i<os.length; ++i) { textArea.setCaretPosition(textArea.getLineStartOffset(sl[i]+la));...
Try this: os=textArea.getSelection(); om=textArea.isMultipleSelectionEnabled(); if (om) { textArea.toggleMultipleSelectionEnabled(); } oc=textArea.getCaretPosition(); textArea.selectBlock(); b=textArea.getSelection(0); textArea.selectNone(); bs=b.getStart(); be=b.getEnd(); textArea.setCaretPosition(be); textArea.backspace(); textArea.setCaretPosition(bs); textArea.delete(); textArea.setCaretPosition(oc-1); if (om) { textArea.toggleMultipleSelectionEnabled(); } textArea.setSelection(os);
This is quite old and I do not seem to completely understand it. If only an example would be there.
NO! This does not conform to macOS standards. If you click an icon in the the dock. the expected behaviour is to go to that application's window and NOT to open a new instance. Maybe if you right click and have a context menu entry "New View", this would fit, but certainly not breaking standard macOS behaviour.
If you use ProjectViewer, it has a "Search in Projct Root" and "Search in Directory". Project Viewer can show different projects per View. Does this help? Or would a macro help which sets the current directory as the search base? Search in current directory: import org.gjt.sp.jedit.search.SearchDialog; import org.gjt.sp.jedit.search.DirectoryListSet; File path= new File(buffer.getPath()); DirectoryListSet searchIn= new DirectoryListSet((path.getParentFile()).toString(), "*", true); String selected...
Keyboard shortcuts to go to the beginning/end of the fold
Here you have 2 macros to achieve that: GoToBeginning of fold os=textArea.getSelection(); om=textArea.isMultipleSelectionEnabled(); if (om) { textArea.toggleMultipleSelectionEnabled(); } textArea.selectFold(); textArea.goToPrevCharacter(false); if (om) { textArea.toggleMultipleSelectionEnabled(); } textArea.setSelection(os); GoToEnd of fold os=textArea.getSelection(); om=textArea.isMultipleSelectionEnabled(); if (om) { textArea.toggleMultipleSelectionEnabled(); } textArea.selectFold(); textArea.goToNextCharacter(false);...
Feel free to add them. I do not see how I could enhance them. I'm not doing anything fancy. The first macro simply inserts a space and selects it while keeping all the other selections. The second one just inserts a space at the end of every selected line, dops the previous selection and selects all those spaces. The only improvement I could think of lies within jEdit: You could allow to delete to the left of selections. You see: In the movie, before I inserted th li-tags I pressed backspace to delete...
You didn't try, did you? Sorry! I think i understood what you meant: If I place the cursors (selections) at the end of the lines, I can only insert new characters and not even delete them. Also I cannot delete to the left.
https://youtu.be/XDuho3-nt4c
You didn't try, did you?
I think this is a very special case. I propse you use a macro to set a comment and remove it. Set the macro: SearchAndReplace.setSearchString("--"); SearchAndReplace.setReplaceString("--"); SearchAndReplace.setBeanShellReplace(false); SearchAndReplace.setWholeWord(false); SearchAndReplace.setIgnoreCase(true); SearchAndReplace.setRegexp(false); SearchAndReplace.replace(view); Registers.cut(textArea,'$'); textArea.setSelectedText("<!-- -->"); textArea.goToPrevCharacter(false); textArea.goToPrevCharacter(false);...
XML: treat - (minus) as a special char
I think this is a very special case. I propse you use a macro to set a comment and remove it. Set the macro: SearchAndReplace.setSearchString("--"); SearchAndReplace.setReplaceString("--"); SearchAndReplace.setBeanShellReplace(false); SearchAndReplace.setWholeWord(false); SearchAndReplace.setIgnoreCase(true); SearchAndReplace.setRegexp(false); SearchAndReplace.replace(view); Registers.cut(textArea,'$'); textArea.setSelectedText("<!-- -->"); textArea.goToPrevCharacter(false); textArea.goToPrevCharacter(false);...
Patch for TextTools Feature Request #348
Please find attached a patch which will modify the "Sort…" dialog by adding 2 columns: 1. Separator 2. Column Number If you specify a separator and a column number (starting with 1), each line is split at the separator (which is a regular expression) and just the specified column is used for sorting. Note that you can use multiple separators in each line. Note that the start and end column, if specified as well, are then used relative to the column. Example: Separator: \t Column: 2 startColumn: 2...
Please find attached a patch which will modify the "Sort…" dialog by adding 2 columns: 1. Separator 2. Column Number If you specify a separator and a column number (starting with 1), each line is split at the separator (which is a regular expression) and just the specified column is used for sorting. Note that you can use multiple separators in each line. Note that the start and end column, if specified as well, are then used relative to the column. Example: Separator: \t Column: 2 startColumn: 2...
Why?
Duplicate of #375
The files are alphabetically ordered. There is no way to reorder besides renaming the files: Proposal: Close -> rejected.
Why not copy the two selections into 2 buffers comparing them?
Why not copy the two elections into 2 buffers comparing them?
This is more than a year old and the OP didn't help -> Propsal: Close
Can't reproduce on macOS 10.12, LibreOffice 5.4.1.2
And here is a macro which will select all your end-of-lines for the current selection(s) sl= textArea.getSelectedLines(); textArea.selectNone(); for (var i=sl.length; i-->0; ) { textArea.moveCaretPosition(textArea.getLineEndOffset(sl[i])-1); textArea.userInput(' '); } if (! textArea.isMultipleSelectionEnabled() ) { textArea.toggleMultipleSelectionEnabled(); } for (var i=sl.length; i-->0; ) { s= textArea.getLineEndOffset(sl[i]); textArea.addToSelection(new Selection.Range(s-2,s-1)); } So now you have...
Does this macro help a bit? if (! textArea.isMultipleSelectionEnabled() ) { textArea.toggleMultipleSelectionEnabled(); } os=textArea.getSelection(); textArea.selectNone(); textArea.userInput(' '); textArea.setSelection(new Selection.Range( textArea.getCaretPosition()-1, textArea.getCaretPosition() ) ); textArea.addToSelection(os); How to use it: 1. Position the cursor where you want your first caret 2. Execute the macro -> A space will be inserted and selected 3. If you want more carets, Place your...
Is this macro sufficient? textArea.selectAll(); Registers.copy(textArea,'$'); jEdit.newFile(view); EditBus.send(new PositionChanging(editPane)); Registers.paste(textArea,'$',false); It will copy the whole file content to a new file.
It's a simple macro: textArea.selectBlock(); textArea.backspace();
Maybe also the replacement which was used? So "scrolling" through the previos search strings would also scroll throught the replacement strings at the same time.
I agree to@Eric Le Jay and would close this.
I agree ti @Eric Le Jay and would close this.
You can use the Hyper Search Bar or the Incremental Search Bar Would it help the Search dialog would be dockable? I personally think #2 is a good idea
Fix for #1891 and #1892
v0.8 Reworked the icons. Fixed some issues in parsing status output
v0.8 Reworked the icons. Fixed some issues in parsing status output