johnm@trsvax.UUCP (11/18/88)
>1) Instead of inserting TABS, I insert 4 spaces. I would really love it if the size of a displayed tab was an adjustable thing and also if the tab implementation (spaces or tab) was selectable. >2) If an empty line is typed, don't drop back one level of indentation. > When I found the spot to change for this, it appeared that it was > possibly a small bug as it was a loop that seemed to stop one short. > >These were both in version3.9e. I don't know if this is the latest >version or not. Yes, I too would like to make this change and one other. Have you ever noticed that splitting the screen slows you down massively when you start editing. I think this is because uEmacs wants to keep the upper screen display coordinated with the lower if they both contain the same file. This isn't strictly necessary though unless the line you are editing also appears in the other window. That is one fix I would love to make. While I'm on a wish list kick, how about: a) a tags function (NOT a convoluted macro) b) mouse support like freemacs has c) temporary windows that go away once you press a key (excellent for functions like apropos) d) a function that creates a file with a unique name e) functions to return the size of files and delete files f) file name completion Which brings me to my final point. I could probably do a couple of these myself if I had the latest uEmacs source or knew where to get it (or even what version it is). Can anybody tell me where to get it? John Munsch
nwd@j.cc.purdue.edu (Daniel Lawrence) (11/20/88)
In article <216100068@trsvax> johnm@trsvax.UUCP writes: > >>1) Instead of inserting TABS, I insert 4 spaces. > >I would really love it if the size of a displayed tab was an adjustable thing >and also if the tab implementation (spaces or tab) was selectable. > in version 3.10 $hardtab is the number of columns between hard tab stops, and $softab is the number of spaces used in soft tabs. (If $softab is zero, hard tabs are used. $hardtab defaults to 8). >>2) If an empty line is typed, don't drop back one level of indentation. >> When I found the spot to change for this, it appeared that it was >> possibly a small bug as it was a loop that seemed to stop one short. >> >>These were both in version3.9e. I don't know if this is the latest >>version or not. This works properly under version 3.10. If you are on a line with just whitespace and hit the newline key at the end, the white space is deleted, and the new line is indented instead. > >Yes, I too would like to make this change and one other. Have you ever noticed >that splitting the screen slows you down massively when you start editing. I >think this is because uEmacs wants to keep the upper screen display coordinated >with the lower if they both contain the same file. This isn't strictly >necessary though unless the line you are editing also appears in the other >window. That is one fix I would love to make. > Maybe I am not running on a slow enough machine, but with two or three windows, I don't notice the difference. The code for this is in the linsert() function in line.c. Just don't update the change flags for the other windows. >While I'm on a wish list kick, how about: > a) a tags function (NOT a convoluted macro) So that everyone pays the price in size so that a few can have tags? Yes I know there are a lot of programmers who would like this built in, but if I put everything like this in we would end up with something the size of GNU emacs, and that just doesn't seem to be the point behind all this. Instead of saying this, why don't you explore writting a non-convoluted macro, or help point out to me what I can do with the macro language that would keep such a thing from working the way you would like. > b) mouse support like freemacs has Under what OS? You relize the mouse support has to be added machine by machine. There doesn't seem to be any standard in the UNIX world for this. Under MSDOS, 3.10 supports the Microsoft Mouse and anything compatable with it. > c) temporary windows that go away once you press a key (excellent for > functions like apropos) I though very seriously about this, but I really don't know what would be a good implementation of this. Too many of these "Temporary output" commands fill up the window and require the user to page throught them. > d) a function that creates a file with a unique name Macro Function? For temporary files? explain. > e) functions to return the size of files and delete files directory listers and OS remove or delete commands seem to work real well for this. ^X$ and ^X! call them up very easily... I don't understand why yet another machine dependant function is needed for this. > f) file name completion > Again, machine incompatability. I don't have to write these once, but 12 times. Not having access to a lot of the more unusual machines I am very hesitant to make uEMACS at all machine dependant. I really wrote it because I was VERY angry about learning loads of different editors everytime I switched hardware. >Which brings me to my final point. I could probably do a couple of these myself >if I had the latest uEmacs source or knew where to get it (or even what version >it is). Can anybody tell me where to get it? > Did you try the docs? Every README file or EMACS.MSS file from version 3.3 and up (4 years ago) has had my address/phone and BBS phone numbers in it. My apologies if you somehow got uEMACS without these files, but I have been on the net a lot and available through the ibm and emacs groups for 3 years as well. BTW, the current version posted on The Programmer's Room is the BETA test version for 3.10. If you download this, please send back feedback to me. I will be preparing a full release in December after the BETA has had a chance to settle out. >John Munsch Daniel Lawrence (317) 742-5153 nwd@j.cc.purdue.edu The Programmer's Room Fido 1:201/10 (317) 742-5533
edf@rocky2.rockefeller.edu (David MacKenzie) (11/20/88)
In article <8308@j.cc.purdue.edu> nwd@j.cc.purdue.edu (Daniel Lawrence) writes: >In article <216100068@trsvax> johnm@trsvax.UUCP writes: >>Yes, I too would like to make this change and one other. Have you ever noticed >>that splitting the screen slows you down massively when you start editing. I >>think this is because uEmacs wants to keep the upper screen display coordinated >>with the lower if they both contain the same file. This isn't strictly >>necessary though unless the line you are editing also appears in the other >>window. That is one fix I would love to make. >> > >Maybe I am not running on a slow enough machine, but with two or three >windows, I don't notice the difference. The code for this is in the >linsert() function in line.c. Just don't update the change flags for the >other windows. Under System V Unix, adding multiple windows doesn't slow things down at all, but under MS-DOS (using MicroEMACS 3.8l compiled with MSC 3.0), it goes from very fast to almost unusably slow when you go from one window to two. I've never understood that, either, nor have I explored that part of the code, but it sure is annoying. >>While I'm on a wish list kick, how about: >> a) a tags function (NOT a convoluted macro) > > So that everyone pays the price in size so that a few can have >tags? Yes I know there are a lot of programmers who would like this >built in, but if I put everything like this in we would end up with >something the size of GNU emacs, and that just doesn't seem to be the >point behind all this. Instead of saying this, why don't you explore >writting a non-convoluted macro, or help point out to me what I can do >with the macro language that would keep such a thing from working the >way you would like. I think that the tags macro I have works pretty well, except that MicroEMACS's regular expresions treat '*' as magic, so it doesn't work with definitions like "char *foo() { ..."; but if you search in non-MAGIC mode, then you might get bogus matches because you have to ignore the '^' and '$' characters in the pattern. Otherwise, I think it just shows how powerful MicroEMACS's macro language already is. Here are a few things *I* am hoping are in 3.10: 1. A way to bind named macros to keys directly, rather than needing the execute-macro-n kluge. 2. A way for macros to access the repeat count given to them (unless they already can and I just missed it). 3. Undo. With all of those control key combinations, I *often* find myself accidentally pressing the wrong key and wondering what in the world I did to mung my file. I usually have to kill the buffer, losing the changes, and reload the file. This is an incentive to save frequently, to be sure. Even limited undo like vi has would be wonderful. 4. More efficient screen redraw in the termcap driver, particularly use of the insert-line and delete-line capabilities. It's just intolerable at 1200 baud currently. 5. Entab- and detab- line functions that only affect leading spaces, so they don't screw up strings in code. Using these, it would be possible to write good shift macros like vi's << and >>; you would detab the lines, add or delete the appropriate number of leading spaces, and then re-entab the lines. I know, I ought to just hack on the beta and do it myself. Wish I had the time! For many purposes, particularly editing multi-file sources, though, MicroEMACS is great. The programmability is wonderful for a non-huge editor. ----- David MacKenzie Environmental Defense Fund edf@rocky2.rockefeller.edu (...rutgers!cmcl2!rocky2!edf)
pjh@mccc.UUCP (Pete Holsberg) (11/21/88)
How about a mail.rc command to change the "search" command to something
other than ^S?? Thanks.
--
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800johnm@trsvax.UUCP (11/21/88)
Before I get started, it seems that Mr. Lawrence took some offence at what I had meant to be constructive criticism. I am very sorry if you mistook my tone to be ungrateful or unfairly critical, it was not meant to be. I appreciate your work and was merely discussing changes I would like to make or see made that would make it the best possible editor for my purposes (i.e. editing C files on a Vax, Amiga, and PC clones. >>I would really love it if the size of a displayed tab was an adjustable thing >>and also if the tab implementation (spaces or tab) was selectable. >> > in version 3.10 $hardtab is the number of columns between hard >tab stops, and $softab is the number of spaces used in soft tabs. (If >$softab is zero, hard tabs are used. $hardtab defaults to 8). Hurray! >>Yes, I too would like to make this change and one other. Have you ever noticed >>that splitting the screen slows you down massively when you start editing. > >Maybe I am not running on a slow enough machine, but with two or three >windows, I don't notice the difference. The code for this is in the >linsert() function in line.c. Just don't update the change flags for the >other windows. As somebody else pointed out, you have to be on a PC to notice it. I'll look for it in the new version. Thanks for telling me where to look. >> c) temporary windows that go away once you press a key (excellent for >> functions like apropos) > > I though very seriously about this, but I really don't know >what would be a good implementation of this. Too many of these >"Temporary output" commands fill up the window and require the user to >page throught them. How about splitting the current window and then deleting the temporary window when a ^G is pressed? >> d) a function that creates a file with a unique name > > Macro Function? For temporary files? explain. It has to do with my firing off makes. Don't let it worry you, it was just a little rambling. >> e) functions to return the size of files and delete files > > directory listers and OS remove or delete commands seem to work >real well for this. ^X$ and ^X! call them up very easily... I don't >understand why yet another machine dependant function is needed for this. There is a problem with that, there is no way to react to the outcome of the execution. Suppose the file isn't there? If not then there is no variable set to the exit value of the command because it is not an internal one. >> f) file name completion > > Again, machine incompatability. I don't have to write these >once, but 12 times. Not having access to a lot of the more unusual >machines I am very hesitant to make uEMACS at all machine dependant. I >really wrote it because I was VERY angry about learning loads of >different editors everytime I switched hardware. This is kind of a strange reply considering the video use that you have in there now (very machine specific), and also the fact that filename completion is only machine dependant WITHIN the code. Filename completion as far as the user is concerned will probably stay the same across all machines. I'm not saying that you should be forced to write this or anything else that you don't want to. But I or someone else can take a stab at it, give you the code, and it can just be an #ifdef in the code. People who don't want it don't have to have it. >>Which brings me to my final point. I could probably do a couple of these myself >>if I had the latest uEmacs source or knew where to get it (or even what version >>it is). Can anybody tell me where to get it? > > Did you try the docs? Every README file or EMACS.MSS file from >version 3.3 and up (4 years ago) has had my address/phone and BBS phone >numbers in it. My apologies if you somehow got uEMACS without these >files, but I have been on the net a lot and available through the ibm >and emacs groups for 3 years as well. You know, I never thought of looking in the docs :-). That was pretty dumb of me. >>While I'm on a wish list kick, how about: >> a) a tags function (NOT a convoluted macro) > > So that everyone pays the price in size so that a few can have >tags? Yes I know there are a lot of programmers who would like this >built in, but if I put everything like this in we would end up with >something the size of GNU emacs, and that just doesn't seem to be the >point behind all this. Instead of saying this, why don't you explore >writting a non-convoluted macro, or help point out to me what I can do >with the macro language that would keep such a thing from working the >way you would like. I saved this for last even though it came first because macros are really important to me. How about taking David Betz's ExTalk language (described in this months Byte magazine) and imbedding the ExTalk virtual machine in uEmacs? How would that help macros, glad you asked... a) Macros would become a compiled entity and the slow startups that PC users with large emacsrc files have would go away. b) The macro language would be more robust in many ways (even to the extent of being object oriented). c) If other applications begin using ExTalk then it could provide users with a common macro language across applications. d) It seems to me (from having written a 25 opcode 68000 emulator in C a long time ago) that the amount of code devoted to the macro language in the editor might even shrink. e) It is written in C and thus would be immediately portable to all the machines uEmacs is now on. John Munsch
edf@rocky2.rockefeller.edu (David MacKenzie) (11/22/88)
In article <414@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: > >How about a mail.rc command to change the "search" command to something >other than ^S?? Thanks. You mean .emacsrc? How about bind-to-key search-forward M-S which binds it to ESC S. ----- David MacKenzie Environmental Defense Fund edf@rocky2.rockefeller.edu (...rutgers!cmcl2!rocky2!edf)