-
Notifications
You must be signed in to change notification settings - Fork 278
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
to be able to redefine punctuation marks #1645
Comments
It somewhat is (although I'm not sure if having multiple entry points with the same name will make the external one override the internal one, or no guarantee), just write your own meta plugin. Lines 94 to 96 in 53c416f
↓ Lines 92 to 105 in 53c416f
↓ plover/plover/meta/punctuation.py Lines 4 to 15 in 53c416f
Documentation: https://plover.readthedocs.io/en/latest/plugin-dev/metas.html At the moment at worst you can probably write your own plugin and write |
request
I’d like to be able to define new bracket shorthands for punctuation. These are preferably system-specific, so they are defined in the Python file for the system, instead of being hard-coded in Plover.
This flexibility can keep dictionaries clean.
examples
Punctuation-mark definitions can vary across languages, or even dialects. For instance, in France French, a no-break space precedes a question mark, whereas in Québec French, the question mark is attached to the previous word.
If punctuation symbols would be definable per system, a user would be able to define
{?}
as{^ ^} ? {-|}
in a France system and{^} ? {-|}
in a Québec system, while keeping the same French dictionary. An entry like{?} et
could stay unchanged; it would adapt its spacing behaviour to the current system.Furthermore, you could define the full stop to have two spaces after it in some contexts. Or for it not to force a capital letter after it in some contexts. (This writing style is convenient for internal documents, because they can then be case-sensitively searched through, because a word is never affected by a sentence-initial capital letter.)
Lastly, if you like to add a punctuation mark, you could define it once in the system definition, and then easily refer to it in dictionaries. This is convenient for hard-to-type punctuation marks, like the en dash or the em dash; they could have
{--}
as shortcut.alternatives
The alternative would be to put the full definition of e.g. a France-style
{?}
every time in each dictionary entry:{^ ^} ? {-|}
. This is cumbersome, and makes the dictionary less maintainable.implementation idea
A requirement would be that the keys start with
{
and end with}
. I think that an already-used definition like{#control(s)}
should be allowed to be remapped as ‹punctuation›; it is up to the user to choose their preferences. This means that the user’s punctuation definitions have higher priority over other bracket things (macros, key combos, etc.).The text was updated successfully, but these errors were encountered: