From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8bc34e14e4555720 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-10 18:00:46 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.gamma.ru!Gamma.RU!news.mailgate.org!zur.uu.net!ash.uu.net!spool0900.news.uu.net!reader0901.news.uu.net!not-for-mail Sender: DB3L@CTWD0143 Newsgroups: comp.lang.ada Subject: Re: This is a simple question References: <9pk4t7$tbm$1@trog.dera.gov.uk> <87zo762rta.fsf@deneb.enyo.de> <9pkc0r$m5j$1@trog.dera.gov.uk> <9pkddm$afh$1@nh.pace.co.uk> <9pvdp5$8im$1@nh.pace.co.uk> <9q1lrp$e1q$1@nh.pace.co.uk> From: David Bolen Date: 10 Oct 2001 21:01:00 -0400 Message-ID: Organization: Fitlinxx, Inc. - Stamford, CT X-Newsreader: Gnus v5.7/Emacs 20.6 NNTP-Posting-Host: 208.247.212.3 X-Trace: 1002762045 reader1.ash.ops.us.uu.net 15062 208.247.212.3 Xref: archiver1.google.com comp.lang.ada:14211 Date: 2001-10-10T21:01:00-04:00 List-Id: "Marin David Condic" writes: > It seemed to come up with an Ada menu option when I figured out how to open > up an Ada file - why no pop-up window with a file selection screen? (We're > back to bitching about it not looking like a Windows app.) Nothing wrong with wanting the GUI file selection, and I won't dispute that if you want a GUI oriented editor, Emacs is probably the wrong base. (In the below C- notation indicates Ctrl, and M- is Meta/ESC) Me, I find the standard GUI file selection too intrusive during development (and slow). For Emacs, hit C-x, C-f, you get prompted for a file and the current directory filled in - you can edit in the prompt using normal Emacs editing commands. At any point, hit ? and you get a list of possible files in a pop-up buffer based on what you've typed so far. At any point hit TAB to auto-complete as much as possible. If you want to browse a directory, hit C-x d, select the directory (same as for a file) and you get a buffer with a list of files and single character commands on each file whether for editing or even deleting. Sure, all of this is text based - which BTW, in these days of massive PCs and wasting modem connections just to pcAnywhere a full graphics screen may not mean much, but boy is it faster in general and more suitable to remote use in many cases. > And here's the > main gripe: After pointing it at an Ada file, it quite nicely opened it up > and managed to look like Notepad or any other standard issue text editor. > Gee. That's swell. Why not just use whatever standard-issue text editor > thats already on my system? Um, because their only similarly may be the fact that they are displaying a text file in a similar visual way? :-) You're editing a text file (the Ada file), so why should it have to look much different than a simple text display? But compared to Notepad there are probably over a thousand various text manipulation and editing operations only a few keystrokes away. Sure, basic movement and inserting the occasional text is the same. But once you watch it auto-indent and format your source, get used to the higher order movement commands that understand the program structure and so on the others fall quickly back. Particularly if you can learn to forget that darn mouse that just slows things down :-) > What I'd like for something that purports to be an IDE to do is let me point > it at a directory full of Ada files and have it put all those files off on a > column on the left with little plus signs that let me click on them and see > all the procedures within the packages, etc. EMACS is supposed to do this? Since that was my original small point, you should at least see what I was talking about ;-) M-x speedbar RET will present the speedbar on your current directory as a separate frame. The speedbar is a general purpose construct that itself knows how to deal with a wide variety of files and language types. It'll list the files and you can expand to include elements within the files and then jump right to them in the main buffer. But for anyone still getting used to Emacs in general, I don't expect that the Speedbar is going to change a point of view much. It's text too :-) > Again, if it does, it doesn't do it automatically and it doesn't have a > "Open Up A Directory Full Of Ada Files And Put Them In A Pannel On The Left" > menu entry. I suppose I could RTFM, but like I tried to point out - I'm > reacting here like a garden variety PC user - I don't want to *study* it - I > just want to *use* it. Yeah, I probably don't have a simple solution - I don't think anyone will dispute that Emacs has a (potentially steep) learning curve. And there's no way you could come up with a single set of menu options that would suffice. And it's been too long from when I first used it to be confident in judging how to learn it most efficiently. I'd certainly start with its online tutorial (M-x help-with-tutorial RET) and the online documentation (M-x info RET), but then it's just use. After a while of accustomization to basic editing commands you'll find yourself discovering other commands and extending your use of its capabilities a bit at a time until after a bit you'll find your efficiency far higher than with any GUI environment I've ever tried. But it takes time, and I would agree that a casual developer probably isn't going to invest the necessary effort. Nothing against that, but its a professional tool - I don't think it would have the same payback for casual use. > I'm not holding up AdaGide as an end-all, be-all of IDEs for Ada. What it > *does* do is provide a pretty simple editor that is integrated with the > compiler & debugger and looks like a basic PC app that an average PC user > can figure out without reading a manual. (At least to do the basic things > like edit/compile/link/run) EMACS may do all of that and so much more, but > it just isn't an *obvious* IDE for Ada. I'd certainly agree. It's not its focus. > Well, my harangue against EMACS stems from earlier discussions about using > it as the basis for an IDE for Ada - making a "kit" for Ada development that > starts to look like other "kits" for other languages. My objection is not > that EMACS lacks power (I'm told by people I trust that it has lots of > power - maybe too much power.) My objection is that as it currently stands, > it doesn't pop-up as an Ada-oriented IDE with fairly obvious > buttons/menus/icons/whatever that do the things one would typically want to > do with a library full of Ada stuff and do it in an > intuitively-obvious-to-the-casual-PS-oriented-observer way. Oh yeah certainly - at least not that final point. Now true, if someone were to really work on an Ada-oriented development mode for Emacs it could be made to simplify pure Ada-related work to the point of being much more accessible to a casual user (you can really control the interface a lot from code), but it's not really the best match of tool and purpose. Now what might be sort of nice is if someone did an IDE that wrapped around an optional external editor and included good support for Emacs. Some IDEs let you choose editing bindings that emulate Emacs, but it's just not quite the same thing. > I've used EMACS (and XEMACS) in various forms on Unix platforms before in > fairly casual ways and never really wanted to learn all of the details. I've > always felt it had a fairly UNIXey feel to it and sort of thought of it as > VI on steroids. From what I've seen of it lately and what others have said > about it, it looks like its an operating-system-wannabe. (Do I *really* need > it to do e-mail for me?) It depends - for me, I probably spend at least 60-70% of my time composing (aka editing text) e-mail, 20-30% reading, and only a small fraction doing management of folders and what not. Seems fairly natural to use an existing editing environment for that. (To be fair, I'm stuck with Outlook at work and I hate it's lack of editing capabilities - sometimes I cut and paste into an Emacs session just to compose before pasting the response back. On prior systems I used mail packages like MM that automatically executed an external editor for editing messages) > I suppose it would have its share of followers and > those willing to learn all of its ins and outs will be rewarded by the power > available to them, but if I were designing an Ada IDE, I'd do it very > differently. (Create all the clever powerful features you want, but make the > *basics* stand out as obvious and simple to use.) I'd agree with the goal. I've just found that in my experience more often than not an IDE designed to present itself as simple and obvious rarely has the underlying depth to become more than simple and obvious when you acclimate to that. That's fine for occasional and casual use, but it begins to fall down quickly for serious development, where you quickly find yourself wanting to bypass all the friendly interface stuff and just get the job done. > (...) > I just wouldn't try to use it as the basis for an Ada IDE if I was building > one from bottom-dead-center with the goal of making a commercially viable > development kit. I'd want something that looked more like what PC developers > are used to seeing. I don't see EMACS fitting that description. Just my > opinion...... I'd say that was fair, particularly for that goal. My co-workers are a good example. Most of them use the VC++ IDE directly. One who uses an external editor uses CodeWright (nice GUI interface). I may think Emacs would be more efficient than eitherz, but it's not something I'm going to try to put up against a GUI IDE or editor simply because it doesn't fit the model of what PC developers want today. Then we have a casual operations guy who also does some code and is working on some of our Python scripts - he's using the PythonWin IDE that comes with Python, and there's no way I'd bother trying to get him up to speed on Emacs instead - its benefits to him for the sort of work he does would be limited. It's important to apply the right sort of tool to the job (or goal). But for a serious professional developer willing to invest time in learning a tool, I think Emacs can more than pay it back over time. -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/