SectionEditing

This is a bounty for section editing (similar to what is requested here), like it exists on many other popular Wiki engines. Each section (starting at a Heading as described in the syntax help) has an 'Edit' button next to its title.

The following is required for the bounty to be granted:

• The default editor opens to show the contents of that section alone.
• When saving the contents and returning to the viewed page, the browser jumps back to the newly edited section.

• Must work with any kind of parser (EDIT 2010-01-17: any kind of parser which supports sections).

  • This is quite impossible -- ReimarBauer 2009-12-30 08:12:16

The following is not required but would be nice:

• Multiple users editing different sections do not create conflicts.

From reading the feature requests for this, it seems like developers are somewhat reluctant to implement this, mostly due to technical reasons. I'm putting 50€ on the table here to help convincing the core team that this is an important fix for the usability of the MoinMoin Wiki engine.

Funding

Until the bounty is taken, anybody can add or remove his/her funding offer to/from this list:

• 20 USD, valid until December 31, 2011. Andreas Kloeckner <inform AT tiker DOT net>

• 50 USD, valid until December 31, 2012. Simon Heath <icefoxen AT gmail DOT com>

• 50 USD, valid until December 31, 2011. Dmitry Kurilov <me AT dmkonweb DOT ru>

Discussion

Implementation should be done in 2.X after merging of the 2.0-storage-dom-bblank repository. -- ReimarBauer 2009-12-31 13:52:49

A feature what have maybe some common ideas (directly fast editing a word / paragraph without scrolling down a lot) is the FeatureRequests/AutoScrollingTheEditorTextArea. This patch makes it possible to double click on a word, then it opens the text editor and finally the textarea will scrolldown to the line where the word is located/clicked. Drawback or K.O. is not working with the GUI, etcetera. -- MarcelHäfner 2009-12-30 11:29:32

• I also see it as rather unlikely that something like section editing can be done cleanly and in a generally working way for moin 1.9 because in moin 1.x parsers work line-by-line and generate output on the fly, so they have no structure knowledge about the whole document. It would be great though if the auto scrolling patch could be made production ready, when looking at that page, it still seems to have some issues and needs more testing (or maybe just the page needs some updating / cleanup?). It would be a great plus in usability if we had that auto scrolling feature and I think it could be added to moin 1.9.x even. So, addressing the bounty creators: do you maybe want to either extend this bounty so that a solution based on autoscrolling is also acceptable for you or (maybe cleaner) create another bounty just about that? Thinking about effort needed, a autoscrolling bounty might be much more likely to get taken and done. -- ThomasWaldmann 2010-01-01 17:42:56

  • Personally, I'm using the hacky section editing patch with 1.8 and am quite happy with it. I'd much prefer section editing to be done cleanly for 2.x over another stopgap measure. However, I do perceive the lack of s.e. as Moin's single biggest usability flaw, so I think it might be wise to treat this with some urgency. -- -- AndreasKloeckner 2010-01-02 00:58:36

Reimar, thanks for taking the time to look at this. I'm not very familiar with MoinMoin's concepts (I am a developer, though), so perhaps I misunderstood something: why can the feature not guarantee that it works with any parser? I guess the parser must have a concept of "section" for this to work, but otherwise, I don't see the problem. -- Carl Seleborg 2009-12-30 16:50

• Hi Carl

  see HelpOnVariables and sign by the SIG var (if you want). You can have parsers which don't have text as input. For an example look at the arnica parser or take a look at the csv parser. It is excatly what you described the parser must have a concept of "section" for this to work. For that reason it is not possible to make it work for any kind of parser. -- ReimarBauer 2009-12-31 13:52:49

  • Hi Reimar,

    Ok, so in the grand tradition of users not knowing what they want, I guess my request was too general. I updated it to "work for any parser that supports sections". Is this reasonable enough? My point is: if I want to use another Wiki syntax like Markdown or dokuwiki or whatever, it should still work. In my opinion, scrolling is great, and should be implemented too. But section editing allows me to limit the amount of text in the input field, which is very important in the context of text-mode editing, where the overview is much more easily lost. When writing technical documentation, like a software specification, tables and other complex formatting elements make the section contents big enough that I don't want to scroll past the section's boundaries when editing around. -- Carl Seleborg 2010-01-17 15:35

Surely the requirements are met on pages where the sections are included from subpages:

• The sections each have an edit link if editlink is given to each Include macro instance.

• The edit links from the Include macro already support a return to the parent page.

• Wherever the Include macro works, the technique works.

Of course, what is missing is the ability to make subpages from sections, but I've written an action that will do this as part of a larger project. The only controversy here is whether pages plus subpages are a valid equivalent of pages with editable sections, but I've noticed that a few Wikis (example) seem to use subpages when managing large numbers of sections. -- PaulBoddie 2011-02-21 15:39:00

I have to qualify my last remark: the edit links only return to the parent page if the user cancels an edit, and they don't return the user to the section being edited. A new patch, FeatureRequests/GoBackToIncludedPageSectionAfterEditing, remedies this. -- PaulBoddie 2011-03-26 20:10:24

CategoryBounty