[Eric] [eric5.0] a few bugs, possibly

[detlev]

On Dienstag, 27. Juli 2010, Angus wrote:
> Thanks Detlev, for the quick response earlier. I've used Eric (eric5)
> for half a day now and I must say I'm impressed with all the features.
> Great work. Hope you don't mind going over a few minor things I came
> across though. All for the sake of perfect polish, I guess.
> 
> *) The values I set in:
> Settings > Preferences > Editor > General > Tab width
> Settings > Preferences > Editor > Edge Mode > Column Number
> Are devided by 2 in the applied output (e.g. setting a tab width of 4
> creates an actual tab width of 2 in the editor).
> I'm using the standard Python3 encoding (without declaration): utf-8.

That should not happen. If these value are correct in the eric5.ini file, it 
is a QScintilla issue. Maybe this is related to using a non monospaced font.

> 
> *) Py3Flakes doesn't understand the 'with' statement even though
> that's recommended way of handling files according to the official
> 
> Python tutorial:
> >>>with open('foo', 'r') as f:
> >>>    l = f.readlines()
> 
> causes: "py3flakes warning: Undefined name 'f'."

That is a bug and should be fixed.

> 
> *) This one is a bit hard to describe, but the only one giving me
> grief. It happens in various widgets containing text, but I'll just
> try to give one specific example of the treeview in Settings >
> Preferences:
> Click the triangle next to an item (e.g. "Debugger"). Often there will
> be no response. Nor will the second click. But then, moving the
> mousing pointer down will cause the screen to update that area. That
> is, the positioning of text will change "on the fly", which looks like
> the screen is "tearing" wherever you move the mouse pointer to. This
> also regularly happens in the help viewer when reading documentation,
> but I've trouble reproducing it consistently (some combination of
> scrolling, selecting text and/or moving the mouse pointer).

I have seen something similar on Windows systems. However, I doubt that it is 
an eric issue but rather Qt or PyQt.

> 
> *) Finally, I consider it a bug to have no public bug tracker (or if
> there is one, it's too hard to find). Having one would it make it
> easier for the developer to keep track of open issues. Furthermore, it
> would make it a lot easier for users to find out what issues are
> already known to the developer, saving wasted energy on redundant
> reports by users and replies by the developer.

It is a bug but probably one that won't get fixed in the near future. Doing 
eric mostly as a one man project doesn't leave me time to manage a bug 
tracker. Bugs should be reported via the built-in bug reporting feature or 
through this mailing list.

Regards,
Detlev
-- 
Detlev Offenbach
detlev at die-offenbachs.de