phpwiki-talk

[Phpwiki-talk] Re: Footnotes

[Jeff D. <da...@da...>]

>That's almost how it works. No special page for editing them.
>It's like text here [1].
>
>blabla
>
>[1] footnote there. Try it out in the latest CVS.

Ooh, that _is_ cool!  I did not fully understand.

I will hack the restore-from-zip-archive code to turn
the references into footnotes.

Jeff.

Re: [Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

[Arno H. <aho...@xm...>]

> || Name || Number || Homepage
> || Jeff |} 123-4567 |{ http://x.y.z/

As long as tables are optional and disabled by default I don't
care about the syntax. Go ahead.

> Tables within tables are excessive.

That's what you think. Wait until the first user cries.
Like, why can't I center lines, headings, tables, ...
For me, even single tables are excessive.

> I'm just thinking about redoing the database API's (for versions);
> and thinking that now would be a good time to get rid of carrying aroun=
d
> all those page references (or footnotes).

Footnotes will not appear in the API. Look at nbtsc's wiki.
Btw, I really like the db schema of your previous branch. With some sligh=
t=20
modifications I guess we are on the right track.

>    Some text requiring a footnote [[1].
>    ...
>    ----------
>    Footnotes:
>    #1# A footnote.

That's almost how it works. No special page for editing them.
It's like text here [1].

blabla

[1] footnote there. Try it out in the latest CVS.

/Arno

[Phpwiki-talk] Re: Stable branch, CVS details (was: FootNotes, Tables, The end of PHP3...)

[Jeff D. <da...@da...>]

>> Are there going to be bug fix releases of 1.2.x?
>> Are the going to remain PHP3 compatible?  Is that going to create headaches?
>
>Yes, yes and no. We tagged 1.2 in CVS and we can commit bug fixes to that
>branch.

Perhaps we should create a 'release-1_2-branch' tag in the CVS, so that
when a developer (like myself) fixes a bug (like the diff hang bug) he
can/should fix it in both the development branch and the stable branch.

Otherwise, when you want to release 1.2.1, it's going to be a pain
to sort out which changes in the CVS are bug fixes, and which are feature
additions (and which changes are PHP3 compatible).  

(As I understand it, the release-1_2_0 tag is intended to mark the
release snapshot, not serve as a branch tag.)

Or am I missing something?

Jeff

Re: [Phpwiki-talk] Altered phpWiki (fwd)

[Steve W. <sw...@wc...>]

Oops. I did forward that in December. Well, have another look! :-)

~swain

On Wed, 7 Feb 2001, Steve Wainstead wrote:

> 
> Another email I didn't forward. You wouldn't believe how much PhpWiki mail
> I have to sort through. (though most of it is from the list...)
> 
> ...............................ooo0000ooo.................................
>    Hear FM quality freeform radio through the Internet: http://wcsb.org/
>                      home page: www.wcsb.org/~swain 
> 
> ---------- Forwarded message ----------
> Date: Wed, 13 Dec 2000 14:14:02 +0100
> From: Pierre Baillet <oct...@vi...>
> To: wai...@us...
> Subject: Altered phpWiki
> 
> Hello,
> 
> I've slightly hacked phpwiki to get my own version of wikiwiki.
> This is basically a phpwiki with integrated css. The templates and the
> css are all part of the database. I've added a cookie authentification
> just because I'm not ready to write open it.
> 
> If you want to have a look at it jump at
> http://oct.zoy.org/?menu
> 
> btw thanks for all the work you've done on phpwiki (great great thing
> :).
> 
> 
> -- 
> Oct.
> 
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] Altered phpWiki (fwd)

[Steve W. <sw...@wc...>]

Another email I didn't forward. You wouldn't believe how much PhpWiki mail
I have to sort through. (though most of it is from the list...)

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

---------- Forwarded message ----------
Date: Wed, 13 Dec 2000 14:14:02 +0100
From: Pierre Baillet <oct...@vi...>
To: wai...@us...
Subject: Altered phpWiki

Hello,

I've slightly hacked phpwiki to get my own version of wikiwiki.
This is basically a phpwiki with integrated css. The templates and the
css are all part of the database. I've added a cookie authentification
just because I'm not ready to write open it.

If you want to have a look at it jump at
http://oct.zoy.org/?menu

btw thanks for all the work you've done on phpwiki (great great thing
:).


-- 
Oct.

[Phpwiki-talk] PhpWiki InterWikiLinking (fwd)

[Steve W. <sw...@wc...>]

Code for InterWiki linking. I got this in December but never forwarded
this to the list for feedback.

~swain

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

---------- Forwarded message ----------
Date: Fri, 8 Dec 2000 15:50:53 -0500 (EST)
From: Steve Wainstead <sw...@pa...>
To: sw...@wc...
Subject: PhpWiki InterWikiLinking (fwd)



http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun

---------- Forwarded message ----------
Date: Fri, 8 Dec 2000 17:25:19 +0000 (GMT)
From: Gary Benson <ga...@ee...>
To: Steve Wainstead <sw...@pa...>
Subject: PhpWiki InterWikiLinking


Hi,

I have implemented an InterWiki linking thing in PhpWiki, and thought you
might want it. In case you do, here's whats in the files:

intermap.patch.gz alters the following files:

 lib/config.php - 2 more options added, $InterWikiLinkRegexp and $intermap_file.
 lib/stdlib.php - added function LinkInterWikiLink($link)
 lib/transform.php - Added hook to tokenize and substitute InterWikiLinks.
 index.php - includes intermap.php (see below)

intermap.php, which should go in lib, generates a hash of Wiki's names
 against their base URL. It also replaces a bit of $InterWikiLinkRegexp so
 that only valid wiki names are parsed as InterWiki links. This emulates
 both Wiki and MeatBall's behaviour.

intermap.txt is a copy of the current intermap file, which is downloadable
from http://www.usemod.com/intermap.txt

Hope it's all okay,

Gary

Re: [Phpwiki-talk] Vote!

[Aredridel <are...@nb...>]

: > Could we emulate that in wiki? Hmmmm. Woa, we have preformatted text, don't
: > we? Now, why do we need tables?
:
: I want a straw poll here on the list. All in favor of simple HMLT table
: syntax, or not, speak your piece now.

Well, it's useful in some cases; HOever, using just HTML makes for a nasty
change in syntax; nowhere ielse in Wiki is there a tag syntax. Might as
well allow using Raw html for that. I kind of liked the caret-syntax --
that could be implemented with a nice regexp. Really, though, tables are
not really that neccesary. It's not often that they're the best way to
show a certain bit of information.

All in all: make it if you wish, make it optional, please.

Ari

Re: [Phpwiki-talk] One more nit to pick?

[<d9...@na...>]

On Wed, Feb 07, 2001 at 11:31:43AM -0800, Jeff Dairiki wrote:
> Does anyone actually put something nice in signature.png?
> (That the thing that says "phiwikiphpwikiphpwikiphpwikiphpwikiphpwiki..=
."
> after you save your edits.)
>=20
> Can we get rid of it?

Yes, please! I don't know why it exists. It's very confusing. A note
saying thanks for editing followed by ------ should do it. Actually I
don't like having the confirmation message on the same page as the
edited page, although I realize this has benefits.

In fact, I always try to get rid of that message after I have edited a
text by pressing reload which makes Netscape repost the recently
edited page which in turn make PhpWiki say stuff like this: "PhpWiki
is unable to save your changes, because another user edited..."

To avoid these problems, perhaps you could change the confirmation
message for lusers like me to:

 "Thank you for editing %s."
 "Your careful attention to detail is much appreciated."
 "Press [here | %s] to remove this confirmation message."

...or something like that. Then I finally would really understand. :)


For people really wanting graphics or a different look when confirming
an edit, perhaps we should make this a template page.


I think I think too much. :)

--=20
___\ Jon =C5slund

Re: [Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

[Steve W. <sw...@wc...>]

On Wed, 7 Feb 2001, Jeff Dairiki wrote:

> Are there going to be bug fix releases of 1.2.x?
> Are the going to remain PHP3 compatible?  Is that going to create headaches?

Yes, yes and no. We tagged 1.2 in CVS and we can commit bug fixes to that
branch.

> Sorry.  By bar syntax, I meant (I saw this awhile ago on some other
> Wiki --- I can't remember which):
> 
>   || introduces a centered column
>   |} introduces a right-justified column
>   |{ introduces a left-justified column
> 
> For example
> 
> || Name || Number || Homepage
> || Jeff |} 123-4567 |{ http://x.y.z/

I guess this would be ok... 

> I'm not sure I understand.
> Bold, italics, links and so forth inside tables should be allowable,
> and shouldn't preset a big problem.
> Tables within tables are excessive.

Agreed...

> Maybe I don't completely understand the significance of footnotes.

Perhaps it will be underutilized as a feature, but I just think it would
be cool to add. I have no other reason beyond that. :-)

> >
> >Oh no, I do like that idea. The wiki_pages table and the wiki_archive
> >table should have separate APIs.
> 
> I think I disagree.
> 
> >There's no reason to assume we will
> >always store pages in the archive the same way we store them in the
> >wiki_pages table.
> 
> Agreed, but that's an implementation detail.  The API should
> insulate us from that.

Poor wording on my part, but I think we understand each other. The
database API will not change (much) but we can implement page tables and
archive tables differently and move between them.

~swain 

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

[Jeff D. <da...@da...>]

>> The move to PHP4:
>
>For a new development tree, which won't mature for at least six months, I
>don't see the reason to slow down development by supporting the old 3.0.x...

Okay, okay.   You win.  I agree that PHP4 is cool.

Are there going to be bug fix releases of 1.2.x?
Are the going to remain PHP3 compatible?  Is that going to create headaches?


>HTML == security hole, basically... we'd have to restrict the markup
>allowed. The bar syntax allows any HTML.

Sorry.  By bar syntax, I meant (I saw this awhile ago on some other
Wiki --- I can't remember which):

  || introduces a centered column
  |} introduces a right-justified column
  |{ introduces a left-justified column

For example

|| Name || Number || Homepage
|| Jeff |} 123-4567 |{ http://x.y.z/


Your suggested markup (with the leading '@') is similar and fine, too.

>Inevitiably people will want to use markup inside tables.. I will say it
>again and keep saying it until I drive all of you off the project: We are
>not going to reinvent HTML. It's not fun.

I'm not sure I understand.
Bold, italics, links and so forth inside tables should be allowable,
and shouldn't preset a big problem.
Tables within tables are excessive.

>> Footnotes:
>It's a small addition, already done, so it's a moot point...

Yeah, I guess.

I'm just thinking about redoing the database API's (for versions); 
and thinking that now would be a good time to get rid of carrying around
all those page references (or footnotes).

Remember that whenever the database API changes all six backends have
to be fixed.  Simpler is better.

Maybe I don't completely understand the significance of footnotes.

Why not just put the footnote in manually:

   Some text requiring a footnote [[1].
   ...
   ----------
   Footnotes:
   # A footnote. 

Or on a separate page?

   Some test requiring a footnote (See MoreDiscussionOfTheProblem.)

Or
   Some test requiring a footnote [1|MoreDiscussionOfTheProblem].


>> Archiving Multiple Versions:
>> 
>>   This has been talked about forever.  Back before I disappeared, 
>>   I suggested a database API which handled this.  You guys apparently
>>   didn't like it (that's okay).
>
>Oh no, I do like that idea. The wiki_pages table and the wiki_archive
>table should have separate APIs.

I think I disagree.

>There's no reason to assume we will
>always store pages in the archive the same way we store them in the
>wiki_pages table.

Agreed, but that's an implementation detail.  The API should
insulate us from that.


>> Security:

>Ack. That is bad. .htaccess? Or add 'nobody' to your group?

Doesn't help (at least in my case).
The .htaccess only affects access via HTTP.
My group is 'users'.
Personal groups are a good idea though, and I'll suggest it to the
provider.

>> PATH_INFO:

>It fell off the radar. Ari has code for it, but we never integrated it.
>You probably recall the NBTSC Wiki code is on Sourceforge in the ftp
>directory.

Yeah, I did it too, in the Jeff's hacks branch.   I guess I should go
look at that.

>If there are no platform issues, I would rather see it a permanent
>feature.

I vaguely remember some issues regarding what happens when PHP is run
from cgi-bin, rather than as an Apache plugin. 

Ari: do you remember anything about this?

Jeff

Re: [Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

[<ph...@de...>]

On Wed, 07 Feb 2001 11:19:29 -0800, you wrote:
 	<snip lots of good stuff>
=> Security:
=>   On machines where httpd runs as 'nobody' (or similar), admin.php must
=>   be world readable.  This allows anyone with an account on the machine
=>   access to the username and password in admin.php (same problem for
=>   the sql password in config.inc).
=>   Is there a solution?

	One shared hosting provider (www.pair.com) allows users
to run PHP "wrapped" through a CGI-WRAP so that the process runs
as the user, rather than as nobody (which allows you to set all
your code and INC files etc etc to 600 or whatever).

	One needs to be sure the code is tight because it's going
to run as if it were the account owner logged in thru telenet
(rather than as the webserver), but it works very well.  Pair
also allows the user (webmaster level account or above) to
configure and compile their own version(s) of PHP under their own
account. Also works quite well.

	Cheers,

	- Don (a pair customer/VAR but don't ask me for an
account)

Re: [Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

[Steve W. <sw...@wc...>]

These tasks are in the task list now, except for the zip= thing, which I
suspect you'll take care of shortly.

~swain

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] One more nit to pick?

[Steve W. <sw...@wc...>]

Oh, I would prefer something in black and white :-)

~swain

On Wed, 7 Feb 2001, Jeff Dairiki wrote:

> Does anyone actually put something nice in signature.png?
> (That the thing that says "phiwikiphpwikiphpwikiphpwikiphpwikiphpwiki..."
> after you save your edits.)
> 
> Can we get rid of it?
> Or perhaps change the distributed signature.png to something prettier?
> 
> Jeff
> 
> 
> 
> 
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] One more nit to pick?

[Steve W. <sw...@wc...>]

If you want to carve out a new one, feel free. I have had it trying to
create png files on Linux.

~swain

On Wed, 7 Feb 2001, Jeff Dairiki wrote:

> Does anyone actually put something nice in signature.png?
> (That the thing that says "phiwikiphpwikiphpwikiphpwikiphpwikiphpwiki..."
> after you save your edits.)
> 
> Can we get rid of it?
> Or perhaps change the distributed signature.png to something prettier?
> 
> Jeff
> 
> 
> 
> 
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

[Steve W. <sw...@wc...>]

On Wed, 7 Feb 2001, Jeff Dairiki wrote:

> The move to PHP4:
> 
>   Is there really
>   a pressing reason to drop support for PHP3?

For a new development tree, which won't mature for at least six months, I
don't see the reason to slow down development by supporting the old 3.0.x.
There are a lot of new features in 4.0 we deny ourselves. Sooner or later
the rest of the world will catch up. There's always the possibility others
will send patches for us; but I want to start using array_walk() and other
4.0 features already. It just makes sense in the long run.

> Tables:
>   As for what markup to use, I have no strong feeling other than that
>   I think one should avoid raw HTML.  (Remind me what's wrong with
>   the bar ('|') based mark-ups?) 

HTML == security hole, basically... we'd have to restrict the markup
allowed. The bar syntax allows any HTML.

> I think the markup should provide
>   for left-adjust, right-adjusted, and centered columns.

Inevitiably people will want to use markup inside tables.. I will say it
again and keep saying it until I drive all of you off the project: We are
not going to reinvent HTML. It's not fun.


> Footnotes:
> 
>   If there's a push for keeping the mark-up simple, why footnotes?
>   Carrying the references around as page meta-data has been a
>   pain-in-the-database-code.  Why not just get rid of it all?

It's a small addition, already done, so it's a moot point...

>   We also need to think about how to deal with the references on
>   the existing pages.   My vote is to make the restore-from-zip-archive
>   tag some text with the references onto the bottom of the page.

This is more of a problem. Your solution sounds fine though. Can existing
references be converted to footnotes?

> When to Archive:
> 
>   If I edit a page that was last edited by myself six months ago,
>   I would like the old contents of the page to be archived.
>   
>   I propose that the edit form should have a checkbox labeled
>   "This is a minor edit, do not archive".  The default state of
>   the checkbox should depend on the whether the current author matches
>   the previous author, and also on the time since last edit.
> 
>   What do y'all think?  I'll add it if you give the go-ahead.

This is great! Basically I want to copy UseModWiki's model.
http://www.usemod.com/cgi-bin/wiki.pl?UseModWiki

Your idea of a checkbox is almost identical to UseMod's approach.

> Archiving Multiple Versions:
> 
>   This has been talked about forever.  Back before I disappeared, 
>   I suggested a database API which handled this.  You guys apparently
>   didn't like it (that's okay).

Oh no, I do like that idea. The wiki_pages table and the wiki_archive
table should have separate APIs. There's no reason to assume we will
always store pages in the archive the same way we store them in the
wiki_pages table.

>   I think this needs to be made a high priority, or it will never get done.

It's on the Task List on Sourceforge as of yesterday (feel free to add
tasks):

<URL:http://sourceforge.net/pm/task.php?group_project_id=7691&group_id=6121&func=browse>


> Security:
> 
>   On machines where httpd runs as 'nobody' (or similar), admin.php must
>   be world readable.  This allows anyone with an account on the machine
>   access to the username and password in admin.php (same problem for
>   the sql password in config.inc).
> 
>   Is there a solution?

Ack. That is bad. .htaccess? Or add 'nobody' to your group?


> PATH_INFO:
> 
>   Whatever happened to page names in PATH_INFO?  Did that get nixed for
>   a good reason?  Or just because I never did it.

It fell off the radar. Ari has code for it, but we never integrated it.
You probably recall the NBTSC Wiki code is on Sourceforge in the ftp
directory.

>   If it's okay, I'll try to add it again.  Should it be switchable in 
>   the config file?

If there are no platform issues, I would rather see it a permanent
feature.

>   On a related note, there's a bug:
> 
>   Currently 'index.php?zip=all' will get you to the wiki page named 'zip=all'.
>   This is probably a bad idea ('zip=all' is an allowable page name, 
>   but it should have to be url-encoded.)
>   I'll fix this unless you object.

nope, hack away! :-)


> I think that's it for now.

Welcome back! :-)

~swain

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] One more nit to pick?

[Jeff D. <da...@da...>]

Does anyone actually put something nice in signature.png?
(That the thing that says "phiwikiphpwikiphpwikiphpwikiphpwikiphpwiki..."
after you save your edits.)

Can we get rid of it?
Or perhaps change the distributed signature.png to something prettier?

Jeff

[Phpwiki-talk] FootNotes, Tables, The end of PHP3, I'm still alive, etc...

[Jeff D. <da...@da...>]

Hi.

Yes I'm still alive!
Great work everyone on the current 1.2.0 release.
Sorry I disappeared so suddenly.
I'm back, at least for a bit.

You didn't ask (well actually you just did, at least on one of these),
but here's my snooty opinions on a bunch of things:

The move to PHP4:

  My (cheap) virtual host provider is still running
  only PHP3.  I've put in a request to fix that, but who know when that
  might happen.  I'm sure others are in the same boat.  Is there really
  a pressing reason to drop support for PHP3?

Tables:

  I personally like the idea of tables --- I've wanted to use them
  on several occasion.

  As for what markup to use, I have no strong feeling other than that
  I think one should avoid raw HTML.  (Remind me what's wrong with
  the bar ('|') based mark-ups?)  I think the markup should provide
  for left-adjust, right-adjusted, and centered columns.

  So count one vote for tables.

Footnotes:

  If there's a push for keeping the mark-up simple, why footnotes?
  Carrying the references around as page meta-data has been a
  pain-in-the-database-code.  Why not just get rid of it all?

  So count one vote against footnotes.

  We also need to think about how to deal with the references on
  the existing pages.   My vote is to make the restore-from-zip-archive
  tag some text with the references onto the bottom of the page.

When to Archive:

  If I edit a page that was last edited by myself six months ago,
  I would like the old contents of the page to be archived.
  
  I propose that the edit form should have a checkbox labeled
  "This is a minor edit, do not archive".  The default state of
  the checkbox should depend on the whether the current author matches
  the previous author, and also on the time since last edit.

  What do y'all think?  I'll add it if you give the go-ahead.

Archiving Multiple Versions:

  This has been talked about forever.  Back before I disappeared, 
  I suggested a database API which handled this.  You guys apparently
  didn't like it (that's okay).

  I think this needs to be made a high priority, or it will never get done.

User ID's / Logins:

  I think they're a good idea.  (Useful for some sites, at least.)
	
Security:

  On machines where httpd runs as 'nobody' (or similar), admin.php must
  be world readable.  This allows anyone with an account on the machine
  access to the username and password in admin.php (same problem for
  the sql password in config.inc).

  Is there a solution?

PATH_INFO:

  Whatever happened to page names in PATH_INFO?  Did that get nixed for
  a good reason?  Or just because I never did it.

  If it's okay, I'll try to add it again.  Should it be switchable in 
  the config file?

  On a related note, there's a bug:

  Currently 'index.php?zip=all' will get you to the wiki page named 'zip=all'.
  This is probably a bad idea ('zip=all' is an allowable page name, 
  but it should have to be url-encoded.)
  I'll fix this unless you object.

I think that's it for now.

Jeff

Re: [Phpwiki-talk] Vote!

[<ph...@de...>]

On Wed, 7 Feb 2001 13:48:50 -0500 (EST), you wrote:
=> I want a straw poll here on the list. All in favor of simple HMLT table
=> syntax, or not, speak your piece now.

[Leaving the corner, where I was quiet for at least a day ...]

	As a newbie to the list/application, it doesn't matter to
me if you care to add HTML tables (but I personally think it's
not really on the path).  I'd suggest making the feature toggle
on/off thru config.php if you do, so folks can select as they
choose.

	I'd put this at the bottom of the to-do list, and ask
first for tasks such as multi-install capability (db and
shareable code) as it would be great to have a series of
independant mini-wikis for one situation I'm working with.

	Also I'd prefer time/attention be spent on those things
that make the wiki UI so great - it's simplicity and absolute
immediate hyper-link abilities. Perhaps faster/better cross-link
lists including that great little "related" feature.

	Another area would be tightening up the ADMIN stuff so
that it's completely transparent to the regular visitor.
Mulit-level archives were suggested earlier and that would come
before tables for me as well.

	In summary, my vote is: it depends.

	Thanks again for such a great little all-powerful app.

	- Don

Re: [Phpwiki-talk] Vote!

[Ori F. <or...@co...>]

2/7/2001 08:48:50, Steve Wainstead <sw...@wc...> wrote:

>I want a straw poll here on the list. All in favor of simple HMLT table
>syntax, or not, speak your piece now.

No tables markup please.

[Phpwiki-talk] Vote!

[Steve W. <sw...@wc...>]

On Wed, 7 Feb 2001, Arno Hollosi wrote:

> Could we emulate that in wiki? Hmmmm. Woa, we have preformatted text, don't 
> we? Now, why do we need tables?


I want a straw poll here on the list. All in favor of simple HMLT table
syntax, or not, speak your piece now.

~swain

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] tables & footnotes

[Arno H. <aho...@xm...>]

> @ ^Judy  ^ju...@fo...        ^212-444-9999
> @ ^Bill  ^bi...@mi... ^xxx-yyy-zzzz
> @ ^Steve ^st...@no...   ^aaa-bbb-cccc

<rant>
Strange, your example table appeared with columns aligned in the email.
How did you do it? Ah, now I know -- I'm using fixed width font.
Could we emulate that in wiki? Hmmmm. Woa, we have preformatted text, don=
't=20
we? Now, why do we need tables?
</rant>

I've added a quick (and dirty?) change to transform.php and stdlib.php --=
=20
footnotes work like they do in NBTSCwiki.

In order to be able to reference footnotes more than once (assuming the=20
last [x] is always the footnote itself) we could do the following:=20
currently all tokens are replaced by $replacements at the end of the line=
=2E
Why not hold of this replacement until all lines are done, and then repla=
ce=20
them in one big swoosh. Then $replacements of previous lines could still =
be=20
redefined. The other solution is to provide hooks for post- &=20
pre-processing of the entire $content.

/Arno

Re: [Phpwiki-talk] wish for 1.3 version

[Steve W. <sw...@wc...>]

An old saying here is "Give them enough rope and they will hang
themselves." This would be my approach to tables.

I think someone suggested something like:

@ ^cell1 ^cell2 ^cell3
@ ^cell1 ^cell2 ^cell3
@ ^cell1 ^cell2 ^cell3

where @ indicates the start of a table row, ^ the contents of the cell.
I'd have to dig it out of the archive. It's a low priority though. I hate
tables.

If we're supporting multi-line markup now, we can just escape to HTML land
for a while, like:

^^^^ (four or more carots starts an HTML block)

<table>
...
</table>

^^^^ (and closes the HTML block)

It's only a warmed over version of the bar syntax. I don't know. It
doesn't excite me much. I think a dirt-simple table syntax like the first
one is good enough and users can hack it if they want to have more
features. I can understand people want to do stuff like: 

@ ^Judy  ^ju...@fo...        ^212-444-9999
@ ^Bill  ^bi...@mi... ^xxx-yyy-zzzz
@ ^Steve ^st...@no...   ^aaa-bbb-cccc

Even that little bit will be a hassle to code though.

~swain

On Wed, 7 Feb 2001, Arno Hollosi wrote:

> 
> > Oh no! Not tables again! We've gotten two patches already! :-)
> > Well, it would be an interesting challenge for Arno ;-)
> 
> Well, I guess my position on tables is clear.
> They are against wiki philosophy.
> 
> But heck, now that we have modular code, I could just add a patch (not in 
> base install) for that.
> 
> Problem is, I have not yet seen a good markup for tables.
> Maybe just use the HTML table tags and let users take care of the rest?
> 
> /Arno
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] "dangling references"

[Arno H. <aho...@xm...>]

> =09I'm sorry, I really was reading the code, but I'm just
> blind or stupid.

Nothing to be ashamed of :o)

I once filed a bug report for kde kmail.

It read: you can't have spaces at end of reply-prefixes.
Actually, just two lines above the box where you could customize that=20
reply-prefix there was a line saying: %_=3Dspace

Now that's bad!

/Arno

Re: [Phpwiki-talk] wish for 1.3 version

[Arno H. <aho...@xm...>]

> Oh no! Not tables again! We've gotten two patches already! :-)
> Well, it would be an interesting challenge for Arno ;-)

Well, I guess my position on tables is clear.
They are against wiki philosophy.

But heck, now that we have modular code, I could just add a patch (not in=
=20
base install) for that.

Problem is, I have not yet seen a good markup for tables.
Maybe just use the HTML table tags and let users take care of the rest?

/Arno

Re: [Phpwiki-talk] FootNotes

[Arno H. <aho...@xm...>]

> I'm also very interested in footnotes. I could not find the mentioned
> NBTSCWiki. Could someone give me a link to it ?

http://www.nbtsc.org/wiki/

Actually, the footnotes there have a "bug": footnotes can't be referenced=
=20
twice.

I try to include footnotes next -- I think that it may need some=20
modification of transform.php.

/Arno