clmebri@uop.edu (Brian Joseph Maiorella) (01/10/88)
I posted an article asking for help because emacs was "chopping off lines. I received about 20 resposes (and several more that were lost somewhere in the UOP UNIX) I want to thank everyone for trying to help. BUT, unfortunately I still have the problem. This is my fault (I reread my last article and *I* could not even figure out what I meant so it does not suprise me that no one else seemed to have any idea either. So I'm going to try one more time. I have a rather large file that should have been created in auto-fill-mode Every line in this file is cut as shown below: This is an example of a line in the middle of a para/ graph. If I use auto-fill it will correctly end lines at word boundrys for all *future* lines typed like this: This is an example of a like in the middle of a paragraph typed in autofill. Here is the problem: I want all *previously* typed text to be wrapped at word boundrys as if it was created in auto-fill-mode. Again instead of tying up this news group needlessly with what I hope is now obvious to all nonrookie emacs users please mail responses directly to: "Its the littlest things that are the hardest to find" ------------------------------------------------------------------------- | ...mcvax!uunet!mit-eddie!garp!ames!ucbvax!ucdavis!\ | |..eunetv!unido!/ ...princeton!rutgers!retix!--uop!clmebri | | ...sun!ptsfa!cogent!/ | -------------------------------------------------------------------------
Ram-Ashwin@cs.yale.edu (Ashwin Ram) (01/11/88)
In article <890@uop.edu>, clmebri@uop (Brian Joseph Maiorella) writes: > > I posted an article asking for help because emacs was "chopping off lines. > > I have a rather large file that should have been created in auto-fill-mode > Every line in this file is cut as shown below: > This is an example of a line in the middle of a para/ > graph. I have a related query. When typing in auto-fill-mode, words that run beyond the right edge of the window are wrapped around AFTER you've finished typing the entire word. Is there any way to have them wrap down to the next line as soon as you type the (right-edge + 1)'th character? I.e., is there any way, when typing Brian's example, to avoid seeing the "para/ graph" phenomenon even temporarily, but instead having "parag" wrapped around as soon as you type the "g"? Thanks... Ashwin Ram. ARPA: Ram-Ashwin@cs.yale.edu UUCP: {decvax,linus,seismo}!yale!Ram-Ashwin BITNET: Ram@yalecs ARPA: Ram-Ashwin@cs.yale.edu UUCP: {decvax,linus,seismo}!yale!Ram-Ashwin BITNET: Ram@yalecs
ekberg@home.csc.ti.com (Tom Ekberg) (01/12/88)
in article <21226@yale-celray.yale.UUCP>, (Ashwin Ram) says: > I have a related query. When typing in auto-fill-mode, words that run > beyond the right edge of the window are wrapped around AFTER you've finished > typing the entire word. Is there any way to have them wrap down to the next > line as soon as you type the (right-edge + 1)'th character? I.e., is there > any way, when typing Brian's example, to avoid seeing the "para/ > graph" > phenomenon even temporarily, but instead having "parag" wrapped around as > soon as you type the "g"? > How about the following functions? The first one is a substitute for the self-insert-command function and the second one sets up the global map to use it. It worked fine for me in my simple test case. The only thing I'm not sure of is what to do about the other keymaps which contain the self-insert-command symbol. To try it out, just evaluate (or byte-compile and load) the two functions, and enter (setup-global-map) into a lisp listener. (defun insert-self-anything (count) (interactive "p") (if (and (>= (current-column) fill-column) auto-fill-hook) (do-auto-fill)) (self-insert-command count)) (defun setup-global-map () (let ((index 0) (global-map-length (length global-map))) (while (< index global-map-length) (if (eq (aref global-map index) 'self-insert-command) (aset global-map index 'insert-self-anything)) (setq index (1+ index))))) -- tom (aisle C-4L), EKBERG%TI-CSL@CSNET-RELAY, TI-CSL!EKBERG@IM4U.UUCP
jr@LF-SERVER-2.BBN.COM (John Robinson) (01/12/88)
>> In article <890@uop.edu>, clmebri@uop (Brian Joseph Maiorella) writes: >> > >> > I posted an article asking for help because emacs was "chopping off lines. >> > >> > I have a rather large file that should have been created in auto-fill-mode >> > Every line in this file is cut as shown below: >> > This is an example of a line in the middle of a para/ >> > graph. If you mean a literal slash character in the file, then something like a query-replace-regexp of "\/^J " with "" ought to do it. If there is no extra character at the broken word aside from the newline and whitespace, you could still do it qith query-replace, but it'd be more tedious (would visit every line). >> I have a related query. When typing in auto-fill-mode, words that run >> beyond the right edge of the window are wrapped around AFTER you've finished >> typing the entire word. Is there any way to have them wrap down to the next >> line as soon as you type the (right-edge + 1)'th character? I.e., is there >> any way, when typing Brian's example, to avoid seeing the "para/ >> graph" >> phenomenon even temporarily, but instead having "parag" wrapped around as >> soon as you type the "g"? There's a tradeoff. SHould emacs check for wrapping as each character is typed, or only when white space is typed. Emacs does the latter. Since the whitespace can be typed anywhere, wrapping of 2X too long lines still works. If you check on every character but only do an equal comparison on the fill column, you have the problem when you glue together a too-long line. Obviously checking for wrapping on each character means you have to work more on each character. What I do is type a space when I want a long line to get broken, then immediately erase it. Also, if it is convenient, meta-Q will just do it for you anytime (fixing the whole paragraph while it's at it). Also, I tend to have my window a whole lot wider (80) than my fill column (70). Finally, when I am typing into the front or middle of a long line, I tend to break it first (control-O) so that the portion to the right of the cursor doesn't have to move over each character, and into the wrapped line, as I type; an automatic filler would have to check the entire line every time to solve this case - can be done, but it's a lot more work. /jr jr@bbn.com or jr@bbn.uucp
jr@LF-SERVER-2.BBN.COM (John Robinson) (01/12/88)
>> The only thing I'm not sure >> of is what to do about the other keymaps which contain the self-insert-command >> symbol. What you should really do is to make your function be the one named self-insert-command, after having carefully saved away the original definition so you can call it at the end. Then you wouldn't have to muck withthe keymaps at all. 'Fraid I can't produce the elisp for this freehand; someone else want to volunteer? /jr jr@bbn.com or jr@bbn.uucp
Ram-Ashwin@cs.yale.edu (Ashwin Ram) (01/13/88)
In article <8801121457.AA21504@ucbvax.Berkeley.EDU>, jr@LF-SERVER-2 (John Robinson) writes: > What you should really do is to make your function be the one named > self-insert-command, after having carefully saved away the original > definition so you can call it at the end. Then you wouldn't have to > muck withthe keymaps at all. 'Fraid I can't produce the elisp for > this freehand; someone else want to volunteer? How about: (fset 'standard-self-insert-command (symbol-function 'self-insert-command)) (defun self-insert-command (count) (interactive "p") (if (and (>= (current-column) fill-column) auto-fill-hook) (do-auto-fill)) (standard-self-insert-command count)) -- Ashwin Ram -- ARPA: Ram-Ashwin@cs.yale.edu UUCP: {decvax,ucbvax,harvard,...}!yale!Ram-Ashwin BITNET: Ram@yalecs
liberte@uiucdcsb.cs.uiuc.edu (01/14/88)
The trouble with replacing the self-insert-command is that it is a primitive function. As such, the new substitute function will be called by lisp functions, but the old primitive function will still be called by primitives since the address to the primitive itself is used, not the symbolic name. There are uses of the self_insert_command primitive in keyboard.c, but I think only to check whether the command being executed is self_insert_command. So we luck out in this case. Dan LaLiberte liberte@a.cs.uiuc.edu uiucdcs!liberte
tron@amdahl.amdahl.com (Ronald S. Karr) (01/15/88)
In article <39749@ti-csl.CSNET> ekberg@home.csc.ti.com (Tom Ekberg) writes: >in article <21226@yale-celray.yale.UUCP>, (Ashwin Ram) says: >> line as soon as you type the (right-edge + 1)'th character? I.e., is there >> any way, when typing Brian's example, to avoid seeing the "para/ >> graph" >How about the following functions? The first one is a substitute for the >self-insert-command function and the second one sets up the global map to use >it. One problem with replacing self-insert-command is that the Emacs main editing loop handles this as a special case, much more efficiently than if it were to call a lisp function for each character typed. The normal trick is to only handle SPC and some other characters differently, which should keep down the load average considerably. In summary, don't do this on a loaded vax. On a single-user workstation or an otherwise lightly loaded CPU, go ahead. -- tron |-<=>-| ARPAnet: amdahl!tron@Sun.COM tron@uts.amdahl.com UUCPnet: {decwrl,sun,uunet}!amdahl!tron [views above shouldn't be viewed as Amdahl views, or as views from Amdahl, or as Amdahl views views, or as views by Mr. Amdahl, or as views from his house]