is there a plan for jEdit plugin?

[GoogleCodeExporter]

It would be great if a Zencoding was available for jEdit. I know there is a 
port of 0.5.1 version but couldn't get it to work.

The coolest thing is that this way I could get Zencoding for a crossplatform 
really customizable editor :)

Original issue reported on code.google.com by cyryl...@gmail.com on 30 Oct 2010 at 2:22

[GoogleCodeExporter]

ZenCoding is the only missing plugin for my jEdit setup... I'm voting for that 
too!

Original comment by jf.stgermain@gmail.com on 11 Nov 2010 at 3:32

[GoogleCodeExporter]

I'm voting for that, too! I like to use Zencording in Jedit!

Original comment by yukiko.i...@gmail.com on 26 Nov 2010 at 11:46

[GoogleCodeExporter]

Original comment by serge....@gmail.com on 12 Dec 2010 at 3:19

• Added labels: Type-EditorSupport

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

jEdit! jEdit! jEdit!

I ignored jEdit for a long time, looking for a decent free html editor.  I 
finally decided that there is not a decent free, WYSIWYG html editor that does 
not play havoc with indentation and element order in your source files.  I 
finally tried jEdit, and now I love it.  What other free text editor has 
up-to-date spell checking under Windows, with underlining of misspelled words 
on the fly (VoxSpell), TextMate-like macros (SuperAbbrevs), color-coded 
highlighting, code beautifiers, tons of bean-shell scripts with a 
well-documented object model, an automatic plugin manager with tons of great 
plugins, recording of keyboard macros, is cross-platform and is intuitive to 
use for Windows users?  IMHO, the only things it really lacks are ZenCoding, 
and an associations editor.  Yes, it is written in Java, and runs a bit slower 
than native code, and starts up a little slow.  Aptana Studio is also written 
in Java, and runs far slower; but is still popular.  Unfortunately, it has no 
spell-checking, and no decent generalized snippets interface (clipper in 
jEdit); and while Eclipse has WYSIWYG for free, it is not good enough to use 
regularly.  IMHO, jEdit has it all over Aptana Studio.  While jEdit starts a 
little slow, once it starts, it runs fast, and can do everything you need - 
except for ZenCoding.  I have it set up for its Project Viewer to "Preview Node 
in Browser", so it is always convenient to view a page you are editing.

I think jEdit is a greatly underestimated editor, in part because it is easy to 
underestimate the features available, how well they work; and because the 
initial download is rather bare-bones.  I think this would be a fabulous editor 
for the ZenCoding project to support.

Original comment by strideroflands@yahoo.com on 3 Feb 2011 at 8:46

[GoogleCodeExporter]

Would it be possible to pass the ZenCoding string you just typed into a 
command-version of ZenCoding (like it is possible with Sparkup as below) :
# echo "div#somediv>p.someclass{some content}" | sparkup

I had to do this to allow some of my students to get some of ZenCoding 
functionality since Sparkup has a command you can place in your $PATH...

Original comment by jc.tabo on 23 Feb 2011 at 11:10

[GoogleCodeExporter]

Although I am not much of a jEdit programmer, I think I can give some hints as 
to a command-line sparkup approach.  First, it has to be multiplatform, because 
Java and jEdit are.  sparkup appears to be written in Python, and if so, Python 
is multiplatform.  I'm not sure how a Python script looks like a binary in 
Lynix, but I would guess that it is finding sparkup.py, and using a file 
association, or else has a script to hand it off.  In any event, it will need 
to run under Windows; as it evidently already runs under Mac.  Second, it will 
need to be able to be downloaded as a jEdit plugin.  jEdit has nearly all of 
its plugins available through its plugin manager; but then Python would have to 
be installed as well, and jEdit would have to find it.  None of these is 
necessarily a problem.

One thing that would be missing, if a command-line sparkup were used, would the 
jumping to the next field.  If a macro were to return a sparkup text buffer, 
how would it know how to jump from place to place?  If such a strategy were 
implemented, lacking this feature, it seems it would only be a temporary 
solution; lacking this important functionality.  That being said, sparkup does 
seem to have some solid advantages over ZenCoding; but I would be happy to use 
either one in jEdit.

Original comment by strideroflands@yahoo.com on 27 Feb 2011 at 9:57

[GoogleCodeExporter]

> That being said, sparkup does seem to have some solid advantages over 
ZenCoding; but I would be happy to use either one in jEdit.

I hate when someone argues that library X is better than Y without 
understanding how Y works.

First, there’s a plugin HOWTO for those who wants to implement Zen Coding 
functionality into their editor of choice: 
https://github.com/sergeche/zen-coding/wiki/plugin-howto

Second, Zen Coding is more that just abbreviation expander and it can’t be 
implemented just like a command-line tool (although it possible to do that).

Third, Zen Coding is implemented in Python and JavaScript, and there’s a Java 
layer on top JS implementation that powers Eclipse plugin: 
https://github.com/sergeche/eclipse-zencoding/tree/master/src/ru/zencoding This 
layer can be used for writing native jEdit plugin without any external 
dependancies like Python runtime.

Original comment by serge....@gmail.com on 27 Feb 2011 at 3:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

>I hate when someone argues that library X is better than Y without 
understanding how Y works.

I do too.  Did I imply that I had any idea of one being better than the other, 
except as a casual user looking at their specification?  For one thing, the 
phrase "seem to have" precludes a matter of fact statement "X is better than 
Y."  Do you just like jumping on people and correcting them, even when it is 
not clear they are wrong?

> Second, Zen Coding is more that just abbreviation expander and it can’t be 
implemented just like a command-line tool (although it possible to do that).

I believe I said as much, that I knew of at least one thing a command line tool 
would not do.  I had tried out Zencoding om emacs and liked it, but found 
printing under Windows to be difficult to set up.  I don't know what, other 
than moving between fields that might be something that a command-line version 
could not do; but I am also, lest you jump to badmouth me again, not implying 
that there are not other reasons - I just don't know.

> Third, Zen Coding is implemented in Python and JavaScript ...

Thank you for pointing out that it not be Python dependent, and made to be 
easily adaptable to other editors.  The fact that Zencoding and jEdit are both 
written in Java, and jEdit in my experience anyway, is much faster than 
Eclipse, suggests to me that they would be a natural fit.  This gives me hope 
that adaptation will go relatively quickly if some of you Java programmers 
actually undertake it.

I am not a Java programmer.  I only thought I might have a little basic info on 
jEdit to contribute to the conversation.

Original comment by strideroflands@yahoo.com on 28 Feb 2011 at 3:10

[GoogleCodeExporter]

Sorry, I don't want to jump on anyone, I'm just saying that there's lots of 
documentation, source code and implementation examples of ZC plugins, but 
nobody wants to read it. It's not a first time when someone tells me that 
Sparkup has better design than ZC.

Original comment by serge....@gmail.com on 28 Feb 2011 at 9:57

[GoogleCodeExporter]

Hi,
if someone is still interested in Zen Coding for jEdit,
I started to implement similar feature in SuperAbbrevs plugin for jEdit.
I started 2 days ago so it is probably not perfect.
You can get it here :
http://community.jedit.org/?q=node/view/5014

Original comment by chocolat...@gmail.com on 6 Dec 2011 at 3:15

[GoogleCodeExporter]

Thanks very much chocolat...!  I've been hoping for this for some time; as 
awesome as SuperAbbrevs already is (TextMate-style abbreviations in Windows).  
I can't say as I've tested it extensively, but it seems to work.  I would have 
the following hopes for it at this point:

1) enable it in php mode, or perhaps select the modes it works in.  I code in 
php usually, although most of what I do is actually html.  Server-side includes 
are just too good to ignore, in addition to other stuff that php can do.

2) although I don't care, somebody somewhere might actually want to disable it, 
and leave the TextMate-style abbreviations working (or vice versa).  It would 
be nice, and presumably easy, to configure if either or both is active.

3) when it is working to your satisfaction, get it committed to the main 
repository (if it is not already), hopefully with an sentence or so indicating 
this super-awesome feature.

That being said, I look forward to trying it out in HTML files, and cutting and 
pasting to PHP. A description of zencoding syntax in the jEdit help would be 
icing on the cake, but it would not be hard for me to set up a macro that opens 
a chm file that hopefully somebody has made that describes the syntax.

Original comment by strideroflands@yahoo.com on 8 Dec 2011 at 2:08

[GoogleCodeExporter]

I also notice that the example ZenCoding line at the main site 
http://code.google.com/p/zen-coding/ does not seem to work correctly.  

div#page>div.logo+ul#navigation>li*5>a

lacks the anchor tags.  It would be good to indicate which version of Zencoding 
you are using in SuperAbbrevs; although having it at all is indeed a huge leap.

Original comment by strideroflands@yahoo.com on 8 Dec 2011 at 3:25

[GoogleCodeExporter]

Hi, thanks for your review.
About enabling it in php mode, I will do it, and for all modes that can contain 
tags.
The problem with php is that some parts are html, and other parts are php code, 
and to be perfect it should be activated only in html parts, but I don't think 
the apis of jEdit give that information.

The behavior of my implementation is to parse the beginning of the line and if 
it match ZenCoding syntax use ZenCoding, if not use the standard abbreviations 
of SuperAbbrevs.

But you are right I'll add an option to activate and deactivate it.

I will try to add the syntax documentation in the plugin help and of course the 
plugin will be released on the plugin central repository when it will be 
finished.

About your bug, I'll fix it as soon as possible.

In fact I don't really use ZenCoding, I implemented the feature from scratch 
and only tried to follow the same syntax (the goal is to have an exact match).

It is implemented using a JavaCC generated parser.

Original comment by chocolat...@gmail.com on 8 Dec 2011 at 6:59

[GoogleCodeExporter]

It strikes me that what you've done is pretty significant.  If, as it says 
above, "Zen Coding is implemented in Python and JavaScript," then you have in 
essence, recreated it using one language instead of two.  I suggest you not 
only continue as you are undertaking, but also release it to someplace like 
SourceForge or another code collaboration site.  If running it is more work 
than you intended, then you might post, either here or elsewhere, your 
willingness to share your work.  ZenCoding will continue to evolve, but using 
two interpretive languages.  A Java-only implementation will need updating as 
things progress, but it might come to be a project on par with the original 
ZenCoding, if released onto such a site.  Perhaps Java ZenCoding and the 
original might leapfrog with innovations, which get added retroactively to the 
other.

Original comment by strideroflands@yahoo.com on 9 Dec 2011 at 2:11

[GoogleCodeExporter]

Hi,
I completely rewritten my implementation, still using JavaCC.

You can get it here it's 2.0pre2
http://community.jedit.org/?q=node/view/5021

Added support for implicit div (.a#b is the same as div.a#b)
Added $$$$ padding support
Fixed a lot of bugs
Added options to deactivate it.
Activated it for html xml jsp php asp languages (but it is not aware of the 
context, so it can be used even in php snippet for example)

It doesn't support table+, ul+, dl+ that are specific to html and can easily be 
configured in standard abbreviations.
It doesn't do specific html things (like
head>link

will do
<head>
    <link rel="stylesheet" href="" />
</head>

with ZenCoding

but only do
<head>
    <link></link>
</head>

in my implentation (no implicit attributes are added)

Not yet supported :
-Filters
-text like p>{hello }

I'm still open to any feedback.
The code is licenced under GPL 2.

Original comment by chocolat...@gmail.com on 11 Dec 2011 at 3:51

[GoogleCodeExporter]

I tried to download it, but it didn't download as before.  Clicking on the 
download link directly appeared to load the archive as a webpage.  
Right-clicking and choosing Save As gave me some HTM file name.  Saving the 
file, renaming it to a JAR, and putting it in the program data folder and 
starting jedit resulted in a complaint that it was an invalid archive.  The 
resulting file size was 96.0k, whereas the desired file size was 113.23 KB.

Original comment by strideroflands@yahoo.com on 11 Dec 2011 at 5:42

[GoogleCodeExporter]

Strange I just tried and it worked, maybe the server failed when you tried.
Anyway I attach it here.

Original comment by chocolat...@gmail.com on 11 Dec 2011 at 8:05

Attachments:

• SuperAbbrevs.jar

[GoogleCodeExporter]

Very nice.  I guess you're at a crossroads, as to if you want to follow the 
ZenCoding standard, or go non-standard.  If non-standard, you might borrow a 
few things from sparkup.  I like that you can even tab between the inner tags.  
I could see the use for nesting, in principle: "p>{hello }".  I could also see 
the use of the newer body attribute with curly brackets, e.g. 
'a[href=z.com]{click me}'.  I say, in principle, because I have become at home 
in jEdit, and haven't had a chance to try zencoding in practice, and see how 
much I use it.  SuperAbbrevs already gives me much of what I hoped ZenCoding 
would, but I'm looking forward to seeing how much I might actually use it, 
given the chance.  It is far enough along now, for me to begin experimenting 
with it to get an idea.  I see that it already follows the surrounding 
indentation, which will add to its usability.  As I will probably be going into 
a programming mode moreso than maintaining websites, I will probably be Qt 
Creator more, so I can't promise in-depth practical feedback until I get around 
to updating websites again, but I'm sure I and others will be plenty excited to 
try it out.

I suggest you might chose to either 1) maintain 100% ZenCoding compatibility, 
2) do something a little more quick and dirty to produce the best adaptation of 
ZenCoding to jEdit, such as doing ul+, as you suggest, with existing 
SuperAbbrevs functionality as one might define ul<Tab>, or get really medieval 
on it, and offer a choice of 1) 100% compatible ZenCoding mode, 2) a ZenCoding 
mode where you might alter the syntax as you like, and 3) Sparkup mode.  I'm 
not saying you should expend the effort to maintain three different syntaxes 
long-term, nor am I saying you shouldn't, but only, depending on the level of 
effort you want to expend, laying out some logical overall choices.

I don't think it being GPL2 will hold anybody back from using it, or 
customizing the code as they like.  As to html-specific tags, I can see how 
somebody might like a link to always expand to '<link rel="stylesheet" href="" 
/>', but other tags might not have such boilerplate attributes.  A more general 
mechanism might be to have options similar to the existing SuperAbbrevs 
options, where you get to specify which attributes will be supplied by default 
by which tags, and where the tab stops are in them.  It would then be trivial 
to predefine typical attributes for various tags.  Handling tags like anchors 
that are sometimes names, and sometimes links, would require an as yet 
undrempt-of strategy.

When I right-click on SuperAbbrevs 2.0pre2 to download the .jar, I get the 
filename "2hlRCWxJ.htm.part", and it's 96k; even after clearing the browser 
cache.  This is in FF 3.6.24, running in SandBoxie, on WinXP Home (I know - I 
just haven't shelled out the $$ for the ug w/ m$ yet).  When I try to download 
it in IE, it calls it "community_jedit_org.zip", but when I rename it to 
superabbrevs.jar, all is well.  This was NOT the case with the first preview, 
nor do I normally experience oddities like this when running in a sandbox.  It 
may represent something odd about the way it was put up, or a bug at the jEdit 
site.  Of course, that will not be an issue to those who upgrade their 
SuperAbbrevs one day, and see a note that ZenCoding has been added.  Many, 
many, many thanks for providing this for jEdit 8P, as I almost passed over 
jEdit for lack of this feature alone, even though I'd never used it.  If 
nothing else, it will be one less barrier to others adopting it, but it may 
speed the XML-esque tag coding of its users considerably.  Ok.  Now my feedback 
is done.  Now I get to actually try it.  Yay!

Original comment by strideroflands@yahoo.com on 12 Dec 2011 at 7:56

[GoogleCodeExporter]

Oh, one last afterthought.  One theoretical consideration, is that if you do 
want 100% ZenCoding compatibility, you might need either special SuperAbbrevs 
codes, or the ability to ignore their definitions.  When you expand an existing 
tag that is only the bare tag itself, does, e.g. "a" expand to the 
TextMate-like SuperAbbrevs definition, or the Zencoding one?  Currently, it 
only seems to use the existing SuperAbbrevs definition, which I do not mind at 
all, but 100% compatibility would require eliminating the conflict, in any 
cases where pre-packaged definitions conflict with ZenCoding.  Nothing that 
bothers me in practice, but for ppl who are coming from another editor who 
already know ZenCoding, 100% compatibility might be brownie points to them.  If 
you have such a mode, checking 100% compatibility would override TextMate-like 
definitions.  Alternately, you might note in the help that some TextMate-like 
definitions need to be changed for 100% compatibility, or have a button that 
changes them.  Like I say, you have a few choices to make now.

Original comment by strideroflands@yahoo.com on 12 Dec 2011 at 8:07

[GoogleCodeExporter]

allowing a TextMate-like expansion key and a Zencoding expansion key to be 
defined might be another way of handling that.

Original comment by strideroflands@yahoo.com on 12 Dec 2011 at 8:10

[GoogleCodeExporter]

I believe I spotted a bug. "h3<Tab>" expands to <h></h>; which must be a 
ZenCoding interpretation, since it does not do this when ZenCoding is disabled. 
 However, "a<Tab>" expands to the TextMate-like definition.  It would be best 
if it were consistent whether the one or the other expansion is used.  As it is 
now, it seems better to let the TextMate-like definition override the ZenCoding 
one, since there is GUI to modify it to one's liking.  Alternately, it might be 
an option, which one overrides the other in a conflict.

Is Zencoding supposed to expand "someunknowntag<Tab>" to 
"<someunknowntag></someunknowntag>" or "<someunknowntag>"?  I don't know, but 
XML guys will have stuff like this come up.  The former seems the more frequent 
case.

If you get as far as specifying which attributes ZenCoding expansions expand 
to, an option for a tag NOT to expand multi-line would be nice, so you could 
write "a[href=abc.com]>b<Tab>" and get '<a href="abc.com" target="_new"></a>', 
e.g.  A different same-line expansion key would be another approach yet; but do 
most authors have some tags as multi-line, and others as same-line, nearly 
always?

I find it odd that "bbbbbb a[href=foo]>b" expands to "<bbbbbb></bbbbbb>", but 
"bbbbbb" expands to nothing.  The former is not the case with ZenCoding off.

Original comment by strideroflands@yahoo.com on 12 Dec 2011 at 8:47

[GoogleCodeExporter]

You can use JS version of original ZC implementation through Mozilla Rhino, as 
I did for Eclipse plugin: 
https://github.com/sergeche/eclipse-zencoding/blob/master/src/ru/zencoding/JSExe
cutor.java

So there’s no need in custom implementation.

Original comment by serge....@gmail.com on 12 Dec 2011 at 11:32

[GoogleCodeExporter]

By "JS version of original ZC implementation", does that refer to an old 
version?  Where is it? I am also, however, intrigued by the possibility of 
custom ZenCoding tag attributes; which I have only yesterday suggested, but 
would mesh with jEdit and SuperAbbrevs rather nicely.  Also, it might help 
chocolat... out to mention where the JS-only version is; as this one reportedly 
is JS+Python - in case he decides to go that way.

Original comment by strideroflands@yahoo.com on 12 Dec 2011 at 8:12

[GoogleCodeExporter]

Here it is:

http://coding.smashingmagazine.com/2009/11/21/zen-coding-a-new-way-to-write-html
-code/

Interestingly, apparently unlike the Google project, the video says "New 
abbreviations and snippets can be added as editor snippets", much as I was 
suggesting.  It says this only works in Espresso only, tho. :~( sniff

I also notice they are on vers. 0.5, whereas the google project is 0.7, and yet 
they can do fancy stuff like highlighting a column of text items, and make a 
<ul> out of it.

Original comment by strideroflands@yahoo.com on 12 Dec 2011 at 8:30

[GoogleCodeExporter]

It seems he is linking to the Google project.  Without knowing anything about 
the libraries internally, I'm not sure whether they require JS AND Python, or 
JS OR Python.  Sergei is using a large JSON to define his snippets.  If a 
snippet file were used, that would be fine by me, too.

Original comment by strideroflands@yahoo.com on 12 Dec 2011 at 9:00

[GoogleCodeExporter]

Hi, I have a lot of work these days so I'm unable to work a lot on that but at 
least I fixed the bug with 
h1 expanding to <h></h>

About the h+ syntax that are redundant with SuperAbbrevs abbreviations I don't 
know what I will do yet.
The nesting syntax like p>{hello } will be implemented but I don't know when.
About expanding link to <link rel="stylesheet" href="" />, I think it can be 
done using the filters when I will implement them.

About JS implementation I know that it exists but I don't like the idea of 
using a scripting language in the middle of this because I would have to 
maintain the Javascript plugin for jEdit too.

Original comment by chocolat...@gmail.com on 17 Dec 2011 at 10:02

Attachments:

• SuperAbbrevs.jar

[GoogleCodeExporter]

I just downloaded the most recent SuperAbbrevs.jar.  I notice that it now 
breaks on the first example on the Google ZenCoding page again:

div#page>div.logo+ul#navigation>li*5>a

I would say, if you only have time to do a few things to SuperAbbrevs due to a 
new job, my hopes would be (I know it looks like a lot, but I'm trying to keep 
it simple - the last two involve no coding):

1) the ability to prefer original SuperAbbrevs definitions for text without 
">", possibly including "#" as well, so that when ZenCoding definitions apply, 
by checking this new option, it will ALWAYS use ZenCoding definitions where 
conflicts exist, or ALWAYS use original SuperAbbrevs definitions.

2) to release it with the bugs worked out of the features you have now, as best 
you can.

3) to release it officially with a description in the help

4) to affix a notice, when you release it, that the code is GPL, and you 
welcome attempts to improve it or repurpose it, with proper notice.

These I would see as the way to spend the least effort to make the most of what 
you've achieved so far.  Many thanks for the excellent effort on behalf of 
jEdit users you've made so far. :P

Original comment by strideroflands@yahoo.com on 17 Dec 2011 at 5:43

[GoogleCodeExporter]

The point of my suggestion of allowing original SuperAbbrevs when selected for 
simple text strings is so that, since there is no mechanism for custom jEdit 
ZenCoding expansions yet, tags can always have custom attributes using the old 
mechanism where desired, with ZenCoding constructs available as well.  It would 
be a kludge until custom ZenCoding expansions might be implemented.  
Alternately, perhaps the existing definitions might ALWAYS be used for 
ZenCoding expansions - perhaps again, optionally.

The suggestion of using the JavaScript ZenCoding would be just so that you 
didn't have to maintain it - only the interface between jEdit and it.  This 
still might involve a fair amount of work.  To me, better objections to the 
JavaScript version would be along the lines of 1) the work involved, with an 
initial draft of SuperAbbrevs 2.0 almost ready, 2) the inability to customize 
the syntax, 3) the time in loading the JavaScript interpreter and initializing 
it, and having an additional install involved.

Original comment by strideroflands@yahoo.com on 17 Dec 2011 at 6:00

[GoogleCodeExporter]

Hi, here is a fix for the broken 
div#page>div.logo+ul#navigation>li*5>a

I started implementation of inner tags like p{sometext} but I have a lot of 
problems because I don't understand the logic of the original ZenCoding here :
for example 
a>{here }*2
expands as
<a href="">here here 
 </a>

That's ok but
a>{here }*2>b
expands to
<a href="">here here 
 </a>

I would expect 
<a href="">here here 
 </a>
instead or am I wrong ?

About GPL, in fact jEdit and almost all plugins of jEdit are released under GPL 
2, and my implementation is already in jEdit's svn repository here

http://jedit.svn.sourceforge.net/viewvc/jedit/plugins/SuperAbbrevs/trunk/superab
brevs/zencoding/html/

Original comment by chocolat...@gmail.com on 23 Dec 2011 at 10:00

Attachments:

• SuperAbbrevs.jar

[GoogleCodeExporter]

a>{here }*2>b is incorect abbreviation: you’re trying to put tag inside text 
node, which is invalid

Original comment by serge....@gmail.com on 23 Dec 2011 at 10:59

[GoogleCodeExporter]

Thank you, so I should not care about the result of that call and the best 
would be to not expand it

Original comment by chocolat...@gmail.com on 23 Dec 2011 at 11:14

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Looking to the example on the home page, and reducing it:
li*5>a
expands to:
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>

thus:
a>{here }*2>b
would lead me intuitively to expect:
<a href="">Here</a>
<a href="">Here</a>

However, since:
a>{here }*2
expands to:
<a href="">here here</a>

I see that the *2 also seems to double things to the right of it also, as in 
the home page on the Google Zencoding site, so, I think I would expect:
<a href="">here here </a>
would indeed follow from this rule.

If it is indeed undefined or an error, and you entertain implementing a 
behavior, it becomes more important to decide if you want to follow the 
official syntax precisely or not.  It sounds like you are leaning toward 
following the official syntax; but if you have a solid reason for departing 
from it, I am not against, e.g. an option to enable your own tweaks.

Inner tags should be a helpful feature, but unless you are able to get a lot 
done pretty soon and working well, I would gravitate to really getting the 
parts you have tried to implement before or including this working really well; 
so as to be of use to ppl sooner; especially if you might get called away on 
yer new job.  That being said, I would indeed like to see inner tags and e.g. 
custom ZenCoding tag attribute definitions for jEdit at some point.  When I was 
a professional software developer, we used to budget fully 1/3 of our time for 
debugging.

Original comment by strideroflands@yahoo.com on 23 Dec 2011 at 8:59

[GoogleCodeExporter]

Hi, I still have some problems with *x syntax and probably others but here is a 
new version.
It supports inner text like 
p>{Click }+a{here}+{ to continue}
It also knows default attributes and their default values for some of them like
img> will expand to <img alt="" src=""></img> (I still need to remove the 
closing tag and expand to <img alt="" src=""/> instead.
I'll be on vacancy for one week, have a nice christmas.

Original comment by chocolat...@gmail.com on 24 Dec 2011 at 9:24

Attachments:

• SuperAbbrevs.jar

[GoogleCodeExporter]

Thanks.  I should get a chance to give some feedback w/in a wk.  Merry 
Christmas!

Original comment by strideroflands@yahoo.com on 24 Dec 2011 at 5:43

[GoogleCodeExporter]

I've been super busy getting money to pay property taxes and preparing for 
dad's surgery. I haven't had time to look at it much yet. However, in my mind, 
the #1 problem with usability is when you want it to expand a SuperAbbrevs 
abbreviation, and you get the ZenCoding one instead. You have it using 
ZenCoding unless there is a SuperAbbrevs expansion, but that leaves one unable 
to customize attributes for some tags. It should either be 1) the other way 
around, preferring SuperAbbrevs where there is a conflicting expansion, so we 
can customize these frequently used expansions, 2) selectable, and/or 3) with 
editable ZenCoding attributes. It is too limiting to say, ok, now you can't use 
SuperAbbrevs for anything ZenCoding does with a single tag, and you can't 
modify what it expands to. That's my two cents anyway, although you and/or 
others may feel differently.

Original comment by strideroflands@yahoo.com on 3 Jan 2012 at 1:20

[GoogleCodeExporter]

About SuperAbbrevs expansions I could reverse . First the SuperAbbrevs and if 
there is on match try ZenCoding.
Abou default attributes and their values it is customizable but I did not make  
option pane for that

Original comment by chocolat...@gmail.com on 3 Jan 2012 at 8:32

[GoogleCodeExporter]

I think reversing it is highly preferable, since SuperAbbrevs/TextMate style 
expansions can be of arbitrary length and use any tags. There is already a GUI 
to edit them, so if you don't like what one is doing, you can change it, and if 
you want the ZenCoding action instead, you can just delete the SuperAbbrevs 
entry. Either way, you can change the behavior you're getting, if you need to.

That sounds great, that you are planning on making default attributes 
customizable. It sounds like you are either going to have a text file, an XML 
file, or a BeanShell script that we can set them in. 

Original comment by strideroflands@yahoo.com on 5 Jan 2012 at 7:25

[GoogleCodeExporter]

Zen Coding also supports snippets of arbitrary length (they called, well, 
"snippets": see "Element Types" section at 
http://coding.smashingmagazine.com/2009/11/21/zen-coding-a-new-way-to-write-html
-code/) and they are almost 100%-compatible with TextMate snippets.

It's a mistake to think of Zen Coding as xHTML generator, it's actually 
advanced snippets system which can fully replace existing snippet system of 
your favourite text editor.

Original comment by serge....@gmail.com on 5 Jan 2012 at 9:20

[GoogleCodeExporter]

About abbreviations snippets, SuperAbbrevs already support them.
But what I'm not sure to understand is how ZenCoding can handle declared 
snippets in ZenCoding syntax :

if I type
mytag#example
if there is no snippet for mytag it will output:
<mytag id="example"><mytag>

but if 
mytag snippet is "hello world", what happens to
mytag#example ?

About customizing default attributes it is already possible with beanshell 
snippet :
everything is properties. For example

defaultattributes.html.iframe.0=src
defaultattributes.html.iframe.1=frameborder
defaultattributes.html.iframe.1.value=0

defaultattributes. is the prefix.
html is the edit mode (so it is possible to have default values that are 
different in html, xml or any edit mode.)
the next element, iframe is the tag name.
Then there is a number of position for the attribute, it starts at 0.
And it is possible to add .value to set a default value, otherwise it will be 
empty.

So to add a new property id you just add this
defaultattributes.html.iframe.2=id
and if you want a default value

defaultattributes.html.iframe.2.value=theid

in beanshell :

jEdit.setProperty("defaultattributes.html.iframe.2","id");
jEdit.setProperty("defaultattributes.html.iframe.2.value","theid");

You can execute beanshell from Utilities->BeanShell menu

Original comment by chocolat...@gmail.com on 5 Jan 2012 at 9:58

[GoogleCodeExporter]

if "mytag" is a snippet with value "hello world", ZC will output "hello world" 
for mytag#example or any other snippet with "mytag" name.

ZC currently has two types of entities: "element" (mistakenly defined as 
"abbreviation") and "snippet" (and will third, "generator" type in v0.8). 
Snippets are arbitrary pieces of text and the only thing ZC can do about 
snippets is to replace attribute placeholders with passed values. For example, 
you can define `mytag: "hello ${id}"` snippet, and for `mytag#John` or 
`mytag[@id=John]` it will output `hello John`, but for `mytag` or `mytag.class` 
it will produce `hello `.

The "element", however, has different behavior. ZC knows how to parse, 
construct and handle them. The final output is actually defined by filters: 
http://code.google.com/p/zen-coding/wiki/Filters

Take, for example, "html" filter, which defines output for HTML and XML. It 
accepts passed abbreviation as parsed tree and updates output for nodes with 
type of "tag", while keeping "snippets" output as is (it just replaces 
placeholders inside them): 
https://github.com/sergeche/zen-coding/blob/master/javascript/filters/html.js#L1
62

Original comment by serge....@gmail.com on 5 Jan 2012 at 10:27

[GoogleCodeExporter]

From what I understand of Serge's message, ZC only allows snippets via the 
agency of filters. Thus, while it would be possible to use Textmate style 
expansions via filters, one would have to type two additional characters to get 
them. Thus:

html|f

might result in a default web page template. As there are a sizable number of 
users who are using SuperAbbrevs TextMate style expansions without such 
filters, while filters would be a nice feature to support later, since Chocolat 
is redoing it all in Java, since we already have such TextMate snippets, and 
since they would be shorter by two characters, simply using the SuperAbbrevs 
expansion if it exists first, as we were suggesting, allows one to tailor these 
using the preexisting interface as one would want, to use with ZenCoding 
expansions, and implementing filters in due time, seems to offer a better 
alternative. Thus, TextMate expansions would be two characters shorter, and 
existing SuperAbbrevs users wouldn't have to relearn a new way to do them. It 
would also be easier to implement.

If there were a way to use filters without a pipe character and filter name, 
then it should be possible to use them to implement existing TextMate-like 
functionality in SuperAbbrevs, but it might also take more development time.

I am impressed by the quality of most jEdit plugins. I have spotted only one or 
two of the ones I've tried to have significant bugs (the calculator is a 
notable example). Many free, open-source editors have a majority of their 
plugins unworking. Chocolat's ZenCoding seems 60-80% of the way to having 
another solid, potentially important function added to jEdit. I thus encourage 
you, Chocolat, not to bite off more than you can get working well in a 
reasonable time, but to get what you do get working to work well.

Original comment by strideroflands@yahoo.com on 9 Jan 2012 at 9:43

[GoogleCodeExporter]

No, you don't need any filter to output snippet! Snippet is a special kind of 
entity ZC understands out-of-the-box. If something is defined as snippet, it 
will be outputted as-is, if something is defined as element (or not defined at 
all), it will be formatted and outputted according to applied filter.

Original comment by serge....@gmail.com on 10 Jan 2012 at 7:46

[GoogleCodeExporter]

Hi, sorry for the few response I do, I'm a little busy.
I tried to move SuperAbbrevs abbreviations to top priority before ZenCodings, 
but the problem in that case is that when I do

a>b
I get 
a>
I don't think it is good.
About snippets it is interesting but I have to think how I could implement them.
I also think that I should release a first version on plugin manager, even if 
it is not 100% complete yet, it is better than nothing and is a good start, 
don't you think ?
If do you think the current version cause too many problems ?

Original comment by chocolat...@gmail.com on 10 Jan 2012 at 10:18

[GoogleCodeExporter]

In my opinion, I usually wind up disabling it, as it interferes with the 
existing SuperAbbrevs. You being the author, it us up to you as to whether to 
release it, but I'd number it 0.x to signify that it lacks a lot to support 
ZenCoding well.

That still might not be a bad idea.  As I pointed out before, if you don't like 

a>b expanding to 
a>

you can just delete the definition of b. As I understand it, this configuration 
will work much like Serge is describing for ZC's snippets. The important thing 
is not to break working snippets with ZenCoding enabled. Breaking ZC with 
TextMate snippets to me seems less bad, what with the ZC feature being the new 
guy on the block. ZC may have a different solution to such issues yet. By 
editing the BeanShell script, one could make their own snippets; but then you 
are SUPERCEDING the TextMate-style expansions. ppl will wonder why all their 
TM-ish snippets changed when ZC is enabled. As it is, there is no user-friendly 
GUI for editing them. The first thing that happens when ZC is enabled is a lot 
of unexpected, and not easily correctable behavior. Making it an option would 
be a good choice too.

Again, an in-line ZC expansion option will help greatly in usability, too. I am 
not as worried about what you do with it now as that your efforts toward making 
it more usable are applied effectively.

Original comment by strideroflands@yahoo.com on 10 Jan 2012 at 2:40

[GoogleCodeExporter]

Hi, I'm back after a long time, sorry for that, I reworked the plugin to make 
it more user friendly.
Now the original superAbbrevs are called first, if nothing happens ZenCoding is 
called.
I will add a new action to call explicitely Zencoding and probably add a 
documentation.
There is still one thing I don't understand well is abbreviations in the end of 
an existing line like this :

name="SuperAbbrevs" default="build" basedir=".">a

the original Zencoding will expand only the a
and I will get 
name="SuperAbbrevs" default="build" basedir="."><a href=""></a>

How Zencoding determine which part of the like must be parsed as Zencoding ? 
and which part must be ignored ?

Original comment by chocolat...@gmail.com on 23 Mar 2012 at 7:58

Attachments:

• SuperAbbrevs.jar

[GoogleCodeExporter]

Thanks Chocalat. I was beginning to wonder if you'd quit updating SuperAbbrevs 
or not. I think your Java Zen-Coding is to the point that I can begin to use it 
practically.  I tried the example on the ZenCoding homepage: 
"div#page>div.logo+ul#navigation>li*5>a".  SuperAbbrevs only expanded the "a" 
tag.  That is good.  I then renamed the "a" tag to something else, and tried 
again.  It worked as on the home page. I guess you know that in your preceding 
example, SuperAbbrevs does not expand it the way you have the original 
Zencoding; hence asking how Zencoding knows.  I don't.  In your above example, 
you currently get a "name" tag. I looked for your custom Zen Coding action, but 
I didn't see it.  I only saw Tab, Shift-Tab, and "Show Expansion Dialog" as 
SuperAbbrevs actions available for binding.  The latter only responded to 
original SuperAbbrevs format.  I didn't see any Expand Zencoding Only action.

I think it works well enough now that I can trying it it practically.  You 
might consider making it part of the official release, as it does not break 
SuperAbbrevs.  My suggestions as to how to improve it from here, beyond 
determining how much to expand, would be:

1. I don't think I'd want Zen Coding expansions to be applied first, until you 
might get Zen Coding macros expansion - TextMate style, so as to replace 
SuperAbbrevs.  Even then, you might keep them around for backward 
compatibility. Even so, other users might want Zen Coding expansions to be 
applied first, like it was. This seems like it would be an easy option to add: 
which gets expanded first.
2. Have a user interface to change additional attributes for tags
3. Have a user interface to add new Zen Coding expansions

OK. Going to play with the new Zen Coding plugin now.

Original comment by strideroflands@yahoo.com on 23 Mar 2012 at 1:53