Last modified: 2014-09-24 01:21:22 UTC
I propose tag <dws>. Preprocessor should discard the tag and all the whitespaces after it. Primary purpose of the tag -- freestyle formatting for templates. Let us consider an example: * Some introductory text {{ template1 | param1=value1 | param2=value2 | param3=value3 | ... }} continuation {{ template2 | param1=value1 | param2=value2 | param3=value3 | ... }} and, finally, finish. Not too readable. I would like to reformat it, use linebreaks and indents for better readability. Since leading and trailing whitespace is often ignored in templates, the example could be reformatted to: * Some introductory text {{ template1 | param1=value1 | param2=value2 | param3=value3 | ... }} continuation {{ template2 | param1=value1 | param2=value2 | param3=value3 | ... }} and, finally, finish. I can add indents: * Some introductory text {{ template1 | param1=value1 | param2=value2 | param3=value3 | ... }} continuation {{ template2 | param1=value1 | param2=value2 | param3=value3 | ... }} and, finally, finish. or add linebreak before template name: * Some introductory text {{ template1 | param1=value1 | param2=value2 | param3=value3 | ... }} continuation {{ template2 | param1=value1 | param2=value2 | param3=value3 | ... }} and, finally, finish. but anyway, braces must remain on the same line with surrounding text. Using <dws> the example could be reformatted to: * Some introductory text <dws> {{ template1 | param1=value1 | param2=value2 | param3=value3 | ... }} <dws> continuation <dws> {{ template2 | param1=value1 | param2=value2 | param3=value3 | ... }} <dws> and, finally, finish. Much better to my taste. This is a simple example. The more complex template code, the more value of good formatting. Other possible applications: 1. Unnamed leading and trailing whitespaces are not ignored in unnamed template arguments. <dws> may be used to format code: {{ some template with unnamed arguments |first unnamed argument value<dws> |second unnamed argument value<dws> }} 2. If someone wants to avoid too long lines in wiki code: * Linebreak terminates list element, <dws> so entire element must be written in one long line. <dws> But tag dws allows writing it in multiple short lines. I think there are even more applications... I have been using the tag in my templates for some time and found in extremely helpful.
Created attachment 9266 [details] Implementation of tag <dws>. This is implementation of the tag <dws>. The patch is developed for MediaWiki 1.17.1. I tested Preprocessor_DOM.php at my local wiki server. Unfotunately, I do not know when Preprocessor_Hash.php is used, so it is not tested. But fix is very similar for both preprocessors.
I would like implement it as an extension, not a patch for MediaWiki core. But it seems it is hardly possible. A new tag can be implemented as an extension, but it is a very special one: it affects whitespace *after* the tag. Of cource, adding a closing tag </dws> makes extension implementation possible, but makes it useless: {{ some template with unnamed arguments |first unnamed argument value<dws> </dws>|second unnamed argument value<dws> </dws>}} looks ugly. The same effect may be achieved by comments: {{ some template with unnamed arguments |first unnamed argument value<!-- -->|second unnamed argument value<!-- -->}} but it does not improve readability, while standalone <dws> does.
I think some way of allowing complex template code to be better formatted without creating masses of 'horizontal whitespace' in the calling page is essential. I'm not 100% sure this is the best way to do it, but I can't think of anything better, so it gets my vote. ... Sorry, I know I shouldn't use the issue tracker for discussion, but I just did.
(In reply to comment #3) > Sorry, I know I shouldn't use the > issue tracker for discussion, but I just did. As long as the discussion is directly relevant to the original issue, discussion is fine. Now to make my discussion ok: (In reply to comment #1) > This is implementation of the tag <dws>. To get this applied could you please supply some parser tests?
Created attachment 9299 [details] Tests. Tests in a separate file.
> To get this applied could you please supply some parser tests? Ping. Tests are ready.
Ping again.
r103795
Thanks! BTW, what is `Preprocessor_HipHop.hphp'? Should I prepare a patch for it?
It's a preprocessor used when compiling with HipHop. http://en.wikipedia.org/wiki/HipHop_(software)
Reverted in r103990. Not sure if this is something desirable at all; it's a weird-looking syntax and modifies the preprocessor (always a dangerous step). Something like this needs to be discussed publicly on the core mailing lists rather than just on an out-of-the-way bug report.
> Something like this needs to be discussed publicly on the core mailing lists… Which of the mailing lists listed in http://www.mediawiki.org/wiki/Mailing_list is "core"?
Should use wikitech-l
Created attachment 9766 [details] A new hook. > Not sure if this is something desirable at all; it's a weird-looking syntax > and modifies the preprocessor (always a dangerous step). Ok, it could be undesirable and dangerous. Will you accept another one-line patch instead which introduces a new hook which makes implementation of <dws> possible as an extension?
> wfRunHooks( 'ParserBeforePreprocess', array( &$this, &$text, $flags ) ); Pretty sure that &$this could be just $this. Please provide docs/hooks.txt for this as well.
Created attachment 9921 [details] Patch for hooks.txt > Please provide docs/hooks.txt for this as well. Here is the patch.
Created attachment 9922 [details] A new hook, v2. > Pretty sure that &$this could be just $this. The next attempt, without "&".
Changed "reviewed" tag to "need-review" to indicate that there's a new patch that awaits code review.
Ping. Both comments by Mark have been addressed. Is there any more blockers?
(In reply to comment #19) > Ping. Both comments by Mark have been addressed. Is there any more blockers? Please post an RFC to wikitech-l and mediawiki.org (https://www.mediawiki.org/wiki/Requests_for_comment) for this. The response I got was that this wasn't really something that anyone wanted.
Mark, Why didn't you ask for the most important blocker first? You requested parser tests — I wrote them, but the final destination for test was a trash bin, because of "a weird-looking syntax and modifies the preprocessor (always a dangerous step)". Then I throw away my first implementation, and proposed a new one -- a new hook, one-line patch, to let me implement my weird-looking syntax as an extension, so my weird-looking syntax is not a problem because it is not a part of MediaWiki anymore. You requested hooks.txt. I wrote hooks.txt just to get know that you think this stuff is not really wanted by anyone. Why didn't you request the most important thing — RFC from the very beginning? Why did you ask for parser test, hooks.txt, $this without ampersand? -------------------------------------------------- Off-topic: > The response I got was that this wasn't really something that anyone wanted. Err... Do you know something real that anyone wanted? (Immortality and tax-less life are not real.) Many people think Wikipedia is a trash created by lamers, so even Wikipedia is *not* a thing that *anyone* wanted. My awkward <dws/> is wanted by two persons. Not too bad for one-line hurtless patch. -------------------------------------------------- https://www.mediawiki.org/wiki/Requests_for_comment/New_hook:_ParserBeforePreprocess Message to wikitech-l sent.
I apologize for offending you but thank you for sending the emails.
I sent a message to wikitech-l@lists.wikimedia.org twice, but I have no evidence it was actually delivered — I don't see my message in the list archive. Could you please somebody resend it? My original text was quite trivial: > https://www.mediawiki.org/wiki/Requests_for_comment/New_hook:_ParserBeforePreprocess > Please comment. > Van.
It went through both times: http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/58761 http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/58962
Hi Van, thank you for the patch! As you may already know, MediaWiki is currently revamping its PHP-based parser into a "Parsoid" prototype component, to support the rich-text Visual Editor project: https://www.mediawiki.org/wiki/Parsoid https://www.mediawiki.org/wiki/Visual_editor Folks interested in enhancing the parser's capabilities are very much welcome to join the Parsoid project, and contribute patches as Git branches: https://www.mediawiki.org/wiki/Git/Tutorial#How_to_submit_a_patch Compared to .diff attachments in Bugzilla tickets, Git branches are much easier for us to review, refine and merge features together. Each change set has a distinct URL generated by the "git review" tool, which can be referenced in Bugzilla by pasting its gerrit.wikimedia.org URL as a comment. If you run into any issues with the patch process, please feel free to ask on irc.freenode.net #wikimedia-dev and the wikitext-l mailing list. Thank you!
