mrd@sun.soe.clarkson.edu (Mike DeCorte) (09/22/88)
Hello,
Some of the people around here (including myself) have noticed some
things that are different or unavailable in GNU emacs and would like
to know if there is someone who can help or perhaps comment (not flame
though).
1) In MicroEmacs there is the command next-buffer. It keeps a
circular list of all the buffers and simply goes from where you are to
the next buffer on the list. I figured this would not be hard to write
up in elisp, I would simply steal some code from list-buffers or
switch-to-buffer. Well grep on the .el files does not reveal a
definition for either one and I can only assume that they are in C?!?
Have I missed something? Or is there no way for me to get a list
of the available buffers in something that I can take the car of?
2) When you are at the bottom (top) of a buffer and execute scroll-up
(scroll-down), emacs responds with "End of buffer" ("Beginning of
buffer"). Wouldn't it make a bit more sense (at least from the
users point of view) to go to the bottom (top) of the file?
3) In overwrite mode, quoted-insert, inserts and does not overwrite.
Yes I know it is quoted-insert but that is still a bit odd.
4) Is there some way to keep multiple marks? In other words, M-5 ^X^X
would swap my point with my 5th mark and M-5 C-space would set my 5th
mark etc. This would not only be useful from the users point of view,
but it would make emulating other edits easier. Many editors define
something like begin-region end-region for cut and paste operations
(no, not only word-star).
5) An emacs manual would be REALLY nice to have.
thankyou,
--
Michael DeCorte // (315)268-2292 // P.O. Box 652, Potsdam, NY 13676
Internet mrd@sun.soe.clarkson.edu // Bitnet mrd@clutx.bitnet
------------------------------------------------------------
Clarkson Archiver Server
archiver-server@sun.soe.clarkson.edu
archive-server%sun.soe.clarkson.edu@omnigate.bitnet
dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server
------------------------------------------------------------jr@PIZZA.BBN.COM (John Robinson) (09/23/88)
> I figured this would not be hard to write > up in elisp, I would simply steal some code from list-buffers or > switch-to-buffer. Well grep on the .el files does not reveal a > definition for either one and I can only assume that they are in C?!? > Have I missed something? Or is there no way for me to get a list > of the available buffers in something that I can take the car of? Yes there are a lot of functions in C that are callable from lisp. In this case, the function you want is called (buffer-list), which is not documented in the way that ^Ha can find it for you, though ^Hf will tell you what it does. It also shows up if you say M-x apropos buffer. I tracked this down in about two minutes using the excellent emacs-tags function recently seen here. > 2) When you are at the bottom (top) of a buffer and execute scroll-up > (scroll-down), emacs responds with "End of buffer" ("Beginning of > buffer"). Wouldn't it make a bit more sense (at least from the > users point of view) to go to the bottom (top) of the file? This sounds wacky to me. scroll-{up,down} move the window. point moves as a side effect, since the semantics of windows require that point stay inside. If instead the window stays put but point moves anyway, that seems broken to me. Obviously the other style can be written as something like: (move-to-window-line 0) (next-line (window-height)) (if (not eobp) (recenter 0)) [warning - this is not tested] You may even be able to find something similar in one of the emulators for other editors (vip.el, edt.el, gosmacs.el) > 3) In overwrite mode, quoted-insert, inserts and does not overwrite. > Yes I know it is quoted-insert but that is still a bit odd. Ack! It is much nicer to be able to type ^Qx to insert an x than to leave over-write mode, type x, and then reenter overwrite mode. Overwriting with a quoted character is just ^Q <char> ^D after all, still easier than toggling modes (and probably less common, at least for me). > 4) Is there some way to keep multiple marks? In other words, M-5 ^X^X > would swap my point with my 5th mark and M-5 C-space would set my 5th > mark etc. Look under ^H a register. Registers are the multipe marks you want. Of course, they can hold text as well as buffer positions, but that's just sugaring. :-) > 5) An emacs manual would be REALLY nice to have. You can order one from the Free Software Foundation for $15, and they are sold in some technical bookstores. All the information in the manual is available on-line in the Info (^Hi) command, and source for the manual is distributed with emacs. An emacs lisp manual (maybe what you really wanted) is in the works. I learn most of what I need to know by reading the source; that's a big part of the reason why the GNU license insists that it always be included. The emacs-tags function helps navigate the sources. > Thankyou, anytime. /jr jr@bbn.com or bbn!jr
spolsky-avram@CS.YALE.EDU (Joel Spolsky) (09/23/88)
In article <MRD.88Sep21225314@sun.soe.clarkson.edu> mrd@sun.soe.clarkson.edu (Mike DeCorte) writes: | 2) When you are at the bottom (top) of a buffer and execute scroll-up | (scroll-down), emacs responds with "End of buffer" ("Beginning of | buffer"). Wouldn't it make a bit more sense (at least from the | users point of view) to go to the bottom (top) of the file? I vote for this one!!! It makes more sense by a long shot. It is more instinctive to hit Page Up a couple of times than to try and hit Meta-SHIFT-< (what with remembering which shift keys to use...:-) While we're on the subject, when I first started using emacs, I thought I would get used to ^K not deleting the newlines. Needless to say I still haven't gotten use to this: I generally delete paragraphs and other such regions by hitting ^K a few times (which is more instinctive, I think, than blocking it off), and the "stutter" effect is aggravating. Especially since this means that M-5 C-k does not mean the same thing as C-k C-k C-k C-k C-k ... Any suggestions for fixes? | 5) An emacs manual would be REALLY nice to have. It's in the package! online! in a dozen happy formats! Joel Spolsky bitnet: spolsky@yalecs uucp: ...!yale!spolsky Yale University arpa: spolsky@yale.edu voicenet: 203-436-1483 "You can't expect to wield supreme executive power just 'cause some watery tart threw a sword at you!!"
spolsky-avram@CS.YALE.EDU (Joel Spolsky) (09/23/88)
In article <1423.590955666@pizza> jr@bbn.com writes: | | 2) When you are at the bottom (top) of a buffer and execute scroll-up | | (scroll-down), emacs responds with "End of buffer" ("Beginning of | | buffer"). Wouldn't it make a bit more sense (at least from the | | users point of view) to go to the bottom (top) of the file? | | This sounds wacky to me. scroll-{up,down} move the window. point | moves as a side effect, since the semantics of windows require that | point stay inside. If instead the window stays put but point moves | anyway, that seems broken to me. Not in my mind. I think of M-v as "move cursor up one pages worth" and I expect it to try no matter where the window is. Why should ^P affect the cursor and M-v affect the scroll region? On my terminal they're attached to (cursor up) and (page up), why shouldn't they behave like every other word processor in existance? Joel Spolsky bitnet: spolsky@yalecs uucp: ...!yale!spolsky Yale University arpa: spolsky@yale.edu voicenet: 203-436-1483 "You can't expect to wield supreme executive power just 'cause some watery tart threw a sword at you!!"
halvers@iraq.steinmetz (Pete Halverson) (09/23/88)
In article <38598@yale-celray.yale.UUCP> spolsky@yale.edu (Joel Spolsky) writes > >While we're on the subject, when I first started using emacs, I thought >I would get used to ^K not deleting the newlines. Needless to say I >still haven't gotten use to this: I generally delete paragraphs and >other such regions by hitting ^K a few times (which is more >instinctive, I think, than blocking it off), and the "stutter" effect >is aggravating. Especially since this means that M-5 C-k does not mean >the same thing as C-k C-k C-k C-k C-k ... > >Any suggestions for fixes? How about the following, which I bind to "M-k": (defun kill-entire-line (&optional arg) "Kill the entire line that the cursor is on. With prefix argument, kill that many lines from point. Negative arguments kill lines backward. When calling from a program, nil means \"no arg\", a number counts as a prefix arg." (interactive "*P") (beginning-of-line) (kill-region (point) (progn (if arg (forward-line (prefix-numeric-value arg)) (if (eobp) (signal 'end-of-buffer nil) (forward-line 1))) (point)))) >Joel Spolsky ~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Pete Halverson ARPA: halverson@ge-crd.ARPA GE Corporate R&D Center UUCP: uunet!steinmetz!iraq!halvers Schenectady, NY halvers@iraq.steinmetz.UUCP "IBM supports UNIX like a rope supports a hanged man" -- net quote
jr@bbn.com (John Robinson) (09/23/88)
In article <38609@yale-celray.yale.UUCP>, spolsky-avram@CS (Joel Spolsky) writes [about (previous-line) and (scroll-down)]: >On my terminal >they're attached to (cursor up) and (page up), why shouldn't they >behave like every other word processor in existance? Okay, okay, sorry I started this. Look, GNU (and other) emacses' BIG win is that if you don't like how it does something, you can change it! Try that with your wordstar. I think someone even wrote a wordstar.el. Would you like to own up? As to "fixes" proposed in this discussion, they ain't. This is religion, folks; there's no right and wrong. Emacs predates "word processors" by a goodly number of years. Those who have lived with (ITS/Bottoms20/GNU) emacses all these years appreciate the consistency they have shown in pritnear all of the default behaviors. The growing body of smart packages to go with are that much more sugar. Maybe the problem is that rigid word procesors made for rigid habits, and since they were for-money products with lean support staff and no friendly user community to improve them, people got their features, and bugs, wired into their fingers. I like Dijkstra's quote about how microprocessors set the art of computer programming back about 20 years. I am tempted to say the same thing about "word processors" and editors. But I won't. Diving for the asbestos... -- /jr jr@bbn.com or bbn!jr
gjditchfield@violet.waterloo.edu (Glen Ditchfield) (09/23/88)
In article <38598@yale-celray.yale.UUCP> spolsky@yale.edu (Joel Spolsky) writes: >While we're on the subject, when I first started using emacs, I thought >I would get used to ^K not deleting the newlines. Needless to say ... > >Any suggestions for fixes? Find a copy of super-kill.el. C-k C-l kills the current line. In general, C-k <movement command> kills everything from point to the spot <movement command> goes to. You'll love it.
brians@hpcljms.HP.COM (Brian Sullivan) (09/24/88)
Here is a function that I use that implements a better ^K function. It will kill the entire line if you are in the first column, otherwise it behaves like the traditional kill-line function. (defun kill-line-twice (&optional numlines) "Acts like normal kill except kills entire line if at beginning" (interactive "p") (cond ( (or (= (current-column) 0) (> numlines 1)) (kill-line numlines) ) ( t (kill-line) ) ) )
mark@comp.vuw.ac.nz (Mark Davies) (09/25/88)
In article <38598@yale-celray.yale.UUCP> spolsky@yale.edu (Joel Spolsky) writes > >While we're on the subject, when I first started using emacs, I thought >I would get used to ^K not deleting the newlines. Needless to say I >still haven't gotten use to this: I generally delete paragraphs and >other such regions by hitting ^K a few times (which is more >instinctive, I think, than blocking it off), and the "stutter" effect >is aggravating. Especially since this means that M-5 C-k does not mean >the same thing as C-k C-k C-k C-k C-k ... > >Any suggestions for fixes? When we first switched to GNU from Gosling emacs I missed the kill-lines-magic variable which if set caused a C-k at the beginning of a line to kill the whole line (including newline) but used anywhere else to behave traditionally, so I added it to GNU emacs. We have been using this successfully for the last 3 years. Here are the diffs to add this to version 18.51 *** simple.el.orig Tue May 24 02:49:48 1988 --- simple.el Tue May 24 11:57:52 1988 *************** *** 1,5 **** --- 1,6 ---- ;; Basic editing commands for Emacs ;; Copyright (C) 1985, 1986, 1987 Free Software Foundation, Inc. + ;; added variable kill-lines-magic mark at vuw90x 17/12/85 ;; This file is part of GNU Emacs. *************** *** 491,496 **** --- 492,502 ---- (forward-line (- arg)) (skip-chars-forward " \t")) + ; mwd vuw Dec 1985 + (defconst kill-lines-magic nil + "*if non-nil a kill-line at the beginning of a line kills the entire line, + including the newline at the end") + (defun kill-line (&optional arg) "Kill the rest of the current line; if no nonblanks there, kill thru newline. With prefix argument, kill that many lines from point. *************** *** 499,504 **** --- 505,512 ---- When calling from a program, nil means \"no arg\", a number counts as a prefix arg." (interactive "*P") + (if (and kill-lines-magic (bolp) (not arg)) ; mwd vuw dec 1985 + (setq arg 1)) (kill-region (point) (progn (if arg -- Domainised: mark@comp.vuw.ac.nz Bang form: ...!uunet!vuwcomp!mark
m1tag00@fed.FRB.GOV (Tim A. Grunwald) (09/27/88)
In article <38598@yale-celray.yale.UUCP>, spolsky-avram@CS.YALE.EDU (Joel Spolsky) writes: > ... > While we're on the subject, when I first started using emacs, I thought > I would get used to ^K not deleting the newlines. Needless to say I > still haven't gotten use to this: I generally delete paragraphs and > other such regions by hitting ^K a few times (which is more > instinctive, I think, than blocking it off), and the "stutter" effect > is aggravating. Especially since this means that M-5 C-k does not mean > the same thing as C-k C-k C-k C-k C-k ... > > Any suggestions for fixes? > Yes, I wrote a simple delete-line function which I assign to a function key. (defun delete-line (&optional count) "Delete line point is on. With ARG delete current line and ARG - 1 more lines" (interactive "P") (beginning-of-line) (let ( (beg (point)) ) (forward-line count) (delete-region beg (point)) ) ) Tim Grunwald Federal Reserve Board uunet!fed!m1tag00
cudcv@warwick.ac.uk (Rob McMahon) (10/04/88)
In article <38609@yale-celray.yale.UUCP> spolsky-avram@CS.YALE.EDU (Joel Spolsky) writes: | In article <1423.590955666@pizza> jr@bbn.com writes: | | | 2) ... Wouldn't it make a bit more sense [if scroll-{up,down} at the | | | limit of the file went] to the bottom (top) of the file? | | | | ... scroll-{up,down} move the window. point moves as a side effect, since | | the semantics of windows require that point stay inside. | | Not in my mind. I think of M-v as "move cursor up one pages worth" and I | expect it to try no matter where the window is. Why should ^P affect the | cursor and M-v affect the scroll region? But doesn't the fact that ESC 4 M-v leaves point where it is, just moving the window by four lines, show that jr's interpretation is correct ? ^P moves point, and M-v moves the window because they're different commands, otherwise there would be no difference between ESC 4 ^P and ESC 4 M-v. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
spolsky-joel@CS.YALE.EDU (Joel Spolsky) (10/08/88)
cudcv@warwick.ac.uk (Rob McMahon) writes: | spolsky-joel@CS.YALE.EDU (Joel Spolsky) (ME!) writes: | | In article <1423.590955666@pizza| jr@bbn.com writes: | | | | 2) ... Wouldn't it make a bit more sense [if scroll-{up,down} at the | | | | limit of the file went] to the bottom (top) of the file? | | | | | | ... scroll-{up,down} move the window. point moves as a side effect, since | | | the semantics of windows require that point stay inside. | | (lots of discussion of such `semantics' deleted) OK OK enough of this. I wrote these two functions to make emacs behave like I expect it to. I like the idea of always moving the cursor a fixed number of lines better because: - page up in the "top" of the file still moves the cursor to the top line, and vice-versa - if you page several screens away to look at something, and then page back, your cursor will end up in the exact same place where you left it. Here are the functions. I bind them to C-v and M-v. They are my first in emacs-lisp so if they are a bit screwy please eMail me. ----- ;;; An attempt to rebind the page down and page up keys to behave ;;; as I expect them to, in other words, to move up(down) the number ;;; of lines in the buffer minus 1. (defun page-down (&optional arg) "Move point down a page worth of lines" (interactive "p") (next-line (if (> arg 1) (* (- (window-height) 2) arg) (- (window-height) 2)))) (defun page-up (&optional arg) "Move point up a page worth of lines" (interactive "p") (previous-line (if (> arg 1) (* (- (window-height) 2) arg) (- (window-height) 2)))) +----------------+---------------------------------------------------+ | Joel Spolsky | bitnet: spolsky@yalecs uucp: ...!yale!spolsky | | | arpa: spolsky@yale.edu voicenet: 203-436-1483 | +----------------+---------------------------------------------------+ These opinions are mine. I do not represent Yale University in any way. (Yale LIKES the way emacs scrolling works. Jeeesh.)