New ligatures request [VERBOSE], # VERBOSE.

[ElonPark]

Hello, first of all, thanks for the great fonts,
I am making and using a logger, in xcode
like this:

// default level string
enum Level: String {
    case verbose = "📢 [VERBOSE]"
    case debug = "🛠 [DEBUG]"
    case info = "💡 [INFO]"
    case warning = "⚠️ [WARNING]"
    case error = "🚨 [ERROR]"
}

and it looks like this:

As you can see, only [VERBOSE] does not apply Rigature.
Can you add [VERBOSE], # VERBOSE like existing ligatures?

my logger here.
https://github.com/ElonPark/EPLogger

thanks for reading

[fabrizioschiavi]

Thanks @ElonPark for this request!
I just added in my Todo list

[amerlyq]

I'm not against adding more ligatures, but @ElonPark , my extensive experience with embedded screams it's not the right thing to do for logging facility. Because you impose personal restrictions and quirks of only the temporary favor and importance onto something, which must be as simple and straightforward as possible. It may look nice for logs of screen worth but very tiring for longs in thousands and hundreds of thousands lines -- I talk both about ligatures and pictograms.
But whatever, try your best, maybe it will be worth it for at least some usecase.

[nomasprime]

These ligatures should be removed. Stopped using ligature variant of the font because it creates too many edge cases and undesirable output.

[Shedward]

I actually want to add to this topic. Those ligatures can create a problems in some languages where things like [Error] or [error] have some meaning.

For example in Swift I might want to use an array of errors with code like this

func errorsExample() -> [Error] {
    var errors: [Error] = []

    if let error = makeSingleError() {
        errors = [error]
    } else {
        errors = makeMultipleErrors()
    }
    return errors
}

which with Pragmata Pro will create this output

Not only it just looks weird, it also erases difference between type and value.

@fabrizioschiavi Is there any way to manually rebuild font without this feature by default?
I didn't find a way to configure open type features in Xcode.

[ElonPark]

I actually want to add to this topic. Those ligatures can create a problems in some languages where things like [Error] or [error] have some meaning.

For example in Swift I might want to use an array of errors with code like this

func errorsExample() -> [Error] {
    var errors: [Error] = []

    if let error = makeSingleError() {
        errors = [error]
    } else {
        errors = makeMultipleErrors()
    }
    return errors
}

which with Pragmata Pro will create this output

Not only it just looks weird, it also erases difference between type and value.

@fabrizioschiavi Is there any way to manually rebuild font without this feature by default?
I didn't find a way to configure open type features in Xcode.

How about this

func errorsExample() -> Array<Error> {
    var errors = Array<Error>()

    if let singleError = makeSingleError() {
        errors = [singleError]
    } else {
        errors = makeMultipleErrors()
    }
    return errors
}

[fabrizioschiavi]

Wow! Thank you friends, I must adjust it absolutely. Ligatures can't become an obstacle to coding.

[nomasprime]

Originally thought these ligatures were a nice idea so I raised an issue to get them working in iTerm: alphanumeric ligatures weren't rendered for performance reasons.

But, like I said before, these alphanumeric ligatures just have too many edge cases and are generally too problematic for serious programmers. If you're willing to mainain another variant, a compromise would be to have two ligature variants: one standard and another standard plus alphanumeric ligatures.

Personally I don't use ligatures at all anymore:

• All the above
• They make motions, especially in Vim, unnecessarily difficult
• General performance cost too high

I can understand why standard ligatures might be nice or useful for specialised use cases but these alphanumeric ligatures just seem superfluous to me.

PS Thank you @fabrizioschiavi for such a great font 👏