Edgewall Software
Modify

Opened 15 years ago

Last modified 4 years ago

#1024 new enhancement

Each section should have a edit button

Reported by: anonymous Owned by:
Priority: normal Milestone: topic-wikiengine
Component: wiki system Version: 0.8
Severity: normal Keywords: section edit helpwanted
Cc: kirean@…, trac-ja@…, stephane@… Branch:
Release Notes:
API Changes:

Description

Attachments (2)

sectedit_l.png (58.9 KB ) - added by trac-ja@… 12 years ago.
sectedit_r.png (56.9 KB ) - added by trac-ja@… 12 years ago.

Download all attachments as: .zip

Change History (48)

comment:1 by Christopher Lenz, 15 years ago

Summary: Each topic should have a edit buttonEach section should have a edit button

comment:2 by Christian Boos, 13 years ago

Keywords: section edit added
Severity: criticalnormal

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

comment:3 by Christian Boos, 13 years ago

… as well as #3558.

comment:4 by Christian Boos, 13 years ago

Milestone: 0.11
Owner: changed from Jonas Borgström to Christian Boos

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…

comment:5 by anonymous, 13 years ago

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

comment:6 by Christian Boos, 13 years ago

Milestone: 0.110.12

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).

comment:7 by fulvio.risso@…, 13 years ago

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.

comment:8 by drop_off .at. centrum .dot. cz, 13 years ago

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 :))

comment:9 by Filipe, 13 years ago

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

in reply to:  9 comment:10 by Emmanuel Blot, 13 years ago

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.

comment:11 by Emmanuel Blot, 13 years ago

Priority: lownormal

comment:12 by bytter@…, 13 years ago

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?

comment:13 by Christian Boos, 13 years ago

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.

comment:14 by Christian Boos, 13 years ago

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 ;-)

comment:15 by anonymous, 13 years ago

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 ;-)

comment:16 by Christian Boos, 13 years ago

Keywords: helpwanted added

A patch would be appreciated ;-)

comment:17 by bytter@…, 13 years ago

Working on it ;-)

comment:18 by anonymous, 13 years ago

Hi,

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

comment:19 by Christian Boos, 13 years ago

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).

comment:20 by kirean@…, 12 years ago

Cc: kirean@… added

comment:21 by tj_yang@…, 12 years ago

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.

comment:22 by trac-ja@…, 12 years ago

Cc: trac-ja@… added

#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.

comment:23 by Christian Boos, 12 years ago

Priority: normalhigh
Status: newassigned

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.

by trac-ja@…, 12 years ago

Attachment: sectedit_l.png added

by trac-ja@…, 12 years ago

Attachment: sectedit_r.png added

comment:24 by trac-ja@…, 12 years ago

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

There are two screenshots:

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

Comments are welcome.

in reply to:  24 comment:25 by trac-ja@…, 12 years ago

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

comment:26 by Christian Boos, 12 years ago

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).

comment:27 by markus, 12 years ago

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.

comment:28 by Christian Boos, 12 years ago

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).

comment:29 by markus, 12 years ago

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! ;-)

comment:30 by stephane@…, 12 years ago

Cc: stephane@… added

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

comment:31 by Christian Boos, 12 years ago

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.

in reply to:  31 ; comment:32 by bwiese@…, 12 years ago

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 "

in reply to:  32 comment:33 by bkwiese@…, 12 years ago

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! =)

comment:34 by catalin.balan@…, 11 years ago

Hi,

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

Thank you, Catalin Balan

comment:35 by FilipeCorreia, 10 years ago

Any chance to include this in the upcoming 0.12?

comment:36 by Christian Boos, 10 years ago

No, but you could use that plugin in the meantime.

In my view, a proper solution should go along the plan outlined in comment:13, and that's clearly a 0.13 thing.

comment:37 by Ryan Ollos <ryano@…>, 10 years ago

Cc: ryano@… added

comment:38 by Christian Boos, 10 years ago

Milestone: next-major-0.1X0.13

comment:39 by anonymous, 10 years ago

this is a really useful plugin,thanks

comment:40 by Christian Boos, 9 years ago

Milestone: 0.130.14-wikiengine

comment:41 by ay4h7optu6tw7@…, 8 years ago

Thanks for adding the plugin, it addresses a widely-requested, sorely-needed, and obviously-neglected feature. It's really hard to believe this hasn't been addressed for 5 years.

in reply to:  41 comment:42 by kirean@…, 8 years ago

Replying to ay4h7optu6tw7@…:

Thanks for adding the plugin, it addresses a widely-requested, sorely-needed, and obviously-neglected feature. It's really hard to believe this hasn't been addressed for 5 years.

You seem to need a better understanding how open source projects works. This is not their job. People spend their free time on this project. Anyone is welcome to contribute. You just sit on your ass whining.

comment:43 by trancesilken@…, 6 years ago

When integrating the plugin's functionality, I would like to have the edit button right aligned, with longer titles floating around it, e.g.

Section Title                                                    [Edit]
...

Rather Long Title Rather Long Title Rather Long Title Rather     [Edit]
Long Title Rather Long Title 
...

comment:44 by Ryan J Ollos, 6 years ago

Cc: ryano@… removed

comment:45 by Ryan J Ollos, 5 years ago

Owner: Christian Boos removed
Status: assignednew

comment:46 by figaro, 4 years ago

Priority: highnormal

Workaround available.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.