Each section should have a edit button

[anonymous]

ie http://www.splitbrain.org/dokuwiki/wiki:dokuwiki

[cboos]

#2867 and #3282 are duplicate requests for this feature.

[cboos]

... as well as #3558.

[cboos]

I sometimes find a need for this feature as well, when editing big wiki pages like the TracFaq.

With the wiki refactoring I have in mind, it should be possible to extract the requested section as well as replaceing it after edit in a robust way.

The concurrent edit check could even be refined to allow for editing different (non-nested) sections...

[anonymous]

I'd just like to point out that I would find this to be a tremendously useful feature, so +1 !

[cboos]

Probably not for 0.11, though the WikiEngine refactoring will help a lot here (ability to identify a section, extract its source, rebuild a full wiki source by replacing only the content corresponding to a section).

[fulvio.risso@…]

Ops... I really hope this will be done in release 0.12. This will help a lot in writing and maintaining the documentation of any project using trac.

[drop_off .at. centrum .dot. cz]

That would be really useful. My users/colleagues are always complaining about the wiki editor and this one would make it easier to use. (Yeah, full-featured Ajax WYSIWYG editor would be even better :))

[Filipe]

+1 Personally, I'd see this as an issue with an higher priority than the current 'low'.

[eblot]

Replying to Filipe:

Personally, I'd see this as an issue with an higher priority than the current 'low'.

Yeah, I agree, the lack of such a feature makes long wiki pages really difficult to preview/edit.

[bytter@…]

Personally, I'd like to see this as an issue with 'Highest' priority, rather than just 'Normal'. Believe it or not, this makes collaborative editing a real pain, and it is an huge disadvantage when comparing to MediaWiki or Dokuwiki. If/when the WikiEngine refactoring is done, how much effort would it take to implement such a task?

[cboos]

Unfortunately it has been a month now (if not more) that I've not touched the WikiEngine code... I hope to be able to resume that next week (fingers crossed).

Implementation notes

The idea is to identify the section based on its anchor (already unique), then retrieve the corresponding Heading node from the parse tree and the Heading node of the same or above level immediately following it. Each node has the needed line number info, so we can retrieve the chunk of text that corresponds to the section's content. If there's no next heading, then we're taking all lines till the end. We also compute a checksum of the original content that we'll carry along.

When we're about to save, we retrieve the similarly identified section from the latest version, compare the checksum of the section's content with the original checksum and replace the original chunk of text with the edited one, provided nothing has changed in the meantime.

This way, editing sections in parallel should be pretty robust, as only concurrent edits in the same section will conflict.

[cboos]

PS: as you can see, the above algorithm could be hacked up without necessarily waiting for the parse tree; a variant of the OutlineFormatter could be written in order to retrieve the necessary line numbers information. But the idea of the TracDev/Proposals/WikiParserFormatterSplit is precisely to avoid all those special purpose hacks ;-)

[anonymous]

Well, I would prefer a special purpose OutlineFormatter? for this feature, and then clean-up the code as soon as WikiEngine is refactored, assuming the effort to make this hack would me rather minimal comparing to the effort of finishing the WikiEngine (correct me if I'm wrong).

Actually, I don't even see this as a enhancement, but rather as a defect, since it makes concurrent editing next to impossible. Either this or a diff-merge ;-)

[cboos]

A patch would be appreciated ;-)

[bytter@…]

Working on it ;-)

[anonymous]

Hi,

Considering the wiki:WikiEngine refactoring is scheduled for milestone:0.11, could this ticket also be considered for 0.11?

[cboos]

Considering it's been two months I haven't made any progress on the WikiEngine refactoring, I frankly don't know... We should probably better just hack away a solution to #3925 and push the 0.11 release out of the door without the refactoring (and that would also move 40 wiki related tickets or so to 0.12).

[tj_yang@…]

This bring up another idea I had. We really need to have bounty trac plugin so that others who need an enhancement of trac can pool money together and have the job done and got rewarded for the trouble.

[trac-ja@…]

#6921 are duplicate requests for this feature.

I attached a patch for this feature againsts source:trunk@6603. (attachment:ticket:6921:trac-0.11dev_r6603-paraedit_r469.patch.gz)

Review it, please.

[cboos]

Same remark as on #216, you could just tidy the patch a bit so that it complies with our TracDev/CodingStyle.

First, I've seen some &ndsp; which look suspicious, in the $.fn.addEditlink function. But that's not that important I think, as I've always pictured the "Edit" as an inlined button, in the same style as the "Reply" button in ticket comments. I think that should rather be added by the formatter itself, and maybe only above a certain threshold.

Then, the way you split the page doesn't look very robust, as you identify sections by a flat sequence number. Have a look at comment:13 and comment:14, where I suggest using the heading id as the section identifier, which can be more robust when handling concurrent edits (which your patch doesn't seem to address either - i.e. the has_collision has to be extended quite a bit).

Other than that I think it's a good starting point which I'm willing to help you refine further.

[trac-ja@…]

I'm trying to update my patch, now. But I worry where layout edit button.

There are two screenshots:

• attachment:sectedit_r.png -- buttons align right
• attachment:sectedit_l.png -- buttons align left

IMO, 'sectedit1.png' is not useful, because it is too away from headdings.

Comments are welcome.

[trac-ja@…]

Replying to trac-ja@i-act.co.jp:

IMO, 'sectedit1.png' is not useful, because it is too away from headdings.

Oops.

'sectedit_r.png' is not useful

[cboos]

Hm, I think attachment:sectedit_r.png, with simply Edit would be perfect ;-)

The fact that it's far away from the headings is rather an advantage, as it gets less in the way when reading (MediaWiki and DokuWiki have this layout as well, as I'm sure many other wikis have).

[markus]

What about placing an edit link next to the pilcrow and also only show it when hovering over the section title? This may be inconsistent with the Reply link in tickets (in contrast to the proposal above), but that way we would avoid to bloat the UI once more.

[cboos]

Markus, I don't remember if you followed the discussion about the "Reply" links, but they were effectively only visible on hover, at first. That was changed for a number of reasons (not easy to figure out the feature if you don't know it, non-standard behavior for buttons, etc.)

There are other ways to avoid the "UI bloat", which is to provide those buttons only when the page is big enough to require them (though it might be not trivial to find the right heuristic for the big enough) or simply have an user option for this.

But I think we should be consistent here with the "Reply" to buttons (another reason to have them on the right side).

[markus]

Ok, I vaguely remember the reply button discussion, now that you mention it. In case the Edit buttons only appear for big pages and/or it's a user selectable option, as you propose, and the layout is consistent with the Reply buttons then I'm fine with it as well! ;-)

[stephane@…]

+1, This will greatly improve our user experience as the longer design and discussion documents become tedious to edit.

Also regarding the attachment:sectedit_r.png, having the [edit] on the right looks pretty good and doesn't clutter the content. I'd agree with it just being 'Edit' instead of 'Edit this'. It also helps breakup that page, even on a page with alot of "whitespace" http://www.monodevelop.com/Documentation

Does anyone know the status of the patch?

[cboos]

Not actively worked on, we have 0.11 to ship first ;-)

Note that http://www.monodevelop.com/Documentation is precisely what I don't want, an "Edit" button for each group of 3 lines... There must be a middle term between editing the full page, however big it is, and micro-edits like this, with an edit link for every section, however small.

[bwiese@…]

Replying to cboos:

Not actively worked on, we have 0.11 to ship first ;-) Note that http://www.monodevelop.com/Documentation is precisely what I don't want, an "Edit" button for each group of 3 lines... There must be a middle term between editing the full page, however big it is, and micro-edits like this, with an edit link for every section, however small.

+100!, As soon as 0.11 is done, please continue work on this feature!!! =) I am SO in need of this for editing very long 'sections' and 'pages'. Perhaps a macro like "[[ NoSectionEdits? ]]" could be used on pages to "hide" the Edit buttons on a per-page basis. I think the Edit buttons should be there by default (like MediaWiki and DocuWiki? - my other 2 favorites), and possibly as a global config value for the entire wiki like "SectionEdits?=1" ... then perhaps even another per-page macro could be used to turn them on if globally turned off "[[ SectionEdit? ]]"

[bkwiese@…]

Replying to bwiese@trac.cotse.net:

Perhaps a macro like "[[ NoSectionEdits? ]]" could be used on pages to "hide" the Edit buttons on a per-page basis. I think the Edit buttons should be there by default (like MediaWiki and DocuWiki? - my other 2 favorites), and possibly as a global config value for the entire wiki like "SectionEdits?=1" ... then perhaps even another per-page macro could be used to turn them on if globally turned off "[[ SectionEdit? ]]"

Also, having this toggle-per-page functionality would be nice for copying and pasting from the HTML page to a text file. Currently it looks good, except for the "paragraph" tags next to each section heading for the #name link. (I like the idea of a hidden edit button being there too, until you hover over it... and would support that, even though there is some consensus to match the reply button (also nice and low-profile)). So, perhaps there could be a "[[ NoSectionLink? ]]" per page macro as well to make copy and paste pretty? This would work like the "[[ PageOutline ]]" macro.

- Thanks again! =)

[catalin.balan@…]

Hi,

Just wanted to let you know that I've posted TracHacks:wiki:SectionEditPlugin on trac-hacks. This plugin in is based on #6921 patch.

Thank you, Catalin Balan