Page MenuHomePhabricator

Tag <dws> for discarding whitespaces.
Open, MediumPublic

Description

Author: van.de.bugger

Description:
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>
}}
  1. 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.

Details

Reference
bz31865

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:48 PM
bzimport set Reference to bz31865.
bzimport added a subscriber: Unknown Object (MLST).

van.de.bugger wrote:

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.

attachment MediaWiki-dws.patch ignored as obsolete

van.de.bugger wrote:

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.

dan.bolser wrote:

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?

van.de.bugger wrote:

Tests.

Tests in a separate file.

attachment dws.txt ignored as obsolete

van.de.bugger wrote:

To get this applied could you please supply some parser tests?

Ping. Tests are ready.

van.de.bugger wrote:

Thanks!

BTW, what is `Preprocessor_HipHop.hphp'? Should I prepare a patch for it?

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.

van.de.bugger wrote:

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"?

van.de.bugger wrote:

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?

attachment Parser.php.patch ignored as obsolete

wfRunHooks( 'ParserBeforePreprocess', array( &$this, &$text, $flags ) );

Pretty sure that &$this could be just $this.

Please provide docs/hooks.txt for this as well.

van.de.bugger wrote:

Patch for hooks.txt

Please provide docs/hooks.txt for this as well.

Here is the patch.

Attached:

van.de.bugger wrote:

A new hook, v2.

Pretty sure that &$this could be just $this.

The next attempt, without "&".

Attached:

sumanah wrote:

Changed "reviewed" tag to "need-review" to indicate that there's a new patch that awaits code review.

van.de.bugger wrote:

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.

van.de.bugger wrote:

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.

van.de.bugger wrote:

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.

audreyt wrote:

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!

matmarex removed a project: Parser.
matmarex set Security to None.
matmarex removed a subscriber: Unknown Object (MLST).