Sluggish scrolling

[lgw]

Gave UEX a try on Fedora 11. Install was flawless, actually easier than windows, except that internet connection was required. The program starts quickly but after loading a file I found scrolling extremely sluggish, (for a text editor). Whether using the arrow keys the page up/down keys or the mouse scroll wheel moving text past the current page display was very slow and appeared to have momentum. This might be acceptable in a web browser but not in a text editor. Hopefully the next version will be better.

[ljhunter]

I tried it myself on Ubuntu 8.1. Had some installation problems, since it requires the libboost-regexp library, and that isn't part of the standard distribution or even available on the standard repositories. However once I was able to find the .deb file for download on the Boost site the installation worked fine. I was really happy until I pulled up a couple of files and found that it wasn't merely sluggish, but more accurately glacial in it's response. Oh well, into the bit bucket and back to Kate. Until I hear someone say that they haved fixed this problem I won't even consider getting the next version. It's too bad, I been using Ultraedit for years on Windows systems and really missed it on Linux.

[tuxpost]

(Slow) scrolling of html files width wordwrap on, then select a bit of text and UEX crashed, all the time. I will wait for version 1.1 or later. Nevertheless I have buyed a license - take this as a kind of support for future versions, the program is not useable for me at the moment (Ubuntu 8.04).

[saibal]

Hi all,
I have the same problem. Slow scrolling of files, slow move of tabs etc etc.

If I disable ati proprietary driver installed on my ubuntu, everything is ok.

Ultraedit is the only package that creates this problem. Any solution?

[saibal]

I resolved it

I have a bad ati video device so I had disable all effects in my ubuntu. This created some problems in vertical scroll of UEX.

Now I reactivated basic effects and everything is ok!!

[simes]

Thanks for that last reply. Setting basic effects fixed it for me as well.

Column mode area selection still a bit sluggish though.

[esimard]

I was using version 1.0.0.11 and I just tried 1.0.0.13. version .13 is worse to the point where I just can't do anything. The release note say improve scrolling I'l say it is now worse.

I'm on Suse 11.2 - 64 bit

Anyway i can download the version 1.0.0.11 until this problem get fix, as for now the tools is unusable for me.

Anyone have any idea?

[tuxpost]

v13: After loading a html or php file every action has a delay of 1-2 seconds and UEX crashed immediately after selecting text. With or without linewrap. v11 crashed too when selecting text, but has no delay. Ubuntu 8.04 without desktop effects, ATI card.

[mrcbis]

Hello, I downloaded Version 1.0.0.11 of uex and scroll is ok, but very often in crash after hitting ctrl-c. Version 1.0.0.13 and Beta 1.0.9.beta.1.1 have the same problem: sluggish scrolling. This makes uex unusable for practical source code editing. I am running slackware 12.2 kernel revision 2.6.25.9 om a quad core 4GB ram PC. Ati HD3870 video card with last ati card video driver.
Any Idea ?

Thanks.

Marco Bisio

[hvaring]

I confirm this. Just installed 10.0.0.13 on Ubuntu 9.10 32-bits. Enabled desktop effects. Keyboard is extremely sluggish and the entire application feels extremely slow. It's just unusable as it is now. I've tried on 64 bits Fedora 11, there it works ok.

[tuxpost]

Scrolling is ok now in UEX version 1.1, fine. But UEX crashed again after selecting some lines of text or code. Now let's see what will happen in UEX 1.2., maybe this could be the version then, which is really usable. Hope so.

[Edit] UEX 1.1, the tar.gz version, has a bug report tool, which pops up after a crash.

[rstaveley]

I'm experimenting with changing my modus operandi with UltraEdit. Forgive me, if I subject you to a bit of background before I comment about the slow scroll on Linux.

I'm a die-hard Semware Editor (a Win32) user, and for a long time I've enjoyed the responsiveness of that editor, and the fact that it is rock solid. More windowsy editors have always felt spongy. Semware feels like a DOS editor, like its predecessor QuickEdit. I hate slow response with a vengeance. However...

1. Semware doesn't do UTF-8
2. Semware has a long way to go before its Linux offering comes out of beta
3. Semware is a one-man band and it is hard to see these developments getting into production for some time

A recent UTF-8 dependent project made me look at the popular alternatives. UltraEdit stood out as an editor, which I can run on my Windows desktop and Linux laptop. I've paid for a lifetime of upgrades in Linux and Windows. I earn my living writing code, so I didn't mind the extra 400% to get a lifetime of bug fixes.

Initial impressions on Windows are fairly good with some reservations:

- It is inevitably spongier than Semware, but my PC is fast enough that it isn't too annoying. So I can live with that. Response time is generally OK.
- I find the slow play-back of macros really irritating. Semware doesn't subject you to an animated replay, you can repeatedly replay macros very quickly. With UltraEdit a repeatedly playing a macro takes a long time. It smacks of a lazy macro implementation. Hopefully, UltraEdit will resource development of instant macro playbacks.
- Recognition of UTF-8 is good, but there is some bugginess about saving UTF-8 files. The BOM (bane of PHP) seems to be saved regardless of the editor's settings in new files and saving a new Linux/UNIX format file seems to override as a DOS format (you have to File Save As.. to get the UNIX line endings).
- File comparison is poor. It seems to lose track of the fact that one file is UTF-8 when one file is opened on a network drive, and flags every diacritic as a difference, mis-displaying in the comparison window. Perhaps that's only a problem with the "lite" comparison, but it is a poor advertisement for that product.
- I like the SFTP support.

I can live with the failings. I expect to wean myself off Semware now and become a full-time UltraEdit user in Windows. Hopefully UltraEdit will address these issues with time.

My Linux story is less rosy. I haven't had any experience of a serious Linux editor. I use 'vi' in the PuTTY console for quick fixes, but natively UltraEdit is competing against the likes of Kate, Eclipse etc., and I've always resorted to doing my serious editing with Semware on Windows, because of familiarity more than anything else.

I'm running Kubuntu (Karmic) on a decent laptop. I find using UltraEdit (1.1.0.0) for anything serious on my Linux laptop is frustrating because of the sluggishness of scrolling, and flakiness of type-ahead. I hold down the backspace and get an unpredictable amount of key repeat buffered and watch my text get gobbled up in slow-motion. I hold the cursor key down, and find myself over-shooting the text I wanted to scroll to. I'm not aware of this having happening on Kate, so I'm not sure if this is simply a matter of KDE not being ready for serious use, or if it is UltraEdit that is too blame.

[Mofi]

Semware doesn't subject you to an animated replay, you can repeatedly replay macros very quickly. With UltraEdit a repeatedly playing a macro takes a long time. It smacks of a lazy macro implementation.

I used the Semware editor as well many years ago before Windows 95 came out and the macro language of Semware editor was really great. Of course writing Semware macros required real programming capabilities, but that gave experienced users a lot of power and fast running macros. The screen updates during playback of UltraEdit macros is really a big problem and I wish also that there would be a possibility to disable the screen updates during macro execution. But now with the Javascript support those screen updates can be avoided by opening a new file maximized and run the script on another file or even better load the entire content of a file into a string variable and manipulate it in memory. Running scripts in UltraEdit are not as fast as the Semware macros, but quite powerful as well.

The BOM (bane of PHP) seems to be saved regardless of the editor's settings in new files and saving a new Linux/UNIX format file seems to override as a DOS format (you have to File Save As.. to get the UNIX line endings).

Uncheck both UTF-8 settings at Advanced - Configuration - File Handling - Save and new files should not be saved anymore with UTF-8 BOM. Also you have to use format UTF-8 - NO BOM in the Save As dialog, NOT format UTF-8.

At Advanced - Configuration - File Handling - DOS/UNIX/MAC Handling you can define the default line termination type for new files. But you are right with Save As dialog and using format UTF-8 or UTF-8 - NO BOM and at the same time line terminator type UNIX. With these options a DOS file is not converted to UNIX. I reported this issue on 14th Jan. 2010 by email to IDM support and got a confirmation for this bug. So I suppose this issue is fixed in one of the next releases of UltraEdit (for Windows).

File comparison is poor. It seems to lose track of the fact that one file is UTF-8 when one file is opened on a network drive, and flags every diacritic as a difference, mis-displaying in the comparison window. Perhaps that's only a problem with the "lite" comparison, but it is a poor advertisement for that product.

Well, I'm using UltraCompare Prof. and not the Lite version, but wait for the next release for the Lite version which is probably build on UC Prof. v7.00 which has improved Unicode support. If the problem still exists in next Lite version, please report it by email to IDM support.

[rstaveley]

Thanks for the swift response, Mofi.

UTF-8 - NO BOM in the Save As dialog, NOT format UTF-8.

Aha! That was my error.

With these options a DOS file is not converted to UNIX....I reported this issue on 14th Jan. 2010 by email to IDM support and got a confirmation for this bug.

Excellent, I shan't repeat your bug report. Do IDM have a public issue tracker, or is it behind closed doors?

Apart from UNICODE, the similarity between the Linux and Windows offering of UltraEdit is what really appeals to me, though.

I would dearly love to resolve the sluggish / keyboard repeat (type-ahead) issue. If the issue is likely to be in KDE/Gnome or something at a lower level, it would be good to know. I find it hard to believe that anyone is doing serious code development with the key buffering that I'm experiencing, which either means that my local set-up needs tweaking or that the Linux product has some way to go before it is genuinely production-ready.

[Mofi]

Do IDM have a public issue tracker, or is it behind closed doors?

The database is not public. (I suppose because UE and UEX are not open source projects.) So I can only write here what I found and reported if it is helpful for somebody else. I have my on database for all my favorite tools, not only for those of IDM.