Malo Pichot wrote: > > Hussein Shafie a ?crit : > > > <snip/> > > > We are not fully satisfied with current semantics of the > > "insert into" command: > > * insert an element at caret position (even if an ancestor > > of ``caret container'' is explicitly selected); > > * OR, only if selected element is empty, add a child to > > this element. > > > > We will probably rethink the "insert into" command but not > > on the short term. > > I have a problem with this command : > > I created a <informaltable> with a <tgroup>/<tbody>/<row>. I want > to insert a <colspec> in the <tgroup>. I explicitly selected the > <tgroup> in the node path bar. When I activate the "Insert into" > command, I didn't see <colspec>. To insert this element, I have > to select the first child of <tgroup> (i.e. <tbody>) and to > activate the "Insert before" command. > > Did I miss something or, definitively, there's a problem with the > "Insert into" ?
There are no known bugs related to "Insert into". (In fact, there no known bugs at all, only features implemented in a way which annoys some users.) 99.99% of the time, "Insert into" is used to insert an element inside a piece of text at the caret position. If what you do is not related to some text and to the caret position, please ignore the "Insert into" command. Currently, "Insert into" will not guess at which position a <colspec> is to be inserted in the <tgroup>. That's why, like you did, you really have to select <tbody> and use "Insert before".
