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

gitmoji support. #16

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

gitmoji support. #16

wants to merge 6 commits into from

Conversation

ss1978
Copy link

@ss1978 ss1978 commented Mar 30, 2020

No description provided.

@iFreilicht
Copy link

I like it!

@cspeterson
Copy link
Owner

I am wondering how best to maintain additions like this one and @iFreilicht 's #18

I think things like these are definitely a positive to have collected and maintained, but my initial feeling is that they might not belong directly in the included database.

And if that's the case, should there be a path of databases that are just not included when run without including them specifically? Maybe a separate (sub?)repo? And can anyone think of any other such collections that would be a good idea like these?

I'd like to hear what you guys think. 😀

@iFreilicht
Copy link

I think you do have a point. Especially because people may want to use this to enter other characters as well that may clash with some custom glyphs, and because not everyone has fonts installed that are able to handle these glyphs properly.

Other collections could include unicode arrows, braille symbols, special punctuation, trigrams or box drawing characters.

There's also many unicode blocks for language-specific script like runes, canadian syllabics (which contain some very cool glyphs), Mongolian, Khmer and many more, though I doubt splatmoji's UI would be useful for entering longer sequences of those.

About the solution to handling multiple of these databases, there's two main directions:

All databases and the respective parasers could stay in this base repo, and we could then think about what mechanism to use for specifying which databases to load, whether it's a config file or just the cli arguments. This would keep everything contained in one place and would make the setup easier for users.

If we want to reduce bloat as much as possible, we could make a git submodule like "splatmoji-databases" or so that can contain a huge amount of databases and allows users to either clone all of them or just download the ones they need. With the current way of having each database in its separate folder, you could also have each database as its separate submodule and just clone the ones you want.
This would make working on databases slightly easier, but would become a huge problem if you ever want to change the format ever again. Also, it would mean that you are not in control of those databases and have to rely on other people to maintain and accept pull requests on those.

I would opt for having the databases in this repo, but following the new format you introduced, where each database gets its own folder that can also contain localisations or other variants of that database. This would still allow separating them out into new submodules that could be maintained in new projects whenever this becomes too big to be feasible to maintain in one repo.

I do agree that not all of them should be enabled by default, though for some I don't see much harm (the braille symbols for example).

@iFreilicht
Copy link

@ss1978

Also an option if splatmoji.config could refer to different urls, for the tsv files.
eg:
external_gitmoji=https://raw.githubusercontent.com/ss1978/splatmoji/master/data/gitmoji.tsv

Hm I don't know if that's a good idea. This would add a lot of complexity that I don't really see the use for. If you already know the external URL, it's easy for the user to just wget that into the correct directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants