Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try harder to use the correct indefinite article (a/an) in messages to the user #3400

Closed
wilfwilson opened this issue Apr 10, 2019 · 6 comments
Labels
kind: discussion discussions, questions, requests for comments, and so on kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements topic: error handling

Comments

@wilfwilson
Copy link
Member

wilfwilson commented Apr 10, 2019

Sorry that this is a vague issue, perhaps the scope should be narrowed, feel free to edit this to something more actionable. But I wanted to make an issue while I still remembered. Some messages to the user in GAP, such as the following one (produced by RequireArgumentEx), use the wrong article:

Error, Field Setter: <data> must be a small integer (not a empty plain list)

To be clear, 'a empty' should be 'an empty'. Although it's not a huge problem, it still doesn't give the best impression of GAP, so I think we should attempt to improve the situation.

@fingolfin suggested a (partial?) solution in a comment on #3994. What does anyone think? I can think of the following steps:

  • Identify where this might occur in GAP (Perhaps RequireArgument is the only place where this happens now? @fingolfin said that he's been trying to solve this problem).
  • Decide how far we are willing to go to choose the most appropriate article.
  • Implement that.
@wilfwilson wilfwilson added kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements kind: discussion discussions, questions, requests for comments, and so on topic: error handling labels Apr 10, 2019
@ChrisJefferson
Copy link
Contributor

Looking around, there are quite a few place where we print "a %s", where %s is set to TNAM_OBJ (usually, but not always as part of a "(not a %s)".

Therefore I'm tempted to suggest a new function, TNAM_OBJ_WITH_ARTICLE (that's a horrible name), which returns TNAMs with the article included.

@ChrisJefferson
Copy link
Contributor

ChrisJefferson commented Apr 11, 2019

A better option might be to add a modifier to '%s', say '%as', which makes it attach 'a/an' as a prefix.

@wilfwilson
Copy link
Member Author

Yes, perhaps introducing %as and putting the logic behind there would be a nice solution.

@fingolfin
Copy link
Member

I am not so sure about %as being a good solution at this point. Perhaps if we identify more places where this would be used. But note that providing a fully generic solution that can be used to print arbitrary stuff is highly non-trivial, as there are a ton of exceptions for the use of "a" vs. "an". To get an idea of what is needed, see e.g. here: https://github.com/rossmeissl/indefinite_article/blob/master/lib/indefinite_article.rb

Whereas for TNUMs, we have a fixed list of <= 256 entries, and we only need to make sure the articles are correct for those. That's a much simpler problem.

So I'd really start with that, and if we then determine that we really need article inflection in more places, then we can look into a more generic solution.

@fingolfin
Copy link
Member

In master we are down to four occurrences of (not a %s) in the kernel, so this is mostly resolved now, I think.

@wilfwilson
Copy link
Member Author

I had a look at the remaining ones, and I think I'm happy with closing this issue. (I didn't create the issue as "Always use the correct indefinite article"!)

Thanks for your work on this Max.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: discussion discussions, questions, requests for comments, and so on kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements topic: error handling
Projects
None yet
Development

No branches or pull requests

3 participants