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

Add musical symbols for unicode completions #54182

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

Conversation

NeroBlackstone
Copy link

I found that julia was missing some useful music notation unicode completions and sometimes had to copy and paste these unicodes to use the published package.

So I picked out some unicode music symbols that might be useful, named from the unicode standard.

I didn't add the test, I don't think it's necessary.

Thanks for reviewing. Please reply if any changes are needed.

@kimikage
Copy link
Contributor

I am fine with this PR being merged, but I think we need to consider the original meaning of the completion.

julia> \two # TAB
\twocaps                \twocups                \twoheaddownarrow
\twoheadleftarrow       \twoheadleftarrowtail   \twoheadleftdbkarrow
\twoheadmapsfrom        \twoheadmapsto          \twoheadrightarrow
\twoheadrightarrowtail  \twoheaduparrow         \twoheaduparrowcircle
\twonotes

Wouldn't it be better to extend what is used in a particular field with a particular package?

@NeroBlackstone
Copy link
Author

I am fine with this PR being merged, but I think we need to consider the original meaning of the completion.

julia> \two # TAB
\twocaps                \twocups                \twoheaddownarrow
\twoheadleftarrow       \twoheadleftarrowtail   \twoheadleftdbkarrow
\twoheadmapsfrom        \twoheadmapsto          \twoheadrightarrow
\twoheadrightarrowtail  \twoheaduparrow         \twoheaduparrowcircle
\twonotes

Wouldn't it be better to extend what is used in a particular field with a particular package?

Agree. My question is, is it possible to extend Unicode completion using a third party package?

@kimikage
Copy link
Contributor

kimikage commented Apr 22, 2024

My question is, is it possible to extend Unicode completion using a third party package?

I believe you got the solution.
https://discourse.julialang.org/t/how-to-custom-unicode-completions/113304/3

Something like:

module MusicalSymbolCompletions

import REPL

function __init__()
    isdefined(REPL, :REPLCompletions) || return
    isdefined(REPL.REPLCompletions, :latex_symbols) || return
    REPL.REPLCompletions.latex_symbols["\\dflat"] = "𝄫"
end

end

@NeroBlackstone
Copy link
Author

My question is, is it possible to extend Unicode completion using a third party package?

I believe you got the solution. https://discourse.julialang.org/t/how-to-custom-unicode-completions/113304/3

Something like:

module MusicalSymbolCompletions

import REPL

function __init__()
    isdefined(REPL, :REPLCompletions) || return
    isdefined(REPL.REPLCompletions, :latex_symbols) || return
    REPL.REPLCompletions.latex_symbols["\\dflat"] = "𝄫"
end

end

Nice! I will respect the maintainer's decision whether or not to merge this pull request. Or just pick a few to merge. Feel free to merge or close this pull request.

@stevengj
Copy link
Member

It's cool that Unicode has all of these symbols, but if we want to add some more to base (not to a package) perhaps we should limit the additions to a few of the most common and well-known symbols.

@LilithHafner
Copy link
Member

LilithHafner commented Apr 22, 2024

I don't love that we have our own custom mapping from strings to unicode characters. It is not friendly to users who switch between Julia and other programs that define similar though not identical mappings.

Given that we do have this mapping, I think we should

  1. Continue to add common characters to it as requested (merge this PR)
  2. Support all Unicode symbols by official name (e.g. \MUSICAL_SYMBOL_SINGLE_BARLINE)
  3. Try to find and adopt a canonical mapping from strings to characters that is more ergonomic than unicode (e.g. latex?)

@NeroBlackstone
Copy link
Author

NeroBlackstone commented Apr 22, 2024

It's cool that Unicode has all of these symbols, but if we want to add some more to base (not to a package) perhaps we should limit the additions to a few of the most common and well-known symbols.

Strongly agree, unicode completions in the REPL should be representative and reduce uncommon symbols. I have removed Mensural notation and Gregorian notation because they are rarely used.
I believe the updated list contains the most commonly used Unicode symbols in modern music notation.
If you think we need to pare it down further, I can go ahead and pick out more common musical symbols.

Copy link
Member

@LilithHafner LilithHafner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cross checked this PR (at a3ad268) against https://www.unicode.org/charts/nameslist/c_1D100.html and found no typos or mistranscriptions.

One inconsistency is musicalbreve vs musicbrace/musicbracket. We should use a single prefix: either music or musical, I don't have much preference for which. Music is shorter, and this is for user input type once read never. Musical is the term unicode uses.

Some additional characters that may warrant the music(al) prefix:

"\\tr"=>"𝆖",
"\\turn"=>"𝆗",
"\\invertedturn"=>"𝆘",
"\\turnslash"=>"𝆙",

That said, I couldn't (after a brief search) find any other unicode characters that could plausibly be called "tr" or "turn" (with the possible exception of "turnstyle" ⊢.

@NeroBlackstone
Copy link
Author

Some additional characters that may warrant the music(al) prefix:

"\\tr"=>"𝆖",
"\\turn"=>"𝆗",
"\\invertedturn"=>"𝆘",
"\\turnslash"=>"𝆙",

I have added "music" prefix for these symbols.

Another change is barline:

        # Bars
    "\\musicsinglebarline"=>"𝄀",
    "\\musicdoublebarline"=>"𝄁",
    "\\musicfinalbarline"=>"𝄂",
    "\\musicreversefinalbarline"=>"𝄃",

I think these symbols may easily confuse users, and it must be noted that they are symbols specifically representing musical notation, so I add "music“ prefix

change naming

Co-authored-by: Lilith Orion Hafner <lilithhafner@gmail.com>
Copy link
Member

@LilithHafner LilithHafner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@LilithHafner LilithHafner added the merge me PR is reviewed. Merge when all tests are passing label Apr 22, 2024
@NeroBlackstone
Copy link
Author

In consideration of the controversy, I once again removed some symbols that were difficult to read or confusing. Only key symbols such as Accidentals, Codas, Clefs, Rests, Notes are retained.

@LilithHafner LilithHafner removed the merge me PR is reviewed. Merge when all tests are passing label Apr 23, 2024
@LilithHafner
Copy link
Member

@topolarity, does this seem reasonable to you in its current state?

@topolarity
Copy link
Member

Maybe this is worth sending to triage for more feedback?

I'm significantly happier with the latest version, but many glyphs are still difficult to read/distinguish and I think this is something of a departure from the conventions for Unicode completions so far (which are mostly math symbols/letters, exponents, etc.)

@LilithHafner LilithHafner added the triage This should be discussed on a triage call label Apr 24, 2024
@LilithHafner
Copy link
Member

a departure from the conventions for Unicode completions so far (which are mostly math symbols/letters, exponents, etc.)

As Julia's usage extends outside of math, IMO it makes sense to expand Unicode completions.

@stevengj
Copy link
Member

stevengj commented Apr 24, 2024

We have all the emoji, too… I'm inclined to be permissive with any symbol that a large number of people might reasonably recognize and use (excluding language-specific symbols that have their own input methods already), and the common music symbols certainly qualify.

@NeroBlackstone
Copy link
Author

Considering that REPL Unicode completion can be extended through third-party packages, I'm actually neutral on whether this PR will be merged or not.

If adding a lot of music symbols is considered too radical, I think it would be acceptable to just add Accidental to provide basic support for MusicTheory.jl.

But I still believe that other musical Unicode symbols can bring potential benefits.

@LilithHafner
Copy link
Member

@tecosaur has a link to a latex symbol table that might have some of these. Barring external, conflicting, canonical names for these symbols, triage is happy with this.

In general, this sort of addition is perfectly fine/good.

@LilithHafner LilithHafner removed the triage This should be discussed on a triage call label Apr 25, 2024
@LilithHafner
Copy link
Member

Chapter 7 of https://ctan.org/pkg/comprehensive lists some (all?) latex musical symbols defined across 12 distinct packages with distinct naming conventions. Some arbitrarily chosen examples:

\musDoubleFlat
\musDoubleSharp
\doublesharp
\flatflat
(but not sharpsharp or doubleflat)

\musEighth
\eightNote

\bassclef (not fclef)

\wholeNote
\fullnote
...

Seems eclectic and not possible to follow sensibly.

I'm going to go ahead and merge soon unless anyone thinks there's a problem with this PR in it's current state.

@tecosaur
Copy link
Contributor

Regarding chapter 7 of The LaTeX comprehensive symbols list, it's inconsistent across packages, but the package I think would be worth using as a reference would be lillyglyphs.

Your names are mostly consistent with lillyglyphs, but there are a few differences that I think may be worth drawing attention to:

  • gclef vs clefg, the lillypond package uses clefX instead of Xclef, and with tab completion in mind I think this seems a bit nicer
  • flatflat instead of doubleflat, I'm not sure which is more discoverable, but I think it's worth considering at least
  • having eighthnote and quaver (etc.) be aliases, this seems nice for discoverability if we don't require unique ascii names for unicode chars.

Other than these comments, this PR looks good to me 🙂. Thanks for making it!

@NeroBlackstone
Copy link
Author

Thank you very much for the review and provided a very good reference, but I don't quite agree with the naming of lillyglyphs.

  • gclef vs clefg, the lillypond package uses clefX instead of Xclef, and with tab completion in mind I think this seems a bit nicer

I think gclef is more intuitive, that's how we call it.

  • flatflat instead of doubleflat, I'm not sure which is more discoverable, but I think it's worth considering at least

Same, I think it's important to be consistent with spoken language. I guess no one will call this "flat flat", in reality we would just call it "double flat".

@NeroBlackstone
Copy link
Author

  • having eighthnote and quaver (etc.) be aliases, this seems nice for discoverability if we don't require unique ascii names for unicode chars.

I think the naming of Notes and Rests is still worth discussing, my current naming is to be consistent with the existing quarternote and eighthnote:

"\\quarternote" => "",
"\\eighthnote" => "",

I find a better naming in SMuFL

    "\\rest8th"=>"𝄾",
    "\\rest16th"=>"𝄿",
    "\\rest32th"=>"𝅀",
    "\\rest64th"=>"𝅁",
    "\\rest128th"=>"𝅂",

Obviously SMuFL's naming is more readable, but would be inconsistent with existing naming if adopted.

@NeroBlackstone
Copy link
Author

NeroBlackstone commented Apr 30, 2024

Maybe?

# Music Symbols - Rests
"\\multirest" => "𝄺",
"\\wholerest" => "𝄻",
"\\halfrest" => "𝄼",
"\\rest4th" => "𝄽",
"\\rest8th" => "𝄾",
"\\rest16th" => "𝄿",
"\\rest32th" => "𝅀",
"\\rest64th" => "𝅁",
"\\rest128th" => "𝅂",
# Music Symbols - Notes
"\\musicbreve" => "𝅜",
"\\wholenote" => "𝅝",
"\\halfnote" => "𝅗𝅥",
"\\note4th" => "𝅘𝅥", #U+1D15F
"\\note8th" => "𝅘𝅥𝅮", #U+1D160
"\\note16th" => "𝅘𝅥𝅯",
"\\note32th" => "𝅘𝅥𝅰",
"\\note64th" => "𝅘𝅥𝅱",
"\\note128th" => "𝅘𝅥𝅲",

In this way, newly added Musical Symbols can remain compatible with existing Miscellaneous Symbols.

"\\quarternote" => "", #U+2669
"\\eighthnote" => "", #U+266A

@stevengj
Copy link
Member

The advantage of putting \clefg rather than \gclef is that you can tab-complete \clef<TAB> to get a list of all the clefs. Similarly for \flatflat vs. \doubleflat — the former is more discoverable from tab-completing \flat. Similarly for the \rest8th etc naming from SMuFL.

@NeroBlackstone
Copy link
Author

The advantage of putting \clefg rather than \gclef is that you can tab-complete \clef<TAB> to get a list of all the clefs. Similarly for \flatflat vs. \doubleflat — the former is more discoverable from tab-completing \flat. Similarly for the \rest8th etc naming from SMuFL.

Thanks for reminding me! I didn't notice that Unicode completion only starts from the beginning of the string!
I think I'll take these suggestions, thanks for the heads up.

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.

None yet

7 participants