we're punting default settings of EDITOR and PAGER from baselayout and it's up to people to set it themselves ... but if eselect had a nice way of doing it ...
Hm, a module that stores the variable in env files without any validity check would be trivial. But for "eselect editor list" one would need a list of what are valid editors. Use a hardcoded list, and check if the binary actually exists? Or some config file (like /etc/shells)?
maintaining a complete list is a dead end. just look at the mess we know as virtual/editor-0. what may work is listing the most common/reasonable values, and then letting people enter a free form as "other". in either case, we'd check for existence, but in the "other" case, we just make them confirm ? or just go with "garbage in, garbage out" ? imo, listing nano/emacs/vim should cover the vast majority of users.
Created attachment 188838 [details] editor.eselect (In reply to comment #2) > what may work is listing the most common/reasonable values, and then letting > people enter a free form as "other". Sounds reasonable. Module for EDITOR is attached; comments are welcome. (The PAGER module will be identical, except for the three variables at the very beginning.)
We could also make it free-form and potentially have each editor and potential pager install something to make a list that way we can eventually get rid of the free-form field. Maybe an eclass which can manage a /etc/pagers and /etc/editors of the format. name:/path/to/name vim:/usr/bin/vim eclass functions could be: add-editor vim /usr/bin/vim del-editor vim IMHO, Mike's solution is the best for the near-term and requires little effort for a lot of benefit. In the long term, the above solution might be the best.
yes, that would get almost complete install coverage (getting 100% is never going to happen as we cant assume everything is provided in portage), but imo it's a lot of overhead for negligible return ... if all of 10 people out there are using non-standard values, then having them type in the binary is reasonable. especially because this isnt something that changes every few days. it gets set pretty once per install. as for the list, i would have it use the short names and do a PATH search at runtime. this way moving packages get handled automatically and people can type in the short name w/out full path if they want to use something outside of the default list. code comments: - ${#@} is really weird. just use $# like everyone else. - quoting is inconsistent ... no quotes on LHS inside of [[ ... ]] - pretty sure the `has` usage is incorrect. `has <item> <list>`, not `has <item> "<list>"`. - if return value of do_update is significant, then you cant omit arg to return
(In reply to comment #5) > as for the list, i would have it use the short names and do a PATH search at > runtime. this way moving packages get handled automatically and people can > type in the short name w/out full path if they want to use something outside > of the default list. It displays the full names, but does a PATH search if you give a short name as input. So, "eselect editor set emacs" will work. > code comments: > - ${#@} is really weird. just use $# like everyone else. > - quoting is inconsistent ... no quotes on LHS inside of [[ ... ]] > - pretty sure the `has` usage is incorrect. `has <item> <list>`, > not `has <item> "<list>"`. Fixed these, thanks. > - if return value of do_update is significant, then you cant omit arg > to return Hm, not sure about this one. The return is taken if the current setting is already valid. I think that it should return a good status in this case? Current version is in SVN trunk. emerge app-admin/eselect-9999 for testing. Another question: Do we have any conventions what to use for the number of the config file? Are "99editor" and "99pager" o.k.? (The OpenRC migration guide mentions "99editor".)
Modules are included in eselect-1.1_rc1.
Nice job, Ulrich. Thanks for this.
