Here's a bullet-pointed summary of what I see as the main issues here.
* Only a few core languages currently "include" syntaxes from other
bundles. EG: HTML including Ruby
* The current unofficial standard for reusing syntax code in more than
one language is to copy it.
* More and more bundles are needing to copy more and more code.
* The code that is being copied is being improved and updated by
different developers than the ones developing the syntaxes that it's
being copied into.
* Maintenance is becoming and will become a major issue as more and
more syntaxes and unofficial bundles branch different versions of the
code.
* Bug fixes can not easily be tracked and updated across all these
languages.
Thus, a solution to these and other issues was devised by Allan in the
form of a unified central bundle repository, from which multiple
languages can include code.
Then the code that would be shared would become standardized and be
able to be updated and maintained separately from each individual
bundle.
The official timeline for release of this update is "there is no ETA
[…] put TM 2.0 up there with Duke Nukem Forever and be positively
surprised the day it is released".
Therefore, since the official release schedule is effectively never,
life must continue under that assumption that we must use what we
currently have available.
So, the logical compromise to solving all these issues is threefold:
1) Split up the code inside the syntaxes as much as possible so that
they can more easily be moved into a central repository once it's
available.
2) Duplicate the few small repository items across the multiple
syntaxes that need them.
3) Split up syntaxes into separate layers of functionality.
Effectively creating 2 or more syntaxes for a single language.
#1 & #2 go hand in hand and will help to keep syntaxes structured well
internally in the short term.
#3 Is not an ideal solution in the short term, but is the only
possibly way to get the results that we need with the current state of
TM1.x
That, that brings us to the practical application of all this where
the rubber hits the road.
What updates are currently planned for existing bundles?
What new bundles are being created?
What old bundles are being replaced?
Who will actually be doing this work?
Who will be responsible for maintenance?
Personally, my interests lie with HTML, CSS, Javascript and its
various libraries.
* With javascript there is only really 1 possible way to embed
javascript inside one syntax while still allowing it to be wrapped
with another syntax. That conversation is happening on another thread.
* With HTML, there is really no perfect solution with the current
state of TM1.x. HTML can potentially embed and be embedded by dozens
of different languages. And there are various different dialects of
HTML. Personally, I'm using a modified version of the current core
HTML syntax for all my personal development.
* CSS is very unique across all "languages". CSS cleanly divides up
into 3 distinct parts. CSS Selectors, CSS Rules & the actual CSS
language that .css files use and that is embedded in STYLE tags in html.
CSS Selectors are currently used in both the "CSS" syntax and the
"jQuery" syntax. The ladder having copied an old version of the
selector code from the former and branched it slightly. I'm currently
working on including CSS Selectors into MooTools Javascript and then
potentially jQuery, YUI, & Prototype.
CSS Rules are currently only used in the CSS syntax. I have plans to
improve the CSS Rules syntax and embed "CSS rules" into all HTML
syntaxes. I already have a version of the HTML syntax on my local that
does include CSS Rules.
So, the question is, what option should we choose for the very unique
situation of the CSS syntax?
If TM2 were out right now, it would be obvious. Modularize it and put
it into a global repository.
But with the current state of TM1:
Should it be modularized (#1) and then branched and copied across all
6-10 syntaxes that use it (#2)?
Or should it be modularized (#1) and then split into 3 syntaxes for
including into the 6-10 syntaxes that use it (#3)?
Before making this decision, let's think of the ramifications of the
decision.
Who is the one developing these syntaxes?
Whose time will be wasted by duplicating and maintaining code across
6-10 syntaxes?
Who will handle the bugtracking and support from 6-10 branches of
this code?
As the bundle maintainer responsible for 4 of the 6-10 potentially
relevant bundles:
JavaScript Prototype & Script_aculo_us
JavaScript MooTools (Review)
JavaScript
CSS
I vote that "we" follow Allan's original intent of a unified bundle
repo and choose option #3 with the CSS syntax.
The only potential side effect is extra "junk" in the Languages list
that can be easily ignored or hidden.
---
On Dec 9, 2007, at 11:33 PM, Michael Sheets wrote:
On Dec 9, 2007, at 3:00 AM, Thomas Aylott - subtleGradient wrote:
CSS doesn't have a monopoly on CSS Selectors.
They're also used in almost all Javascript libraries.
They can get rather complex and it's certainly something that needs
to be DRY.
CSS Rules aren't unique to CSS either,
they're also used in various versions of HTML in the style attribute.
They are also used in a number of Ruby libraries for generating CSS.
I can relate to the fact that duplication is a bad thing, it's been
done very poorly in various HTML related bundles.
This is not the same issue as PHP & HTML. That is a separate and
distinct issue that doesn't relate to the matter at hand. I know
people have been confused in the past because they chose the "PHP"
language when editing php files. That has nothing to do with this issue.
However something like CSS selectors isn't really a moving target, I
think we can work out a solid grammar for them and not have it
change much. What I'd recommend is a repository item that can be
duplicated as needed, and since it's a single 'item' it can be kept
updated easily.
Ideally what we need is a "global repository" as I hear is coming in
TM2. So what we really need to figure out is a stopgap between the
current state of duplication and the perfect solution of the "global
repository".
I also have to goal of supporting the E-texteditor and friends as much
as possible. I'm a bundle developer, not an application developer. I
have no idea what their plans are for TM2 level features.
Is disagree that duplicating a "CSS Selectors" repository across
multiple languages would have a low maintenance impact. People don't
always stay up to date with non-core bundles. While they update core
bundles at least as often as they update the application itself.
Keeping the "CSS Selectors" rules separate and in a core bundle would
require much less work on the part of the developers (EG: me), the
support crew (EG: you) and the user.
While a "CSS Selectors" syntax shouldn't be a moving target, I will
probably be updating it soon and it may take a while for me to get it
all done. With all these new browsers coming out, and all these new js
libraries supporting all this new stuff, it's worth the effort to get
it updated and included properly across all 6-10 bundles.
It's not a clean solution no, but I think we should attempt to hide
the imperfections from everyday use as much as possible.
"hid[ing] the imperfections…" is the business of the app, not the
bundle developers. If there is a weakness in the app, then it should
be handled by the application developer that is getting paid to sell
that app. Whether that be InType, E-texteditor or TextMate.
However, what you suggested for js (to rename the syntax to have them
sorted separately) would help keep people from making the wrong
choice. No matter how amazingly unlikely and inconsequential that
mistake may be. (this is not the PHP / HTML issue, remember)
Keeping it inside the grammars makes it only visible to the much
smaller percentage that try and change/extend the grammars.
There are only 3 ways to use at a language:
1) Open a file and the correct type is automatically chosen.
2) Embedded into another language. The language chooses what to
embed, no user choice available.
3) Manually selected from the languages dropdown.
#3 is the only area where confusion could possibly arise.
If there are three "languages" that say "CSS" in them, people will
choose "CSS" first and be happy. If they choose "CSS Selectors" or
"CSS Rules" incorrectly, it'll be immediately obvious that they made
the wrong choice and they need to select something else. This is not
the same issue as the PHP/HTML issue.
As for the reasoning that having multiple "languages" in the list
is confusing to people, simply enable the option to hide languages
as you can currently do with all other bundle items. Most people
don;t bother selecting a language since the right thing is used
when embedded and is auto-matched to the filetype when opening files.
Might be nice but until that's possible it's a reason against, not
for. ;)
My point above stands. The amount of potential confusion people might
hypothetically get when choosing between these "languages" is
infinitesimal versus the amount of actual development, maintenance and
"other horrible side-effects" that duplication of code can, will and
have caused to real developers (EG: me and maybe you). DRY [1] SoC[2]
The alternative is to duplicate all the rules and selectors stuff
in all HTML lang[uag]es, CSS, All Javascript Libraries, etc...
For the selectors I recommend the single repository item idea above,
for the rules I think it would be possible to have a top-level rule
that can tell we are in a css attribute and activate the rules
repository item. Should work for most cases.
How to break the syntax up and duplicate it as a repository item in
each language isn't the issue. If you can include it, then you can
include it, not matter if you're including from the repository or
another syntax.
[1] http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
[2] http://en.wikipedia.org/wiki/Separation_of_concerns
—Thomas Aylott – subtleGradient—
_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/mailman/listinfo/textmate-dev
