Darker Theme 1.1: CSS Selector and OSGI Weaving

I am proud to announce Darker theme plugin 1.1 [1] for Eclipse 4.x platform. The reasons to be proud are two:

1. It gets 32 stars! As a one-day amateur work, I originally just try to experience and show the Eclipse 4 good stuffs[2]. But the community pushes the project forward. I decide to maintain the project constantly until we can get one better theme in the Eclipse itself of some time.
   
2. One weaving facility has been added into the Darker. The Darker is the first/only theme plugin to get over some styling defects shipped with the standard Eclipse instance. With this on the Darker, I can announce that it can do almost anything to challenge IDEA all round on the aesthetics of dark UI! (However, I truely have no time to make this done^_^)

To update minor version, Of course, it not only contains several bug fixings, but also introduces new things. One thing is,

• CSS selector.

The is an old pearl of e4/CSS works. But I am aware of its power until Lars[4]' pointing out in one issue[5]. In fact, the Eclipse 4 makes a hard work to provide one full CSS-spec-conformant styling engine.(At least, they want it to be full^_^) The CSS properties is just one aspect of CSS spec. The full story should includes the CSS selector. The CSS selector syntax provides a very powerful way to pick up some elements/objects to apply your style with.

Like Lars suggest "styling the Quick Access box"[5], this styling could be done by this following piece[7]:

Here, #SearchField Text is a traditional descendant selector syntax in CSS[8], which picks up the Text widget on the widget with ID #SearchField.

Simple and neat!

If you want to dig a little more, the Eclipse's wiki here[9] and the old Kai tutorial(in the bottom of that wiki page)[10] may be useful. The CSS styling engine gives more fun to Eclipse UI developers, although I am afraid that the layout problems seemly show barriers mentioned in that wike page in the meantime:)

The another new is just as I mentioned above,

• OSGI Weaving.

This weaving facility use the OSGI weaving functionality introduced in OSGI R4.3[6]. It allows load-time bytecode weaving, which can grant your some AOP capacities without huge dependencies.

It is a must. Because the investigation into another request[15] shows the SWT CLabel, as the background widget of stateline, forces a fixed OS related widget color as its foreground color from Control. That is, the CSS property setting is dumb here. Obvoiusly, the problem is systematic and  it can not be fixed in a near future of Eclipse development(or maybe never). I will feel very unhappy and stupid if I say to our guies that like "please wait, I have filed a bug entry against Eclipse". Then, the OSGI weaving comes to help.

Maybe you have known Equinox weaving[11] or AspectJ[12]. Yes, the OSGI weaving is a simplified version of Equinox weaving(but note that they are still different codes). AspectJ is an big animial. I have bitter memories about the AspectJ in my Scala IDE journey[13]:) One big headache is, that the Scala IDE users regularly report some update or functionality does not take effect in their environment. One reason is just due to the weaving configuration file have not been updated or picked up successfully by their Eclipse instances. I hope Iulian Dragos(leader of Scala IDE, Typesafe) has solved this problem:)

For one little theme plugin, I definitely do not want to take the nigtmare to the users. As a developer, we should be cautious to any addition. Then, the OSGI weaving is my choice.  The detail of implementation needs some ASM bytecode generation knowledge and provides the context based weaving(like cflow pointcut in AspectJ). To be honest, AspectJ syntax is simpler than direct bytecode manipulation if you have much complex context/condition combinations. I am just preparing a game-changing AOP kind of tool, but it needs time to come to the world:)

With correct weaving to SWT CLabel, Darker get a right white text color for the dark status line.


One tricky part I just to point out here, is the starting sequence of the plugins. The weave-working plugin should takes effect before the Eclipse UI things, more detailly here SWT CLabel, loaded into runtime. If you define this logics in your UI plugin, the order is definitly wrong. I solve this problem with two
simple points:

• separate the UI and weaving(non-UI) logics into different bundles;

• start the weaving bundle immediately after framework started.

The interesting thing is I use another new R4.3 "Start Level" API[4].(The other way may be to use kinds of hook[14], but I think it is just overkill.) It avoids any forced configuration modification for users in the Eclipse. It is a good practice.

OK, after this update, I plan to fully focus on my wonderful backend stuffs in my hobby time.
Stay tuned!


[1]:  https://github.com/jinmingjian/eclipse.themes.darker
[2]:  http://jmj-eclipse.blogspot.jp/2012/12/practices-for-eclipse-4-programming.html
[3]:  http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/hook/weaving/WeavingHook.html
[4]:  http://www.vogella.com
[5]:  https://github.com/jinmingjian/eclipse.themes.darker/issues/14
[6]:  http://wiki.osgi.org/wiki/Release_4.3
[7]:  https://gist.github.com/jinmingjian/5546115
[8]:  http://www.w3.org/TR/CSS21/selector.html#descendant-selectors
[9]:  http://wiki.eclipse.org/Eclipse4/RCP/CSS
[10]: http://www.toedter.com/blog/?p=477
[11]: http://eclipse.org/equinox/weaving
[12]: http://www.eclipse.org/aspectj
[13]: http://www.scala-lang.org/gsoc2010
[14]: http://wiki.eclipse.org/Adaptor_Hooks
[15]: https://github.com/jinmingjian/eclipse.themes.darker/issues/11

Practices for Eclipse 4 Programming Model

For "Eclipse 4 programming model"[1], I mean the way of how to program with the Eclipse 4.x platform, not the "Eclipse 4 application model"[2] itself, although they definitely have some close relations.

There are several tutorials[3] for the Eclipse 4 techologies. Here, I share some of practices in my last weekend theme plugin project[4] for making your projects more happy in Eclipse 4 platform. They may not be the best practices although I hope them are. So it is welcome to add criticisms and suggestions here:)

The biggest advantages of Eclipse 4 programming model, IMHO, is that:

• Dependency injection has been introduced;

We have had the Guice[5] from crazy Bob[6] for a long time. We found it is bettter to be adopted for container/framework-provided behaviors. This has been widely used in Java EE 6+ world. And now it comes to Eclipse planet!

• Many services have been extracted and become standard;

This is a absolute overhaul for Eclipse platform. This makes the consuming to Eclipse platform become much simple and relaxed.

Let me summarize somethings for you:

1. Consume the services by dependency injection way as possible.

For a self-explained instance,

Loading ....

Here, I get the IEclipsePreferences service.

Another way is to use the programatic API call. As you known, the service is verbose to use it correctly. The DI way makes your life easier!
[caveats/bugs]
Note, there are some caveats described here[9]. If you have problems in DI, please report it to Eclipse[10] and this helps Eclipse 4 to faster growth.

2. Consume plaform services as possible.

There are many very important services have been abstracted as the services of platform.

Loading ....

In this sinppet, Eclipse will provide four services for us. For example, the event service is powerful for general use. It, in fact, provides a mechanism for hooking/intercepting into the whole platform.

Loading ....

Here, I observe the theme change event for hooking editor-scoped preferences customization.

More detailed services could be seen in [7] and [8].
[caveats/bugs]
In my experiences with the event service, there is a bug for @EventTopic injection now, which, I found, has been discussed here[12]. That is, if you work under the Eclipse IDE environment, then the @EventTopic annotated method parameter will be injected with an org.eclipse.equinox.console.command.adapter.CommandProviderAdapter object. My workaround, shown above, is to use the event handler explicitly. But seemly you can use @Optional annotation with combination of @Inject as metioned in that discussion[12], although it is an e4 specific annontation and the semantics of it is not for the workaround obviously. However, finally, I prefer @EventTopic way in that reason shown in the following #3.

3. Injection to your objects in a full managed way is simple.

The truth here is, Eclipse 4 DI does not come into your world automatically. Then, how to link the Eclipse world with your business?
One workable way is to use IEclipseContext to bind you model. IEclipseContext is hierarchical. There are several kinds of IEclipseContext. Do not mess you up with the hierarchy! You can consult one Jonas's tutorial [11] for getting more basic infos. If you construct an RCP, then you may like to use this way.
For IDE managed enirvoment, like an Eclipse plugin, I recommend you to use the model processor extension as your entry point to the Eclipse 4 DI world.

Loading ....

You can extend the extension point org.eclipse.e4.workbench.model to enable it, like this:

Loading ....
It extension point is for the application model, in fact, as the document. But I think, it is simple and nice to use it with you business objects before we have a general DI hooking point if you want to forget the programatic injection.

[caveats/bugs]
Do not assume that a platform UI side services or objects could be injected and used here. For instance, you can not inject the IThemeEngine service in the model processor(IThemeEngine service is prepared after the processing of model). I guess it is intentional. There are still two ways for  this:

• use the EventHandler to watch the UI side topic exactly.
• use application model to bridge to your UI related POJOs. You can inject kinds of services here. This is just the way the e4 bundles selfs do their works.

4. Eclipse 4 Tooling is your friend.

It is not easy to consume the Eclipse 4 technologies now. There is a tooling project[13] come to help you: it includes the CSS Spy, CSS editor, application model editor and live editor.
For example, there are two ways to contribute/extend the application model:

• one is to change the model pragramatically(this is my favorite way).
• another is to use e4xmi model file. For this way, an application model editor is expected to have. Lars has provide the step-by-step guide[16].

[caveats/bugs]
The emf live editor is a little out-of-date in the weekend. I think it will be fixed soon. If you meet error log shows that one shell can not be found and injected. You can pull the source from[13] and annonated IServiceConstants.ACTIVE_SELECTION) to it. This is an intentional change documented in the[9].

As my evaluation to the Eclipse 4.3 nightly, it is good to consume now!
And we have got famous perfermance bugs fixed[14].
And I find the quick fixing for plugins is more intellisense[15].
And GTK3 is out for linux fans' testing(But it has an obvious bug now. So, I suggest you wait one or two milestone to test)[15].

As a plaform, Eclipse 4 has many many advantages to IDEA 12, IMHO. Do not hesitate to migrate to Eclipse 4! Help us to evolve!


References:
[1] http://www.eclipse.org/eclipse4/
[2] http://eclipsesource.com/blogs/2012/05/10/eclipse-4-final-sprint-part-1-the-e4-application-model/
[3] http://wiki.eclipse.org/Eclipse4/Tutorials
[4] https://github.com/jinmingjian/eclipse.themes.darker
[5] http://code.google.com/p/google-guice/
[6] http://blog.crazybob.org/
[7] http://wiki.eclipse.org/E4/Contexts
[8] http://wiki.eclipse.org/E4/EAS
[9] http://wiki.eclipse.org/Eclipse4/RCP/Dependency_Injection
[10] https://bugs.eclipse.org/bugs/
[11] http://eclipsesource.com/blogs/tutorials/eclipse-4-e4-tutorial-part-4-dependency-injection-basics/
[12] http://www.eclipse.org/forums/index.php/t/351144/
[13] http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/
[14] http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation
[15] http://download.eclipse.org/eclipse/downloads/drops4/S-4.3M4-201212140730/news/
[16] http://www.vogella.com/articles/EclipseRCP/article.html

Eclipse Darker Theme and Sorry to Unexpected Blog Update

Firstly, please allow me to say sorry to my unexpected update to one of my blog entry in the last weekend. This caused an very old blog entry re-posted to the planet again.

Because I am planning to start new round of posts in the community, so I do a little tweaking to the blog. I do a update to that blog entry in that several readers asked the status of my SEED project[1] in its release-following period. Unfortunately I must say it has been dead for many reasons.

After the SEED project M0, I have done a more deep investigation and reflection to the current languages on JVM. Like Scala, Kotlin(Ceylon, althoug I've forgot it, but not including the Groovy and Xtend), the basic conclusion is that the complexity much outweights the advantages of the language after the advanced features coming right before your eyes. Some adopters likes to keep to use a subset of the language to keep a good taste. But, if we only limits us to a subset, why we choose this language?

For example, recently, our Xtender Sebastian addressed an exception checking codes in Xtend v.s. Java 8[2]. His favorate Xtend codes like this:
"
import static extension Throwables.*
val uri = [| new URI(requestURI) ].onException [
new IllegalArgumentException(it)
]
"

This codes, IMHO, just uncovers one big problem(or fault) which is much popular in the current mainstreaming JVM languages: that is, "Symbol Hell".

Who knows what " [| new URI(requestURI) ]" stands for when one man meets these codes firstly? In some language, the operator could be mostly arbitrarily customized(to encourage the flow controlling). The result is that, you would regularly sees the in “clever” coders 's DSL library or framework:

~[...] ... ^ ... -|| ... <- -="-" ...="..."> ...

Are this codes happy to see by us?... I am afraid that, it is not the right direction that for the future of language...



Now, back to the topic of this post:)

Recently, IDEA 12 re-introduce a darkula theme[3], which makes our community a little nervous. The chronon boy posted one solution in the planet[3].

Recently, I start to migrate to the Eclipse 4.3 from old 3.8 platform. As I point out in my preious post[1] , the biggest problem to Eclipse Juno is that, the UI  is ugly. The color is not harmony with native platform. The default Sash separation is too large. The worst thing is that, we always hate the round-corner tab[4]!

Not it is the time to eat our dog food!

In the weekend, I hack a simplest dark theme implemenation for the community: eclipse.themes.darker[5], which is based the style schema of eclipse-color-theme[6].

As you can see, the dark theme still has some not-dark elements in fact. Some of these is from the limitation of the SWT, like the button background color. But the css style engine still leaves the contribution space for us. After a little more work, I got this:

Yes, it is darker than that of the dark:)



The big fun is that, the codes are minimized by using Eclipse4 platform technologies like dependency injection[7]. It proves that again, the concise codes and advanced features could be achieved by contributing or extending with the external form(like library, framework). New language is not necessary just for this kind of purpose.


"Java Is Dead, Long Live Java!"


[1] https://github.com/jinmingjian/seed
[2] http://zarnekow.blogspot.jp/2012/12/fixed-checked-exceptions-xtend-way.html
[3] http://eblog.chrononsystems.com/dark-eclipse-theme
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=367691
[5] https://github.com/jinmingjian/eclipse.themes.darker
[6] https://github.com/eclipse-color-theme
[7] http://wiki.eclipse.org/Eclipse4/RCP/Dependency_Injection

SEED(Scala Eclipse Effort for Development) 1.0M0 Reached

NOTE: the project has been stopped in that no enough time and my reflection to the language.

Firstly, thanks for your jumping into this entry. The SEED(Scala Eclipse Effort for Development) project is my current weekend project. The sources of SEED can be seen in the github: https://github.com/jinmingjian/seed.

table of contents

Motivation

M0: a clear architecture

Incubated in the bleeding edge

Answer to the community

What’s next

Invite to contribute

Self-introduction

​

Motivation

​What do you really matter when taking Scala into one large software production instead of Java? the IDE tooling? Yes, the professional Scala Developers need the professional tools to hack engineering. Because Java IDE have set a high bar to the user experience of language IDE, it is hard to think the developers and especially the enterprises will be comfortable with changing into a much worse coding environment although the language itself seem better.

The basic motivation is to drive the design and implementation of SEED to match the requirements of the professional Scala Developers.

​

M0: a clear architecture

The basic philosophy of the SEED is :

1. stable user experiences is first

2. reflect the language characteristics and merits of Scala itself

3. do not depend on uncontrolled sources;

4. invite community to contribute

The overall architecture and concerns could be seen as follow picture:

Then, what can we see in the SEED m0? Compare two snapshots between the SEED m0 and the Scala-IDE(one version in July, 2011):

​

from Scala-IDE

​

from SEED

from the snapshots, it can been seen that:

1. the packagings are mapped usefully

it will provide the viewpoint of flattening the packaging(collapse empty packagings)

2. method member's signature only displays the type of parameter, some member's type is missing

this is by design almostly , except the main(Array) is not full displayed for the unfinished type model. It is decided that the SEED Scala model scanner will not do any inference than the simple syntax scanning. Then, how to get the type infos? The type infos will be decorated in the later when it is resovled by the nsc. The Scala model scanner is not replacement for NSC. It collaborates with NSC.

3. ':', '=' are highlighted as the keyword

these symbols are reserved words explicitly by the Scala specification[1]. As this is a little different to the Java, the SEED will provide a preferences to configure this in the future.

4. expression have been addressed

this construct is quasi-unique for Scala(but similar to the initialization block ), like the self type, early definition, class parameters, type definition... The SEED will provide the outline item for visualizing them. However, as the reason that I mentioned in one previous blog entry, it is decided that the SEED Scala Model scanner will not do any inference than the simple syntax scanning. So, the Expression, as one kind of template statement, will be displayed as {...}, FYI.

​

The internal thought behind the snapshot is:

1. the SEED have a lightweight Scala Model system which services for the presentation layer ​and kept in the memory with editor.

2. Scala NSC will provide the full semantics and AST of Scala sources as a background service;

3. Scalal NSC nuts (like AST...) considered heavyweight will be discarded by UI immediately after used.(however, it has not right to ask the NSC to do this as well)

For the time limitation, I do not deep into more aspects of design. However, heavy investigations and works have been done in the m0. I believe the architecture have given a solid basic editing exprience to the SEED, and will pave the way for cool features like reference navigation in the next.

In m0, the SEED goes beyond the editor.

​

Incubated in the bleeding edge

This is long topic for the SEED. I pick up some interestings for showing. The SEED adopts two techniques in e4: EMF and DI(Dependency Injection).

​These two techniques are just the basestones of the coming Eclipse 4.2 release("Juno") . However, they are not very known even by Eclipse platform developers.

EMF is one effective modeling framework in fact. The big picture of the SEED Scala Model is here:

​​It shows a early version of model structure in that I drop the ecore graphical tooling later for the obvious sync problem. And the type subsystem is still in the changing.

​EMF really makes the SEED deveoplement easier. With it, the SEED model elmenets have the capabilities of notification and navigation when it borns. And I have done the ContentProvider for thirty model elements in thirty lines by just using the EMF reflection. And I predicate that more emf based techniques would contribute to the SEED. This is just the trend shown in Eclipse Juno.

​

The other technique - e4 DI(Dependency Injection), is relatively new topic in the Eclipse world.

The OSGI DS spec trys to remove the boilerplate codes in the services' publishing/referencing in the form of one component model. However, the component model itself introduces some new boilerplates. One problem is, you need to reference the service in one component in the DS. Even through one component is like one POJO in appearance, its cost is far from that of POJO in the bottom. The worse thing is, the component instantiation is under the control of (DS) framework. If some components need to be instantiated by hand or by other frameworks, the own business object can not consume the service directly. It needs to design kinds of auxiliary callback structures to expose the service to the business object(or some services may be designed with "Whiteboard" pattern). (This is by my understanding to the DS spec in the early years. If some one think it is not true, please correct me. I will clear it for DS^_^) The final result is that, we pusblish the serivce in the DS-style, but return to consume it in the ServiceTracker-style in our own business object.

​The e4 DI is one technique which could solve all these problem . We can use the e4 DI to inject the service directly. The contexts should/can maintain the boiledplates for service consumers.

For the Eclipse 4.2's ugly face and a little bad experiences, I still use the Eclipse 3.8 milestone. After some investigation into sources, I have successfully integrate the e4 DI in the 3.8 enviroment. There are some tricks for doing this. However, still for the time limitation, I can write another blog to address these tricks. If you want to do similar things just now, you can consult the usage of ILexingService in the com.github.seed.core here.

In a word, the SEED, as the Eclipse-based IDE, have aligned with the newest Eclipse techniques. Futhermore, the SEED will follow the rhythm of Eclipse, but not the Scala(however, the internal of SEED will depends on the svn head of Scala after bootstrap). The SEED definitely should support to choose your favorite Scala system library(I leave the Scala team to guarantee the compatibility^_^). the SEED R1.0 will come soon after the Eclipse R4.2/3.8. I will definitely consider the compatibility to the Eclipse platform. As for the clear base, the SEED may support the plaftform from R3.6 to R4.2 if it is really needed:)

There are many other internal designs and implementations in the SEED not mentioned above. such as how about the Scala Model Scanner, the source Lexer. Some of them are in the changing. The key here is that, all designs and implementations have been thought to conform to the basic philosophy mentioned above. For the limitation of both time and space, it is hoped it could be covered in the future.

What’s next

Recent milestone concerns:

M1 theme: bootstrapping

type system(index system)

nsc integration(I am planning to do a tweek for NSC to make the integration more more natively)

build system(fsc?/sbt?)

M2 theme: self-hosted

binary class viewer

preference to switch your own scala system library

classpath container support

SEED codes wiill switch to Scala(eat my own dog food)

M3-R1.0:

performance

preferences

customized CNF-based "Scala Package" view

basic mixed Java/Scala integration

basic refactoring support(rename)

my implicit highlighting work

...

any contributions

Answer to the community

I may answer one question to the community: why not contribute to the Scala-IDE project?

The answer is: Simply, I can not agree on the base architecture of the Scala-IDE. In fact, the two projects has much different architectures. SEED is a clean-room implementation, even for its icons. All of my ideas are hard to be implemented in the Scala-IDE. Workarounds may exist, but it is definitely ugly. The tooling for Scala should originally be one straight, happy, rhythmical work for developer. But now it becomes the headaches of some hardworker. However, in the future, it could be possible to collaborate if we reach an agreement on the base. I hope the SEED would become a seed for one great Scala IDE.

Invite to contribute

For the clear architecture, it is easy and fun to contribute to SEED. The informal prerequisite is the basic knowledge of Java, Scala, Eclipse and/or OSGI. But you can contribute anything even if you are not a programmer.

Let's say about the feature of "Mark Occurrences", it could be implemented by adding a new token based occurrences detection service (like IFetchOccurrencesService) by consuming the LexingService as the backend. As for the frontend(UI), you can mock my token highlighting logic firstly. Or it is better to abstract one token based rendering service for all kinds of things in the future. It may cost hours or days which depends on what you want to do and how much you are familiar with the Eclipse platform.

I will be very glad to see your name here. Or you like to fork or clone to play the codes first.

Self-introduction

This last section in this blog entry seem odd. I hope this advertisement will not disturb you. I have written a blog entry about myself and my techinical road here in July.

I have touched several startups for some Scala opportunities. It is interesting that the number of scala opportunities is much less than ruby/python/javascript in the U.S..

However, it is found that the main problem for me is that the foreign H1B sponsorship is considered heavy for the startup. So, I decide to widen the seeking range to Eclipse/OSGI(or Java?) now.

If you read here and your employer are seeking Scala/Eclipse/OSGI work and your employer supports the foreign H1B sponsorship, please help to give me a recommendation if you think I am qualified for your works. What I can promise is, if it fail to apply for the work permit, I can contribute to one project your company pointing in my two month's weekends to compensate your application cost! My current work is about the web serivce component development for an well-known application server. In fact, I have done many backend works as well. For the sake of privacy, we can talk about more privately. I gratefully thank for any opportunities on behalf of my family.

I will pause the SEED development in the following several weekends for fully seeking the new opportunities. But I think it will be finalized quickly. I will be back soon.

Finally, as a rule, the SEED 1.0 should have a codename. I decide to call the R1.0 as the "SuperDaddy"(under the umbrella of Eclipse "Juno"^_^) to acknowledge my wife and daughter's support in these weekends. I love you!

When is the SEED M0?

When is the SEED M0?

As recently one Chinese developer have commented about the status of my recently blogged project about the Scala Eclipse IDE. Because this blog is published without any tags. So I used to think nobody will focus on it. This is my expectation in that I I have no habit of publishing any toys.

I'd like to first announce the name of project is SEED - Scala Eclipse Effort for Development":) This project will be hosted in the github. The recent funny thing is Linus Torvalds move the latest linux kernel tree to the github.

The biggest hard point of SEED now is the time. I basically have no time to contribute it except the weekend. I have killed two version of the implementation way. Finally, I decided that there must be one new Scala Model for eclipse-side presentation layer for putting the SEED into one stable and lightweight tooling in the daily usage(like JDT). One hand-written recursive descent parser/scanner for members of Scala top template definition is under construction(parser generators are too terrible for use).

​The harder work is here is the spec of Scala language is complex to fully understand. The EBNF syntax notation of Scala in spec have shown some entanglement. Like PATH is StableId, but StableId is also the PATH. This may let the notation writer more convenient, but increase the complexity of understanding and implementation. Some parts of notation is anti-intuitive. like some one pointing out in the official forum, Scala allows such definition:

val 1 = 2

from the syntax aspect, this is allowed by the fact that the pattern match style contructs can be used as one way to define variable(s). Some one think it will be kept for symmetry. But I think there is non-symmetric here in fact(like this literal pattern matching). The scope of the semantic of pattern matching is larger than that of variable definition. It is a bad smell in the language! In fact, this allowance is mainly for convenience. In almost cases, we can move the pattern match semantic just to the right of assignment, like:

val x = selector match { case ....

This kinds of design in the language much increase the freedom of language. But I think the freedom is not always the good thing for the developers. If many ways can reach one point, which way we should choose to go?

And furthermore, the wrost things for the IDE tooling designer is, for parsing such a little constructs, I even need to include almost all the syntax constructs into the parser/scanner. So heavy cost!

Some trade-offs have been made in the process. And I think everything is still under the control. It is hope by me, the SEED M0 could be published in two more weekends or so. That is the time! I am seeking some Scala related opportunities. If this can become true, I will have definitely constant daily time to contribute to the SEED. Wait for that day.

Thanks for all the followers!