unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* ASPELL_CONF isn't honored by the 'aspell_provider_list_dicts' function of enchant
@ 2016-04-25 15:15 宋文武
  2016-04-25 22:20 ` Kevin Atkinson
  0 siblings, 1 reply; 2+ messages in thread
From: 宋文武 @ 2016-04-25 15:15 UTC (permalink / raw)
  To: aspell-devel; +Cc: guix-devel

Hi!  I have some problems to package gspell for GNU Guix, and I think it's
the issue of aspell...

In Guix, aspell and every dict are installed in seperated directory (prefix),
and then symlink together into a profile.  We have wraped the aspell
executable with `ASPELL_CONF=dict-dir $HOME/.guix-profile' to let it
finding dicts:
  <http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/aspell.scm#n110>

But the GNOME gspell, which is a GObject API wrapper upon enchant,
uses 'aspell_provider_list_dicts' (similiar to the list-dicts.c example)
to find all aspell dicts, where the ASPELL_CONF variable is not honored
at all.  Even with dicts avaliable in the dict-dir specidied by ASPELL_CONF,
gspell reports none.

The list-dicts example have this issue too.  shouldn't the default
AspellConfig returned by new_aspell_config honor ASPELL_CONF?
Or, maybe there are better way to handle dict localtions?
I'd be very happy to use a variable like ASPELL_DICT_DIRS :-)

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: ASPELL_CONF isn't honored by the 'aspell_provider_list_dicts' function of enchant
  2016-04-25 15:15 ASPELL_CONF isn't honored by the 'aspell_provider_list_dicts' function of enchant 宋文武
@ 2016-04-25 22:20 ` Kevin Atkinson
  0 siblings, 0 replies; 2+ messages in thread
From: Kevin Atkinson @ 2016-04-25 22:20 UTC (permalink / raw)
  To: 宋文武; +Cc: guix-devel, aspell-devel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1408 bytes --]

Hi,

I fail to see how this is an issue with Aspell.  It looks like more of an 
issue with enchant.  Is there something Aspell can be doing differently?

Thanks,
Kevin Atkinson
Maintainer of Aspell



On Mon, 25 Apr 2016, 宋文武 wrote:

> Hi!  I have some problems to package gspell for GNU Guix, and I think it's
> the issue of aspell...
>
> In Guix, aspell and every dict are installed in seperated directory (prefix),
> and then symlink together into a profile.  We have wraped the aspell
> executable with `ASPELL_CONF=dict-dir $HOME/.guix-profile' to let it
> finding dicts:
>  <http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/aspell.scm#n110>
>
> But the GNOME gspell, which is a GObject API wrapper upon enchant,
> uses 'aspell_provider_list_dicts' (similiar to the list-dicts.c example)
> to find all aspell dicts, where the ASPELL_CONF variable is not honored
> at all.  Even with dicts avaliable in the dict-dir specidied by ASPELL_CONF,
> gspell reports none.
>
> The list-dicts example have this issue too.  shouldn't the default
> AspellConfig returned by new_aspell_config honor ASPELL_CONF?
> Or, maybe there are better way to handle dict localtions?
> I'd be very happy to use a variable like ASPELL_DICT_DIRS :-)
>
> _______________________________________________
> Aspell-devel mailing list
> Aspell-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/aspell-devel
>
>

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Aspell-devel mailing list
Aspell-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/aspell-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-04-25 22:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-25 15:15 ASPELL_CONF isn't honored by the 'aspell_provider_list_dicts' function of enchant 宋文武
2016-04-25 22:20 ` Kevin Atkinson

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).