diff --git a/config/nginx/default.conf b/config/nginx/default.conf
index ba17923022a2d809b631c9d25d95954074866b3b..4b6ba566b1ba7aebb51caa9030f343b0b3bd5a6c 100644
--- a/config/nginx/default.conf
+++ b/config/nginx/default.conf
@@ -276,76 +276,76 @@ server {
location = /org/langsymp/A%20note%20for%20the%20Eclipse%20Language%20Conference.pdf {
- return 301 https://$host/org/langsymp/a-note-for-the-eclipse-language-conference.pdf;
+ return 301 https://$host/events/2005/langsymp/a-note-for-the-eclipse-language-conference.pdf;
}
location = /org/langsymp/content/org/langsymp/Adding%20support%20for%20a%20new%20language%20to%20an%20Eclipse%20based%20.pdf {
- return 301 https://$host/org/langsymp/adding-support-for-a-new-language-to-an-eclipse-based-ide.pdf;
+ return 301 https://$host/events/2005/langsymp/adding-support-for-a-new-language-to-an-eclipse-based-ide.pdf;
}
location = /org/langsymp/Ascher%20-%20Eclipse%20Position.pdf {
- return 301 https://$host/org/langsymp/ascher-eclipse-position.pdf;
+ return 301 https://$host/events/2005/langsymp/ascher-eclipse-position.pdf;
}
location = /org/langsymp/CDT%20Managed%20Build%20System.pdf {
- return 301 https://$host/org/langsymp/cdt-managed-build-system.pdf;
+ return 301 https://$host/events/2005/langsymp/cdt-managed-build-system.pdf;
}
location = /org/langsymp/Compiled%20Language%20Support%20In%20Eclipse.pdf {
- return 301 https://$host/org/langsymp/compiled-language-support-in-eclipse.pdf;
+ return 301 https://$host/events/2005/langsymp/compiled-language-support-in-eclipse.pdf;
}
location = /org/langsymp/CraigRasmussen.pdf {
- return 301 https://$host/org/langsymp/craig-rasmussen.pdf;
+ return 301 https://$host/events/2005/langsymp/craig-rasmussen.pdf;
}
location = /org/langsymp/Doug%20Lang%20Symp.pdf {
- return 301 https://$host/org/langsymp/doug-lang-symp.pdf;
+ return 301 https://$host/events/2005/langsymp/doug-lang-symp.pdf;
}
location = /org/langsymp/Eclipse%20and%20Dynamic%20Languages.pdf {
- return 301 https://$host/org/langsymp/eclipse-and-dynamic-languages.pdf;
+ return 301 https://$host/events/2005/langsymp/eclipse-and-dynamic-languages.pdf;
}
location = /org/langsymp/EclipseEverywhere.pdf {
- return 301 https://$host/org/langsymp/eclipse-everywhere.pdf;
+ return 301 https://$host/events/2005/langsymp/eclipse-everywhere.pdf;
}
location = /org/langsymp/eclipseLanguagePosition.pdf {
- return 301 https://$host/org/langsymp/eclipse-language-position.pdf;
+ return 301 https://$host/events/2005/langsymp/eclipse-language-position.pdf;
}
location = /org/langsymp/Extending%20Eclipse%20with%20Languages%20Other%20Than%20Java.pdf {
- return 301 https://$host/org/langsymp/extending-eclipse-with-languages-other-than-java.pdf;
+ return 301 https://$host/events/2005/langsymp/extending-eclipse-with-languages-other-than-java.pdf;
}
location = /org/langsymp/Extending_Eclipse_with_Compiled_Languages_other_than_C.pdf {
- return 301 https://$host/org/langsymp/extending-eclipse-with-compiled-languages-other-than-c.pdf;
+ return 301 https://$host/events/2005/langsymp/extending-eclipse-with-compiled-languages-other-than-c.pdf;
}
location = /org/langsymp/ExtendingEclipseInHaskell.pdf {
- return 301 https://$host/org/langsymp/extending-eclipse-in-haskell.pdf;
+ return 301 https://$host/events/2005/langsymp/extending-eclipse-in-haskell.pdf;
}
location = /org/langsymp/JulianDolby_paper.pdf {
- return 301 https://$host/org/langsymp/julian-dolby-paper.pdf;
+ return 301 https://$host/events/2005/langsymp/julian-dolby-paper.pdf;
}
location = /org/langsymp/lang_symposium_oct_2005.pdf {
- return 301 https://$host/org/langsymp/lang-symposium-oct-2005.pdf;
+ return 301 https://$host/events/2005/langsymp/lang-symposium-oct-2005.pdf;
}
location = /org/langsymp/MImrisek_Languages_Workshop_PositionPaper.pdf {
- return 301 https://$host/org/langsymp/m-imrisek-languages-workshop-position-paper.pdf;
+ return 301 https://$host/events/2005/langsymp/m-imrisek-languages-workshop-position-paper.pdf;
}
location = /org/langsymp/Multi%20Language%20Support%20-%20User%20Perspective.pdf {
- return 301 https://$host/org/langsymp/multi-language-support-user-perspective.pdf;
+ return 301 https://$host/events/2005/langsymp/multi-language-support-user-perspective.pdf;
}
location = /org/langsymp/Split%20along%20Technology%20not%20Language%202005-10.pdf {
- return 301 https://$host/org/langsymp/split-along-technology-not-language-2005-10.pdf;
+ return 301 https://$host/events/2005/langsymp/split-along-technology-not-language-2005-10.pdf;
}
location = /org/langsymp/StayingPragmatic.pdf {
- return 301 https://$host/org/langsymp/staying-pragmatic.pdf;
+ return 301 https://$host/events/2005/langsymp/staying-pragmatic.pdf;
}
location = /org/langsymp/TestPointInPractice.pdf {
- return 301 https://$host/org/langsymp/test-point-in-practice.pdf;
+ return 301 https://$host/events/2005/langsymp/test-point-in-practice.pdf;
}
location = /org/langsymp/Volanakis%20-%20Mixed-language%20usage%20scenarios.pdf {
- return 301 https://$host/org/langsymp/volanakis-mixed-language-usage-scenarios.pdf;
+ return 301 https://$host/events/2005/langsymp/volanakis-mixed-language-usage-scenarios.pdf;
}
location = /org/langsymp/langsympduimovich.html {
- return 301 https://$host/org/langsymp/common-eclipse-support-for-language-ides;
+ return 301 https://$host/events/2005/langsymp/common-eclipse-support-for-language-ides;
}
location = /org/langsymp/Oct2005LanguageGroup.html {
- return 301 https://$host/org/langsymp/language-support-in-eclipse-wtp-sse;
+ return 301 https://$host/events/2005/langsymp/language-support-in-eclipse-wtp-sse;
}
location = /org/langsymp/position_paper_martin_aeschlimann.html {
- return 301 https://$host/org/langsymp/a-seed-for-an-eclipse-language-toolkit;
+ return 301 https://$host/events/2005/langsymp/a-seed-for-an-eclipse-language-toolkit;
}
# Legal migration
diff --git a/content/org/langsymp/_index.md b/content/org/langsymp/_index.md
deleted file mode 100644
index 0befb8535f2962ccef29fb6a2f0521e1ec9e2829..0000000000000000000000000000000000000000
--- a/content/org/langsymp/_index.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: The Eclipse Languages Symposium
-hide_sidebar: true
-keywords: ["The Eclipse Languages Symposium"]
-layout: single
----
-
-## Position Papers Received So Far;
-
-- [Martin Aeschlimann "A Seed for an Eclipse Language Toolkit"](./a-seed-for-an-eclipse-language-toolkit)
-- [David Ascher "An Alien's Perspective"](./ascher-eclipse-position.pdf)
-- [Ward Cunningham "TestPoint In Practice"](./test-point-in-practice.pdf)
-- [Julian Dolby "Using Static Analysis For IDE's for Dynamic Languages"](./julian-dolby-paper.pdf)
-- [John Duimovich "Common Eclipse support for language IDE"](common-eclipse-support-for-language-ides)
-- [Brian Foote "Architectural Balkanization in the Post-Linguistic Era"](./balkanization.pdf)
-- [Bjorn Freeman-Benson "Extending Eclipse with Languages Other Than Java"](./extending-eclipse-with-languages-other-than-java.pdf)
-- [Leif Frenzel "Extending Eclipse in Haskell"](./extending-eclipse-in-haskell.pdf)
-- [Doug Gaff "Extending Eclipse with Compiled Languages Other than C/C++"](./extending-eclipse-with-compiled-languages-other-than-c.pdf)
-- [Guy Harpaz "Multi Language Support (MLS) - User perspective"](./multi-language-support-user-perspective.pdf)
-- [Martin Imrisek "Compiled Language Debug as Extensions to Platform Debug vs. Parallel Hierarchy"](./m-imrisek-languages-workshop-position-paper.pdf)
-- [Mike Milinkovich "Staying Pragmatic"](./staying-pragmatic.pdf)
-- [Jeffrey Overbey "Instant IDEs: Supporting New Languages in the CDT"](./etx-paper.pdf)
-- [Andrey Platov "Eclipse and Dynamic Languages"](./eclipse-and-dynamic-languages.pdf) (not attending)
-- [Alan Pratt "A note for the Eclipse Language Conference"](./a-note-for-the-eclipse-language-conference.pdf) (not attending)
-- [Craig Rasmussen "Native Parser/Compiler Front Ends for Eclipse?"](./craig-rasmussen.pdf)
-- [Chris Recoskie ""Compiled" Language Support in Eclipse"](./compiled-language-support-in-eclipse.pdf)
-- [Reginald Reed "Eclipse Everywhere"](./eclipse-everywhere.pdf)
-- [Doug Schaefer "Can the CDT DOM be used to represent languages other than C and C++"](./doug-lang-symp.pdf)
-- [Michael Scharf "Split along Technology not Language"](./split-along-technology-not-language-2005-10.pdf)
-- [Markus Schorn "Adding support for a new language to an Eclipse based IDE"](./adding-support-for-a-new-language-to-an-eclipse-based-ide.pdf)
-- [Mikhail Sennikovsky "CDT Managed Build System"](./cdt-managed-build-system.pdf)
-- [Leo Treggiari "Build Configurations & Tool-chains"](./lang-symposium-oct-2005.pdf)
-- [Elias Volanakis "Mixed-language usage scenarios in Eclipse"](./volanakis-mixed-language-usage-scenarios.pdf)
-- [Ed Warnicke "A Desire for a Point of Integration"](./eclipse-language-position.pdf)
-- [David Williams "Language Support in Eclipse WTP/SSE"](language-support-in-eclipse-wtp-sse)
-
-[All papers in one zip.](all.zip)
-
-## Workshop Format
-
-We'll run the workshop in the [LAWST](http://www.kaner.com/lawst.htm) / [WOPR](http://www.performance-workshop.org/content/view/28/64/) style. The workshop will have seven sessions, each with a different topic emphasis:
-
-* Thursday 9-10:30 - Overview/Architecture
-* Thursday 11:00-12:30 - Existing Frameworks
-* _lunch_
-* Thursday 1:30-3:00 - IDE for Dynamic Languages
-* Thursday 3:30-5:00 - _wild card_
-* _dinner_
-* Friday 9:00-10:30 - IDE for Compiled Languages
-* Friday 11:00-12:30 - Plug-ins Written in Other Languages
-* _lunch_
-* Friday 1:30-3:00 - _wild card_
-
-For each session, I will choose one of the relevant attendees to be the center of the discussion. We'll start with a question like "tell us about what you did" and the center will give us an unrehearsed, but very knowledgeable description, probably based on their position paper. Then we'll spend about half an hour discussing the center's story; questions like "how did that work?" and "how did you solve this problem?" are legitimate - questions that form little mini-lectures about "I did X" are not. Once we have extracted the center's story and commingled it with the experiences of the others, we will open the discussion up to others with similar systems, experiences, ambitions or beliefs. Here's where you can tell a bit about your story while still staying focus on the session's topic.
-
-The wild card sessions at the end of each day will be used to continue or extend interesting topics that arise during the day. They might be used for another center of discussion session or they might be used to brainstorm about direction and action items or they might be used to continue an earlier discussion or ...?
-
-## Older Paragraphs about the Workshop Format
-
-We'll run the workshop in the [LAWST](http://www.kaner.com/lawst.htm) / [WOPR](http://www.performance-workshop.org/content/view/28/64/) style. This means that all attendees must submit a position paper. No paper; no attendance; no exceptions (even Mike and I will write position papers). The position paper should be on one of the four topics:
-
-* Eclipse Language Support for dynamically typed languages (Perl, Tcl, Python, PHP, Ruby,etc).
-* Support for writing Eclipse plug-ins in dynamically typed languages (Python, Ruby, Tcl, etc).
-* Generic compiled language debugging infrastructure and implementation
-* Current state and future of the text and document model in Eclipse
-* All issues related to supporting compiled and dynamic languages in Eclipse
-
-The intent of requiring a position paper is to (1) have everyone better prepare by writing � or at least outlining � a paper and reading all the other papers prior to a session, and (2) frankly to filter out the idly curious. These people are not unwelcome, but especially when they dilute the discussion or occupy limited seats then their attendance does not have high priority. The idea is to have brief position papers or longer, more developed papers to help each of us lead a group-wide discussion. In the most recent LAWST workshop session, several papers were only one or two pages long, and the longest was about 25 pages. The flavor is different than traditional conferences, with mostly one-way communication to a large group. These workshop sessions are more like small group peer reviews with lots of impromptu brainstorming.
-
-The position papers are all distributed (email) in advance. The papers will be grouped into approximately six sessions. Not all papers will be included (there might just not be a logical place). Each session will start with presentations by the select authors. Not slick powerpoint presentations, but more of an interactive talk: the author will describe his or her experiences, ideas, difficulties, and so on. A couple powerpoint slides or, better yet, a demo, are acceptable, but the key here is that this is a workshop - an interactive conversation - not a lecture. In general, the talk should be about successes and future successes, but instructive failures are also welcome. After the war stories, there is general discussion between the audience and the speakers - the key feature of the discussion is that it stays focused on the speakers' points and does not devolve into each audience member giving a short speech about his or her own ideas.
-
-## Logistics
-
-* The symposium will be held October 27th and 28th at the QNX headquarters at [175 Terence Matthews Crescent, Kanata, ON, Canada](http://maps.google.com/maps?q=175+Terence+Matthews+Cres,+Kanata,+ON,+Canada&spn=0.003736,0.005657&t=k&hl=en). There is no registration fee for this workshop which also means that you're responsible for your own transportation and accommodation. Sharon (the Eclipse administrator and Ottawa resident) suggests these hotels:
- * [Holiday Inn Select](http://www.ichotelsgroup.com/h/d/hi/1/en/hd/yowow?irs=null)Â Â Â Middle of the road
- * [Brookstreet](http://www.brookstreethotel.com/reach_us/)Â Â Â Â Â Â Â High end
- * [Days Inn](http://www.daysinnottawawest.com/cont.htm)Â Â Â Â Â Â Â Â BasicThey are all about 10-15 minutes by car from QNX.
-* We will begin each day at 8:30am 9:00am. Not everyone can attend both days (some people are in the CDT workshop that overlaps by a day; some people have early flights out on Friday), but we'll do the best we can. We will have a group dinner outing Thursday evening.
-* The CDT Workshop that we are overlapping with is holding a party Wednesday night, October 26th and we're all invited. [Linda Campbell](mailto:linda@qnx.com) of QNX would like your RSVP if you plan to attend so that she can order enough food. The details are:
- * Pizza, Beer, Pool @ Le Skratch - [1642 Merivale Road, Nepean, Ontario](http://maps.google.com/maps?q=1642+Merivale+Road,+Nepean,+Ontario&t=k&iwloc=A&hl=en) - 6:30 p.m. until 9:00 p.m or later.
-
-### The CDT Workshop
-
-Note that QNX is hosting the CDT workshop Tue-Wed-Thurs at the same location. In fact, it is QNX's generosity with their space that allows this Languages Workshop to occur. The key thing to remember is that the CDT Workshop (Tue-Wed-Thurs) is separate from the Languages Workshop (Thurs-Fri). They are co-located to take advantage of many of your travel plans, but they are separate events. I'm not organizing the CDT Workshop; I am organizing the Languages Workshop.Â
-
-## Goal of the Languages Symposium
-
-The goal is to get a group of smart engineers and researchers together for two days to talk about, and plan the future of, language support in Eclipse. The symposium will be a very interactive workshop - not a conference with formal papers and lots of bored listeners reading email on their laptops.
-
-## Deadlines
-
-The original deadline was Friday, October 14th, but we all know that these things slip a bit, so the new deadline is a week later: Friday, October 21st. But I'm still happy to accept very very late papers - so send them in.
-
-To attend, you must submit a position paper.
\ No newline at end of file
diff --git a/content/org/langsymp/a-note-for-the-eclipse-language-conference.pdf b/content/org/langsymp/a-note-for-the-eclipse-language-conference.pdf
deleted file mode 100644
index 1017b078e894d069db6ba17908cfc9edf3d14f05..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/a-note-for-the-eclipse-language-conference.pdf and /dev/null differ
diff --git a/content/org/langsymp/a-seed-for-an-eclipse-language-toolkit.md b/content/org/langsymp/a-seed-for-an-eclipse-language-toolkit.md
deleted file mode 100644
index a7f7049375d42fdf0bcbd05636ec2ee0dd4c9059..0000000000000000000000000000000000000000
--- a/content/org/langsymp/a-seed-for-an-eclipse-language-toolkit.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: A Seed for an Eclipse Language Toolkit
-hide_sidebar: true
----
-
-## Martin Aeschlimann, IBM Research Zurich
-
-Position paper for the Eclipse Language Symposium in Ottawa (October 2005)
-
-
-## My background
-
-I'm a member of the Eclipse JDT UI team since its beginning. Responsibilities are the quick fix feature, including the underlying code rewriting infrastructure. I'm in close contact with the JDT model and DOM-AST and also helped there evolving these APIs. I happened to be the author of a 3 week C-plug-in prototype that later became be the seed for the current CDT plug-in.
-
-## Motivation
-
-The approach taken when implementing this CDT prototype was to follow the concepts and structure of the JDT plug-in. Eclipse gives you comprehensive support to integrate (e.g. building, launching, compare and search) and reusing/extending existing components like editors with outline views. Still there were parts that had to been copied; most notable the language model infrastructure.
-
-Several other language plug-in implementations followed that same way and duplicated again the same code, resulting in the desire that Eclipse should provide a common infrastructure for language models to avoid code duplication.
-
-API is always costly in creation and especially in maintenance. It introduces new dependencies that can hinder innovation as you get locked into solutions. JDT was therefore very conservative investing work towards this topic. However, more infrastructure has significant benefits. For developers it's a time saver, users get language plug-ins, faster and maybe designed more consistently, and the Eclipse platform wins by providing new infrastructure.
-
-To summarize, the goals are:
-
-* Distill the JDT / Platform proven concepts so they can also be used for new language plug-ins.
-* A fresh look at the problem, make is as simple as possible. Start fresh and don't have the goal to bring existing plug-ins into the framework. Gain more experience with new language plug-ins to create new infrastructure and improve existing plug-ins in this direction.
-* Provide a seed with the goal to be grown by the community
-
-## Proposal
-
-In my proposal for a seed, I would like to look at the problem from a compiler and not from an editor or explorer perspective. A compiler's inputs are tokens and it uses parsers to build syntax trees. Most of the tooling for a language plug-in (e.g. refactoring, quick fix) directly works on ASTs. The proposal therefore 'structures' the language model along these lines and use _tokens_, _AST nodes_, _token streams_ and _parser_ as foundation for a language independent toolkit.
-
-The interesting question is, what kind of concepts are needed as a foundation to implement as much concrete functionality as possible?
-Only having AST nodes and tokens will not be enough. For example it would not be possible to show an outline (of declarations) in a generic way. The solution is to add additional information to AST nodes such as structural information. This additional information can be annotations on the node itself or provided by visitors that calculate it.
-
-This is a sketch of abstractions, concrete type names have been used for illustration only:
-
-* **ILanguageModel**: access point to the languages infrastructure
- * getTokenStream(ISourceElement) : ITokenStream
- * createAST(ITokenStream) : AST
-* **ITokenStream**
- * getNextToken(): ITokenNode
-* **IAST**
- * getASTRoot(): IASTNode
- * findNode(position)
-
-The types ITokenNode and IASTNode could both be unified using INode
-
-* **ITokenNode**: abstract base class for tokens
-* **IASTNode**: abstract base class for AST nodes: has parent (AST node) and children (nodes: AST nodes and tokens), provides functionality to traverse children and to the node type
-* **INodeType**: meta information describing token types and AST node types
- * what are the children for a node of this type: what token types what node types, are they mandatory
- * which nodes are declarations
-
-Languages often have the concept of declarations and references to these declarations. A resolver connects references to declarations
-
-* **IResolver**
- * Given a AST node, find the corresponding declaration (to be discussed in what format)
-
-The following sections describe what language neutral infrastructure can be built using these abstractions:
-
-* **Handle based elements**: ASTs are usually expensive to build and to keep in memory. There's a need for a more lightweight element that can be used e.g. by viewers. These elements are created from the AST, but don't hold a reference to it. They can rebuild the underlying AST anytime when required.
-The handles are usualy only a subset of the existing AST nodes, typically all declarations.
- * **NodeHandle**
- * Inexpensive representatation of an AST node that can be shown in viewer. Does not hold on the full AST, but can rebuild AST if necessary
- * Handles: Might not exist anymore (or not yet)
- * can be stored/restored using mementos
-* **Search index**: Indexing declarations and references
-* **AST flattening** and **code formatting** using the AST node type properties
-* **AST rewriting** infrastructure using AST flattening and code formatting
-
-
-On the user interface front it is now possible to implement a 'generic editor':
-
-* **syntax highlighting** from token streams
-* **structure views** (Outlines) from handle based elements
-* **code resolve** ('Open Declaration F3') using the resolver
-* **structured selection expansion** (Source > Expand Selection) and **bracket matching** using AST nodes
-* **mark occurrences** and **local (linked) rename** with the resolver
-* **auto-indent** using the formatter
-* ...
-
-It has to be noted that using such a generic editor is good to get quick results for new plug-ins. It is likely that language plug-in will use the generic editor as a base, but extend with language specific features.
-
-Optional opportunities (extra plug-ins):
-
-* Generation of compatible scanners and ASTs from a grammar
\ No newline at end of file
diff --git a/content/org/langsymp/adding-support-for-a-new-language-to-an-eclipse-based-ide.pdf b/content/org/langsymp/adding-support-for-a-new-language-to-an-eclipse-based-ide.pdf
deleted file mode 100644
index 970a02860f41b2eafa8fe2a24aa01970969b15d2..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/adding-support-for-a-new-language-to-an-eclipse-based-ide.pdf and /dev/null differ
diff --git a/content/org/langsymp/all.zip b/content/org/langsymp/all.zip
deleted file mode 100644
index 41aec11dd2562983018d214561db88f096e209ac..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/all.zip and /dev/null differ
diff --git a/content/org/langsymp/ascher-eclipse-position.pdf b/content/org/langsymp/ascher-eclipse-position.pdf
deleted file mode 100644
index 65a66baa85bcb6f7b428367cdaeea38266fbc26d..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/ascher-eclipse-position.pdf and /dev/null differ
diff --git a/content/org/langsymp/balkanization.pdf b/content/org/langsymp/balkanization.pdf
deleted file mode 100644
index b5d5dd5104476ec6dce7d63ab618aeb47f91453d..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/balkanization.pdf and /dev/null differ
diff --git a/content/org/langsymp/cdt-managed-build-system.pdf b/content/org/langsymp/cdt-managed-build-system.pdf
deleted file mode 100644
index 0556efb02faf1b41f3b4b1a026ebaa4fd05405c9..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/cdt-managed-build-system.pdf and /dev/null differ
diff --git a/content/org/langsymp/common-eclipse-support-for-language-ides.md b/content/org/langsymp/common-eclipse-support-for-language-ides.md
deleted file mode 100644
index 59107593a1b2bec2fb9f3865e96dcd1eb42ee890..0000000000000000000000000000000000000000
--- a/content/org/langsymp/common-eclipse-support-for-language-ides.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Common Eclipse support for language IDEs
-hide_page_title: true
-hide_sidebar: true
----
-
-
-# Common Eclipse support for language IDEs Position Paper for Eclipse Languages Symposium
-
-John Duimovich
-October 21, 2005
-
-**Position**
-
-I am interested in making it simpler to create new programmming language IDEs for the Eclipse platform. I am motivated by my work on a Smalltalk IDE for Eclipse in which I found I was writing too much code for the functionality I was getting in return. I found that was that much of the code ends up being very similiar to code found in JDT and CDT. In fact, it has become a common joke that the way to get a new IDE for eclipse, is to take code from JDT and replace the "J" with your language letter in the class name (I used ST). I have seen many initial ports of new languages done this way and as a quick and dirty way to get started it's a pretty good way to go, especially if you borrow ideas (and code) from a well architected piece of code like JDT. Of course, the drawback to this technique is that you "bake in" the bugs you copied from the original code and you don't get the fixes as they are made in the original. You also miss new innovations as they appear in JDT and the underlying platform. Given that many of these components end up being quite similiar I feel it should be possible to create generic components for creating language IDEs, possibly starting from existing components from the existing language IDEs and generalizing them to allow re-use in other contexts. Clearly over time as you re-use components from one language in another, you will create common components as the problem accross many languages becomes better understood.
-
-So, this suggests a path forward. As IDEs for different languages are built, there will be opportunities to harvest components which will be applicable to different languages.
-
-A non-exhaustive list of tools (and problems to solve) may look something like this (I make no claims on how hard or easy the specific items are).
-
-* **generic components for data based simple integrations (no code required)**
- * token based syntax colouring
- * non context-sensitive code assist
- * consoles and process control
- * external compiler (or other tools) error processing
- * declaration of artifacts for external tools
-* **common utilities for parsers, syntax colouring, code assist**
- * grammar and parsing tools - generate common DOM for programming language
- * indexers (with persistence) for structured searching
- * partial/incorrect code parser support
-* **common tools for for compiled languages**
- * C/C++, Fortran, COBOL, Ada ...
- * external tool-chain launch and processing (makefiles, compile, link)
- * external program (execution/debug) launch and processing
-* **common tools for for dynamic languages**
- * PHP, Ruby, Smalltalk
- * external program (execution/debug) launch and processing
- * the "intermediate" language problem (script lang generates Java (or C) or ...
- * techniques for dealing with mixed languages in same file (HTML, PHP etc)
- * internal scripting execution (scriptable eclipse?)
-* **common tools for for all languages**
- * integrated performance and testing tools
-
-Once we've identified these common components, the next steps would be the "IDE Wizard" tools which help you generate "your first" IDE. What I really would like to see is the Eclipse IDE equivalent of "_glasses in about an hour_" in which much of the the first implementation of an IDE is generated for you. You can then tailor the generated components for the specific needs or wholesale replace them with custom versions which provide tighter integrations. The reaction I get when talking to most people about this type of tool for creating IDEs is typically divided into two distinct groups. There's the _when can I have it?_ people and the _that's impossible!_ people. I understand the motivation of the first group, they want a simpler way to build IDEs. The latter group, is clearly thinking that we intend to auto generate JDT level functionality which is a pretty high bar or if you don't do a JDT then it won't be usefull. I don't think you're going to generate a JDT class IDE for "free" but I think you may be able to generate a usefull first cut. The tricky part is defining what "usefull" means in this context or even describing what you could expect from a generated IDE. One way, is to look at the level of functionality that an IDE has and decide what kind of functionality you could expect to find in a generated IDE.
-
-**Levels of integration in an Eclipse based IDE**
-
-There are many possible levels of integration with Eclipse. The simplest integration is to use Eclipse as your edit, compile, run (and possibly debug)system. The next level is to create a program model (parse the source code) so that you can implement language aware functionality. As the integration becomes more advanced, the opportunities become richer and features like program manipulation (refactoring, code generation, and full round trip editing for code generation systems that use programming languages as their intermediate language) become possible
-
-For simplicity, I decided to describe IDEs in terms of **levels of integration** with eclipse.
-
-* **Editor Level Integration or Basic Integration (Level 0)**
- * Functionality: Text editor for source files, external compiler, compiler errors parsed into markers, launch external debugger, token based syntax coloring, text search, token based search.
-* **Language Aware Integration - (Level 1)**
- * Functionality: outline view, language hierarchy/structure view, syntax based coloring, code assist, structured search (references, declarations), structured compare. Eclipse debugger support.
-* **Advanced Language Aware Integration - (Level 2)**
- * Functionality: refactoring, quick fix, intentional programming (type inferencing, auto-complete of statements DOM for language and extension to these tools.
-* **Uber-Integration - JDT class integration (Level 3,4,5)**
- * Functionality: all of the above and more. Full exploitation with of the platform functionality. Continued innovation in IDE technology.
-
-My position is that a IDE Wizard could create a level 0 or level 1 IDE. The key to this being a successfull strategy is the ability to selectively replace generated components. This would allow the ide implementor start with a basic IDE, and grow into full featured IDE (in the uber JDT spirit) incrementally.
\ No newline at end of file
diff --git a/content/org/langsymp/compiled-language-support-in-eclipse.pdf b/content/org/langsymp/compiled-language-support-in-eclipse.pdf
deleted file mode 100644
index e1f40d14fe1345e148f98376c5fd5671a063bc7d..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/compiled-language-support-in-eclipse.pdf and /dev/null differ
diff --git a/content/org/langsymp/craig-rasmussen.pdf b/content/org/langsymp/craig-rasmussen.pdf
deleted file mode 100644
index d03ca87a21e0ea5ef26680a494d4694d629dde22..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/craig-rasmussen.pdf and /dev/null differ
diff --git a/content/org/langsymp/doug-lang-symp.pdf b/content/org/langsymp/doug-lang-symp.pdf
deleted file mode 100644
index 0d8490f2b1d67c7fa5635179e0607a73fbcab6fd..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/doug-lang-symp.pdf and /dev/null differ
diff --git a/content/org/langsymp/eclipse-and-dynamic-languages.pdf b/content/org/langsymp/eclipse-and-dynamic-languages.pdf
deleted file mode 100644
index 3bb53514224468a60749c68d24acfca1dfc4dc7e..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/eclipse-and-dynamic-languages.pdf and /dev/null differ
diff --git a/content/org/langsymp/eclipse-everywhere.pdf b/content/org/langsymp/eclipse-everywhere.pdf
deleted file mode 100644
index 6060b1f77a2a7baa1dbfee3ba1161b5e19cfce41..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/eclipse-everywhere.pdf and /dev/null differ
diff --git a/content/org/langsymp/eclipse-language-position.pdf b/content/org/langsymp/eclipse-language-position.pdf
deleted file mode 100644
index 4364ed5b372be7ad641f5b04b709db8be397d348..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/eclipse-language-position.pdf and /dev/null differ
diff --git a/content/org/langsymp/etx-paper.pdf b/content/org/langsymp/etx-paper.pdf
deleted file mode 100644
index f9b677b24eb36523c13b7e49a15fad221d094e19..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/etx-paper.pdf and /dev/null differ
diff --git a/content/org/langsymp/extending-eclipse-in-haskell.pdf b/content/org/langsymp/extending-eclipse-in-haskell.pdf
deleted file mode 100644
index 9147deb52c1efcbdc9bf42702b01feeaee836eba..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/extending-eclipse-in-haskell.pdf and /dev/null differ
diff --git a/content/org/langsymp/extending-eclipse-with-compiled-languages-other-than-c.pdf b/content/org/langsymp/extending-eclipse-with-compiled-languages-other-than-c.pdf
deleted file mode 100644
index 9f654148e38ad688b082686e29d8044ccd5d3544..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/extending-eclipse-with-compiled-languages-other-than-c.pdf and /dev/null differ
diff --git a/content/org/langsymp/extending-eclipse-with-languages-other-than-java.pdf b/content/org/langsymp/extending-eclipse-with-languages-other-than-java.pdf
deleted file mode 100644
index 4e449c1a6697bb591ec359cfb81c54f79fc73e36..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/extending-eclipse-with-languages-other-than-java.pdf and /dev/null differ
diff --git a/content/org/langsymp/julian-dolby-paper.pdf b/content/org/langsymp/julian-dolby-paper.pdf
deleted file mode 100644
index 1dfd128d69c01fb87bb00148b3769f0e727ed982..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/julian-dolby-paper.pdf and /dev/null differ
diff --git a/content/org/langsymp/lang-symposium-oct-2005.pdf b/content/org/langsymp/lang-symposium-oct-2005.pdf
deleted file mode 100644
index 762e6b6e1e567aa840db81f03d7caf76d4fbecab..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/lang-symposium-oct-2005.pdf and /dev/null differ
diff --git a/content/org/langsymp/language-support-in-eclipse-wtp-sse.md b/content/org/langsymp/language-support-in-eclipse-wtp-sse.md
deleted file mode 100644
index 5a4b2ddbdf50e5d2369db91405fde1151c20605f..0000000000000000000000000000000000000000
--- a/content/org/langsymp/language-support-in-eclipse-wtp-sse.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-title: Language Support in Eclipse WTP/SSE
-hide_sidebar: true
----
-
-## Position Paper for Eclipse Language Workshop
-October, 2005
-
-David Williams
-(and team: Nitin Dahyabhai, Phil Avery, Amy Wu)
-
-In [Eclipse WTP](http://www.eclipse.org/webtools/main.html) we provide editing related support for XML, DTD, HTML, XHTML, CSS, JavaScript, and JSP's. I'd like to relate some of our experiences and plans that might be useful to the larger "language community". And -- shameless plug -- if you like what you see, maybe you'll be convinced to make some contributions! :)
-
-### ContentType based
-
-Things like XML and JSP are good use cases for the importance of content type based function, since not obvious "file extensions" are always used.
-
-### Mixed Languages
-
-For us, all content is "mixed language" to some extent, even simple HTML can have JavaScript or CSS.
-
-JSP's can not only have text/html, but text/xml, text/css, etc
-
-## Editors should be extensible, by extension point
-
-### SourceViewerConfiguration
-
-The structured text viewer configuration customizes various aspects of the Structured text editor. It defines syntax highlighting, content assist, and more. Clients must subclass org.eclipse.wst.sse.ui.StructuredTextViewerConfiguration to provide a custom viewer configuration for their content type. Clients contributing new configuration for new content types can utilize an existing configuration. They can subclass the existing configuration to build on top if it. Or they can create a new instance of the existing configuration in their configuration, and call the methods within it. The StructuredTextViewerConfigurationJSP, for example, creates new instances of the StructuredTextViewerConfigurationHTML, StructuredTextViewerConfigurationXML, JavaSourceViewerConfiguration and retrieves their processors to be reused in JSP content.
-
-**Discussion Point:** Is there need to separate out highlighting, content assist, etc?
-
-### OutlineConfiguration
-
-The outline view configuration customizes the editor's outline view. It defines how the current editor's input maps to elements in a Tree control, as well as selection filtering, toolbar/menu contributions, etc. Clients must subclass org.eclipse.wst.sse.ui.views.contentoutline.ContentOutlineConfiguration to provide a custom outline view for their content type
-
-### PropertySheet Configuration
-
-The properties view configuration customizes the editor's properties view. It defines how the current editor's input maps to a list of properties in a Table control, as well as toolbar/menu contributions, etc. Clients must subclass org.eclipse.wst.sse.ui.views.properties.PropertySheetConfiguration to provide a custom properties view for their content type.
-
-### Source Page Validation
-
-Allows participants to provide an org.eclipse.wst.validation.core.IValidator for source validation (as-you-type) via the org.eclipse.wst.sse.ui.extensions.sourcevalidation extension point. The enablement ("what" the validators can operate on) of the source validators can be specified by content type ( org.eclipse.core.runtime.content.IContentType ) and partition types ( org.eclipse.jface.text.ITypedRegion.getType() ) within each content type. \[This is likely the same org.eclipse.wst.validation.core.IValidator used for "batch" validation via the org.eclipse.wst.validation.validator extension.\] The validation messages are displayed to the user on the source page as as "temporary" annotations. These show up in the text as "squiggles" beneath the text and in the overview ruler as rectangles. The validation message itself is displayed by hovering the squiggle or rectangle.
-
-### Target ID Resolution
-
-Clients can target their editor configuration to either a specific content type and/or editor. In the event there are conflicts as to which configuration should be used, below is the resolution policy.
-
-* configuration with matching editor id
-* configuration with matching editor id + ".source" in multipage editors
-* configuration with matching content type id
-* configuration for content type's base content type
-* default Structured Text Editor configuration
-
-If more than one configuration is defined for an editor type or content type, the first one defined, is the first one served.
-
-**Discussion Point:** How much and when is there a need for "user choice" in resolution.
-
-## SSE Model/Document Concepts
-
-### Structured Documents
-
-Once central concept is the `IStructuredDocument` . It is intended to be similar to an IDocument, but with a few significant differences.
-
-* It has an associated parser and re-parser, which in our experience is how most programmers think of text models.
-* It also does not depend on a "reconciler thread" to reconcile the model. Instead, it notifies the model immediate of changes. Our philosophy is that it is the model itself that should decide if there would be a delay or a separate thread required to reconcile itself. For small and fast models, there is no need to do this on a separate thread and the user's experience will appear much more responsive. For other cases a longer time may be required, but when handled correctly, the model can still give immediate feedback to the user that a longer operation is in progress.
-
-The IStructuredDocument is conceptually a stream of characters made up of (divided into) IStructuredDocumentRegions. The main constraint on what types of languages are appropriate for structured documents and structured regions is whether or not it has the concept of having a syntactically determined end. This is used to know how to correctly handle reparsing (deciding what is a "safe start" and "safe end" for the reparse operation).
-
-### Parsers and re-parsers
-
-Parsers and reparsers can (will) be associated to a StucturedDocument via extension point. The parser/reparser pair has a few conceptual requirements. They must be able to handle any text (legal or not) and must return regions that completely cover the input text (for example, whitespace can not simply be ignored). Another, more difficult constraint to implement is that for any subset of text, the reparser must give the same results that the parser would if whole document re-parsed. (Granted, a legal fall-back is just to re-parse whole document, but can be "expensive").
-
-Its important to handle ill-formed text. Heuristics are often used to make these decisions so sometimes we can and do "guess right" (based on what a user might be in the process of typing) and sometimes not -- in other words, its not always easily predictable as it is for "valid" text but is based on doing a reasonable job which would not invalidate subsequent reparsing.
-
-### Structured Document Events
-
-The StructuredDocumentEvents are similar to IDocument's DocumentEvents, but provide much more information about the nature of the change in terms of IStructuredDocumentRegions (and the ITextRegions of which they are composed). Listeners, such as DOM parsers, can make use of this to minimize the amount of reparsing/rebuilding they have to do.
-
-### Content Models
-
-These are abstract "descriptions" of what an instance document could or should look like. We use these for content assist, validation, and in some cases to actually parse a document to its "model" (or tree structure). We compute content models for arbitrary schemas, dtd, and taglibs, and have a "hard coded" one for html 4.01
-
-### Structured Models
-
-Structured models are mostly interesting due to is extended types and implementers and exists as an abstraction to provide a consistent way to manage shared models and also to access its underlying structured document.
-
-### Node Notifiers
-
-In addition to IAdaptable, many "Node" structures in SSE related models make use of a finer level of adaption which includes notification. This mechanism can be used to have improved UI updates or can be used to keep related models "in synch" (for example, a DOM model change can cause a change in an EMF model, and vis versa).
-
-### Model Management
-
-Another important contribution of sse.core is the IModelManager. Its purpose is to provide a StructuredModel, appropriate to contentType, that can be shared between many clients at runtime. This increases efficiency since each client doesn't have to (re)create their own, but just as importantly, it is an easy way for clients to all stay "in synch"--a change in the model made by one client will be known by all others clients. The other motivation for this is it allows looser coupling, since clients who may not even know about each other can share the model without passing it around to each other.
-
-## My View of future of an "LTK layer" (to spur discussion, not to volunteer :)
-
-Further use of "participant pattern" in other areas of common source language handling
-(similar to refactoring, search)
-
-* Format (model, no UI)
-* Task Tags
-* Validation
-* Content Assist
-* Quick Fix
-* General Purpose Dependancy Mechanism
-
-### Reference: Current Links to Eclipse Components
-
-[Primary documentation link and CVS information](http://www.eclipse.org/webtools/wst/components.html)
-
-[SSE](http://www.eclipse.org/webtools/wst/components/sse/overview.html)
-
-[XML](http://www.eclipse.org/webtools/wst/components/xml/overview.html)
-
-[DTD](http://www.eclipse.org/webtools/wst/components/dtd/overview.html)
-
-[CSS](http://www.eclipse.org/webtools/wst/components/css/overview.html)
-
-[JavaScript](http://www.eclipse.org/webtools/wst/components/javascript/overview.html)
-
-[HTML](http://www.eclipse.org/webtools/wst/components/html/overview.html)
-
-[JSP](http://www.eclipse.org/webtools/wst/components/jsp/overview.html)
-
-[End User Oriented Documentation](http://www.eclipse.org/webtools/community/tutorials/ReintroducingSSE/ReintroducingSSE.html)
diff --git a/content/org/langsymp/m-imrisek-languages-workshop-position-paper.pdf b/content/org/langsymp/m-imrisek-languages-workshop-position-paper.pdf
deleted file mode 100644
index 73edc5ade42d7b12377ae53d564fa0fb74657e7d..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/m-imrisek-languages-workshop-position-paper.pdf and /dev/null differ
diff --git a/content/org/langsymp/multi-language-support-user-perspective.pdf b/content/org/langsymp/multi-language-support-user-perspective.pdf
deleted file mode 100644
index 4aa967c1938477f7e94306a60cd852d078f6a88e..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/multi-language-support-user-perspective.pdf and /dev/null differ
diff --git a/content/org/langsymp/split-along-technology-not-language-2005-10.pdf b/content/org/langsymp/split-along-technology-not-language-2005-10.pdf
deleted file mode 100644
index 42b3bad442605d464de98fd4648f10bacefd9cec..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/split-along-technology-not-language-2005-10.pdf and /dev/null differ
diff --git a/content/org/langsymp/staying-pragmatic.pdf b/content/org/langsymp/staying-pragmatic.pdf
deleted file mode 100644
index 77e40f49cbf0764ef1b8cb5716c35813df59c86d..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/staying-pragmatic.pdf and /dev/null differ
diff --git a/content/org/langsymp/test-point-in-practice.pdf b/content/org/langsymp/test-point-in-practice.pdf
deleted file mode 100644
index 0ff3dcffa2f3f3b4403c6e1cb06909b54d58e9bc..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/test-point-in-practice.pdf and /dev/null differ
diff --git a/content/org/langsymp/volanakis-mixed-language-usage-scenarios.pdf b/content/org/langsymp/volanakis-mixed-language-usage-scenarios.pdf
deleted file mode 100644
index 0c78545a61393c176d7fbf210184999c60354684..0000000000000000000000000000000000000000
Binary files a/content/org/langsymp/volanakis-mixed-language-usage-scenarios.pdf and /dev/null differ