Patrick R. Michaud wrote: > >> I appreciate that you are being flippant, but your suggestion requires >> "forking" a fairly major piece of core code which will obviously >> now have to be maintained from version to version and also it breaks >> any further recipes trying to do the same thing >> > > I think I'm being less flippant than you think. To me it's not a > "fork" --
You are arguing against common terminology. A "fork" is where someone is maintaining a parallel branch of code independently to the upstream maintainer > PmWiki fully recognizes that people may want to customize > markups, and it's been designed with that in mind. PmWiki implements what is typically called "monkey patching" in dynamic programming language circles. It's got a mixed following, but clearly it's a very powerful feature when used carefully. The main issues are that the patched code "rots" and falls out of sync with upstream (I have this very issue with some Rails patches where I have patched some core functionality...) As you might remember I have been using pmwiki for around 5 years, so I obviously like the very "meta" approach that it implements. However, as I do mostly Ruby stuff these days my comments are that the core could sometimes benefit from some of the functions being broken up a bit smaller so that it's simpler to patch only a small piece of functionality rather than forking a whole chunk of code... Anyway, back to the current question - I had considered that this might break some small amount of automatic closing of tags when I proposed the change, however, as I am upgrading from a couple of years back installation where it wasn't even possible to have nested div tags it seemed completely moot given that I never even had that feature before... If we must have named blocks then can we discuss making the names meaningful: - You mentioned nested tables - last time I had a look at the markup this wasn't obviously yet implemented? Can we please have (:table1:) etc syntax implemented? Better yet (:table_inner:) which adds a class="inner" to the table...? - Why not lets make the nested syntax useful? Perhaps >>blah<< could mean the same as (:div_blah:) and so the div class or ID is specified automatically? My preferred idea would still be: - How about one class of div tags nests automatically and another doesn't? eg (:div1:) doesn't nest and closes automatically when it meets another (:div1:). However, (:div:) implements automatic nesting? (or (:div_pick_a_nest_level_for_me_automatically:) or whatever...). - This could be an option enabled at the site config level. I *think* it could be implemented simply by having the Cells function generate numbered tags automatically (ie fairly non intrusive). The tags used would be in a slightly different format to the current numbers so that they can't overlap. I need a bit of help understanding how the CloseMarkup function works before I can properly propose the code change? Some other thoughts: - It would be desirable to support <TH> in the (:table:) markup. Can this please be considered? (The web is moving fast towards semantic markups and CSS). Right now it would appear that I have to "fork" the whole Cells() function in order to add this once cell type - I can't personally see how to simplify the function to avoid that though, hence request it becoming part of core? - Consider adding some counters to the nesting levels. This could be very interesting for table cells/rows. With the addition of being able to do "MOD()" arithmetic then you can do zebra stripes, etc using only core functions and some maths to read the $Row/$Col variable). This seems to be a fairly low impact change? Some of this stuff is in a cookbook recipe, but it seems like several of the main bits could actually be added into core without being too intrusive? (hence easier to maintain going forward) I still think on any non trivial sized page it's no easier to use the autoclosing tags than it is to manually close tags. Just before I wrote this email I messed up a test page which took some time to realise it's because I didn't close a div tag... Have you got some real examples of how the autoclose is actually useful? Seems to me that you still need to manually close the outer div and you need to track the nested div level in order to make use of the autoclose syntax so it's no easier than just closing the thing manually on anything other than really small paragraphs? Thanks for listening... Ed W _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
