[bug#49828] [PATCH 02/20] gnu: minetest: Search for mods in MINETEST_MOD_PATH.

[Leo Prikler]

Hi,

Am Dienstag, den 03.08.2021, 13:10 +0200 schrieb Maxime Devos:
>               (patches (search-patches "Add-environment-variable-
> MINETEST_MOD_PATH.patch"))
This line is a bit long.  Even if might look a little weird, I think
it's better split in three.

> ++    // XXX: for some reason, simply writing
> ++    // Strfnd mod_search_paths (std::string(c_modpath));
> ++    // leads to a compilation error:
> ++    //
> ++    // request for member ‘at_end’ in ‘mod_search_paths’, which is
> of
> ++    // non-class type ‘Strfnd(std::__cxx11::string)
> ++    // {aka BasicStrfnd<char>(std::__cxx11::basic_string<char>)}’
> ++    std::string modpath = std::string(c_modpath);
> ++    Strfnd mod_search_paths(modpath);
Try Strfnd mod_search_paths{modpath}.  The normal bracket style
confuses C++, because it can also be parsed as a function declaration.

> + * core.get_modpath() (possible in async calls)
> +-    * returns path to global modpath
> ++    * returns path to global modpath, where mods can be installed
> ++* core.get_modpaths() (possible in async calls)
> ++    * returns list of paths to global modpaths, where mods have
> been installed
> ++
> ++      The difference with "core.get_modpath" is that no mods should
> be installed in these
> ++      directories by Minetest -- they might be read-only.
This is a somewhat weird interface imo.  I think core.get_modpath
should be the first element of core.get_modpaths and documented in that
way, so that any GUI that deals with "all known mods" needs to simply
call the latter, whereas any GUI that deals with installing can
comfortably use either the former or whatever Lua has for car.  WDYT?

Otherwise LGTM.