[Cuis-dev] Fix for VectorCanvas>>#image:at:

Fri Jun 2 08:28:01 PDT 2023

Ah, great, I’m trying a mix of both approaches: I enclose it in double
quotes and add a dot at the end, and also set the color to the default text
color so shout doesn’t color it as a comment. I’ll use it like this for a
while and see how it feels, and see if there are still any problems with
coloring or underscores.

Thanks!
Luciano

On Fri, 2 Jun 2023 at 16:31 Juan Vuletich <juan at cuis.st> wrote:

> My previous answer is completely wrong, because I conflated two issues you
> raised.
>
> Your solution works well to avoid styling the result of a printIt as if it
> was Smalltalk code. But it doesn't address the other issue you raised, that
> is, after that point, the styling of the rest of the workspace is messed up.
>
> My suggestion (modifying #printIt to enclose the result in double quotes)
> actually addresses both issues: comments are not styled, and smalltalk code
> after them is styled correctly. Maybe we'd push this instead? Perhaps we'd
> also tweak the style so it doesn't look like comments, but the main point
> is that parsing will be correct afterward. We could also add a dot after
> the comment, maybe that makes Shout happier in case you forgot to type it.
>
> The real fix would be to shout from scratch after 2 empty lines. That was
> the intended behavior some time ago, and it works for coloring but not for
> assignment arrows. Fixing this is a bit more complicated. so I'd sugges
> opening an issue on GitHub so we don't forget.
>
> Thanks,
>
>
> On 6/2/2023 11:36 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>
> Last week I did the change to enclose printIt output in double quotes, and
> I used it like that for a couple of days. I didn’t really like it, but
> perhaps I’m just not used to it. It colored the printIt output with the
> gray color that I use for comments, and for some reason it didn’t feel
> right to me.
>
> Another thing that seems to cause problems with highlighting is my habit
> of neglecting to type the last dot in the last sentence, because it’s
> optional in Smalltalk and I never type it… but then it confuses the syntax
> highlighter, even if I leave several empty lines between fragments of code,
> it seems.
>
> It’s weird that my change doesn’t work for you. I just tried it in the
> latest image and it doesn’t seem to work, but it works in my project image
> and I can’t figure out why it fails in the stock image. See the attached
> change set. I guess it would be more correct to change
> TextColor>>dominates: adding "or: [other isForShout and: [self isForShout
> not]]", or something like that... but still, why doesn't it work? If some
> part of the text has attributes that dominate over shout attributes it
> shouldn't change them, right? Is this a bug?
>
> BTW, I'm not pushing to adopt my change, I don't know yet what's the best
> solution.
>
>
> On Fri, 2 Jun 2023 at 15:23 Juan Vuletich <juan at cuis.st> wrote:
>
>> Please see inline.
>>
>> On 6/2/2023 10:09 AM, Juan Vuletich via Cuis-dev wrote:
>>
>> I couldn't get that idea to work. Would you attach a changeset?
>>
>> In any case, another simple but maybe less comfortable solution is to
>> enclose the result in double quotes, making it comment.
>>
>> Thanks,
>>
>>
>> Of course the above is completely wrong, because I conflated two issues
>> you raised.
>>
>> Your solution works well to avoid styling the result of a printIt as if
>> it was Smalltalk code. But it doesn't address the other issue you raised,
>> that is, after that point, the styling of the rest of the workspace is
>> messed up.
>>
>> My suggestion (modifying #printIt to enclose the result in double quotes)
>> actually addresses both issues: comments are not styled, and smalltalk code
>> after them is styled correctly. Maybe we'd push this instead?
>>
>>
>> Thanks,
>>
>>
>> On 6/2/2023 7:23 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>>
>> Oh, just after sending this email I gave it another try and found a
>> simple solution. In SmalltalkEditor>>#printIt I set the color of the output
>> text to Theme current text, and I changed TextColor>>dominates: adding “or:
>> [other isForShout]”. That’s all :)
>>
>> On Fri, 2 Jun 2023 at 11:59 Luciano Notarfrancesco <luchiano at gmail.com>
>> wrote:
>>
>>> I’ve been thinking how to prevent the printIt output to be syntax
>>> highlighted. I think it’s best to do that because the output is not
>>> Smalltalk code, so the syntax highlighter gets it almost always wrong. It
>>> could be a preference, or it could be specified in the printOn: methods
>>> that know that the output is not Smalltalk code. What do you think? How
>>> would you implement it? A new text attribute makes sense to you or do you
>>> have any other idea?
>>>
>>> On Thu, 1 Jun 2023 at 20:53 Luciano Notarfrancesco <luchiano at gmail.com>
>>> wrote:
>>>
>>>> Oh, that’s great, using subpixel antialiasing just solved the problem!
>>>> Thanks!
>>>>
>>>> I’ll try NeoEuler. It would be nice to have fallback fonts too… some
>>>> math glyphs are missing in DejaVu… but it’s not a big deal. Another minor
>>>> aesthetic problem is that the syntax highlighter sometimes gets confused
>>>> with the output of printIt, perhaps would be better to not apply syntax
>>>> highlighting to the output, or to have the option to “lock” the output text
>>>> in some printOn: methods so that the syntax highlighter doesn’t change it
>>>> (perhaps a new attribute? not sure if this makes sense). Also sometimes the
>>>> underscores are not converted to arrows in a workspace, perhaps this is
>>>> related to the syntax highlighter getting confused.
>>>>
>>>> Thanks!
>>>> Luciano
>>>>
>>>> On Thu, 1 Jun 2023 at 17:42 Juan Vuletich <juan at cuis.st> wrote:
>>>>
>>>>> Hi Luciano,
>>>>>
>>>>> On 5/30/2023 9:06 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>>>>>
>>>>> BTW, in case anyone is curious, here is how matrices look when
>>>>> printing them on a workspace with cmd-p. I draw matrices over the binary
>>>>> field in a special way (first screenshot), and I scale them down if they
>>>>> are too big.
>>>>> I did this because it was hard to make matrices look good when
>>>>> printing them as text, so instead I draw them on a form and embed the form
>>>>> when printing them. I only do this with matrices, they are especially
>>>>> problematic when printing because they print with more than one line, they
>>>>> are the only objects in my system that need more than one line for
>>>>> printing. When I printed them as text with more than one line, printing a
>>>>> list of matrices (for example an array of matrices, as in the example where
>>>>> I print a basis of a vector space in the screenshots) they would look
>>>>> horrible. Now a list of matrices is printed in a single line as expected,
>>>>> and the point size of the enclosing parentheses is adjusted automatically
>>>>> (I have messages Stream>>#withParentheses:, #withBrackets:,
>>>>> #withAngleBrackets:, etc, that do this automatically).
>>>>>
>>>>>
>>>>> It looks beautiful!
>>>>>
>>>>> I still have two little problems that I might want to tweak:
>>>>> 1) the parentheses are too thick, setting the point size is not the
>>>>> right thing to do, maybe we need a new text attribute for scaling text
>>>>> without changing the point size?;
>>>>>
>>>>>
>>>>> The easiest solution is to use a different font, just for the
>>>>> parentheses. For example, NeoEuler parentheses are much lighter at large
>>>>> point sizes.
>>>>>
>>>>> 2) matrices inside matrices loose the transparent background, the
>>>>> background becomes black, as you see in the example in the second
>>>>> screenshot.
>>>>>
>>>>>
>>>>> I guess this should be fixable. If you can prepare an image with such
>>>>> example for me to play with, I'll give it a try. For example (not sure if
>>>>> related) VectorEngine can do blending over translucent backgrounds, but
>>>>> only if subpixel sampling is used. I know, there is no relation between
>>>>> these two features... But I wanted to keep options to a small number, and
>>>>> usually we only use cheaper whole pixel AA and cheaper alpha blending that
>>>>> can't blend over translucent backgrounds. So, maybe just using the SubPixel
>>>>> engine solves this problem, or I'll be happy to take a look.
>>>>>
>>>>>
>>>>> On Tue, May 30, 2023 at 7:27 PM Luciano Notarfrancesco <
>>>>> luchiano at gmail.com> wrote:
>>>>>
>>>>>> This change set fixes a little bug in VectorCanvas that cames up when
>>>>>> using the canvas to draw text with images on a form (outside morphic). I do
>>>>>> this to draw matrices, and when drawing a matrix whose coefficients are
>>>>>> also matrices this came up. The fix is simply checking that the world is
>>>>>> not nil.
>>>>>>
>>>>>
>>>>> Integrated and at GitHub. Thanks!
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>
>> --
>> 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
>>
>>
>>
>> --
>> 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
>>
>>
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230602/d1aff4bd/attachment-0001.htm>