landauer@morocco.Sun.COM (Doug Landauer) (04/05/89)
In article <1686@wpi.wpi.edu>, jhallen@wpi.wpi.edu (Joseph H Allen) wrote: > And, most importantly and with religeous intensity, when moving > between lines, the cursor MUST NOT EVER change column position. > If the cursor gets placed after the end of a line or if it gets > placed in the middle of a tab field, then, on the next command > which requires the cursor to be in a valid position, the cursor > should jump to the beginning of the next line, end of current line > or beginning or end of the tab field, depending on the command. WHY should the cursor jump at all??!?!? Why is there such a ridiculous notion as "valid position"??? If the cursor is out beyond the end of a line and you start typing, then dammit the editor should insert enough spaces to allow you to type there! If it's "in a tab field", then the tab should convert to the appropriate amount of spaces! In other words, I agree with your first sentence more than you do! I hate this notion that programmer's editors (vi & emacs) have of some kind of "shrink-wrap" covering the existing text in a file. My mental model of a text file is that it is like a piece of paper. I move the pen (the cursor) and then write stuff there. *Right there!*. Not at some location that the editor picks because it was easy for the guy who designed the editor. -- Doug Landauer -- Sun Microsystems, Inc. -- Software Products Group landauer@sun.com or ...!sun!landauer -- P.S. does gnuemacs have a mode where it works that way?
mike@arizona.edu (Mike Coffin) (04/05/89)
From article <97499@sun.Eng.Sun.COM> (Doug Landauer): > If the cursor is out beyond the end of a line and you start typing, > then dammit the editor should insert enough spaces to allow you to > type there! If it's "in a tab field", then the tab should convert > to the appropriate amount of spaces! [...] > -- P.S. does gnuemacs have a mode where it works that way? Yes. (Any question of the form "does gnuemacs have ..." has the answer "yes" ;-) Try picture-mode. You can even change the default direction of cursor movement and type from top to bottom or right to left if you want to. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike Tucson, AZ 85721 (602)621-2858
gaynor@athos.rutgers.edu (Silver) (04/05/89)
landauer@morocco.sun.com > Why is there such a ridiculous notion as "valid position"??? If the cursor > is out beyond the end of a line and you start typing, then dammit the editor > should insert enough spaces to allow you to type there! If it's "in a tab > field", then the tab should convert to the appropriate amount of spaces! This action is easy enough to program into reasonable editors. However, there's enough whitespace-sensitive shtuff out there that this is a little too dangerous to make this the default. White characters are usually `invisible' in the sense that you can't easily discern the difference between " " (4 spaces, a tab, and a space) and " " (9 spaces) In GNU Emacs, I would probably achieve your suggestion by making a minor mode called White (or something), in which whitespace is assumed to be freely mungeable. Regards, [Ag] gaynor@rutgers.edu
gaynor@athos.rutgers.edu (Silver) (04/05/89)
landauer@morocco.Sun.COM (Doug Landauer) writes: > -- P.S. does gnuemacs have a mode where it works [as detailed in my previous > article, where whitespace is freely mungeable to match cursor > motion]? Yes, picture-mode. It appears that many of the motion commands will work in other modes as well. Regards, [Ag] gaynor@rutgers.edu
jhallen@wpi.wpi.edu (Joseph H Allen) (04/05/89)
In article <97499@sun.Eng.Sun.COM> landauer@sun.com (Doug Landauer) writes: >In article <1686@wpi.wpi.edu>, jhallen@wpi.wpi.edu (Joseph H Allen) wrote: >> And, most importantly and with religeous intensity, when moving >> between lines, the cursor MUST NOT EVER change column position. >> If the cursor gets placed after the end of a line or if it gets >> placed in the middle of a tab field, then, on the next command >> which requires the cursor to be in a valid position, the cursor >> should jump to the beginning of the next line, end of current line >> or beginning or end of the tab field, depending on the command. > >WHY should the cursor jump at all??!?!? Why is there such a ridiculous >notion as "valid position"??? If the cursor is out beyond the end of >a line and you start typing, then dammit the editor should insert >enough spaces to allow you to type there! If it's "in a tab field", >then the tab should convert to the appropriate amount of spaces! >-- P.S. does gnuemacs have a mode where it works that way? gnuemacs has "picture-mode" or something similarly named. It does the same thing that the turbo editors (which is what you're describing) do. The only problem I have with this is that I like using the Cursor Right key to move to the beginning of the next line and (unique to my cursor motion method (on my own very non-portable editor)) the Cursor Left key to move to the end of the line when the cursor is in the "invalid-position" after the end of a line. I have to occasionally use the Turbo-C editor which has the cursor motion the way you like. I personally can't stand having to hit the "End" key so often. Wordstar method: move to the end of the line or beginning of tab stop when cursor moves to an "invalid" position [yuk!!] Turbo method: change tabs into spaces and extend lines when cursor moves to "invalid" positions [nice for drawing text pictures] My method: see above. Actually, I got this idea from the Radio Shack "Scriptset" editor- only Scriptset gave an error message which required a reply if you tried to type in the "invalid" positions. - - - - - - How does everyone like the idea of formatting paragraphs in this manner: When you type in a paragraph, lines which continue get a SPACE character appended to them. The last line of a paragraph and non-paragaph lines may not contain spaces after them (I.E. this indicates "hard CRs"). This way, a "global reformat paragraph" command can work and WYSIWYG-like editing which automatically reformats paragraphs can be done on normal text files. Also, what is everyone's preferred methode for storing format information in normal text files? What I'd like to do is use "dot-commands" for things like margen settings and ANSI escape sequences for attributes- but then, I don't like seeing the "dot-commands" and not everyone has ANSI terminals. Another possibility is to have an auxilliary file along with each text file to store the format information. The idea is to make a word processor suitable for most college-level paper and "news" message writting which keeps the file formatted as "normal" ascii text.
cks@white.toronto.edu (Chris Siebenmann) (04/06/89)
In article <97499@sun.Eng.Sun.COM> landauer@sun.com (Doug Landauer) writes: | In other words, I agree with your first sentence more than you do! I | hate this notion that programmer's editors (vi & emacs) have of some | kind of "shrink-wrap" covering the existing text in a file. My mental | model of a text file is that it is like a piece of paper. I move the | pen (the cursor) and then write stuff there. *Right there!*. Not at | some location that the editor picks because it was easy for the guy who | designed the editor. Here we have a conflict between two basic models of how editors should work. One school has the view that you are editing the bytes in the file directly; what you see on the screen is just an approximation to this (tabs are expanded for your convenience, for example). The other school holds that what you're editing is a sheet of paper with the text plunked down on it, so you should be able to scribble in the margins or in the middle of a tab stop. Both views have their virtues (it's easier to make changes in random places with the paper view, but it's easier to edit a binary file with the stream-of-bytes view). For better or worse, Emacs-style editors (and to a lesser extent vi-style editors as well) have chosen the stream-of-bytes approach. -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann ...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks cks@white.toronto.edu or ...!utgpu!{,csri!}cks
jlg@lanl.gov (Jim Giles) (04/06/89)
From article <10088@megaron.arizona.edu>, by mike@arizona.edu (Mike Coffin): > Yes. (Any question of the form "does gnuemacs have ..." has the > answer "yes" ;-) Try picture-mode. You can even change the default > direction of cursor movement and type from top to bottom or right to > left if you want to. I'm not sure your parenthetical is true. I want an editor in which the carriage return key is _only_ a cursor positioning key. No matter what 'mode' the editor is in, I want the carriage control key to put the cursor at the beginning of the next line - and _most_especially_NOT_ insert a new line or split the line I was on! In other words, I want the carriage control key to behave exactly as it does on a dumb mechanical typewriter (even in 'insert mode'). Does gnuemacs do that (without me having to rewrite the keyboard driver or assign a macro to the carriage return key or something)?
mike@arizona.edu (Mike Coffin) (04/06/89)
From article <11542@lanl.gov>, by jlg@lanl.gov (Jim Giles): > I want an editor in which the carriage return key is _only_ a cursor > positioning key. No matter what 'mode' the editor is in, I want the > carriage control key to put the cursor at the beginning of the next > line - and _most_especially_NOT_ insert a new line or split the line > I was on! That's how gnuemacs picture-mode works. Picture-mode provides the illusion of a semi-infinite quarter plane --- you just move and plop down text. Carriage return moves you to the beginning of the next line; it only inserts a new line if you are at the end of the buffer. For those familiar with vi but not emacs, picture-mode is not a 'mode' in the sense of vi insert mode. In gnuemacs you generally don't hop from mode to mode in the same buffer. Instead, you use fortran-mode to edit Fortran, latex-mode for LaTeX, text-mode for text, etc. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike Tucson, AZ 85721 (602)621-2858
gaynor@athos.rutgers.edu (Silver) (04/06/89)
> I want an editor in which the carriage return key is _only_ a cursor > positioning key. No matter what 'mode' the editor is in, I want the carriage > control key to put the cursor at the beginning of the next line - and > _most_especially_NOT_ insert a new line or split the line I was on! > Does gnuemacs do that (without me having to rewrite the keyboard driver or > assign a macro to the carriage return key or something)? Associating functionality with the insertion of a newline (e.g, the automatic justification, indentation, etc.) can save a lot of editing time in the long run. However, I agree that often, one simply wants to insert a newline. For the modes I use most often in GNU Emacs, I bind [RET] to insert a newline with all the bells and whistles, and [LFD] to insert a raw newline. (As a side point, most extension languages are not macro languages. Macros are provided as a way to make fast, primitive, interactive extensions, but they are not the typical modus operandi in the editor machine. Modern editor extension languages are really full-blown languages and should be treated as such.) I took a whack at automating the process, but found the number of breeches in standard nomenclature and coding practices reduced the function to a poor heuristic. Load the file of lisp if necessary (using require or load), and rebind the keys (using define-key). Regards, [Ag] gaynor@rutgers.edu
neubauer@bsu-cs.bsu.edu (Paul Neubauer) (04/06/89)
In article <11542@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <10088@megaron.arizona.edu>, by mike@arizona.edu (Mike Coffin): >> Yes. (Any question of the form "does gnuemacs have ..." has the >> answer "yes" ;-) Try picture-mode. You can even change the default > >I'm not sure your parenthetical is true. I want an editor in which the >carriage return key is _only_ a cursor positioning key. No matter what >'mode' the editor is in, I want the carriage control key to put the >cursor at the beginning of the next line - and _most_especially_NOT_ >insert a new line or split the line I was on! In other words, I want >the carriage control key to behave exactly as it does on a dumb mechanical >typewriter (even in 'insert mode'). Does gnuemacs do that (without me >having to rewrite the keyboard driver or assign a macro to the carriage >return key or something)? Sure you can do that easily. The point that many posters have made here recently is that an editor is a VERY personal tool. You want the return key to have a particular behavior. I find that particular behavior very irritating when I encounter it. I therefore want an editor that I can (without unreasonable effort) customize to my own preferences. Rebinding the return key is no big deal. Why do you seem to assume that GNU Emacs ought to conform to your preferences by default? My observation is that comparatively few people happen to want that return key behavior. I could very well be wrong and if I am, then there is almost certainly someone around who has exactly what you want and can send it to you, and if I am right, then you may have to do it yourself. (Which should not be more than a couple of lines added to your .emacs file.) One of the characteristic features of Emacs is precisely the fact that not only can it be customized, but its philosophy actively encourages you to customize it to suit yourself. Emacs is not alone in this, but it (and RMS) are certainly up toward the head of the pack. I admit that LISP is rather more different from the languages that most people use than TPU, for example, but so what? If you want to use it you will. Please don't anybody flame RMS for doing the service he has just because you would rather he had done something differently. No two people seem to really agree on everything anyway. -- Paul Neubauer neubauer@bsu-cs.bsu.edu neubauer@bsu-cs.UUCP <backbones>!{iuvax,pur-ee}!bsu-cs!neubauer
gast@lanai.cs.ucla.edu (David Gast) (04/07/89)
In article <1706@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: >How does everyone like the idea of formatting paragraphs in this manner: > > When you type in a paragraph, lines which continue get a SPACE character >appended to them. The last line of a paragraph and non-paragaph lines may not >contain spaces after them (I.E. this indicates "hard CRs"). This way, a >"global reformat paragraph" command can work and WYSIWYG-like editing which >automatically reformats paragraphs can be done on normal text files. This is not a good idea for general use. It assumes that you are using a word processing package like WORD* (that is a Kleene Star). I do not want to use a WYSIWYG text formatting program. > Also, what is everyone's preferred methode for storing format information in >normal text files? LaTeX commands > The idea is to make a word processor suitable for most college-level paper >and "news" message writting which keeps the file formatted as "normal" ascii >text. If I want to reformat a paragraph while preparing an item to post to news, I use the command fmt. Anyway, news and mail both have limits on line length (RFC821 specifies 1000 characters) but I am not sure what limits are typically in place. Therefore, your idea will result in long lines/paragraphs being truncated. Further, I do not want to have to have every word processor built in so I can read news in whatever format you decide to send it. David Gast gast@cs.ucla.edu {uunet,ucbvax,rutgers}!{ucla-cs,cs.ucla.edu}!gast
jhallen@wpi.wpi.edu (Joseph H Allen) (04/08/89)
In article <22669@shemp.CS.UCLA.EDU> gast@cs.ucla.edu (David Gast) writes: >In article <1706@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: >>How does everyone like the idea of formatting paragraphs in this manner: > >> When you type in a paragraph, lines which continue get a SPACE character >>appended to them. The last line of a paragraph and non-paragaph lines may not >>contain spaces after them (I.E. this indicates "hard CRs"). This way, a >>"global reformat paragraph" command can work and WYSIWYG-like editing which >>automatically reformats paragraphs can be done on normal text files. > >This is not a good idea for general use. It assumes that you are using >a word processing package like WORD* (that is a Kleene Star). I do not >want to use a WYSIWYG text formatting program. No no, I didn't make myself clear and you misunderstood. I'm thinking of writting an editor which does this- the idea being that appending some extra spaces to paragraph continuation lines won't screw up any other programs (news, for example) but will allow the editor to do automatic paragraph reformatting a la WYSIWYG. eat this, line counter.
las) (04/11/89)
In article <Apr.5.05.39.04.1989.17024@athos.rutgers.edu> gaynor@athos.rutgers.edu (Silver) writes: }landauer@morocco.Sun.COM (Doug Landauer) writes: }} -- P.S. does gnuemacs have a mode where it works [as detailed in my previous }} article, where whitespace is freely mungeable to match cursor }} motion]? }Yes, picture-mode. It appears that many of the motion commands will work in }other modes as well. The picture-mode macros silently fill lines out to the cursor position with whitespace characters whenever you move the cursor beyond the end of a line. (Well, not quite silently, the "buffer-modified" flag is turned on so that it shows on the status line that you've made a change). I would prefer that the fill operation be postponed until I actually type some data. In my "spare" time (ha!) I hope to rewrite the macros to support this if it is possible. Has anyone already done this or something like it? regards, Larry -- Signed: Larry A. Shurr (att!cbnews!cbema!las) Clever signature, Wonderful wit, Outdo the others, Be a big hit! - Burma Shave (With apologies to the real thing. The above represents my views only.) (Please note my mailing address. Mail sent to me on cbnews doesn't make it.)
tpriddy@homrun.intel.com (Tim Priddy) (04/15/89)
In article <Apr.5.05.39.04.1989.17024@athos.rutgers.edu>, gaynor@athos writes: >> -- P.S. does gnuemacs have a mode where [...] whitespace is freely >> mungeable to match cursor motion? > >Yes, picture-mode. Ack! It doesn't work with the mouse. Tacked on is right. Tim Priddy (Oakland Coliseum, Sec: 123, row: 3, seat: 13) internet: tpriddy@homrun.intel.com uucp: ...!{decwrl|hplabs!oliveb}!intelca!mipos3!tpriddy
gaynor@athos.rutgers.edu (Silver) (04/17/89)
> Ack! It doesn't work with the mouse. Afraid to get your hands dirty? The following function does what you want (I think), a trivial change to x-mouse-set-point. ;; Copyright (C) 1987, 1989 Free Software Foundation, Inc. (defun x-mouse-set-point (position &optional force) "Select Emacs window under the mouse, and move point to character nearest the mouse position. If FORCE is non-nil, appropriate whitespace is inserted to ensure that point is moved to the mouse's position." (let* ((relative-coordinate (x-mouse-select position)) (rel-x (car relative-coordinate)) (rel-y (car (cdr relative-coordinate)))) (if relative-coordinate (let ((delta-y (- rel-y (move-to-window-line rel-y))) (delta-x (- rel-x (move-to-column (+ rel-x (current-column)))))) (if force (progn (if (/= delta-y 0) (newline delta-y)) (if (/= delta-x 0) (indent-to-column rel-x)))))))) ;; Suitable for picture-mode. (defun x-mouse-set-point-force (position) "Like x-mouse-set-point, except the no FORCE is supplied - it is always t. So, the point is always moved directly to the mouse." (x-mouse-set-point position t)) Ok, so that's takes care of the function. Now, to bind it to a key... ;; Example binding for x-mouse-set-point-force, to the left button, shifted. (define-key mouse-map x-button-s-left 'x-mouse-set-point-force) > Tacked on is right. Are you saying picture mode is `tacked on' to GNU Emacs? Whadya want, it works... Considering what it does, I'd say it's not bad at all. I mean, it changes one of the basic, hard-coded premises of buffers in Emacs. And although it took a little work and thought, by looking at the code I guess that it wasn't difficult to implement, and it doesn't look difficult to extend. Regards, [Ag] gaynor@rutgers.edu
gaynor@athos.rutgers.edu (Silver) (04/17/89)
My last posting contained enough flaws to justify a repost. tpriddy@homrun.intel.com writes: > gaynor@rutgers.edu writes: >> [GNU Emacs has picture-mode, in which whitespace is freely mungeable to >> match cursor motion.] > > Ack! It doesn't work with the mouse. Afraid to get your hands dirty? Which windowing system? The following function does what you want in X (I think), a trivial change to x-mouse-set-point. ;; Copyright (C) 1987, 1989 Free Software Foundation, Inc. (defun x-mouse-set-point (coordinate &optional force) "Select Emacs window under the mouse, and move point to the mouse COORDINATE. If optional FORCE is non-nil, whitespace is inserted to ensure that the point is moved to the mouse POSITION." (let* ((relative-coordinate (x-mouse-select coordinate)) (rel-x (car relative-coordinate)) (rel-y (car (cdr relative-coordinate)))) (if relative-coordinate (let ((delta-y (- rel-y (move-to-window-line rel-y))) (delta-x (- rel-x (move-to-column (+ rel-x (current-column)))))) (if force (progn (if (/= delta-y 0) (newline delta-y)) (if (/= delta-x 0) (indent-to-column rel-x)))))))) ;; Suitable for picture-mode. (defun x-mouse-set-point-force (coordinate) "Like x-mouse-set-point, except FORCE is always t. So, the point is always moved directly to the mouse, possibly inserting whitespace." (x-mouse-set-point coordinate t)) Ok, so that's takes care of the function. Now, to bind it to a key... ;; Example binding for x-mouse-set-point-force, to the left button, shifted. (define-key mouse-map x-button-s-left 'x-mouse-set-point-force) tppiddy continues: > Tacked on is right. Are you saying picture mode is `tacked on' to GNU Emacs? Whadya want, it works... Considering what it does, I'd say it's not bad at all. I mean, it overrides one of the basic, hard-coded premises of buffers in Emacs. And although it took a little work and thought, by looking at the code I guess that it wasn't difficult to implement, and it doesn't look difficult to extend. Regards, [Ag] gaynor@rutgers.edu