Article View: comp.editors
Article #3551Re: why do editors "shrink-wrap" the text?
From: Silver
Date: Mon, 17 Apr 1989 03:39
Date: Mon, 17 Apr 1989 03:39
50 lines
2701 bytes
2701 bytes
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
Technical Details
Message-ID:
<Apr.16.23.39.58.1989.2541@athos.rutgers.edu>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!rutgers!aramis.rutgers.edu!athos.rutgers.edu!gaynorReferences:
<1686@wpi.wpi.edu> <97499@sun.Eng.Sun.COM> <Apr.5.05.39.04.1989.17024@athos.rutgers.edu> <3903@mipos3.intel.com> <Apr.16.20.57.07.1989.2012@athos.rutgers.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!rutgers!aramis.rutgers.edu!athos.rutgers.edu!gaynor From: gaynor@athos.rutgers.edu (Silver) Newsgroups: comp.editors Subject: Re: why do editors "shrink-wrap" the text? Message-ID: <Apr.16.23.39.58.1989.2541@athos.rutgers.edu> Date: 17 Apr 89 03:39:59 GMT References: <1686@wpi.wpi.edu> <97499@sun.Eng.Sun.COM> <Apr.5.05.39.04.1989.17024@athos.rutgers.edu> <3903@mipos3.intel.com> <Apr.16.20.57.07.1989.2012@athos.rutgers.edu> Distribution: na Organization: Rutgers Univ., New Brunswick, N.J. Lines: 50