On 10/6/06, Juergen Spitzmueller <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> I plan to support splitidx, since it runs once on the file. So, it is
> easier to handle. For example, I will not have to control the number
> of indices, since the file write handle of Latex is limited.
This is a strong argument IMO. The 16 writes are not much if you are using
sectionated bibliographies and a splitted index plus a toc, a lot and a lof.
Maybe.. but, you know, in some day users will complain as, where is my
twentieth index etc. The problem here is to keep track of number of
writes, some of which are not index related files, not to exceed
number 16. My programming habits tell me I should control it for the
sake of consistency. But, I am too lazy/ have too little time to
implement it. This is why my first choice is splitidx.
> However, splitidx is not available in every distro (for example my
> suse doesn't have it). I hate software which keeps asking some other
> software to work correctly. Therefore, I plan also to support David M.
> Jones' implementation (index). I haven't scrutinized both packages,
> but it seems to me, Jones' implementation have some slight advantages
> (like custom counters, etc..) and some disadvantages..
> supporting both packages brings new difficulties in terms of
> consistency, though...
yes. And I don't know if it's worth supporting both. But the one who
implements it decides ;-)
Then I decide.. :)
(you also will have to take care that things also work with different index
processors, like xindy).
Oh yes, I know that..
> Oh, I will also keep support for ordinary index package.
You mean LaTeX's native index implementation?
yes..
> If you have no time, I can start the implementation immediately.
Great. (However, I think it would be good to get your insetcommand changes in
first, since the index stuff will rely on that).
I have already sent the inetcommandparams changes. There is no change
for insetcommand from me.. Georg will improve it a little and submit
to svn, i guess.. This is necessary also for my nomencl
implementation..
> But I
> have to ask a couple of things..
>
> - I assume you have some idea on how to implement this feature, in
> terms of user interface etc. If you share your vision about multiple
> indices, then both of us will be happy with the result.
OK. My idea was to add an "index" pane to the documents dialog, where the user
can select "multiple indices" and add new indices in a browser widget similar
to the branches browser. When this is selected, a combo box in the index
dialog lets the user select in which index a given index entry should appear.
That's basically all for the UI side. Internally, you'll have to add a buffer
param and things (a look at the bibtopic implementation might help).
we are thinking in parallel then.. My only concern is for index.sty
there are four obligatory and one optional parameter. it will be hell
of a crowded dialog.. This number reduces to two for spliidx.sty.
> - I have limited time. I mean in two months, I will probably disappear
> for six months. therefore I need somebody to maintain the code when I
> am away. I am sure that I will finish a working and clean version
> before I leave, but I cannot guarantee things will work in every
> frontend.
I'll try to, but I cannot guarantee anything, since my time is limited as
well. But I'm interested in helping to polish it.
that is what I am asking. And (if I don't have time) qt3 and gtk ports..
Jürgen
