On 9/30/06, Georg Baum <[EMAIL PROTECTED]> wrote:
Am Freitag, 29. September 2006 10:01 schrieb Ozgur Ugras BARAN:
> Thanks a lot for reviewing the code. I will be more careful about
> formatting. Here are some some answers:
>
> - What I mean with the nested command support is something like:
> \command {\command{content}}
> An example is basic index command : \index { entry @{\myformat
> {entry}} }. I see that this is not necessary for the moment, but,
> well... I am just speculating. :)
I think we should not allow arbitrary LaTeX in these parameters, only
normal text.
Agreed.
> - Indeed implementing map was easier than implementing the multimap.
> But I couldn't imagine if a parameter can apply multiple times or not.
> Then I tried to stay in the safe side. Speculating again, take the
> index command.. An index entry like
> \index {aaa!bbb!ccc}
> can be handled as:
> LatexCommand
> command_name index
> add_index_entry aaa
> add_index_entry bbb
> add_index_entry ccc
> end_inset
> As I said, just a speculation...
This is a specialization, but I think we should keep it generic and simple.
InsetCommandParams would just store a number of parameters, and the LaTeX
command generated from then would simply be
\command{param1}[optparam2][optparam3]{param4} etc.
Ah.. What I intended to do here is introduce a new base class
(insetparams maybe..). Then one can extend his/her specific params by
applying new keys_. Index is just an example here and I really didn't
think about if this is applicable or not. I just open a door for
specific implementations. If you find it too fantastic, feel free to
drop all keys and maps from the code.
- Show quoted text -
Actually we don't.. I just prefer listed keys for maintainability. We
just have all keys listed and while writing a more general code like
conversion routines, those keys would reduce time to scrutinize which
possible keywords are used..
> - Sorry again for altered whitespace. My editor did that. I tried to
correct it after I finished with the code, but I guess it was not
enough :).
Then you should get a decent editor that does not fight you in maintaining
indentation etc, but helps.
Kate.. decent enough I guess. I just changed its set-up. There won't
be any problems, anymore.
> - There is something nasty in the svn code, it is now not possible to
alter the insets. I couldn't trace the differences, but the behavior
changed around revision 149xx. Therefore I cannot commit a clean diff for
the nomencl support. I will send it after I managed to run it properly.
Sure you can. If the current code does not work for you, then you can
always do an
svn update -r 14900
. If you then generate a diff with svn diff it will be the right thing. But
of course it would be even better to find the problem in current snv :-)
Well, I know how to use svn, just I was too lazy to track down the
changes for more than 200 diffs. But I did!!! The error is introduced
with revision 15068.
I really like to correct the bug, but i guess this dispatch issue is a
bit too complex for a newbie like me. If you have any documentation
about how this mechanism works (and worked before), then I can give it
a try..
Georg
