release1Add my vote for this tag create new tag
, view all tags

Athens Release

Released as TWikiRelease01Dec2001

Next Release codenamed BeijingRelease


Athens is the code name for release that came out in 01 Dec 2001


List of features and fixes that should go into the Athens Release. The CoreTeam should update this list.

Item: Owner: Spec: Impl: Docs:
FormattedSearch PeterThoeny 100% 100% 100%
RenameKillsAttachmentsAndFormsBug JohnTalintyre 100% 100% 100%
ViewShowsTopRevUserForOlderRevs PeterThoeny 100% 100% 100%
FixingTopicChangesUser PeterThoeny 100% 100% 100%
OsDetectionFailsOnMacOSX JohnTalintyre 100% 100% 100%
DocumentationBug01 (Docs sometimes refers to "TWikibeta") PeterThoeny 100% 100% 100%
SearchsTooManyDirectories JohnTalintyre 100% 100% 100%
EmptyNotificationAfterRenamingTopic PeterThoeny 100% 100% 100%
OperaBrowserDoublesEndOfLines PeterThoeny 100% 100% 100%
VariablesDoNotGetExpandedInForms PeterThoeny 100% 100% 100%
SimplifiedPrefixForWikiWords PeterThoeny 100% 100% 100%
ViewAuthHandlingForTOC PeterThoeny 100% 100% 100%
BetterLists (fix XHTML validation error) PeterThoeny 100% 100% 100%
NoWarningWhenEnteringNonStdChars PeterThoeny 100% 100% 100%
Total: 14 Progress: 100% 100% 100%

"Nice to Have" List

All: Please add other features you would like to see in the Athens Release. The CoreTeam will evaluate what is possible.

Item: Owner: Spec: Impl: Docs:
UploadZeroFileSizeWin2KBug JohnTalintyre 0% 0% 0%
VerbatimExpandsVariables Main. 0% 0% 0%
NestedVerbatimTags Main. 0% 0% 0%
SaveAndContinueWorkingFromPreview Main. 0% 0% 0%
RcsNonStrictLocking ColasNahaboo 100% 100% 0%
Total: 5 Progress: 20% 20% 0%

Change Proposals for AthensRelease still being worked on

Search for topics that still need work:

Priority Proposal Type State Outstanding Issues #
Total: 0 Proposals 0 Issues

Change Proposals for AthensRelease Awaiting Merge

Search for topics Proposed for AthensRelease that are waiting for merge to the MAIN branch:

Priority Proposal Summary Outstanding Issues #
Total: 0 Proposals 0 Issues

Change Proposals for AthensRelease Merged to Main SVN Branch

Search for topics Proposed for AthensRelease that have been MergedToCore or ImplementedAsExtension:

Proposal Summary Outstanding Issues #
ViewShowsTopRevUserForOlderRevs     0
Total: 15 Proposals 0 Issues
AuthenticationBasedOnGroups     0
BetterTWikiTagTemplateProcessing     0
DocumentationBug01     0
EmptyNotificationAfterRenamingTopic     0
FixingTopicChangesUser     0
FormattedSearch     0
OperaBrowserDoublesEndOfLines     0
OsDetectionFailsOnMacOSX     0
ReferencesInIncludedTopics     0
RenameKillsAttachmentsAndFormsBug     0
SearchsTooManyDirectories     0
SimplifiedPrefixForWikiWords     0
VariablesDoNotGetExpandedInForms     0
ViewAuthHandlingForTOC     0

Release State Summary

Change Proposal State Proposals Issues
Still being worked on 0 0
Awaiting Merge 0 0
Merged to Main SVN Branch 15 0
Total 15 0

See also AthensReleaseSummary and AthensReleaseUpgradeGuide

Known issues

See KnownIssuesOfTWiki01Sep2001.

Feedback and requests

Please add below.

-- PeterThoeny - 13 Nov 2001

I would like to add RefreshEditPage as a nice to have - this is fairly significant in that it can cause a loss of edit text, the second time someone edits a page. It could be controlled by an option, but IMO should be the default since it has no negative impact and works with any browser. I've tested it quite a bit with various browsers.

The BackFromPreviewLosesText issue is more significant, but unfortunately there is no fix for this, so all that can be done is to reference it in the docs.

-- RichardDonkin - 15 Nov 2001

Added TopicNotFoundInThisWeb, I hope that's okay. I guess though that if this release is only bug-fixes then it shouldn't go in.

If that's the case, perhaps can we start a topic for the subsequent release that in which we can request added features?

-- MartinCleaver - 15 Nov 2001

I have just lost some editing done to a page on TWiki.org because of RefreshEditPage! This is really annoying... Anyone who is using Opera is at high risk of losing edits through this problem - even though I'm aware of this issue, I forgot to do the Refresh on the second Edit, and thus lost the edits.

Can we please implement the fix on RefreshEditPage in the AthensRelease? This works fine for me with various browsers, and ColasNahaboo has also tested it. Perhaps it should be controlled by an option for people who only use IE5 and don't want the extra characters on URLs (although this only affects the Edit URL, which should of course never be bookmarked, so the extra characters are not really an issue IMO).

Just because IE5 doesn't have this problem doesn't mean it should stay unfixed... Once this fix is in, Opera will become a good browser for TWiki use, since it doesn't suffer from BackFromPreviewLosesText (as IE5 does).

-- RichardDonkin - 17 Nov 2001

I'd also like WebFastIndex, PopupPageIndexForEditing, and ScriptToCreateNewWeb please. Gosh! I seem so demanding! embarrassment Would anyone like to second my requests?

-- MartinCleaver - 17 Nov 2001

I quite like the PopupPageIndexForEditing, but unfortunately it may well cause the BackFromPreviewLosesText bug on IE5, so I would prefer not to see this included until we have a good solution for that bug. ScriptToCreateNewWeb would be nice, and presumably has little impact on the rest of TWiki.

-- RichardDonkin - 19 Nov 2001

Fair point.

How about SaveAndContinueWorkingFromPreview?

-- MartinCleaver - 19 Nov 2001

Dunno what it involves, but it would be nice to clean up all the TWiki text formatting rules that require white spaces. I haven't started a list - can you determine which this applies to from how different markup code is handled? Some from memory:

  • can't enclose Interwiki links in square brackets to make more readable links ex ... "speaking of Wiki:WardCunningham" VS "speaking of WardCunningham"
  • *bold*'s - stuff like that breaks the flow of using shorthand, you gotta drop in HTML
  • etc (is an individual case list needed or is this some general parsing order/rules thing?)

-- MikeMannix - 22 Nov 2001


  • can't enclose Interwiki links in square brackets to make more readable links ex ... "speaking of Wiki:WardCunningham" VS "speaking of WardCunningham"

A solution to this could (might) disable the ability to see the Web using the square link syntax. (To me, seeing the Web is desirable, at least under some circumstances, for example Wikilearn.WebHome.)

-- RandyKramer - 22 Nov 2001

I agree. There are times when the visible "path" is good, it not only indicates a remote link, but also to where. But, in other cases, it's a problem, it destroys the syntax of sentences in a more troublesome way than WikiWords are sometimes accused of doing (which was the motivation for square brackets, to be able to separate words and write in lowercase and hide URLs). Interlinks adds words, often meaningless to the reader, with a colon that on many screens is near invisible, and doesn't intuitively suggest a remote link in any case.

My point on TWiki shorthand - a point now splattered all over Codev; I'll have to gather it all up eventually - is: Why half-step? TWiki has made a point of going to great lengths to create all sorts of preprocessing rules - there's no real line, unless things get out of control, too complicated. Peter just last night simplified one rule, to fix an unexpected problem - see SimplifiedPrefixForWikiWords - because a word expanded for Ref-by got reprocessed in its expanded form into a new string and broke itself.

It would be great if TWiki notation could do certain things seamlessly. It's already powerful, but has its blind spots. I can bold Billy with ease, but *Billy*'s bolding can suddenly take a turn for the nonfunctional. The more that's offered, the more that's expected.

In the specific case you mention, there are all sorts of possible solutions, well within the spirit of TWiki dev: a small inline world icon (QBullets is a cool 11pt free set for this use), could pop up, indicating a remote link. Etc. But would that lead to other complications, functionally or in usuability, or both? A good, comprehensive spec for TWiki shorthand would be excellent, an arbitrary list of great capabilities, a limited set to perfect. IMHO.

-- MikeMannix - 22 Nov 2001

One admin/process comment - we should really be discussing longer-term changes elsewhere, since this AthensRelease is primarily for bug fixes and minor features. Improving the TWiki syntax is not as minor as it appears IMO.

  • SaveAndContinueWorkingFromPreview would be nice, but it's not a solution to BackFromPreviewLosesText, since many users would still hit the browser's Back button and run into this problem.
  • TWiki formatting shorthand is a compromise between having powerful formatting and simple syntax - in some ways, it's already veered towards the 'power' end of the spectrum, but it is still hard to do some things. Unfortunately, I'm not sure that there is an easy solution to this without introducing more HTML-like markup. Perhaps a JavaScript or Java WYSIWYG editor would allow richer formatting by using such markup - this is probably the way to go, as it allows better formatting without decreasing usability.
  • As for the Interwiki and other-web links, I think sometimes you want the full path to be shown and in some cases you want just the web name or some other text altogether. It would be great to improve the regularity of TWiki features, i.e. make sure that feature X can be applied with features A, B and C.

I am a big fan of EasierExternalLinking, i.e. links like [[http://www.foo.com Foo Corp]] - this was driven by the fairly complex syntax for this in standard TWiki. However, nobody else seems to be bothered enough by this to add it to the core code smile

-- RichardDonkin - 26 Nov 2001

Not sure if this is a bug or if createtopic needs some text rearranging. When I create a topic, I see: All Topics generally be given a WikiWord as their name, otherwise automatic linking of topic text will not happen. Exceptions:

  • All capitals (at least 3 letters) will link
  • For topics in the Products Web - a single word with initial capital (at least 3 letters) will link

Neither of these rules seems to apply in the default installation (I created a "Products" web just to see). Is there an additional administrative steop I need to take to make these special rules effective?

-- DavidWeller - 03 Dec 2001

Is your createtopic template from the TWiki core or from the TigerSkinPlugin? If the latter, it needs to be in the TigerSkinPluginDev topic.

-- JohnRouillard - 04 Dec 2001

On RcsNonStrictLocking (last proposal, not the first one): I suggest implementing my last fix, which consists in setting in TWiki the env variables USER and LOGNAME that RCS needs to properly lock topics

-- ColasNahaboo - 05 Dec 2001

Changed to FeatureDone...finally. Maybe some of the unimplemented "Nice to Have" items should be moved forward to the BeijingRelease, or maybe even the next one after that? I guess that should be left to parties interested in particular items to do.

-- WalterMundt - 08 Jan 2003

Sure, you are right, but I guess many of them are already in.

If you feel like tidying up, I suggest you could add sections titled 'Items brought forward to BeijingRelease', 'Items implemented' and 'Items dropped'.

-- MartinCleaver - 09 Jan 2003

Edit | Attach | Watch | Print version | History: r37 < r36 < r35 < r34 < r33 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r37 - 2005-02-15 - SamHasler
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.