longlines-mode

longlines-mode

[Reiner Steib]

Hi,

I'd like to propose some changes to longlines-mode:

- The default off `longlines-show-hard-newlines' should be changed to
  t.  When set to nil, there's soft and hard newlines are
  indistinguishable.  I tried longlines-mode several times, but I
  found it very hard to use until I discovered this option.

- The default value of `longlines-show-effect' is
  (propertize "|\n" 'face 'escape-glyph).

  `M-x customize-variable RET longlines-show-effect RET' should allow
  to change only the character (e.g. `|' -> `¶' = "PILCROW SIGN",
  "PARAGRAPH SIGN", i.e. keep the properties.

  Maybe splitting string and face would make it easier to customize
  it?

- As the "old name" of `¶' ("PILCROW SIGN", old name: "PARAGRAPH
  SIGN", U+00B6, 0xB6) indicates, this symbol might be more suitable
  as a default in `longlines-show-effect'.  Disadvantage: Is isn't an
  ASCII character, but I'd guess that > 99% users of Emacs 22+ can
  display it fine.  As `¶' is more visible than `|', we might want to
  use a smaller font as well.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: longlines-mode

[Chong Yidong]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> - The default off `longlines-show-hard-newlines' should be changed to
>   t.  When set to nil, there's soft and hard newlines are
>   indistinguishable.  I tried longlines-mode several times, but I
>   found it very hard to use until I discovered this option.

The current default is more familiar to new users, since it is the
behavior in the other editors/editing widgets that longlines-mode
imitates.  I don't know of any other editor that marks hard newlines
by default.

I suspect most of the people concerned about identifying soft vs hard
newlines with a glyph are very experienced Emacs users, who should
have no trouble changing the default.

> - The default value of `longlines-show-effect' is
>   (propertize "|\n" 'face 'escape-glyph).
>
>   `M-x customize-variable RET longlines-show-effect RET' should allow
>   to change only the character (e.g. `|' -> `¶' = "PILCROW SIGN",
>   "PARAGRAPH SIGN", i.e. keep the properties.
>
>   Maybe splitting string and face would make it easier to customize
>   it?

Good idea.

> - As the "old name" of `¶' ("PILCROW SIGN", old name: "PARAGRAPH
>   SIGN", U+00B6, 0xB6) indicates, this symbol might be more suitable
>   as a default in `longlines-show-effect'.  Disadvantage: Is isn't an
>   ASCII character, but I'd guess that > 99% users of Emacs 22+ can
>   display it fine.  As `¶' is more visible than `|', we might want to
>   use a smaller font as well.

I'll play around with it and see how well it works.

Re: longlines-mode

[Stefan Monnier]

> - The default value of `longlines-show-effect' is
>   (propertize "|\n" 'face 'escape-glyph).

>   `M-x customize-variable RET longlines-show-effect RET' should allow
>   to change only the character (e.g. `|' -> `¶' = "PILCROW SIGN",
>   "PARAGRAPH SIGN", i.e. keep the properties.

>   Maybe splitting string and face would make it easier to customize
>   it?

Or maybe Customize should have a special :type that says that by default
it should display the sexp rather than the resulting value (i.e. as if
the user had used "Show Saved Lisp Expression").

As for the default... FWIW I have the following in my .emacs:

    (setq longlines-show-effect (propertize "¶\n\n" 'face 'escape-glyph))

I find the empty line very helpful.


        Stefan

Re: longlines-mode

[Juri Linkov]

>> - The default value of `longlines-show-effect' is
>>   (propertize "|\n" 'face 'escape-glyph).
>>
>>   `M-x customize-variable RET longlines-show-effect RET' should allow
>>   to change only the character (e.g. `|' -> `¶' = "PILCROW SIGN",
>>   "PARAGRAPH SIGN", i.e. keep the properties.
>>
>>   Maybe splitting string and face would make it easier to customize
>>   it?
>
> Good idea.
>
>> - As the "old name" of `¶' ("PILCROW SIGN", old name: "PARAGRAPH
>>   SIGN", U+00B6, 0xB6) indicates, this symbol might be more suitable
>>   as a default in `longlines-show-effect'.  Disadvantage: Is isn't an
>>   ASCII character, but I'd guess that > 99% users of Emacs 22+ can
>>   display it fine.  As `¶' is more visible than `|', we might want to
>>   use a smaller font as well.
>
> I'll play around with it and see how well it works.

Maybe it would be better to use the same glyphs as were recently
discussed on emacs-devel and implemented in whitespace.el?  Or simply
to enable whitespace-mode in longlines-mode (maybe with disabling some
options unnecessary for longlines-mode)?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: longlines-mode

[Reiner Steib]

On Sat, Feb 23 2008, Chong Yidong wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>> - The default off `longlines-show-hard-newlines' should be changed to
>>   t.  When set to nil, there's soft and hard newlines are
>>   indistinguishable.  I tried longlines-mode several times, but I
>>   found it very hard to use until I discovered this option.
>
> The current default is more familiar to new users, since it is the
> behavior in the other editors/editing widgets that longlines-mode
> imitates.  I don't know of any other editor that marks hard newlines
> by default.

If the defaults are chosen for similarity to other long-lines editors,
I'd guess you should turn on `longlines-wrap-follows-window-size' by
default.  At least gedit (and notepad.exe, IIRC) do it by default.

> I suspect most of the people concerned about identifying soft vs hard
> newlines with a glyph are very experienced Emacs users, who should
> have no trouble changing the default.

Hm, maybe you are right.  I use longlines-mode only occasionally (up
to now; maybe more often in the future) either when receiving files
from others with very long lines or when editing text in Emacs before
pasting it e.g. to HTML forms or some M$ programs.

Maybe displaying an indicator in the fringe by default?

>> - The default value of `longlines-show-effect'  [...]
[ ... and customizing it. ]
>>   Maybe splitting string and face would make it easier to customize
>>   it?
>
> Good idea.
>
>> - As the "old name" of `¶' ("PILCROW SIGN", old name: "PARAGRAPH
>>   SIGN", U+00B6, 0xB6) indicates, this symbol might be more suitable
>>   as a default in `longlines-show-effect'.  [...]
>
> I'll play around with it and see how well it works.

Thanks.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: longlines-mode

[Chong Yidong]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> If the defaults are chosen for similarity to other long-lines editors,
> I'd guess you should turn on `longlines-wrap-follows-window-size' by
> default.  At least gedit (and notepad.exe, IIRC) do it by default.

I would, if not for the fact that longlines-wrap-follows-window-size
doesn't behave well when the buffer is simultaneously displayed in two
windows with different widths.  This is not fixable without C-level
changes.  There have been discussions about this issue on this list in
the past, but I don't think it'll be fixed in the immediate future.
So the current behavior is a compromise.

> Maybe displaying an indicator in the fringe by default?

That might work.

Re: longlines-mode

[Miles Bader]

I disagree about changing the defaults -- the current mode basically
acts like "everybody" expects it to act.

-Miles

-- 
Advice, n. The smallest current coin.

Re: longlines-mode

[Xavier Maillard]

   I disagree about changing the defaults -- the current mode basically
   acts like "everybody" expects it to act.

I am also pleased with the defaults, if my voice can count.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: longlines-mode

[Johan Bockgård]

Chong Yidong <cyd@stupidchicken.com> writes:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>> If the defaults are chosen for similarity to other long-lines editors,
>> I'd guess you should turn on `longlines-wrap-follows-window-size' by
>> default.  At least gedit (and notepad.exe, IIRC) do it by default.
>
> I would, if not for the fact that longlines-wrap-follows-window-size
> doesn't behave well when the buffer is simultaneously displayed in two
> windows with different widths.  This is not fixable without C-level
> changes.  There have been discussions about this issue on this list in
> the past, but I don't think it'll be fixed in the immediate future.
> So the current behavior is a compromise.

BTW, Is it time to merge Kim's patch?

  Line wrapping during redisplay
  http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg01112.html

-- 
Johan Bockgård

Re: longlines-mode

[David Reitter]

On 27 Feb 2008, at 12:20, Johan Bockgård wrote:

> BTW, Is it time to merge Kim's patch?
>
>  Line wrapping during redisplay
>  http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg01112.html

This would be much appreciated. It would fix a number of problems with  
third-party packages. In my case, writing a 200-page thesis in LaTeX  
with AUCTeX, longlines mode and proportional fonts has brought up  
numerous issues that had been pointed out in the thread you refer to.

- D

Re: longlines-mode

[Stefan Monnier]

>>> If the defaults are chosen for similarity to other long-lines editors,
>>> I'd guess you should turn on `longlines-wrap-follows-window-size' by
>>> default.  At least gedit (and notepad.exe, IIRC) do it by default.
>> 
>> I would, if not for the fact that longlines-wrap-follows-window-size
>> doesn't behave well when the buffer is simultaneously displayed in two
>> windows with different widths.  This is not fixable without C-level
>> changes.  There have been discussions about this issue on this list in
>> the past, but I don't think it'll be fixed in the immediate future.
>> So the current behavior is a compromise.

> BTW, Is it time to merge Kim's patch?

>   Line wrapping during redisplay
>   http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg01112.html

That is indeed a feature we want to integrate and now wouldn't be the
worst time for it.  Kim, would you have time to help us do that?


        Stefan

Re: longlines-mode

[Kim F. Storm]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>   Line wrapping during redisplay
>>   http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg01112.html
>
> That is indeed a feature we want to integrate and now wouldn't be the
> worst time for it.  Kim, would you have time to help us do that?

I'll try to find some time.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: longlines-mode

[Johan Bockgård]

storm@cua.dk (Kim F. Storm) writes:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>>>   Line wrapping during redisplay
>>>   http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg01112.html
>>
>> That is indeed a feature we want to integrate and now wouldn't be the
>> worst time for it.  Kim, would you have time to help us do that?
>
> I'll try to find some time.

I may add that I've been running with a patched Emacs ever since this
patch was posted, although I've only barely tested the feature.  And I
think the Aquamacs guys may have been using it too.

-- 
Johan Bockgård

Re: longlines-mode

[Miles Bader]

David Reitter <david.reitter@gmail.com> writes:
>>  Line wrapping during redisplay
>>  http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg01112.html
>
> This would be much appreciated. It would fix a number of problems with
> third-party packages. In my case, writing a 200-page thesis in LaTeX
> with AUCTeX, longlines mode and proportional fonts has brought up
> numerous issues that had been pointed out in the thread you refer to.

I think Kim's patch is a good thing, but please note that it will _not_
magically solve all your problems.

In particular, there are many issues associated with _editing_
display-wrapped code -- common Emacs' commands will often do the wrong
thing (most obviously C-a, C-n, and other line-movement commands).

-Miles

-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: longlines-mode

[David Reitter]

On 28 Feb 2008, at 02:58, Miles Bader wrote:
>
> In particular, there are many issues associated with _editing_
> display-wrapped code -- common Emacs' commands will often do the wrong
> thing (most obviously C-a, C-n, and other line-movement commands).

We have been using different code for these that does the right thing.  
This was necessary primarily because of variable width fonts. <down>  
is bound to `visual-line-down', which moves the point to the next  
visual line and to the column that is closest on the screen (pixel  
wise), minimizing horizontal offset (in pixels). Other functions  
provided are `beginning-of-visual-line', `end-of-visual-line', `kill- 
visual-line', `kill-whole-visual-line'.

Re: longlines-mode

[Miles Bader]

David Reitter <david.reitter@gmail.com> writes:
>> In particular, there are many issues associated with _editing_
>> display-wrapped code -- common Emacs' commands will often do the wrong
>> thing (most obviously C-a, C-n, and other line-movement commands).
>
> We have been using different code for these that does the right
> thing. This was necessary primarily because of variable width
> fonts. <down>  is bound to `visual-line-down', which moves the point to
> the next  visual line and to the column that is closest on the screen
> (pixel  wise), minimizing horizontal offset (in pixels). Other functions
> provided are `beginning-of-visual-line', `end-of-visual-line', `kill- 
> visual-line', `kill-whole-visual-line'.

Of course the question is whether simple rebinding of common user
command is enough; obviously any _other_ function which attempts to do
line-oriented manipulation may act "weird" as a result.

-Miles

-- 
Bore, n. A person who talks when you wish him to listen.

Re: longlines-mode

[Stefan Monnier]

>> In particular, there are many issues associated with _editing_
>> display-wrapped code -- common Emacs' commands will often do the wrong
>> thing (most obviously C-a, C-n, and other line-movement commands).

> We have been using different code for these that does the right
> thing. This was necessary primarily because of variable width
> fonts. <down> is bound to visual-line-down', which moves the point to
> the next visual line and to the column that is closest on the screen
> (pixel  wise), minimizing horizontal offset (in pixels). Other
> functions provided are beginning-of-visual-line',
> `end-of-visual-line', `kill-  visual-line', `kill-whole-visual-line'.

Could you show us the corresponding code?


        Stefan

Re: longlines-mode

[David Reitter]

On 28 Feb 2008, at 16:47, Stefan Monnier wrote:
>>
>> We have been using different code for these that does the right
>> thing. This was necessary primarily because of variable width
>> fonts. <down> is bound to visual-line-down', which moves the point to
>> the next visual line and to the column that is closest on the screen
>> (pixel  wise), minimizing horizontal offset (in pixels). Other
>> functions provided are beginning-of-visual-line',
>> `end-of-visual-line', `kill-  visual-line', `kill-whole-visual-line'.
>
> Could you show us the corresponding code?


The code is below. This is straight out of Aquamacs (osxkeys.el) and  
may or may not run as is.

Note that `visual-line-up' and friends use two different methods to  
figure out the best position to move to because of a slowness with  
outline-(minor-)mode. One of the methods (basically binary search) is  
much faster when a lot of hidden text is present, but a bit slower in  
all other cases.

We have `visual-line-down' bound to <down> (and so forth), with  
special cases for minibuffers.

N.B. I do not take comments about non-conforming code formatting etc.  
at this point.


(defun visual-col-at-point ()
(- (point)
   (save-excursion
     (vertical-motion 0)
     (point))))
  ;; seems slower (in situations with very long lines)
  ;;(or (car (nth 6 (posn-at-point))) 0))

(defun visual-pixel-col-at-point ()
(or
  (car-safe (pos-visible-in-window-p (point) nil 'partial))
  0))

(defvar visual-movement-temporary-goal-column nil)
(make-variable-buffer-local 'visual-movement-temporary-goal-column)

(defvar visual-previous-scroll-margin 'none)
(defun visual-restore-scroll-margin ()
  (if (integerp visual-previous-scroll-margin)
      (setq scroll-margin visual-previous-scroll-margin))
    (remove-hook 'pre-command-hook 'visual-restore-scroll-margin))



(defcustom visual-scroll-margin nil
"Number of lines of margin at top and bottom of a window.
For visual scrolling with up and down keys, this value
applies instead of `scroll-margin' if it is non-nil.

The reason this variable exists is that clicks in the first and last
line of a window will set the cursor within the standard scroll-margin,
causing the buffer to scroll immediately. This is usually undesired.
In this case, set `scroll-margin' to zero and `visual-scroll-margin'
to the desired margin."
:group 'Aquamacs)

;; (setq scroll-margin 0)
;; (setq visual-scroll-margin 5)
(defun visual-line-up (num-lines)
"Move cursor vertically up NUM-LINES lines.
Interactively, vscroll tall lines if `auto-window-vscroll' is
enabled.  If there is no character in the target line exactly
over the current horizontal pixel position, the cursor is
positioned close to the character in that line at the same position,
or at the end of the line if it is not long enough.

The command C-x C-n can be used to create
a semipermanent goal column for this command.
Then instead of trying to move exactly vertically (or as close as  
possible),
this command moves to the specified goal column (or as close as  
possible).
The goal column is stored in the variable `goal-column', which is nil
when there is no goal column.

This function differs from `previous-line' as it moves vertically
in the visual sense. The result differs when variable-width font is
used or when characters of non-standard width (e.g. TABs) are used.

If you are thinking of using this in a Lisp program, consider using
`forward-line' with a negative argument instead.  It is usually easier
to use and more reliable (no dependence on goal column, etc.)."
  (interactive "p")
  (if (bobp) (signal 'beginning-of-buffer nil))
  (let ((pixel-col (visual-pixel-col-at-point))
	(visual-col (visual-col-at-point))
	(old-point (point))
	(end-of-old-line))

    ;; temporary binding of scroll-margin
    ;; cannot do this with a temporary let binding
    (setq visual-previous-scroll-margin scroll-margin)
    (if visual-scroll-margin
	(setq scroll-margin visual-scroll-margin))
    (add-hook 'pre-command-hook 'visual-restore-scroll-margin)



    (save-excursion
      (vertical-motion 1)	;; trying going one down, to left
      (setq end-of-old-line (point)))

      (vertical-motion 0)

    (let* ((beg-of-old-line
		;; move right, but not further than to end of line
	    (prog1 (point)
	      (vertical-motion (- num-lines))))	    ;; one up again
	   (beg-of-new-line (point))
	   (rel-beg-of-old-line  (- beg-of-old-line (point) 1)))

      ;; handle track-eol...
      (if (and track-eol (= old-point (1- end-of-old-line))
	       ;; Don't count beg of empty line as end of line
	       ;; unless we just did explicit end-of-line.
	       (or (not (= old-point beg-of-old-line))
		   (eq last-command 'end-of-line)))
	  (setq visual-movement-temporary-goal-column 9999))

      ;; approximate positioning
      (if (and (or goal-column visual-movement-temporary-goal-column)
	       (memq last-command '(visual-line-up
				    visual-line-down
				    osxkeys-visual-line-up-in-buffers
				    osxkeys-visual-line-down-in-buffers))
	       (= old-point (1- end-of-old-line)))	
	  ;; jumping from end of line
	
	   (forward-char (min (or goal-column
				  visual-movement-temporary-goal-column)
			      rel-beg-of-old-line))
	;; else, do complete positioning
	;; save original position
	(setq visual-movement-temporary-goal-column visual-col)
;	(forward-char (min visual-col rel-beg-of-old-line))
	
	;; this won't work because we don't have the
	;; absolute position, just the position within window
	;; (let ((p (pos-visible-in-window-p old-point nil 'p))
;; 	      (p2 (pos-visible-in-window-p beg-of-new-line nil 'p) ))
;; 	  (print (cons (car p) (cdr p2)))
;; 	  (posn-set-point (cons (car p) (cdr p2)))
;; 	  )
	(if (> (abs (- (point) beg-of-old-line)) 400)
	    ;; aq-find-position-at-pixel-col is much faster when
	    ;; large portions of hidden text are to be crossed.
	    ;; this can happen in outline-(minor-)mode for instance.
	    (goto-char (aq-find-position-at-pixel-col  pixel-col))
	  ;; approximate positioning
	  (forward-char (min visual-col rel-beg-of-old-line))
	  (if (>= (visual-pixel-col-at-point) pixel-col)
	      (progn
		(while (and
			(> (visual-pixel-col-at-point) pixel-col)
			(> (point) beg-of-new-line)) ;; do not cross line
		  (forward-char -1)))
	    (progn
	      (while (and
		      (< (visual-pixel-col-at-point) pixel-col)
		      (< (point) (1- beg-of-old-line))) ;; do not cross line
		(forward-char +1)))))
	
	))))


(defun visual-line-down (num-lines)
"Move cursor vertically down NUM-LINES lines.
Interactively, vscroll tall lines if `auto-window-vscroll' is enabled.
If there is no character in the target line exactly under the current  
column,
the cursor is positioned after the character in that line which spans  
this
column, or at the end of the line if it is not long enough.
If there is no line in the buffer after this one, behavior depends on  
the
value of `next-line-add-newlines'.  If non-nil, it inserts a newline  
character
to create a line, and moves the cursor to that line.  Otherwise it  
moves the
cursor to the end of the buffer.

The command C-x C-n can be used to create
a semipermanent goal column for this command.
Then instead of trying to move exactly vertically (or as close as  
possible),
this command moves to the specified goal column (or as close as  
possible).
The goal column is stored in the variable `goal-column', which is nil
when there is no goal column.

This function differs from `next-line' as it moves vertically
in the visual sense. The result differs when variable-width font is
used or when characters of non-standard width (e.g. TABs) are used.

If you are thinking of using this in a Lisp program, consider
using `forward-line' instead.  It is usually easier to use
and more reliable (no dependence on goal column, etc.)."
(interactive "p")

(if (and next-line-add-newlines (= num-lines 1))
     (if (save-excursion (end-of-line) (eobp))
	 ;; When adding a newline, don't expand an abbrev.
	 (let ((abbrev-mode nil))
	   (end-of-line)
	   (insert hard-newline)))
   (if (eobp) (signal 'end-of-buffer nil)))
(let ((pixel-col (visual-pixel-col-at-point))
	(visual-col (visual-col-at-point))
	(old-point (point))
	(beg-of-line)
	(next-line-start)
	(rel-next-line-start))

    ;; temporary binding of scroll-margin
    ;; cannot do this with a temporary let binding
    (setq visual-previous-scroll-margin scroll-margin)
    (if visual-scroll-margin
	(setq scroll-margin visual-scroll-margin))
    (add-hook 'pre-command-hook 'visual-restore-scroll-margin)

    (vertical-motion num-lines) ;; down
    (save-excursion
      (setq beg-of-line (point))
      (vertical-motion +1) ;; down
      (setq next-line-start (point))
      (setq rel-next-line-start  (- (point) beg-of-line 1)))
    (unless (= beg-of-line (point-max))
      ;; handle track-eol...
      (if (and track-eol (= old-point (1- next-line-start))
	       ;; Don't count beg of empty line as end of line
	       ;; unless we just did explicit end-of-line.
	       (or (not (= 0 visual-col))
		   (eq last-command 'end-of-line)))
	  (setq visual-movement-temporary-goal-column 9999))
	  ;; approximate positioning
	  (if (and (or goal-column visual-movement-temporary-goal-column)
		   (memq last-command '(visual-line-up
					visual-line-down
					osxkeys-visual-line-up-in-buffers
					osxkeys-visual-line-down-in-buffers))
		   (= old-point (- beg-of-line 1))) ;; jumping from end of line
	
	      (forward-char (min (or goal-column
				     visual-movement-temporary-goal-column)
				 rel-next-line-start))
	    ;; else, do complete positioning
	    ;; save original position
	    (setq visual-movement-temporary-goal-column visual-col)
	    ;; aq-find-position-at-pixel-col is much faster when
	    ;; large portions of hidden text are to be crossed.
	    ;; this can happen in outline-(minor-)mode for instance.
	    (if (> (abs (- old-point next-line-start)) 400)
		(goto-char (aq-find-position-at-pixel-col  pixel-col))
	      (forward-char (min visual-col rel-next-line-start))
	      (if (> (visual-pixel-col-at-point) pixel-col)
		(progn
		  (while (and
			  (> (visual-pixel-col-at-point) pixel-col)
			  (> (point) beg-of-line)) ;; do not cross line
		    (forward-char -1)))
	      (progn
		(while (and
			(< (visual-pixel-col-at-point) pixel-col)
			(< (point) (1- next-line-start))) ;; do not cross line
		  (forward-char +1)))))))))


(defun aq-find-position-at-pixel-col  (pixel-col)

  (let ((beg-of-line) (end-of-line))
    (vertical-motion 1)	;; trying going one down, to left
    (setq end-of-line (point))
    (if (eq (point) (point-max)) (vertical-motion 0) (vertical-motion  
-1))
    (setq beg-of-line (point))

    (let ((op (point)))
					; move to beg of line
      (vertical-motion 0) ;; trying going one down, to left
      (forward-char (/ pixel-col (frame-char-width)))

      (aq-find-position-at-pixel-col-recursive
       beg-of-line end-of-line pixel-col)

      (let* ((nearest-pos (point))
	     (smallest-distance
	      (abs (- pixel-col (visual-pixel-col-at-point)))))

	(let ((pdif (abs (- pixel-col
			    (progn (forward-char -1)
				   (visual-pixel-col-at-point))))))
	  (when (< pdif smallest-distance)
	    (setq nearest-pos (point))
	    (setq smallest-distance pdif)))

	(let ((pdif (abs (- pixel-col
			    (progn (forward-char 2)
				   (visual-pixel-col-at-point))))))
	  (when (< pdif smallest-distance)
	    (setq nearest-pos (point))
	    (setq smallest-distance pdif)))
	(goto-char nearest-pos))

      (point))))


(defun aq-find-position-at-pixel-col-recursive
  (beg-of-line end-of-line pixel-col)
   ; set it in the middle

  (if (eq beg-of-line end-of-line)
      (point)

  (let ((middle (+ beg-of-line (round (/ (- end-of-line beg-of-line)  
2)))))
    (if (or
	 (eq middle (point)) ;; wouldn't change point any more
	 (eq (visual-pixel-col-at-point) pixel-col))
	(point)
      ;(incf steps)
      (goto-char middle)
      (if (> (visual-pixel-col-at-point) pixel-col)
	  (aq-find-position-at-pixel-col-recursive
	   beg-of-line (point) pixel-col)
	(aq-find-position-at-pixel-col-recursive
	 (point) end-of-line pixel-col))))))

	
(defun beginning-of-visual-line ()
  (interactive)
  (if (bobp)
      (signal 'beginning-of-buffer nil))
  (vertical-motion 0))

(defun end-of-visual-line ()
  (interactive)
  (if (eobp)
      (signal 'end-of-buffer nil))
  (let ((end-of-line (line-end-position)))
    (vertical-motion 1)
     (unless (or (eobp)
		 (< (point) end-of-line)) ;; jumping over wrapped text
      (backward-char 1))))

;; this code based on simple.el
(defun kill-visual-line (&optional arg)
  "Kill the rest of the visual line; if no nonblanks there, kill thru  
newline.
With prefix argument, kill that many lines from point.
Negative arguments kill lines backward.
With zero argument, kills the text before point on hthe current line.

When calling from a program, nil means \"no arg\",
a number counts as a prefix arg.

To kill a whole line, when point is not at the beginning, type \
\\[beginning-of-line] \\[kill-line] \\[kill-line].

If `kill-whole-line' is non-nil, then this command kills the whole line
including its terminating newline, when used at the beginning of a line
with no argument.  As a consequence, you can always kill a whole line
by typing \\[beginning-of-line] \\[kill-line].

If you want to append the killed line to the last killed text,
use \\[append-next-kill] before \\[kill-line].

If the buffer is read-only, Emacs will beep and refrain from deleting
the line, but put the line in the kill ring anyway.  This means that
you can use this command to copy text from a read-only buffer.
\(If the variable `kill-read-only-ok' is non-nil, then this won't
even beep.)"
  (interactive "P")
  (kill-region (point)
	       ;; It is better to move point to the other end of the kill
	       ;; before killing.  That way, in a read-only buffer, point
	       ;; moves across the text that is copied to the kill ring.
	       ;; The choice has no effect on undo now that undo records
	       ;; the value of point from before the command was run.
	       (progn
		 (if arg
		     (vertical-motion (prefix-numeric-value arg))
		   (if (eobp)
		       (signal 'end-of-buffer nil))
		   (let ((end
			  (save-excursion
			    (end-of-visual-line) (point))))
		     (if (or (save-excursion
			       ;; If trailing whitespace is visible,
			       ;; don't treat it as nothing.
			       (unless show-trailing-whitespace
				 (skip-chars-forward " \t" end))
			       (= (point) end))
			     (and kill-whole-line (bolp)))
			 (visual-line-down 1)
		       (goto-char end))))
		 (point))))


(defun kill-whole-visual-line (&optional arg)
  "Kill current visual line.
With prefix arg, kill that many lines starting from the current line.
If arg is negative, kill backward.  Also kill the preceding newline.
\(This is meant to make \\[repeat] work well with negative arguments.\)
If arg is zero, kill current line but exclude the trailing newline."
  (interactive "p")
  (if (and (> arg 0) (eobp) (save-excursion (vertical-motion 0) (eobp)))
      (signal 'end-of-buffer nil))
  (if (and (< arg 0) (bobp) (save-excursion (vertical-motion 1) (bobp)))
      (signal 'beginning-of-buffer nil))
  (unless (eq last-command 'kill-region)
    (kill-new "")
    (setq last-command 'kill-region))
  (cond ((zerop arg)
	 ;; We need to kill in two steps, because the previous command
	 ;; could have been a kill command, in which case the text
	 ;; before point needs to be prepended to the current kill
	 ;; ring entry and the text after point appended.  Also, we
	 ;; need to use save-excursion to avoid copying the same text
	 ;; twice to the kill ring in read-only buffers.
	 (save-excursion
	   ;; delete in one go
	   (kill-region (progn (vertical-motion 0) (point))
			(progn (vertical-motion 1) (point)))
	 ))
	((< arg 0)
	 (save-excursion
	   (kill-region (point) (progn (end-of-visual-line) (point))))
	 (kill-region (point)
		      (progn (vertical-motion (1+ arg))
			     (unless (bobp) (backward-char))
			     (point))))
	(t
	 (save-excursion
	   (kill-region (progn (vertical-motion 0) (point))
			(progn (vertical-motion arg) (point)))))))


(defun osxkeys-visual-line-up-in-buffers ()
"Moves the cursor up one (visual) line.
If the `up' key would normally be bound to something else than
`previous-line' (as it is the case in minibuffers), the other binding
is called."
  (interactive)
  (let* (osx-key-mode  ;; turn off mode temporarily
	 (binding (key-binding [up])))
    (if (eq binding 'previous-line)
	(call-interactively (function visual-line-up))
      (call-interactively binding))))


(defun osxkeys-visual-line-down-in-buffers ()
"Moves the cursor down one (visual) line.
If the `down' key would normally be bound to something else than
`next-line' (as it is the case in minibuffers), the other binding
is called."
  (interactive)
  (let* (osx-key-mode  ;; turn off mode temporarily
	 (binding (key-binding [down])))
    (if (eq binding 'next-line)
	(call-interactively (function visual-line-down))
      (call-interactively binding))))

;; mark functions for CUA
(dolist (cmd
	 '( beginning-of-visual-line
	    end-of-visual-line
	    visual-line-down visual-line-up
	    osxkeys-visual-line-up-in-buffers
	    osxkeys-visual-line-down-in-buffers))
  (put cmd 'CUA 'move))