Menu
▾
▴
phpwiki-talk
|
From: Adam S. <ad...@pe...> - 2002-02-20 22:25:27
|
did we ever decide on a syntax for putting inline comments in the wiki text? i think this would be useful for instructions which are important to people editing the page but not to people reading the page (eg. please add comments below here ... or please be careful not to screw up this table ...). i think it could also be useful as a primitive meta data system though i know that other better systems for that have been discussed. i believe that the two most obvious options "^#" and "^;" have been rejected due to collisions with other markup. what about allowing html style comments? <!-- stuff --> or is that a security risk? adam. |
|
From: Jeff D. <da...@da...> - 2002-02-21 00:12:56
|
Adam Shand said: > did we ever decide on a syntax for putting inline comments in the wiki > text? No. > i believe that the two most obvious options "^#" and "^;" have been > rejected due to collisions with other markup. # clearly conflicts with lists... The leading semi-colon could co-exist with the new markup syntax if/when we switch completely to that. > what about allowing html style comments? <!-- stuff --> or is that a > security risk? I can't see how it could be a security risk. OTOH, both new and old parsers at this point are fairly line oriented as would have trouble dealing with things like <!-- inline comments -->, etc... So it's probably better to adopt a comment syntax which is inherently line oriented. Maybe the C++/PHP style: // Here's a comment? > adam. > > > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
|
From: Jeff D. <da...@da...> - 2002-02-21 04:42:23
|
On 20 Feb 2002 19:59:52 -0800 "Adam Shand" <ad...@pe...> wrote: > > I can't see how it could be a security risk. OTOH, both new and old > > isn't javascript and other such stuff embedded in comment strings? Yes it is, but... The whole point of the comment syntax is that the comments don't get sent to the browser. That makes it hard to do anything malicious with them. > will it interfere with people who might paste c code into a wiki? any > other languages that use // as a comment string? Good point. Though nearly any comment syntax will screw up pasting whatever kind of code the syntax is stolen from. Probably: don't allow/recognize comments within <verbatim> blocks. (Probably not within <pre> blocks either. Also you can always escape them: ~// This is not a comment. |
|
From: Adam S. <ad...@pe...> - 2002-02-21 15:26:41
|
> Yes it is, but... The whole point of the comment syntax is that the > comments don't get sent to the browser. That makes it hard to do anything > malicious with them. ah, i was orgininally thinking that we could just enable the comment html tag and let it pass through to the browser since it won't be seen. it didn't occur to me that there was a simpler alternative :) > Good point. Though nearly any comment syntax will screw up pasting > whatever kind of code the syntax is stolen from. > > Probably: don't allow/recognize comments within <verbatim> blocks. > (Probably not within <pre> blocks either. Also you can always escape > them: > ~// This is not a comment. sounds reasonable to me. thanks, adam. |
|
From: Jeff D. <da...@da...> - 2002-02-21 15:31:23
|
Adam Shand said:
>> Yes it is, but... The whole point of the comment syntax is that the
>> comments don't get sent to the browser. That makes it hard to do
>> anything malicious with them.
>
> ah, i was orgininally thinking that we could just enable the comment
> html tag and let it pass through to the browser since it won't be seen.
> it didn't occur to me that there was a simpler alternative :)
Ooh. We could do that, too. Still not a problem, I think, as long as
the comment text is htmlspecialchar()ed ('<' -> '<').
|
|
From: Adam S. <ad...@pe...> - 2002-02-21 15:46:43
|
> > ah, i was orgininally thinking that we could just enable the comment
> > html tag and let it pass through to the browser since it won't be seen.
> > it didn't occur to me that there was a simpler alternative :)
>
> Ooh. We could do that, too. Still not a problem, I think, as long as
> the comment text is htmlspecialchar()ed ('<' -> '<').
if it can be done without security risks then that would be my vote.
the information isn't secret, just not displayed, so we may as well pass
it to the browser, it might be useful for something.
adam.
|
|
From: Steve W. <sw...@pa...> - 2002-02-21 16:08:35
|
Adam Shand wrote:
>>>ah, i was orgininally thinking that we could just enable the comment
>>>html tag and let it pass through to the browser since it won't be seen.
>>> it didn't occur to me that there was a simpler alternative :)
>>>
>>Ooh. We could do that, too. Still not a problem, I think, as long as
>>the comment text is htmlspecialchar()ed ('<' -> '<').
>>
>
> if it can be done without security risks then that would be my vote.
> the information isn't secret, just not displayed, so we may as well pass
> it to the browser, it might be useful for something.
Well, I'll be the curmudgeon here and voice two objections: one, the
comment will appear in the HTML source and likely won't make any sense
to the end user who views it (and won't know it came from the Wiki
markup); and two, we are arbitrarily letting some HTML through and not
others, like <i> and its kin; so we now send a confusing message to end
users ("HTML is not allowed! Use HTML comments for your Wiki markup!")
My preference would be for Wiki-specific comment tags; but thinking of
Ari's approach, there is no equivalent in the course of normal writing
(except "asides" like this statement in parentheses).
Maybe ((I am a comment)) would suffice. Flame me as you must.
~swain
|
|
From: Lawrence A. <la...@us...> - 2002-02-21 16:27:07
|
I'll join Steve on the pyre, now he's put his hand in the fire.
I can't see any need at all to allow comments through to the browser. I
can just about see the use of comments in the wiki source. I would not
like the markup to resemble comments in most other languages eg c++ or php,
because people who use wiki's for source documentation will be confused by
text disappearing! I don't think that disallowing comments in <pre> blocks
helps - indeed I think it makes it even more confusing. Anyway, people
should not have to use <pre> for code blocks if they don't want to (even if
it *is* a good idea). And if they don't, they should not find that their
source code comments have vanished. It takes enough effort to get people
to put them in the first place!
So ....
Since comments are only likely to be used by people who know what they are
doing, we can afford for the markup to be a little unintuitive. How about
something like {{comment}}. (Someone is about to tell me that that is a
how you define a function in xyz language, no doubt)
Also, whilst I'm on this rant, why should comments not be multiline? Would
it be useful to be able to comment out large blocks of wikitext, without
actually deleting it? They could be picked up by the block parser, and the
inline parser, couldn't they?
Lawrence
At 16:04 21/02/2002, you wrote:
>Adam Shand wrote:
>>>>ah, i was orgininally thinking that we could just enable the comment
>>>>html tag and let it pass through to the browser since it won't be seen.
>>>>it didn't occur to me that there was a simpler alternative :)
>>>Ooh. We could do that, too. Still not a problem, I think, as long as
>>>the comment text is htmlspecialchar()ed ('<' -> '<').
>>if it can be done without security risks then that would be my vote. the
>>information isn't secret, just not displayed, so we may as well pass
>>it to the browser, it might be useful for something.
>
>Well, I'll be the curmudgeon here and voice two objections: one, the
>comment will appear in the HTML source and likely won't make any sense to
>the end user who views it (and won't know it came from the Wiki markup);
>and two, we are arbitrarily letting some HTML through and not others, like
><i> and its kin; so we now send a confusing message to end users ("HTML is
>not allowed! Use HTML comments for your Wiki markup!")
>
>My preference would be for Wiki-specific comment tags; but thinking of
>Ari's approach, there is no equivalent in the course of normal writing
>(except "asides" like this statement in parentheses).
>
>Maybe ((I am a comment)) would suffice. Flame me as you must.
>
>~swain
>
>
>
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
|
|
From: Jeff D. <da...@da...> - 2002-02-21 16:37:24
|
Lawrence Akka said: > Anyway, people should not have to use <pre> for code > blocks if they don't want to (even if it *is* a good idea). If we adopt the new markup they will have to. Otherwise their code will get run together in one big paragraph. > Also, whilst I'm on this rant, why should comments not be multiline? > Would it be useful to be able to comment out large blocks of wikitext, > without actually deleting it? They could be picked up by the block > parser, and the inline parser, couldn't they? As long as we make them either block-level or inline-level the parsers will be able to deal with them fairly easily. (I.e. if we make them inline ((so that you can do this)), then they will not be allowed to span paragraphs.) I'm not sure we want to make it too easy to comment large blocks of text anyway. Comments as instructions to the editor are good, I think. Comments as a place to store work in progress (or whatever) are a bad idea (on a wiki). Either just show the work in progress, or put it on it's own page.... |
|
From: Lawrence A. <la...@us...> - 2002-02-21 16:40:51
|
At 16:37 21/02/2002, you wrote:
>Lawrence Akka said:
> > Anyway, people should not have to use <pre> for code
> > blocks if they don't want to (even if it *is* a good idea).
>
>If we adopt the new markup they will have to. Otherwise their
>code will get run together in one big paragraph.
Oh yes. I'd forgotten that.
> > Also, whilst I'm on this rant, why should comments not be multiline?
> > Would it be useful to be able to comment out large blocks of wikitext,
> > without actually deleting it? They could be picked up by the block
> > parser, and the inline parser, couldn't they?
>
>As long as we make them either block-level or inline-level the parsers
>will be able to deal with them fairly easily. (I.e. if we make them
>inline ((so that you can do this)), then they will not be allowed to
>span paragraphs.)
What I had in mind was the
{{ability to
do this }}
sort of {{thing}}
>I'm not sure we want to make it too easy to comment large blocks of
>text anyway. Comments as instructions to the editor are good, I
>think. Comments as a place to store work in progress (or whatever)
>are a bad idea (on a wiki). Either just show the work in progress,
>or put it on it's own page....
Actually, I think I agree with that (happens sometimes, you know)
L
|
|
From: Steve W. <sw...@pa...> - 2002-02-21 16:51:01
|
Finally, we should consider whether this is just programmer gold
plating. I think we should have three good reasons to have comment
blocks in Wiki markup.
Oh, and to muddy the waters further (and continue to reinvent HTML),
comments could optionally render as HTML comments on the other end.
yuck
~swain
Lawrence Akka wrote:
> At 16:37 21/02/2002, you wrote:
>
>> Lawrence Akka said:
>> > Anyway, people should not have to use <pre> for code
>> > blocks if they don't want to (even if it *is* a good idea).
>>
>> If we adopt the new markup they will have to. Otherwise their
>> code will get run together in one big paragraph.
>
>
> Oh yes. I'd forgotten that.
>
>
>
>
>> > Also, whilst I'm on this rant, why should comments not be multiline?
>> > Would it be useful to be able to comment out large blocks of wikitext,
>> > without actually deleting it? They could be picked up by the block
>> > parser, and the inline parser, couldn't they?
>>
>> As long as we make them either block-level or inline-level the parsers
>> will be able to deal with them fairly easily. (I.e. if we make them
>> inline ((so that you can do this)), then they will not be allowed to
>> span paragraphs.)
>
>
> What I had in mind was the
> {{ability to
> do this }}
> sort of {{thing}}
>
>
>
>> I'm not sure we want to make it too easy to comment large blocks of
>> text anyway. Comments as instructions to the editor are good, I
>> think. Comments as a place to store work in progress (or whatever)
>> are a bad idea (on a wiki). Either just show the work in progress,
>> or put it on it's own page....
>
>
> Actually, I think I agree with that (happens sometimes, you know)
>
> L
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
>
>
|
|
From: Adam S. <ad...@pe...> - 2002-02-21 16:47:44
|
> Well, I'll be the curmudgeon here and voice two objections: one, the
> comment will appear in the HTML source and likely won't make any sense
> to the end user who views it (and won't know it came from the Wiki
my assumption was that anyone who was viewing the html source was
probably smart enough to investigate :-)
> markup); and two, we are arbitrarily letting some HTML through and not
> others, like <i> and its kin; so we now send a confusing message to end
> users ("HTML is not allowed! Use HTML comments for your Wiki markup!")
i thought the new markup did allow very simple html (ie. <b>,<i>,<em>,
etc) which is why i suggested it.
> My preference would be for Wiki-specific comment tags; but thinking of
> Ari's approach, there is no equivalent in the course of normal writing
> (except "asides" like this statement in parentheses).
>
> Maybe ((I am a comment)) would suffice. Flame me as you must.
that's kinda nice though. i always forgot to step back from it and
think "what's the most wiki way to do this" and should be fairly
unlikely to happen accidentally.
well i just did some reseach. (( doesn't appear anywhere in the main
phpwiki wiki. it appears once on my personaltelco wiki and four times
on meatball. all instances are ((situations like) this) or math like
this ((4+7)*6). since none of those should match ((.*)) we should be
fairly safe.
also, i did want to say to everyone here. one of the reasons i like
phpwiki is that it really trys to keep things wiki and keep things
simple while progressing onto new features. i love all the features in
twiki (and moin is getting there) but they are getting aesthetically
ugly and over complicated. usemod i think is the "most true wiki" but
it's a little featureless for my tastes.
anyway, just wanted to say thanks, i think ya'll strike pretty much the
perfect balance with phpwiki and i'm happy to do my (very) little part
to help out.
adam.
|
|
From: <mal...@cs...> - 2002-02-22 01:05:17
|
On Thu, Feb 21, 2002 at 08:47:07AM -0800, Adam Shand wrote: > > well i just did some reseach. (( doesn't appear anywhere in the main > phpwiki wiki. it appears once on my personaltelco wiki and four times > on meatball. all instances are ((situations like) this) or math like > this ((4+7)*6). since none of those should match ((.*)) we should be > fairly safe. What about ((4+7) * (3+3))? Malcolm -- Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/ AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-4936 "He causes his sun to rise on the evil and the good, and sends rain on the righteous and the unrighteous." - Matt 5:45 |
|
From: Reini U. <ru...@x-...> - 2002-02-22 18:44:50
|
Malcolm Ross Kinsella Ryan schrieb:
> On Thu, Feb 21, 2002 at 08:47:07AM -0800, Adam Shand wrote:
> > well i just did some reseach. (( doesn't appear anywhere in the main
> > phpwiki wiki. it appears once on my personaltelco wiki and four times
> > on meatball. all instances are ((situations like) this) or math like
> > this ((4+7)*6). since none of those should match ((.*)) we should be
> > fairly safe.
>
> What about ((4+7) * (3+3))?
not to forget lisp and esp. scheme.
I have a lot of "((" situations in my acadwiki.
I'm for "<!-- ...\n... -->", not displayed to the user, or
"//" on col 1
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X