[Cuis-dev] Making Cuis Unicode-only and VectorGraphics-only. (was Re: Alternative arrows)

Tue Oct 18 23:57:55 PDT 2022

Oh, I see now that you were suggesting removing support for $_ but not for
$^. So for $^ I guess we could use the syntax highlighter to show a
preferred arrow. But can we do that for a substring of two characters like
‘:=‘? If we can, we could also do the same for ‘>=‘, ‘<=‘, etc, almost like
ligatures…

On Wed, 19 Oct 2022 at 12:23 Luciano Notarfrancesco <luchiano at gmail.com>
wrote:

> Hi Juan,
> I like the idea to make everything Unicode and get rid of old code!
>
> About removing support for $^ and $_ I’m not so sure… depends how we do
> it. The first question that comes to my mind is how are we going to input
> other arrows for assignment and for return. The LaTeX commands like \oplus
> are very convenient for my math stuff, but seem too much typing for
> something that we can do with one keystroke (two keys actually with SHIFT).
> Also, I see that removing support for assignment with $_ has the benefit of
> making available that character for something else, but removing support
> for $^ doesn’t seem to bring any benefits (since we can already use it as
> binary selector).
>
> Probably you gave more thought to this, and I’d like to know. In the
> meantime I throw this idea: get rid of $_, in the actual source and changes
> files use ‘:=‘ and $^, and make the syntax highlighter show assignment and
> return as any Unicode that the user chooses (with some arrows as default).
> Does this make sense? I’m not sure how this would work when you save a
> method that was syntax highlighter, do we need to convert back the Unicode
> arrows to ‘:=‘ and $^ ? It we never insert real Unicode arrows in the text
> and just display them with the arrow glyphs, like we do with useST80Glyphs?
>
>
> On Wed, 19 Oct 2022 at 02:02 Juan Vuletich via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> Hi Luciano,
>>
>> I also think it would be good to make this configurable. It is also bad
>> that I hardcoded this in the plugin, making it harder to change.
>>
>> Still, this opens a different discussion. Something I have been thinking
>> about, but hadn't talked about in the list.
>>
>> Now that the VectorEnginePlugin is in the official VMs, it means we can
>> count on it. So, what I want to do is to make the "Use Unicode" preference
>> the default and only behavior, and actually remove support for ISO 8859
>> files (and StrikeFonts, and a lot of the older stuff). And if everything is
>> Unicode, then there's no need to have these special glyphs for $_ and $^.
>> We could use instead a real Unicode left arrow for assignment, and just
>> remove support for $_ for assignment. (Using := would still be possible).
>> All this "Smalltalk-80 glyphs" kludge would go away.
>>
>> What do you think?
>>
>> If we decide to go in this direction, it may make sense to temporarily
>> disable the "Smalltalk-80 glyphs", at least if you want to use the Unicode
>> arrows for something else.
>>
>> Opinions?
>>
>> On 10/17/2022 6:20 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>>
>> Perhaps instead of the useST80Glyphs boolean in Tahoe displayUtf32:
>> method we could pass a translation table, a WordArray with pairs of code
>> points to replace when displaying. Juan, what do you think?
>>
>> On Mon, 17 Oct 2022 at 13:06 Luciano Notarfrancesco <luchiano at gmail.com>
>> wrote:
>>
>>> I changed those methods but still couldn’t get it to work. Now I see
>>> this is hardcoded in the VectorEngine plugin. Juan, could we make this
>>> configurable?
>>>
>>> On Mon, 17 Oct 2022 at 04:23 Gerald Klix <cuis.01 at klix.ch> wrote:
>>>
>>>> On 16.10.22 22:54, Luciano Notarfrancesco wrote:
>>>> > I don’t mean to change the current behavior. I just would like that
>>>> the
>>>> > user could easily choose the code points of the glyphs to be used for
>>>> those
>>>> > characters. Right now they are hardcoded in TTFFontReader and
>>>> VectorEngine.
>>>> > As a preference they would be more flexible, but I can just change
>>>> those
>>>> > methods in my image for now. I’m using all DejaVu Sans and the thick
>>>> arrows
>>>> > look nice.
>>>> Yes, that was my initial impression; I even started
>>>> to write an encouraging E-mail.
>>>> Then I tried some other fonts and discovered that the fonts
>>>> mentioned below do not have the necessary glyphs.
>>>>
>>>> Perhaps a dictionary that maps the font-name to code-point
>>>> substitution mapping, would be a general solution.
>>>> Actually we also have to look at the syntactic context ...
>>>>
>>>> Anyway, I like the thicker arrows that DejaVu provides
>>>> and I am willing to help to find a solution.
>>>> >
>>>> > On Mon, 17 Oct 2022 at 03:38 Gerald Klix <cuis.01 at klix.ch> wrote:
>>>> >
>>>> >> Luciano,
>>>> >>
>>>> >> I see your problem,
>>>> >> but these Characters only have glyphs in the
>>>> >> DejaVu, JetBrainsMono, KiwiMaru and KurintoSans fonts.
>>>> >>
>>>> >> To make this work properly, we need some means
>>>> >> to discover the aforementioned situation
>>>> >> and switch back to the current behavior.
>>>> >>
>>>> >>
>>>> >> Sorry and HTH,
>>>> >>
>>>> >> Gerald
>>>> >>
>>>> >>
>>>> >> On 06.10.22 12:55, Luciano Notarfrancesco via Cuis-dev wrote:
>>>> >>> What do you think about adding two preferences to set the unicode
>>>> >>> characters to be used for displaying ^ and _? The problem I’m
>>>> having is
>>>> >>> that the arrows that we currently use are the same that are
>>>> commonly used
>>>> >>> in mathematics for morphisms, and the code gets a bit confusing in
>>>> my
>>>> >>> system, so I’d like to use the thick arrow 16r2B05 for _ and
>>>> 16r2B06 for
>>>> >> ^,
>>>> >>> and to avoid annoying people who like the current arrows I think we
>>>> could
>>>> >>> make this a preference. Is this reasonable?
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>>
>>
>> --
>> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20221019/5758c580/attachment-0001.htm>