What were you guys thinking??
By philip.cz... on June 30, 2013 23:45 (imported from Google Code)
--> ** READ THIS **
--> ATTACH YOUR ~/Library/Preferences/com.googlecode.iterm2.plist
--> FILE TO THIS ISSUE!
--> Almost all issues are configuration-specific. Issues missing
--> this file will be closed.
Unfortunately, this dictum does not apply in my case. Nevertheless, here you go.
--> What steps will reproduce the problem?
- running iTerm2
- using any non-American words or symbols
- there is no requisite 3rd condition.
--> What is the expected output? What do you see instead?
I expect to see non-ASCII output in the font I CHOSE... (...and HAVE BEEN allowed to choose for gee, how many years now? And have built dozens if not hundreds of megabytes'-worth of code to display various things, like any of the other languages I use to communicate, low-grade CLI "graphics" as framing, or geez, just simply aesthetic enhancements...) and after spending uncountable hours figuring out JUST the right font size and shape for exactly what I needed, here come TWO new updates that just decide to up and drop trou right in front of me and just poopie all over all that effort with not a modicum of explanation for such a drastic - and arguably impolite - change. Lovely.
Seriously though: What could possibly possess/induce/threaten@gunpoint? you guys to release an update that blanket-deletes functionality that has existed since pretty much the start of the project?!? Who greenlit that??? And... WHY?
Whatever happened to doing it sensibly, by, oh, I don't know, making a flippin' radio button to select to do this to your own sessions, or, gosh, JUST ABOUT ANYTHING ELSE?? How about even a HIDDEN SETTING to not enable this newest "improvement" to what is, aside from this inexplicable Hot Carl of a "fix", an outstanding product?
My god, I have seen you guys do some crazy stuff over the years, but never anything like this.
In the spirit of at least a patina of fairness here, let me add that pretty much the only reason I'm all discombobulated to the point of writing such a report is because iTerm2 is far and away the ABSOLUTE BEST TERMINAL EMULATOR for the MOX platform, bar none - at least in my opinion (which at this point, you might not care too much about, but I'm hoping whoever reads this values honesty over BS PC platitudes). And no, I've retained my sense of perspective in this, and am fully aware the product is free, so I can basically shove this report up my own tuchus if I'm so upset.
Yeah, I know.
But seriously, you guys are responsible for the productivity (and, it must be said, yes, joy of use) of a LOOOOOOOT of people out there. I think overall, you are incredibly respected for what you do, including by me. Which is precisely why I am beside myself in disbelief at this decision, making it what looks like THREE releases now, with NO fix!
Come on.
Please. PLEASE fix this.
Please.
I'll even send you some of my lower-quality code so you can have a shoot-soda-through-your-nose comedy break as a reward, should you request it.
Just please fix this. Make it a secret setting if you must (to save face? christ, I dunno... b/c I just can't figure out what circs could lead you to this decision in the first place), but please, please, fix it.
:o(....
--> What version of the product are you using? On what operating system?
I'm using 1.0.0.20130319 for the obvious reason that all newer versions contain the above issue.
--> Please provide any additional information below.
I'm sad.
Well, ok, there IS one other point... despite seeing red about the change in the log (which I always read BEFORE installing), I went ahead in the hope that this would at least resolve the issue with the HORRENDOUS performance from 'fontd'... NOPE.
So, what is up with fontd? I realize this is not yours, but I'm wondering whether you are aware of ANY workarounds to this horrible bottleneck? Because any attempts to display even a single section of the UCS results in like, Commodore64 performance.
Again, I'm understand that fontd is not your beast... but could there perhaps be some unfixed, old hack for the way you talk to the thing hanging around in your code? If not, are you aware of what is causing this slowdown on apple's end?
Failing that, can you perhaps point me in the direction of a sensible place to start to address this myself? I'm okay with fairly low-level scary übernerdery, so if you know of ANYTHING that is in the right general direction, I'd appreciate it. (Indeed, the reason I'm asking is because there are SO MANY places to start, and quite a few would require a large time investment before I would even know if it's the right track, that any such help will save me gobs of time.)
If not, that's ok.
(And in the unlikely event you were not aware of this, please consider this a bug report for same. As mentioned, any quick access and screen-display of a contiguous section of Unicode above the ASCII-equivalent area, say, anywhere from 4-20 rows of 16 chars each, depending on char complexity (combining chars seem to cause the worst slowdown) will cause a MASSIVE CPU spike in fontd's usage and memory consumption that REMAINS in the session. A "cmd-R" reset removes this slowdown, but only at the cost of never scrolling back through that region. Doing so puts you back to square one, and often, the session must be closed. And since I do a lot of typography-type work, this affects me quite a bit.)
Regardless, thanks.
~Philip