Jean-Marc Lasgouttes a écrit :
"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
[...]
+ case LFUN_OUTLINE: {
+ lyx::toc::OutlineOp const op =
+
static_cast<lyx::toc::OutlineOp>(convert<int>(cmd.argument));
+ lyx::toc::outline(op, buffer_, cursor_.pit());
So this is a weird lfun that takes arguments 0, 1, 2, 3? What might be
better would be to have 4 different functions, that could be mapped to
kbd actions. Then I could see mergin this with LFUN_DEPTH_PLUS/MIN,
which are the same thing for environments. Note that lists would also
benefit from a way to move items (and everything nested under them) up
or down.
That would be great indeed. We could even try to extent the Toc dialog
later in order to support that kind of operation.
+ cursor_.text()->setCursor(cursor_, cursor_.pit(), 0);
+ buffer_->markDirty();
+ updateCounters(*buffer_);
+ update();
+ }
This does not look good in a case where the function did not trigger.
Of course in this case the button is disabled, but it is still a bit
ugly. Also, why do you need to reset the cursor?
outline() could return a bool telling whether something happened. Or
LFUN_OUTLINE could have proper getStatus support (which return code
would be used to enable/disable buttons).
Agreed.
+void outline(OutlineOp mode, Buffer * buf, pit_type & pit)
+{
+ ParagraphList & pars = buf->text().paragraphs();
Why not pass a cursor directly? What is the information available from
the TOC itself?
See Martin, Jean-Marc is on my side ;-)
+ case Up: {
...
+ case Down: {
...
I guess this is where problems can occur :)
+ case In:
+ for (; lit != lend; ++lit) {
+ if ((*lit)->toclevel == thistoclevel + 1) {
+ s->layout((*lit));
+ break;
+ }
+ }
+ break;
It could be possible/nice too to increase toclevel of all the nested
headings below (i.e. if a sections becomes subsection, have its
subsections become subsubsections). Should not be too difficult if we
ignore nested text insets.
I thought this was already the case but you're right, this is a must.
Abdel.
All in all, I like this patch. I am not sure yet whether it should go
in 1.4.2, but it could go in later.
IMHO, at least the last point should be implemented before this feature
ends up in 1.4.x
Abdel.
