fabricius: joined #tikiwiki
joined #tikiwiki
joined #tikiwiki dhazel: joined #tikiwiki CIA-98: tikiwiki: 03lindonb * r42873 10/trunk/lib/headerlib.php: Notice. goj_killedByISP: joined #tikiwiki CIA-98: tikiwiki: 03lindonb * r42874 10/trunk/tiki-edit_draw.php: Notice and some indenting
tikiwiki: 03lindonb * r42875 10/trunk/lib/wiki-plugins/wikiplugin_draw.php: Notices GillesM: joined #tikiwiki redflo: joined #tikiwiki fabricius: joined #tikiwiki bala: joined #tikiwiki fabricius: polom dennmans: joined #tikiwiki bala: joined #tikiwiki
left #tikiwiki Tiki|bot: joined #tikiwiki rodrigoprimo: joined #tikiwiki RobertPlummer: joined #tikiwiki ricks99: joined #tikiwiki RobertPlummer: polom all amette: polom y'all :) RobertPlummer: I'll start the morning here in the US off by asking, why such an obscure syntax as "[[" where "[[meh]" produces "[meh]" and "[[meh]]" produces "[[meh]]"?
If that syntax can be removed from the new parser, that'd be a +1 from me, as I'm not sure the value of this syntax.
~np~[meh]~/np~ seems much more strait forward. amette: the double [ bracket is for not making a hyperlink
aaah, that does sound reasonable though -: ricks99 thought that "[ [ " was required to create a single " [ " in text without creating a link ricks99: too much extra typing to use ~np~[meh]~/np~ instead of [[meh]
jus saying... amette: yeah, I think that's the thing... also much easier for beginners to remember RobertPlummer: I don't even think it is a big deal to use "[[meh]]" to produce "[meh]" it is just that "[[meh]]" producing "[[meh]]" and "[[meh]" producing "[meh]" is somewhat odd. ricks99: i've never used two closing brackets "] ]" amette: yeah, what do you do, if you want one opening and two closing brackets? -: ricks99 thinks [[meh]] should produce [meh]] amette: yep -: amette thinks so too RobertPlummer: That is not what the parser test does. amette: and [[[meh]] should do [[meh]] ricks99: i agree with amette RobertPlummer: I'd rather stick with the convention.
I will call this unnamed syntax "unlink" marclaporte: joined #tikiwiki
polom amette: moloq RobertPlummer: polom marclaporte ricks99: polom too RobertPlummer: marclaporte: I'm going to need to finish up on this commit before I jump into CartoGraf, is that ok?
I just want to make sure I don't loose everything I've been working on from the weekend. marclaporte: sure
commit early and often RobertPlummer: marclaporte: I know I know.
This commit branches the CKeditor from the jison parser, and adds tons of fixes, one thing touches the other. marclaporte: :-) RobertPlummer: marclaporte: Good part is that it is it's own feature still.
marclaporte: But we are going to see a new plain of stability with the parser, so it all good.
level I should say.
And I mean over the existing parser. sandroandrade: joined #tikiwiki CIA-98: tikiwiki: 03amette * r42876 10/trunk/tiki-check.php: [FIX] Check default_charset for real marclaporte: amette: with latest commit, default_charset is reported 'bad' on http://demo.tiki.org/cartograf/tiki-check.php Bsfez: joined #tikiwiki amette: marclaporte: "default_charset should be UTF-8 as Tiki is fully UTF-8. Please check your php.ini." ;)
by default PHP's default_charset is unset - so the empty field would fit
marclaporte: see http://demo.tiki.org/cartograf/tiki-phpinfo.php - "default_charset no value no value" RobertPlummer: all: is l2r and r2l text called "directional"?
if not, what is it called? amette: RobertPlummer: I think so, because when you mix them up in one text that is called bi-directional text. CIA-98: tikiwiki: 03amette * r42877 10/trunk/tiki-check.php:
tikiwiki: [FIX] Time limits of 0 also mean unlimited in php.ini
tikiwiki: [KIL] Duplicate code Bsfez: joined #tikiwiki
Hi all
Hi Robert, it refer directly to css text direction: http://www.w3schools.com/cssref/pr_text_direction.asp so i guess it can be called directionnal :) radek82: joined #tikiwiki RobertPlummer: all: definition lists don't have a nested syntax, do they? Bsfez: ... RobertPlummer: For example:
;foo:bar
;;foo2:bar2
;foo3:bar3 Bsfez: http://doc.tiki.org/Wiki-Syntax+Lists#Creating_a_Nested_List
# Level 2
## Level 2 a
## Level 2 b
### Level 2 b i ricks99: robertplummer: you are correct. a definitiion list is only 1 level of term/definition RobertPlummer: ricks99: Woohoo! ricks99: there is a 1:1 relationship term:definition Bsfez: Hi ricks99 ricks99: term : definition
hiya bernard
@RobertPlummer: however, you should be able to have nested li and ol lists within a definition
so that:
;foo:bar RobertPlummer: I'm just thinking, I might have to use the same class/methods to process them. ricks99: *foo
the first bulleted FOO should appear under the DEFINTITION -- not the term (that is, bar -- not foo) RobertPlummer: ricks99: Produces what html? ricks99: where the <li> .. </li> is nestee within the defintiion -- not the term -: Bsfez is discovering html "Definition List" <dl></dl> :D ricks99: @RobertPlummer: something like this:
<dl><dt>foo</dt><dd>bar<ul><li>bullet></li></ul></dd></dl> RobertPlummer: ricks99: great...
rick, the current parser does not group them.
I just checked: http://demo.tiki.org/trunk/tiki-index.php?page=def+list+testing ricks99: correct... this is a "rick would really like the ability to make a bulleted list under a term/definition *term* item" desire -: ricks99 dreams big dhazel: joined #tikiwiki RobertPlummer: ricks99: After I add the initial syntax to the new parser, we can work on merging regular lists with the new set.
Sound good?
It'll be pretty easy, but I have to watch the current scope of work. ricks99: +1 RobertPlummer: Besides, I need someone else to know how to use Jison, so others may learn.
ricks99: I think it would be easier to integrate it into the existing list model I've created, so actually I think your syntax is going to be best,. CIA-98: tikiwiki: 03amette * r42878 10/trunk/tiki-check.php:
tikiwiki: [ENH] More comprehensible check for how errors are reported by PHP
tikiwiki: [ENH] More reliable check for ini_set RobertPlummer: lol, ricks99: done!
Man the new parser is easy to alter!
And keep stable. rinnan: Hi there folks: I have a quick question about a new tiki-install:
I've been able to enable the searching of documents in the file galleries, but not in attachments. What am I missing here? Any pointers would be much appreciated. Been searching all over to no avail. The file in question is a word document (I know, but its a requirement from my company ;)
tiki 9.1 on fedora btw. marclaporte: rinnan: you mean wiki attachments? rinnan: indeed, the way they are stored when someone hits the "Attach File" button at the bottom of a wiki page marclaporte: wiki page attachments are not indexed. There is an experimental preference to store wiki page attachments in the File Gallery but do proper testing before proceeding rinnan: aha, I found the option under admin-file galleries marclaporte: If you turn off wiki attachments, you can still upload files when you are in a wiki page, but they will go in the file gallery (and be indexed) rinnan: excellent, that will do the trick. Thanks a lot!
(well if my testing doesnt fail that is :) ricks99: *note that when using the file gallery (instead of attachments), the uploaded file *remains* available, even if you delete the wiki page rinnan: I see, that is important to remember
My first test is a success :) Will investigate further time_r: joined #tikiwiki arildb: joined #tikiwiki
joined #tikiwiki CIA-98: tikiwiki: 03amette * r42879 10/trunk/ (4 files in 2 dirs): [ENH] Move security checks that are solely based on PHP properties over to tiki-check.php rodrigoprimo: left #tikiwiki RobertPlummer: all: is ~pp~ treated like ~np~ but wraps in a <pre />?
ricks99: ^ ricks99: y fabricius: joined #tikiwiki
joined #tikiwiki RobertPlummer: ricks99: should "ntextn" return "<br />text</br >"?
Or should it return "<br />text"?
I seem to remember that a "n at the end is the end of a block, like open close, so shouldn't it output "<br />text"? ricks99: hmm
sounds reasonable to me
does te RobertPlummer: If you do a search and replace of n, everything is double spaced. ricks99: does the 'use wiki paragraph' setting matter? RobertPlummer: So it sounds right that it should only be "<br />text".
Not at this time, not incorporated it into the new parser.
It might get it's own handler. ricks99: k fabricius: polom
ricks99 RobertPlummer : discussing parser? RobertPlummer: fabricius: Yes sir.
Working on the new one right now.
Almost to a stable beta for standard parsing. fabricius: I tried the WYSIWYG=WIKI parser in 9x and pre-10 RobertPlummer: fabricius: Not quite there yet.
with wysiwyg.
I'm laying foundation for it though. fabricius: this seems to develop to a reasonable alternative for me in case of a site that must use WYSIWYG as standart configuration RobertPlummer: fabricius: Every different type of syntax handler will in-fact have a different handler. fabricius: I do not like the HTML based CKE so much - always a conflict between non-tecchie wannabe editors and admin then-mustbe-but-not-like to editors RobertPlummer: They can inherit from the base handler.
You can have a custom handler too.
Also, the new parser is getting a pretty cool new feature, injectable plugins. fabricius: I felt, that in pre-10 the WIKI-WYSIWYG works kind of better - is that right? RobertPlummer: $myNewPlugin = new myNewPlugin();
$parser->injectPlugin($myNewPlugin);
$parser->parse($data);
fabricius: You might find some fixes in there, but I've shifted my effort to rebuild the parser, as that will save time in the long run. fabricius: hmmm I do not really understand that
ah RobertPlummer: fabricius: Injectable plugins? fabricius: yes
what's that?
you know, I am not a coder RobertPlummer: We are wanting to test how plugins are integrated into the parser, so we are going to created them dynamically and let the parser use them.
Ok, say you are a company and you have a tiki install, but you do not want to extend it. fabricius: creating plugins dynamically?
ok RobertPlummer: Right, so you have a tax spraedsheet plugin, but you don't want to store it in lib/core/WikiPlugins fabricius: why?
or why not? RobertPlummer: you want to store in a different location, you can inject them into the parser. fabricius: ah RobertPlummer: Look, I just want to test how plugins run, it is a byproduct of it. fabricius: no problem RobertPlummer: It makes tiki more extendable. fabricius: :-) RobertPlummer: Little extendable steps make it much easier to incorporate into existing systems later on. fabricius: like backporting new plugins to older systems? RobertPlummer: fabricius: Not so much.
fabricius: More like using existing infrastructure in tiki.
It makes plugins truly plugable.
The plugin doesn't even have to exist, and it can be created.
Before it had to be a file before the system would do anything.
fabricius: what do you think?
Sorry if I sound irritated, just typing fast.
(I'm on a coding spree!) fabricius: RobertPlummer: so you can inject the plugin in advance and create it lateron? RobertPlummer: fabricius: There may never be a need to create it later.
fabricius: It injects it into the parser so the parser can execute it without it ever needed a php file.
fabricius: So the plugins are then dynamic.
fabricius: You can have a plugin that creates a plugin, and executes it.
:) fabricius: they are not php files, but ... for ex on a wikipage or something somewhere else RobertPlummer: fabricius: a php instantiated object (class) fabricius: left #tikiwiki
joined #tikiwiki
oops redflo: joined #tikiwiki deeku: joined #tikiwiki marclaporte: polom
Hey everyone:
Tiki rocks! CIA-98: tikiwiki: 03marclaporte * r42880 10/trunk/admin/include_textarea.php: The plugins tab of tiki-admin.php?page=textarea tends to take a lot of memory, so this will avoid errors (will only work on hosts that accept ini_set of memory_limit) Jyhem: polom
marclaporte: you just noticed? :-) CIA-98: tikiwiki: 03robertplummer * r42881 10/trunk/lib/core/JisonParser/Wiki/HtmlCharacter.php: [NEW] Html Character handler, added because there may be some difference between some handlers, like CKeditor eventually
tikiwiki: 03robertplummer * r42882 10/trunk/lib/core/WikiPlugin/ParserNegotiator.php: [NEW] Added injectable plugins, plugins that may exist, but only in the form on an instantiated object, to further test and extend parser.
tikiwiki: 03robertplummer * r42883 10/trunk/lib/core/JisonParser/Wiki/List.php: [NEW] Added definition lists and fixed a few bugs with lists and types '-' and '+'
tikiwiki: 03robertplummer * r42884 10/trunk/lib/core/JisonParser/WikiCKEditor/ (. Handler.php HtmlCharacter.php): [NEW] Placeholder for ckeditor handler, which extends the base handler for wiki syntax
tikiwiki: 03robertplummer * r42885 10/trunk/lib/core/WikiPlugin/CKEditorNegotiator.php: [NEW] CKEditor gets its own parser negotiator, somewhat of a placeholder for now RobertPlummer: *signs his destiny as he fully enters into the world of wysiwyg* CIA-98: tikiwiki: 03robertplummer * r42886 10/trunk/lib/parser/parserlib.php: [ENH] Use alternate ckeditor handler if jison is on, no affect to those who don't want cutting edge for now
tikiwiki: 03robertplummer * r42887 10/trunk/lib/core/JisonParser/Wiki/Header.php: [FIX] Give credit where due
tikiwiki: 03robertplummer * r42888 10/trunk/lib/core/JisonParser/ (Wiki/Handler.js Wiki/Handler.php Wiki.jison Wiki.js Wiki.php): [ENH] Added missing functionality required by wiki syntax as outlined in older wiki tests
tikiwiki: 03robertplummer * r42889 10/trunk/lib/test/core/JisonParser/OutputTest.php: [ENH] Added more testing to the jison parser, modified buggy syntax a little from old tests
tikiwiki: 03robertplummer * r42890 10/trunk/lib/core/JisonParser/Wiki/Handler.php: [REM] the ability to parse everything but wiki syntax redflo: joined #tikiwiki fabricius: RobertPlummer: you r coding wild today RobertPlummer: fabricius: Hopefully I didn't break anything.
I've actually been working on that commit for about a week or so. fabricius: [REM] the ability to parse everything but wiki syntax ??
hehe RobertPlummer: lol, it was a problem we had with plugins.
Since then, the method toSyntax() was created for the plugin negotiator.
We needed the bodies of the plugins. fabricius: I just have been lost in reading a book about the chinese expeditions ... the seem to have visited America 70 years before Columbus and went aswell all around the world RobertPlummer: Oh, wow.
Yea, I hear columbus was a terrible person. fabricius: just forgot the time
book title: 1421 RobertPlummer: But, that is just what I heard. fabricius: I never meat him in person
too old - did die a few years ago I guess
don't mind my bad humor ... especially when I am tired. getting late here and I still have to move a website from local to webserver
but anyway RobertPlummer it seems that I will be one of your dirst testes on a productive website
especially I would be, if you went to backport to 9.x
not yet sure, if I would dare to upgrade one of the two projects to pre-10
but there are definitely two projects, where I'd go for using wikisyntax and wysiywig
what I have seen up to now, wikisyntax is far more stable than html based wysiwyg
will that be the sme (or better) with the new parser RobertPlummer ?
the same?
I like the stability of the wikisyntax