jEdit, my trustiest Flare companion

[Phlawm53]

In the spirit of contributing productivity-enhancing tips and tricks, I recently realized that pretty much every time I run Flare, I also run the free open-source jEdit text editor (http://jedit.org/).

jEdit is a nifty Java-based programmer's editor designed to work with a variety of programming and scripting languages including CSS, XHTML, and XML. I also run Notepad++ and gVim, but jEdit is by far my favorite, indeed at this point an essential, supplement to Flare's native capabilities.

One key reason for this is that jEdit supports a staggering number of Plugins. Among the handiest of jEdit's plugins is Project Viewer. Project Viewer enables one to work efficiently with directories full of files, including doing REGEX Find/Replace operations across multiple files.

jEdit's ability to Find/Replace across multiple project files makes it much easier to search all topic files for a string cited in a Flare error message, particularly file names cited in Flare link or cross-reference errors. I believe Flare's Find in Files tool may also enable one to do this, but I find jEdit's Find/Replace, Java REGEX, and HyperSearch Results tools to be "friendlier" and faster to work with.

Additionally, the ability to work with multiple files is also enormously handy when performing tasks like changing a color specification across multiple Page Layout and Table definition files. Rather than click one's way through multiple GUI windows and dialogs to find and change each separate color spec, one can simply search the pertinent files for the old color spec (using REGEX if desired), then replace the old value with the new color spec, all within a few seconds.

Finally, jEdit's various code-completion utilities make it a wonderful CSS editor. I almost always do most of my CSS work in jEdit, resorting to Flare's GUI CSS editor only for Flare-specific constructs.

Here's a screenshot showing the Project Viewer and Sidekick plugins at work.

jEditProjectViewerCSSEditorAndSidekick.png

The Sidekick extension obviously makes it very easy to quickly locate and position to CSS styles and classes.

Not all Flare users are comfortable working directly with XML / CSS / XHTML. But for those of you who are, if you're not already familiar with jEdit, take a look.

Cheers & hope this helps,
Riley
SFO

[Nita Beck]

Riley, speaking for myself and the members of the Rochester Flare User Group, thanks so much for telling the community about this tool. I will definitely make my members aware of your post and of this tool. We LOVE collecting tools to make our Flare authoring more efficient.

[LTinker68]

jEdit is a nifty Java-based ...

I haven't used this tool and have no opinion either way as to its use, but just be aware that Java is heavily targeted by virus and Trojan writers. If you use the tool -- or any other Java-based tool -- make sure you stay on top of updates to the Java platform.

Just a note of caution...

[Phlawm53]

…be aware that Java is heavily targeted by virus and Trojan writers. If you use the tool -- or any other Java-based tool -- make sure you stay on top of updates to the Java platform.

Lisa makes a very good point.

In addition to routine security updates, note also that Java is an especial problem in web browsers. So much so that one does well to disable Java functionality there.

Cheers & hope this helps,
Riley
SFO

[NorthEast]

I took a look at jEdit, mainly to see how well it handled CSS editing.

One big problem I found is that it doesn't handle Flare's MadCap| styles. If your stylesheet includes a MadCap| style, then it doesn't parse the whole remainder of the stylesheet - e.g. there's no syntax highlighting, and the styles are missing from the sidekick window.

Have you found a way round this?


Also, in addition to the plugins mentioned, I'd recommend using the 'XML' plugin - it does code completion, and has a sidekick tree display.
(I'd also not recommend the 'CSS Editor' plugin.)

[Phlawm53]

Hi Dave:

One big problem I found is that it doesn't handle Flare's MadCap| styles. If your stylesheet includes a MadCap| style, then it doesn't parse the whole remainder of the stylesheet - e.g. there's no syntax highlighting, and the styles are missing from the sidekick window.

Have you found a way round this?

Well, the following screenshot is yet another demonstration of Gershwin's Theorem ("It ain't necessarily so").

jEditSidekickListingMadcapStyles.png

In this particular instance, jEdit's Sidekick plugin is listing at least some of the Madcap "|" styles.

But in fairness, yes — Madcap styles can affect CSS syntax parsing and highlighting in jEdit. In the preceding screenshot the problem is neatly illustrated in the p.FigureCaption class that immediately follows the auto-numbered p.TableCaption class.

The problem seems to be the Madcap selectors' use of apostrophes ( ' ). So it's not just Madcap | styles, but also Flare cross-reference formats and autonumbering that disorder jEdit's CSS parsing since they also use apostrophes ala mc-auto-number-format: 'GT:Table {n+}: '.

The apostrophes hypothesis seems to be confirmed by the fact that jEdit's CSS ssyntax highlighting will resume following some number of the right sort of Madcap items in sequence. Evidently at some point the apostrophes count increments to a value that puts jEdit's CSS parser back into synch(?)

As far as a circumvention, the only thing I've done is move the Madcap items to the bottom of the CSS stylesheet as a way of minimizing their disruption. One could, I suppose, experiment with creating a dummy CSS selector containing whatever number of apostrophes are required to put jEdit's CSS syntax highlighting back in order. Finally, jEdit itself has lots of options; I wonder if there's some way to tell it to step around the apostrophes.

As far as it being a "big" problem, for me it's merely an annoyance. jEdit's other capabilities are so handy that even when syntax highlighting goes wonky, I still find it useful to run jEdit in tandem with Flare: I can get certain things done so much more easily and quickly when I do. That's particularly true when creating CSS selectors and specifying their properties since I do that so regularly as part of setting up a project. And as I mentioned, it's absolutely the handiest way I've discovered to work with a Flare project's entire set of color specs.

Not incidentally, one other advantage I realize by using an external editor such as jEdit is that I can easily move the jEdit window behind the Flare window when I don't need it. Because I don't have two displays, opening a Flare project's stylesheet in Flare's internal text editor permits me to either dock the internal editor's window, have it float intrusively in front of the Flare window, or move it off the edge of the display at which point it's not very usable. Flare 9's new side-by-side feature wherein one can put the XML Editor and the Text Editor in adjoining Flare u.i. panels is nice enough, but it seems to presume more screen real estate than I have if I'm working on a customer site with my laptop…

------
You're right about the CSS Editor plugin — it's not necessary. One will do better to edit one's CSS (indeed pretty much anything) in a jEdit buffer and let jEdit and any pertinent plugins handle things like syntax highlighting, code completion, and so on.

And finally, speaking of jEdit buffers, one of the first things I do whenever I set up a new instance of jEdit is install the BufferTabs plugin and make it the default way of managing multiple buffers. jEdit's default buffer list isn't nearly as nice…

Cheers, thanks, & hope this helps,
Riley
SFO

[RamonS]

…be aware that Java is heavily targeted by virus and Trojan writers. If you use the tool -- or any other Java-based tool -- make sure you stay on top of updates to the Java platform.

Lisa makes a very good point.

In addition to routine security updates, note also that Java is an especial problem in web browsers. So much so that one does well to disable Java functionality there.

Yes, and the security issues are generally limited to the use of Java n browsers using Java applets. Stand alone apps running on top of Java are not more susceptible to hacks as any other app running on a third party platform (such as Flare on top of .NET). In either case, applying updates is key. Only want to point out that there is a lot of negative hype around Java lately that generally does not apply to the runtime used outside of browsers.

[NorthEast]

In this particular instance, jEdit's Sidekick plugin is listing at least some of the Madcap "|" styles.

I was a bit perplexed by that, and after a few tests I found out what the problem was. I'd assumed the style list on the right was failing for the same reason as the syntax highlighting - i.e. due to MadCap| styles.

However, the stylesheet I was using has a @media statement, and it appears the sidekick window doesn't display any styles inside media statements.

jedit CSS problem.png

For me, that's an even more severe problem than I first thought, since I use media statements extensively in Flare projects (for different targets) and websites (for responsive layouts).

Do you not have that same problem - or are there other better plugins available that can handle media statements correctly?

I currently use notepad++ which also has syntax highlighting (which works for Flare styles) and auto-complete; but doesn't have an equivalent to the sidekick tree view, which I'd find handy. So jEdit does look pretty good, I'd probably try using it if/when it works properly with CSS.

[RamonS]

You may want to look for a plugin for Notepad++, there are very many awesome plugins available.

[NorthEast]

You may want to look for a plugin for Notepad++, there are very many awesome plugins available.

Yep, I've used Notepad++ for a number of years, and heavily use that and FAR HTML for Flare (and web) development. I don't actually use Flare for any CSS editing, as even the advanced editor is a bit klunky for my liking. Notepad++ has a lot of good plugins; e.g. Zen Coding, Tidy, and XML Tools to name a few. I'm not aware of a CSS tree browser, but will have another look around.

[Phlawm53]

@Dave re:

…it appears the sidekick window doesn't display any styles inside media statements.

For me, that's an even more severe problem than I first thought, since I use media statements extensively in Flare projects (for different targets) and websites (for responsive layouts).

Do you not have that same problem - or are there other better plugins available that can handle media statements correctly?

You're correct — I hadn't noticed that before.

I have a @media print section. If I remove the @media statement and its delimiters from a test buffer, jEdit's Sidekick reports, inter alia, two body elements, one for default and now a second for the print media section.

Oh well, still not a show stopper for me. As I said, I hadn't noticed it until you mentioned it… (Although I may explore what ideas the jEdit forums offer now that I'm aware of the issue…)

(It's interesting, too, that at least some more technically minded Flare users feel constrained by the Flare's built-in tools…)

Cheers & hope this helps,
Riley
SFO

[daleanson]

Sorry for reopening an older post, but I'm the author of the css sidekick plugin for jEdit. A ticket was opened against the plugin for the parsing issues: https://sourceforge.net/tracker/index.p ... tid=565475

So far, I have not been able to reproduce any issues with the MadCap files I've tested with. The only problems so far have been some legitimate syntax error in the files. If you continue to find css files that don't parse correctly, please feel free to attach them to the tracker at the link above and I'd be happy to help figure out what is wrong.

Thanks,

Dale Anson

[Phlawm53]

------
Be advised that as of 28 April, the Sidekick version 1.6 plugin now correctly handles @media statements:

http://sourceforge.net/p/jedit/plugin-b ... age=1#dae8

Per the plugin's developer:

Okay, I've fixed the parsing of @media. It turns out it had never actually been updated to handle all of the CSS 3 modifications and really only worked correctly on CSS 2.1 media queries. I still need to fix the error reporting.

I just tested the updated version and it works beautifully:

2014-04-28_jEdit0501WithSidekick0106.png

Very handy before, even handier now.

(Also, note that I'm running jEdit (and Eclipse, and Flare 10, and…) with JRE 8. JRE 8 is still being tested but is available from Oracle.com and seems to be working well.)

Cheers & hope this helps,
Riley
SFO