Thread View: comp.sys.next.programmer
6 messages
6 total messages
Started by Allen King
Sat, 19 Dec 1992 19:01
A few small changes for 3.1
Author: Allen King
Date: Sat, 19 Dec 1992 19:01
Date: Sat, 19 Dec 1992 19:01
64 lines
3414 bytes
3414 bytes
Here are a few little nuisances I've found with 3.0 which maybe
NeXT could clean up before 3.1 comes out. Perhaps others have found
them too, perhaps not. Other's may want to add to the list too. I'd
hate to have a new release come out without them, just because NeXT
didn't think of them and nobody thought to mention them, especially if
they are easy ;-).
EDIT
1. when editing a .m file, a quick "edit associated .h file"
button. Ditto for .h to .m.
2. A menue which would display only .m and .c files. Perhaps
that's a file selection mask on the file:open_folder... . Something
like "*.m *.c PB.*".
3. A way to get a TAGS search. Currently I only seem to be able to
use TAG files for Source commands, and it would eliminate alot of
grepping
4. A way the find pannel could do complete-word searches. It is
important to find all of the instances of short variables (e.g. "k").
Think C has it as a mode which works well -- it might also be a
"variable-break" special character.
GDB
1. Everything possible to speed up the compile/load/debug/go cycle:
1a. The idea of staying in gdb between compiles is great, with
automatic detection an reload of symbols on recompile. However, there
seems to be a bug, and the symbols are loaded incorrectly when it
tries to do this are. I could spend some time and give you an example
if you cannot recreate it yourself.
1b. When reloading symbols, much time is spent loading shared
library symbols, such as libMedia_s.A.shlib, libNeXT_s.C.shlib, and
libsys_s.B.shlib. Why can't those symbols be loaded once and never
reloaded? E.g. load them first, and save the high-water marks, or an
image of them. If only portions are loaded, it still deserves some
work, because I'd bet that the portion that gets loaded very
infrequently changes.
2. The browser should not reposition sliders during step, because
often one wants to monitor a variable at the bottom, and the sliders
keep bumping back to the top.
3. Have gdb print out what variables were changed by the statement
just executed, and their new values. I spend a lot of time tracing
this information down when I step through a program. I'm not sure how
the symbol table could be made to contain this, but it'd be nice to
have.
4. A compiler switch to make all variables visible in gdb (by
forcing them out of registers). (Maybe this already exists.)
WORKSPACE
1. When duplicating a file in the workspace, let the name be edited
while the copy is in progress. That's a very frequent sequence, and
things would go much faster that way.
PB
1. Why not recognize the suffix .project, and not require the full
name PB.project? It seems more standardized, and would allow me to put
a bunch of projects onto my shelf and tell them apart. This way, they
all look alike!
2. The debug button should be smarter about not spawning too many
Terminal's. If there's one there, use it and tell it that things have
been recompiled.
Re: A few small changes for 3.1
Author: Todd A Green
Date: Sat, 19 Dec 1992 21:25
Date: Sat, 19 Dec 1992 21:25
14 lines
998 bytes
998 bytes
In article <lj6sbkINNhg9@news.bbn.com> aking@BBN.COM (Allen King) writes: >[ suggested need for changes] > > >EDIT > 1. when editing a .m file, a quick "edit associated .h file" >button. Ditto for .h to .m. Better yet, IMHO, have a splitview with the .h in the top and the .m in the bottom. You can adjust the views as needed. Todd -- NeXTmail: tagreen@cica.indiana.edu
Re: A few small changes for 3.1 (Edit and gdb)
Author: Dick Silbar
Date: Mon, 21 Dec 1992 16:24
Date: Mon, 21 Dec 1992 16:24
17 lines
1331 bytes
1331 bytes
In article <lj6sbkINNhg9@news.bbn.com> aking@BBN.COM (Allen King) writes: > > Here are a few little nuisances I've found with 3.0 which maybe > NeXT could clean up before 3.1 comes out. Perhaps others have found > them too, perhaps not. Other's may want to add to the list too. I'd > hate to have a new release come out without them, just because NeXT > didn't think of them and nobody thought to mention them, especially if > they are easy ;-). > [munch on a list of nuisances and good suggestions] One thing about the Edit/gdb combination that annoys me is that I like, while stepping thru code, to jump about and print out various things, so see what happened in a given step. But then I often lose track of where the program actually is. It would be nice if Edit's cursor returned to the next line to be processed. Dick Silbar
Re: A few small changes for 3.1
Author: Scott Wisdom
Date: Tue, 22 Dec 1992 22:42
Date: Tue, 22 Dec 1992 22:42
10 lines
1001 bytes
1001 bytes
In article <lj6sbkINNhg9@news.bbn.com> aking@BBN.COM (Allen King) writes: > 4. A compiler switch to make all variables visible in gdb (by >forcing them out of registers). (Maybe this already exists.) I believe that optimization causes this problem, even when the -g flag is supplied. If you 'make debug' from the command line or build from Project Builder with 'debug' as an argument, you should not have this problem. -Scott Wisdom wisdom@geom.umn.edu
Re: A few small changes for 3.1 (Edit and gdb)
Author: Tim Pugh
Date: Thu, 24 Dec 1992 15:37
Date: Thu, 24 Dec 1992 15:37
31 lines
1921 bytes
1921 bytes
silbar@cantina.lanl.gov (Dick Silbar) writes:
>In article <lj6sbkINNhg9@news.bbn.com> aking@BBN.COM (Allen King) writes:
>>
>> Here are a few little nuisances I've found with 3.0 which maybe
>> NeXT could clean up before 3.1 comes out. Perhaps others have found
>> them too, perhaps not. Other's may want to add to the list too. I'd
>> hate to have a new release come out without them, just because NeXT
>> didn't think of them and nobody thought to mention them, especially if
>> they are easy ;-).
>> [munch on a list of nuisances and good suggestions]
>One thing about the Edit/gdb combination that annoys me is that I like,
>while stepping thru code, to jump about and print out various things, so
>see what happened in a given step. But then I often lose track of where
>the program actually is. It would be nice if Edit's cursor returned to
>the next line to be processed.
> Dick Silbar
One addition that should be both easy to make and quite useful is to follow
the example set by the Stuart terminal emulator by adding an "extent" option
to the print pannel. This allows one to print: all, selection, visible.
I have found this to be extremely useful.
Tim Pugh
--
Tim Pugh |MicroCALL Services
tim@aplcen.apl.JHU.EDU |8713 Briarcroft Lane
|Laurel, MD 20708-1355
------------------------------------------------------------------------------
Re: A few small changes for 3.1 (Edit and gdb)
Author: Alex Blakemore
Date: Tue, 29 Dec 1992 06:28
Date: Tue, 29 Dec 1992 06:28
16 lines
1432 bytes
1432 bytes
tim@aplcenmp.apl.jhu.edu (Tim Pugh) writes: > One addition [to Edit.app for 2.1] that should be both easy to make and > quite useful is to follow the example set by the Stuart terminal emulator > by adding an "extent" option to the print pannel. Another good idea that Edit and other apps should borrow from Stuart is to use alt-up and alt-down to scroll. (alt-left and alt-right to cycle thru windows) these are the main reasons I have to stop typing and reach for the mouse, a real slow down in a word processing type of app. Please NeXT, I know your GUI gods have declared some nonsensical use for alt arrow keys that even Edit's writers had the good sense to ignore, but please give us a way to scroll quickly without using the mouse. And NO, holding down the arrow key as the cursor covers the whole page is not quick. -- --------------------------------------------------- Alex Blakemore alex@cs.umd.edu NeXT mail accepted
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads