[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspell-devel] Add and Remove Word Lists
From: |
Jose Da Silva |
Subject: |
Re: [aspell-devel] Add and Remove Word Lists |
Date: |
Wed, 17 Nov 2004 14:50:45 -0800 |
User-agent: |
KMail/1.6.1 |
On Wednesday 17 November 2004 06:21 am, Gary Setter wrote:
> Hi,
>
> I want to make a dialog for adding and removing word lists from
> the dictionary. Adding a list would involve compiling it and
> adding the compiled name to the configured master dictionary,
> which I assume will be a multi dictionary. Removing a word list,
> would involve removing the compiled file name from the word list.
One multi-special dictionary while the other dictionaries are ordinary?
That likely means 2 different sets of program flow so that one dictionary is
treated special while the others are treated ordinary.
If one program function flow is going to become different from the other, it
may mask potential bugs and/or problems in one procedure while the other
procedure may not have such a bug due to different handling of data.
Wouldn't it be simply better to either make all dictionaries special or all
dictionaries ordinary? ...this way you use the same code everywhere,
therefore reducing code, complexity, potential bugs.
> Typically in this situation, I make two list boxes with availed
> on items on one side and in use items on the other and two
> buttons in the middle to move the selected items from side to
> side.
>
> The word list problem is special in that the item name changes
> when you compile it. Further, the directory of the source word
> list is lost. So there is a lose of continuity when the user
> compare what is available (word lists in the source dir) with
> what is in use (compiled dictionaries in dict-dir).
>
> I'm thinking of this, put the path of the source file in the
> multi file after compiled name as a comment. The paths of the
> source files would go in the in use list and would be removed
> from the available list.
The wordlist problem does strip information out, but wouldn't it be better to
hold the subword list "requests" in another area/file rather than within the
dictionary itself?
Suppose you have multiple users in the same family which use the same
computer... each user has their own account and personalities.
Something like this?
Bob the mechanic:
English=yes
mechanical-terms=yes
scientific-terms=no
programming-terms=no
Scientific Sally:
English=yes
mechanical-terms=no
scientific-terms=yes
programming-terms=no
Programming Pete:
English=yes
mechanical-terms=no
scientific-terms=no
programming-terms=yes
> I'm interested in what people think of this idea.
It may be simpler to pass a list of dictionaries to check, or check a default
($home)file holding a list of dictionaries to read, this way not everyone in
the same group is locked into using the same list.
On the other hand, if there is a special group need, it may be worth holding
1 2 or 3 lists such as seen in UNIX file permissions:
personal-list (my own list, plus my language preferences)
group-list (suppose we are all part of architecture firm with drawing words)
other-list (accessible by all?)
My suggestion is to keep the dictionary lists consistent so that you/users
don't end up confusing one type of dictionary for a special multi-dictionary
and you/users use the same routines for all dictionaries versus having
special routines for the special dictionaries.
My suggestion would be to use a different method of inquiring multi
dictionaries, such as a separate text or *.INI type of file in the $home for
personal choices and somewhere in the "/" area for the group choices.
Hope this helps as a suggested direction.