Hi Robert, I am forwarding your message to the erlide-devel mailing list, so that it is archived. Please see inline comments below.
Thank you very much for all the suggestions! I wish all the users did send as detailed comments and suggestions. I see that you're part of the RefactorErl team, interesting that you didn't comment on the Wrangler integration :-) As a general answer, most of the things you pointed out are known issues. If you are interested, you can see the list of tickets at https://www.assembla.com/spaces/erlide/tickets. For those that aren't there or that have extra information/requirements, I will create/update tickets. On Wed, Aug 26, 2009 at 00:38, Kitlei Róbert<kit...@elte.hu> wrote: > Dear developers, > > I would like to have give you some suggestions about the current (stable as > of today) version of ErlIDE. > > Actually, I have tried ErlIDE several times over the last year (always with > fresh installs of both the newest Erlang, the newest Eclipse and the stable > version of the tool, no customisation whatsoever), but until today, the > actual version almost always failed to connect to the Erlang node. Now it > seems that the current version starts all right exactly every second time, > and every other second time I get "rpc failed". Repair it, please (or ask > for more details if you can't reproduce it). You should have contacted us before, we had several cases where the connection failed, but I think we managed to solve all of them. We don't see this kind of behaviour (we have 40+ developers using it in their daily job, it wouldn't be possible if it crashed so often). The first thing to do when something goes wrong is go to Window->Preferences->Erlang->Report problems, fill in the details and create a report (will be saved in your home directory). Mail it to me and we can proceed from there. > On to my suggestions. > > First, and most importantly of all, about the debugger. The debugger is high up on our priority list. > - The way the debugger displays the values bound to the variables should be > more flexible in several ways. Lists are always displayed as strings if > applicable, which is a bad idea for showing things like D = > [[lists:seq(I*10, I*10+9) || I <- lists:seq(1, 5)]] -- even when I use the > drop-down to inspect D:0, D:1 etc., there is no way to see the values. > - The variables window has a bottom part where the chosen expression is > shown; the expressions appearing there should be formatted (similar to ~p of > io:format), and be not wider than the window (automatically resizing with > it, of course), else long lists with deeply nested lists/tuples will end up > on one line, which is unusable. > - Changing the value of a variable works very well most of the time, except > that the display goes bad when I add/remove elements to list: all the > bindings are listed again in reverse order (this only affects the variables > window, the bindings are all right on the Erlang level). Changing the value > again results in a badmatch. > - It would be nice to have a custom piece of code run instead of calling one > function with an optional list of arguments; of course, a dummy module with > a dummy function containing the same code can be set up as a workaround. Do you mean when starting a backend with your project's code? > Autocompletion. Here we use the functionality that Eclipse provides. Some of the things you mention can't be changed easily, but we need to copy the eclipse internal code in our project - which we don't want to do without a very good reason, because we get to maintain that code too, verify that it's not breaking with other Eclipse versions. > - Autocompletion should mark which functions have associated documentations. > - The documentations appear after a delay; this should be adjustable in the > Erlang menu. > - The appearing window is often too small for the documentation, both width > and length (e.g. file:consult/1), even when there is abundant space for it; > in contrast, the autocompletion window is usually much wider than needed > most of the time. > - When the documentation appears, the hint says, "Press F2 for focus." This > should also mention that pressing Tab switches to the documentation; even > then, the documentation can't be scrolled without touching the mouse first. > - When choosing a module completion (e.g. file:), the autocompletion for the > module functions should appear immediately. > - When inside the text of a function call -- that is, somewhere among the > function call arguments --, CTRL-Space should still display the function > documentation. The Java version even highlights the actual parameter. > - Non-OTP style function documentation could look a bit better. At least > without the initial % marks and padding whitespace. > Console. The console is (right now) in the middle of a major rewrite. Part of it is an exploration to find out what is the best way to interact with the console. I have a lot of ideas about that, but some work, some don't. I think that I will revert to a more basic console and test the new fancy stuff in a separate view, so that people don't get too confused. > - When navigating through history, the previously shown commands leave a > grey shadow below the newly displayed ones (or typed text). > - When at the bottom of the console, entering a new multiline command shows > only one line of the command; the appearing red/green bar should grow > upwards by one line instead. > - It would be nice to have autocomplete in the console as well. The homepage > says it is in there, but I couldn't make it work. > - Sometimes when an expression is entered, the cursor winds up someplace > other than the next command line (the beginning of the output, it seems). > - Just now I happened to freeze the console: the red bar stays up, text can > be entered, but it neither turns green, nor does anything when I press Enter > -- however, the console still works all right if I maximise it, having a > separate red/green input bar, while the original red one remains at the > bottom. > - If the program terminates with an error (e.g. io:format("~d~n", [1]) or > throw(apple) or a badmatch), where is the full error report available? > Having only [exit, null] in debug mode is not enough, and the normal console > simply disacknowledges that an error has occurred. Which program do you refer to here? The one started with the call specified in the launch configuration? There are issues with being able to intercept things that are written to stdout; the shell we have is a remote shell that doesn't "see" that output. This is somewhat better in the latest nightly builds, but there's still work left to do here. > Having written so many suggestions, you might think that I dislike your > tool. This is not true, on the contrary; however, I think all of the above > are more or less important in order to make it really useful. Especially the > ones about debugger value display. > Best regards and keep up the good work, > Kitlei Róbert Thanks a lot and if you see any problems please let us know right away. best regards, Vlad ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Erlide-devel mailing list Erlide-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/erlide-devel
