R# fails to display bulb, Alt-Enter does nothing right of column 75

Jeremy,

I can't reproduce anything that you have a problem with. I rarely ever break my code into multiple lines so long statements way beyond column 75 are the norm for me. RS4 reacts well to all of them that I've looked at. The version I'm running on VS.Net 2008 is 4.0.819.19.

Interesting. I can reproduce this on at least three machines. I wonder what the pattern might be, and it is surely going to have to be something configuration related, seeing as you're not seeing the problem. Thanks for posting up your results!

If there's anyway you can zip and copy your RS configuration file I'll be happy to test it on my machine at work. I mention that because I use the same configuration file at home and I know for sure I've never had a problem like yours. I'd know soon enough if your configuration file contains something specific.

Jeremy,

You are absolutely right! When I said I could not replicate your problem it's because I don't get the problem on the same column number as you.

I've attached two screenshots showing that I can reproduce the same problem but in my case it's at the transition between columns 87 and 88. Upto column 87, the bulb is shown but from 88 onwards the bulb disappears and that's the last I see of it until I scroll back to column 87 and lower. It's possibly not relevant but the only item in the bulb list is the invitation to split the string.

Peter.

I can reproduce it in a simple project like this:

1. Create a new DOS console application in .Net (I'm using 2008).
2. Create this line of code:

string x = "***************************************************"; // Add lots and lots of characters between the quotes.

3. Position the caret and scroll along one character at a time in. In my case, the bulb blows at the transition from column 87 to 88. In other words, it does not appear to be related to the complexity of the project source. That's why I thought I'd try it with a new solution and very minimal code.

I've searched my RS configuration settings and I can't find anything that might cause it to happen.

The problem occurs if you do use non-True-Type font in the editor.

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Peter Hamilton-Scott" <no_reply@jetbrains.com> wrote in message
news:1699592.92401215506260548.JavaMail.jive@app4.labs.intellij.net...

Jeremy,

>

You are absolutely right! When I said I could not replicate your problem
it's because I don't get the problem on the same column number as you.

>

I've attached two screenshots showing that I can reproduce the same
problem but in my case it's at the transition between columns 87 and 88.
Upto column 87, the bulb is shown but from 88 onwards the bulb disappears
and that's the last I see of it until I scroll back to column 87 and
lower. It's possibly not relevant but the only item in the bulb list is
the invitation to split the string.

>

Peter.

Eugene,

My apologies if I misunderstand your reply but I was not sure if you were implying a question or making a statement. The reason I write that is that I changed .Net's font from the FixedSys I usually use to Courier. Both types of fonts are fixed width. I then changed to a proportional font, such as Arial. In all three cases the same problem is evident and the only difference is the column number where you 'lose' the bulb. In my Control Panel -> Fonts the vast majority, 99.8%, are TrueType fonts and the exceptions are types that I would never use for editing. Did I misinterpret your reply?

Peter.

Sorry for the inconvenience,
I've said that ReSharper has problems if the editor use non-TrueType font.

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Peter Hamilton-Scott" <no_reply@jetbrains.com> wrote in message
news:2178777.93661215520330864.JavaMail.jive@app4.labs.intellij.net...

Eugene,

>

My apologies if I misunderstand your reply but I was not sure if you were
implying a question or making a statement. The reason I write that is that
I changed .Net's font from the FixedSys I usually use to Courier. Both
types of fonts are fixed width. I then changed to a proportional font,
such as Arial. In all three cases the same problem is evident and the only
difference is the column number where you 'lose' the bulb. In my Control
Panel -> Fonts the vast majority, 99.8%, are TrueType fonts and the
exceptions are types that I would never use for editing. Did I
misinterpret your reply?

>

Peter.

Ding, ding, ding! We have a winner. I'm using Dina, and for readability reasons (after trying dozens of fonts) won't be changing any time soon. So, the real question now is:

When will R# fix this bug? ;)

Jeremy,

What is Dina? A font? I don't have such a beast on my laptop. What makes it so unique in your experience?

Dina is a raster font designed specifically for programming. It is one of many (without even counting more general fonts that happen to be good for programming), and as with many visual issues is highly subject to personal preferences. I've been using Dina for years now and stop to look at the programming font landscape at least once each year to try out some new and/or updated ones but always end up back at Dina. YMMV, of course. ;)

Eugene, my apologies for making such heavy going of this but I'm still puzzled. I downloaded the Dina font that Jeremy uses and that's a raster font I believe. If that font is classified as a non-TrueType then it leaves me with the same problem with non-TrueType fonts and also with TrueType fonts. In other words it implies that no matter what type of font I use I will get the problem occuring at different column numbers in every case. Does that mean it's something RS can fix rather than inheriting a problem related to specific types of font?

Jeremy: I actually quite like Dina as a font. It's sort of minimalist in a pleasant sort of way. Thanks for the reference.

Just a data point: I use the default of Courier New, and I don't see this
problem at all. I went way out to column 200 and never saw an issue.

"Peter Hamilton-Scott" <no_reply@jetbrains.com> wrote in message
news:17288468.96691215548712126.JavaMail.jive@app4.labs.intellij.net...

Eugene, my apologies for making such heavy going of this but I'm still
puzzled. I downloaded the Dina font that Jeremy uses and that's a raster
font I believe. If that is classified font as a non-TrueType then it
leaves me with the same problem with non-TrueType fonts and also with
TrueType fonts. In other words it implies that no matter what type of font
I use I will get the problem occuring at different column numbers in every
case. Does that mean it's something RS can fix rather than inheriting a
problem related to specific types of font?

>

Jeremy: I actually quite like Dina as a font. It's sort of minimalist in a
pleasant sort of way. Thanks for the reference.

I have to admit that I've been a fan of it for a while. I'm not big on ClearType, and often run in portait mode anyway (where ClearType cannot be used), and as such a lot of TrueType fonts don't look all that great at the font sizes I tend to code at (which aren't all that small, for the record ;) ). Raster fonts built for use at specific sizes can definitely provide better text readability, assuming they were well-designed and suit your personal tastes.

Raster fonts aside for the moment, there are also some good TrueType programming fonts out there, especially if you can use ClearType and like it. There are even a few that draw their inspiration from the classic raster programming fonts. Envy Code R is one such example, which even has an italic-as-bold option for use in Visual Studio if you're into that kind of thing.

Since you've mentioned also seeing the problem with TrueType fonts, perhaps I'll grab a bit of time to see if I also see the issue with a TrueType font in place.

I tried Courier New and my bulb blows at 88. Odd, is it not?

I am pretty sure I have the reproduction pattern nailed down for this, and it does provide a (somewhat clunky) workaround for people running into it too often between now and the time JetBrains corrects the issue.

Major point #1: the issue isn't related to TrueType versus raster typefaces. It can be made to happen with both.

Major point #2: both typeface and point size affect the behaviour.

Major point #3: The behaviour kicks in first depending on the typeface and point size configured for the IDE at launch time. Each launch configuration provokes the issue at a different column. Some launch configurations don't seem to provoke it, or at the very least don't do so at a column anyone would care about getting out to.

Major point #4: Typeface/point size changes after launch, either before or after loading a solution, pick up a behaviour that can be dependent on both their metrics and that of the launch typeface and point size. This is where the workaround comes in. If you are working in wide code for a while and keep running into the issue, configure the IDE with a font R# "likes more" (more on this as we go, and with true emphasis on the "more" in "likes more"), restart the IDE, then change to your preferred font.

Major point #5: The issue holds regardless of whether or not you launch the IDE with a TrueType or raster typeface and instead seems to depend only on the configured font's metrics. (I suspect the important metric in question is the rendered character width ala MeasureString.) Different launch typefaces / point sizes provoke the issue at different columns. 8 point Haettenschweiler, for example, which is a TrueType typeface, only provokes the issue once at column 209. Immediately change to 8 point Dina and the issue crops up at column 39. This implies that it isn't just a launch-font-problem-at-column-X-equals-post-launch-font-change-problem-at-column-X, it seems to be dependent on both fonts' metrics. Launch the IDE configured with 12 point Haettenschweiler, on the other hand, and the issue pops up at column 110 instead of 209 for the 8 point size of the same typeface. Immediately change to 8 point Dina and the issue appears at column 76.

Major point #6: Every permutation of launch typeface (TrueType or raster) & point size I've tried so far produces this behaviour at some column X. From there, every post-launch typeface (TrueType or raster) or typeface and point size change (but not just point size change, it would seem) produces this behaviour at some column Y that is usually dependent on the relationship between the launch typeface/point size metrics and the post-launch typeface/point size metrics. There are permutations, however, where Y doesn't seem dependent on the launch font, though I have yet to nail them down (and doubt I would be able to given the number of permutations available.) My gut (and a tiny inconclusive bit of ad-hoc testing) tells me that this (in)dependence is related to the relative (non-)monospace nature of the two typefaces. This mix of (in)dependent behaviour complicates the workaround as you might imagine.

I have not done strong enough testing beyond the first post-launch typeface and/or point size change to know whether or not things like a third font are affected just by its relation with the launch configuration or if it is also affected by the post-launch configurations along the way, though I suspect it is more likely that its behaviour is just tied to the launch font (where presumably R# and/or the IDE are setting themselves up with some kind of font metrics.)

As for specific workaround examples, the permutations are far too great to provide anything that would work for everyone, but in the small amount of searching I have done so far it seems that launching the IDE in Courier New and then changing to your preferred font is the best place to start. At the very least it works well for me by launching with 8 point Courier New and then going to 8 point Dina, but of course your mileage may vary.

That sounds quite thorough and impressively deduced. I'm glad it was not just me having the problem with TrueType and non-TrueType fonts. It'll be interesting to see how the RS team decide to address it. I hope they will as the loss of the light bulb mid-statement is quite serious, to me at least. ;)

Admittedly, it isn't all that common that people customize typefaces beyond the common Courier New and Consolas, and the somewhat less common Lucida Sans variants, Proggy, Dina, Envy Code, etc. choices, but given that some of my permutations exposed problems before even column 40, hopefully JetBrains will take a look into it.

I have encountered this issue as well, and finally got fed up with it and
changed my font to one that played nicer with R# (not in ideal solution).
This seemed to be an issue introduced in version 3 of R# I believe because
before that, I never encountered this issue.

Admittedly, it isn't all that common that people customize typefaces
beyond the common Courier New, Consolas, Lucida Sans Typewriter,
Proggy, Dina, Envy Code, etc. choices, but given that some of my
permutations exposed problems before even column 40, hopefully
JetBrains will take a look into it.

Jeremy Gray wrote:

Dina

My personal choice for programming font is 'Andale Mono'
(http://www.softlookup.com/display.asp?id=23163)

--
by Peter Sulek at 14. 7. 2008 13:14:56
XanaNews 1.18.1.6

Looks like I'll have to do another run-through of available typefaces some time soon. Taking a look online at your Andale Mono suggestion led me to typefaces like Liberation Mono that I have not had a chance to try. Thanks for the Andale Mono suggestion! I can't quite recall if I've already tried that one out (probably have, given its age) but will make sure to give it another go in my next round-up.