line-line-move-visual: was line motion problem

line-line-move-visual: was line motion problem

[T. V. Raman]

Would it be possible to make line-move-visual user customizable?

At present the change its default setting of T causes to cursor
motion is a drastic change to how Emacs has always behaved.

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: line-line-move-visual: was line motion problem

[Stefan Monnier]

> Would it be possible to make line-move-visual user customizable?
> At present the change its default setting of T causes to cursor
> motion is a drastic change to how Emacs has always behaved.

Yes, it should be a define-minor-mode (with name ending in "-mode").
Can someone make this change?


        Stefan

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On 16 Jul 2008, at 12:26, Stefan Monnier wrote:
>
> Yes, it should be a define-minor-mode (with name ending in "-mode").
> Can someone make this change?


What do we conclude from the discussion related to this?

My understanding is that we were going to have visual navigation  
(arrow keys, C-n, C-p) default to on, and leave default behavior of C- 
a and C-e as is, with some code (from the visual-line-mode that I  
posted) to optionally remap C-a and C-e to visual navigation as it is  
sensible in text modes.

Should this be one minor mode that defaults to on, or should we have  
two minor modes then?
Also, should C-a and C-e default to the visual mode in all text modes?  
(Would that just go in text-mode-hook?)




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[Chong Yidong]

David Reitter <david.reitter@gmail.com> writes:

> On 16 Jul 2008, at 12:26, Stefan Monnier wrote:
>>
>> Yes, it should be a define-minor-mode (with name ending in "-mode").
>> Can someone make this change?
>
> What do we conclude from the discussion related to this?
>
> My understanding is that we were going to have visual navigation
> (arrow keys, C-n, C-p) default to on, and leave default behavior of C- 
> a and C-e as is, with some code (from the visual-line-mode that I
> posted) to optionally remap C-a and C-e to visual navigation as it is
> sensible in text modes.
>
> Should this be one minor mode that defaults to on, or should we have
> two minor modes then?
> Also, should C-a and C-e default to the visual mode in all text modes?
> (Would that just go in text-mode-hook?)

I think we should have a defcustom that sets the default value of
line-move-visual, and a minor mode (I guess it'll be called
visual-line-mode, since there doesn't seem to be any better name) that
provides the rest of the visual editing features.

The minor mode would then turn on word-wrap and line-move-visual in
buffers where it is activated.

Re: line-line-move-visual: was line motion problem

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> I think we should have a defcustom that sets the default value of
> line-move-visual, and a minor mode (I guess it'll be called
> visual-line-mode, since there doesn't seem to be any better name) that
> provides the rest of the visual editing features.

The following patch implements this approach.  I've taken bits from
visual-line.el, and re-written other bits to make use of the new
features of vertical-motion in Emacs 23.

Could people try it out and see if it DTRT?

As Richard suggested, it binds M-[ and M-] to logical previous-line and
next-line.  I don't know, OTOH, where a logical kill-line should be
bound (visual-line.el bound it to C-K, but this doesn't seem optimal,
since OTOH we try not to use upcased keybindings where possible).


*** trunk/lisp/simple.el.~1.934.~	2008-07-15 14:47:32.000000000 -0400
--- trunk/lisp/simple.el	2008-07-16 14:23:26.000000000 -0400
***************
*** 3906,3916 ****
    :type 'boolean
    :group 'editing-basics)
  
! (defvar line-move-visual t
    "When non-nil, `line-move' moves point by visual lines.
  This movement is based on where the cursor is displayed on the
  screen, instead of relying on buffer contents alone.  It takes
! into account variable-width characters and line continuation.")
  
  ;; Returns non-nil if partial move was done.
  (defun line-move-partial (arg noerror to-end)
--- 3906,3919 ----
    :type 'boolean
    :group 'editing-basics)
  
! (defcustom line-move-visual t
    "When non-nil, `line-move' moves point by visual lines.
  This movement is based on where the cursor is displayed on the
  screen, instead of relying on buffer contents alone.  It takes
! into account variable-width characters and line continuation."
!   :type 'boolean
!   :group 'editing-basics)
! (make-variable-buffer-local 'line-move-visual)
  
  ;; Returns non-nil if partial move was done.
  (defun line-move-partial (arg noerror to-end)
***************
*** 4017,4022 ****
--- 4020,4027 ----
    (let ((inhibit-point-motion-hooks t)
  	(opoint (point))
  	(orig-arg arg))
+     (if (floatp temporary-goal-column)
+ 	(setq temporary-goal-column (truncate temporary-goal-column)))
      (unwind-protect
  	(progn
  	  (if (not (memq last-command '(next-line previous-line)))
***************
*** 4365,4371 ****
--- 4370,4499 ----
      )
    nil)
  \f
+ ;;; Editing based on visual lines, as opposed to logical lines.
+ 
+ (defun end-of-visual-line (&optional n)
+   "Move point to end of current visual line.
+ With argument N not nil or 1, move forward N - 1 visual lines first.
+ If point reaches the beginning or end of buffer, it stops there.
+ To ignore intangibility, bind `inhibit-point-motion-hooks' to t."
+   (interactive "^p")
+   (or n (setq n 1))
+   (if (/= n 1)
+       (let ((line-move-visual t))
+ 	(line-move (1- n) t)))
+   (vertical-motion (cons (window-width) 0)))
+ 
+ (defun beginning-of-visual-line (&optional n)
+   "Move point to beginning of current visual line.
+ With argument N not nil or 1, move forward N - 1 visual lines first.
+ If point reaches the beginning or end of buffer, it stops there.
+ To ignore intangibility, bind `inhibit-point-motion-hooks' to t."
+   (interactive "^p")
+   (or n (setq n 1))
+   (if (/= n 1)
+       (let ((line-move-visual t))
+ 	(line-move (1- n) t)))
+   (vertical-motion 0))
+ 
+ (defun kill-visual-line (&optional arg)
+   "Kill the rest of the visual line.
+ If there are only whitespace characters there, kill through the
+ newline as well.
+ 
+ With prefix argument, kill that many lines from point.
+ Negative arguments kill lines backward.
+ With zero argument, kill the text before point on the current line.
+ 
+ When calling from a program, nil means \"no arg\",
+ a number counts as a prefix arg.
+ 
+ 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")
+   (let ((opoint (point))
+ 	(line-move-visual t)
+ 	end)
+     ;; 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.
+     (if arg
+ 	(vertical-motion (prefix-numeric-value arg))
+       (if (eobp)
+ 	  (signal 'end-of-buffer nil))
+       (setq 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)))
+ 	  (line-move 1)
+ 	(goto-char end)))
+     (kill-region opoint (point))))
+ 
+ (defun next-logical-line (&optional arg try-vscroll)
+   "Move cursor vertically down ARG lines.
+ This is identical to `previous-line', except that it always moves
+ by logical lines instead of visual lines, ignoring the value of
+ `line-move-visual'."
+   (interactive "^p\np")
+   (let ((line-move-visual nil))
+     (with-no-warnings
+       (next-line arg try-vscroll))))
+ 
+ (defun previous-logical-line (&optional arg try-vscroll)
+   "Move cursor vertically up ARG lines.
+ This is identical to `previous-line', except that it always moves
+ by logical lines instead of visual lines, ignoring the value of
+ `line-move-visual'."
+   (interactive "^p\np")
+   (let ((line-move-visual nil))
+     (with-no-warnings
+       (previous-line arg try-vscroll))))
  
+ (defvar visual-line-mode-map
+   (let ((map (make-sparse-keymap)))
+     (define-key map [remap kill-line] 'kill-visual-line)
+     (define-key map [remap move-beginning-of-line] 'beginning-of-visual-line)
+     (define-key map [remap move-end-of-line]  'end-of-visual-line)
+     (define-key map "\M-[" 'previous-logical-line)
+     (define-key map "\M-]" 'next-logical-line)
+     map))
+ 
+ (define-minor-mode visual-line-mode
+   "Define key binding for visual line moves."
+   :keymap visual-line-mode-map
+   :group 'convenience
+   (if visual-line-mode
+       (progn
+ 	(setq line-move-visual t
+ 	      word-wrap t))
+     (kill-local-variable 'line-move-visual)
+     (kill-local-variable 'word-wrap)))
+ 
+ (defun turn-on-visual-line-mode ()
+   (visual-line-mode 1))
+ 
+ (define-globalized-minor-mode global-visual-line-mode
+   visual-line-mode turn-on-visual-line-mode
+   :lighter " vl")
+ \f
  (defun scroll-other-window-down (lines)
    "Scroll the \"other window\" down.
  For more details, see the documentation for `scroll-other-window'."

Re: line-line-move-visual: was line motion problem

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> The following patch implements this approach.  I've taken bits from
> visual-line.el, and re-written other bits to make use of the new
> features of vertical-motion in Emacs 23.
>
> Could people try it out and see if it DTRT?

Since no one has commented, I've gone ahead and checked in
visual-line-mode into CVS.  Problem reports would be welcome.

Re: line-line-move-visual: was line motion problem

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> Since no one has commented, I've gone ahead and checked in
> visual-line-mode into CVS.  Problem reports would be welcome.

Seems to work pretty well...

C-k acts a bit strangely, I think because it doesn't delete the
whitespace at the end of the killed "line"; the result is that the
cursor always ends up on the end of the previous "line" after using it.

Also, what about dealing with fringe continuation glyphs?  I understand
that some people want them, even in visual-line-mode, but I think many
won't want them, so it would be good if there were an easy setting that
would cause visual-line-mode suppress them.

Thanks,

-Miles

-- 
Education, n. That which discloses to the wise and disguises from the foolish
their lack of understanding.

Re: line-line-move-visual: was line motion problem

[Stefan Monnier]

> Also, what about dealing with fringe continuation glyphs?  I understand
> that some people want them, even in visual-line-mode, but I think many
> won't want them, so it would be good if there were an easy setting that
> would cause visual-line-mode suppress them.

I don't know how many people actually want them in visual-line-mode
(I'd like a fringe item at a hard newline, but until this is
implemented the next best thing is a display-table element for \n).


        Stefan

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

On 18 Jul 2008, at 10:16, Stefan Monnier wrote:

>> Also, what about dealing with fringe continuation glyphs?  I  
>> understand
>> that some people want them, even in visual-line-mode, but I think  
>> many
>> won't want them, so it would be good if there were an easy setting  
>> that
>> would cause visual-line-mode suppress them.
>
> I don't know how many people actually want them in visual-line-mode
> (I'd like a fringe item at a hard newline, but until this is
> implemented the next best thing is a display-table element for \n).

We could leave the continuation glyphs, but make them less conspicuous.

To mark hard newlines, try the code below.   I suggest to include this.


(defface blank-newline
   '((((class color) (background dark))
      (:foreground "lightgrey" :bold nil))
     (((class color) (background light))
      ( :foreground "lightgrey" :bold nil))
     (t (:bold nil :underline t)))
   "Face used to visualize NEWLINE char mapping.

See `blank-display-mappings'."
   :group 'blank)


  ;; 2230 = \x8B6
(defvar show-newlines-newline-code (vector (make-glyph-code 2230  
'blank-newline) 10))
(define-minor-mode show-newlines-mode
   "Mark newlines in current buffer"
  :group 'convenience

  (unless buffer-display-table
    (setq buffer-display-table (or standard-display-table (make- 
display-table))))
  (if show-newlines-mode
      (aset buffer-display-table 10 show-newlines-newline-code)
    (aset buffer-display-table 10 nil)))

(define-minor-mode global-show-newlines-mode
   "Mark newlines in all buffers"
   :group 'convenience
   :global t

  (unless standard-display-table
    (setq standard-display-table (make-display-table)))
  (if global-show-newlines-mode
      (aset standard-display-table 10 show-newlines-newline-code)
    (aset standard-display-table 10 nil))
  (dolist (buffer (buffer-list))
    (with-current-buffer buffer
      (if buffer-display-table
	 (show-newlines-mode (if global-show-newlines-mode 1 -1))))))


(define-key-after menu-bar-showhide-menu [show-newlines-mode]
   (menu-bar-make-mm-toggle global-show-newlines-mode
			   "Show Newlines"
			   "Show hard newlines") 'highlight-paren-mode)


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[Stefan Monnier]

>> I don't know how many people actually want them in visual-line-mode
>> (I'd like a fringe item at a hard newline, but until this is
>> implemented the next best thing is a display-table element for \n).

> We could leave the continuation glyphs, but make them less conspicuous.

For a mode that expects most lines to be wrapped, I see not point in
leaving continuation marks.

> To mark hard newlines, try the code below.   I suggest to include this.

>  ;; 2230 = \x8B6
> (defvar show-newlines-newline-code (vector (make-glyph-code 2230
> blank-newline) 10))

[ Too long a line, huh? ]

My font doesn't seem to know the char 2230, and UnicodeData.txt doesn't
seem to know that char either.  So we should probably use something else.

>  (if show-newlines-mode
>      (aset buffer-display-table 10 show-newlines-newline-code)
>    (aset buffer-display-table 10 nil)))

Better write it as:

 (aset buffer-display-table 10
       (if show-newlines-mode show-newlines-newline-code))


-- Stefan

Re: line-line-move-visual: was line motion problem

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> I don't know how many people actually want them in visual-line-mode
  > >> (I'd like a fringe item at a hard newline, but until this is
  > >> implemented the next best thing is a display-table element for \n).
  > 
  > > We could leave the continuation glyphs, but make them less conspicuous.
  > 
  > For a mode that expects most lines to be wrapped, I see not point in
  > leaving continuation marks.
  > 
  > > To mark hard newlines, try the code below.   I suggest to include this.
  > 
  > >  ;; 2230 = \x8B6
  > > (defvar show-newlines-newline-code (vector (make-glyph-code 2230
  > > blank-newline) 10))
  > 
  > [ Too long a line, huh? ]
  > 
  > My font doesn't seem to know the char 2230, and UnicodeData.txt doesn't
  > seem to know that char either.  So we should probably use something else.
  > 
  > >  (if show-newlines-mode
  > >      (aset buffer-display-table 10 show-newlines-newline-code)
  > >    (aset buffer-display-table 10 nil)))
  > 
  > Better write it as:
  > 
  >  (aset buffer-display-table 10
  >        (if show-newlines-mode show-newlines-newline-code))

whitespace.el already has many many ways of dealing with whitespaces,
wouldn't this mode be a better fit in whitespace.el?

Re: line-line-move-visual: was line motion problem

[Stefan Monnier]

> whitespace.el already has many many ways of dealing with whitespaces,
> wouldn't this mode be a better fit in whitespace.el?

Probably, yes,


        Stefan

Re: line-line-move-visual: was line motion problem

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> whitespace.el already has many many ways of dealing with whitespaces,
> wouldn't this mode be a better fit in whitespace.el?

whitespace.el is already a huge bloated mess, let's not make it worse...

-Miles

-- 
Accordion, n. An instrument in harmony with the sentiments of an assassin.

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 4072 bytes --]

On 21 Jul 2008, at 00:49, Chong Yidong wrote:
> If anyone on this list has a patch that is still waiting for  
> approval or
> further comments, now would be a good time to ping.


OK, there is still the paragraph marking function. The following two  
major items (and some smaller issues) have been addressed:

Stefan Monnier:

> My font doesn't seem to know the char 2230, and UnicodeData.txt  
> doesn't
> seem to know that char either.  So we should probably use something  
> else.

On 18 Jul 2008, at 11:30, Dan Nicolaescu wrote:
>
> whitespace.el already has many many ways of dealing with whitespaces,
> wouldn't this mode be a better fit in whitespace.el?


Any objections to the patch below.
Can't put it in simple.el because make-glyph-code can't be autoloaded,  
and the code is probably happy in whitespace.el.

- D




*** whitespace.el	06 May 2008 03:57:59 -0400	1.80
--- whitespace.el	21 Jul 2008 11:04:45 -0400	
***************
*** 2352,2357 ****
--- 2352,2406 ----
         (whitespace-mode -1)))
     nil)					; continue standard unloading

+ \f
+ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+
+
+
+ ;; Show-newlines-mode
+ (defface blank-newline
+  '((((class color) (background dark))
+     (:foreground "lightgrey" :bold nil))
+    (((class color) (background light))
+     ( :foreground "lightgrey" :bold nil))
+    (t (:bold nil :underline t)))
+  "Face used to visualize NEWLINE char mapping.
+
+ See `blank-display-mappings'."
+  :group 'blank)
+
+ (defvar show-newlines-newline-code
+   (vector (make-glyph-code 182 'blank-newline) 10))
+
+ ;;;###autoload
+ (define-minor-mode show-newlines-mode
+   "Mark newlines in current buffer"
+   :group 'convenience
+
+   (unless buffer-display-table
+     (setq buffer-display-table
+ 	  (or standard-display-table (make-display-table))))
+   (aset buffer-display-table 10
+ 	(if show-newlines-mode show-newlines-newline-code)))
+
+ ;;;###autoload
+ (define-minor-mode global-show-newlines-mode
+  "Mark newlines in all buffers"
+  :group 'convenience
+  :global t
+
+  (unless standard-display-table
+    (setq standard-display-table (make-display-table)))
+  (if global-show-newlines-mode
+      (aset standard-display-table 10 show-newlines-newline-code)
+    (aset standard-display-table 10 nil))
+  (dolist (buffer (buffer-list))
+    (with-current-buffer buffer
+      (if buffer-display-table
+ 	 (show-newlines-mode
+ 	  (if global-show-newlines-mode 1 -1))))))
+
+

   (provide 'whitespace)

*** menu-bar.el	10 Jul 2008 00:27:23 -0400	1.341
--- menu-bar.el	21 Jul 2008 11:45:01 -0400	
***************
*** 653,659 ****
     (let ((need-save nil))
       ;; These are set with menu-bar-make-mm-toggle, which does not
       ;; put on a customized-value property.
!     (dolist (elt '(line-number-mode column-number-mode size- 
indication-mode
   		   cua-mode show-paren-mode transient-mark-mode
   		   blink-cursor-mode display-time-mode display-battery-mode))
         (and (customize-mark-to-save elt)
--- 653,660 ----
     (let ((need-save nil))
       ;; These are set with menu-bar-make-mm-toggle, which does not
       ;; put on a customized-value property.
!     (dolist (elt '(global-show-newlines-mode line-number-mode
! 		   column-number-mode size-indication-mode
   		   cua-mode show-paren-mode transient-mark-mode
   		   blink-cursor-mode display-time-mode display-battery-mode))
         (and (customize-mark-to-save elt)
***************
*** 700,705 ****
--- 701,714 ----

   (defvar menu-bar-showhide-menu (make-sparse-keymap "Show/Hide"))

+ (define-key menu-bar-showhide-menu [show-newlines-mode]
+  (menu-bar-make-mm-toggle global-show-newlines-mode
+ 			   "Show Newlines"
+ 			   "Show hard newlines"))
+
+ (define-key menu-bar-showhide-menu [newlines-separator]
+   '("--"))
+
   (define-key menu-bar-showhide-menu [column-number-mode]
     (menu-bar-make-mm-toggle column-number-mode
   			   "Column Numbers"



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[Chong Yidong]

David Reitter <david.reitter@gmail.com> writes:

> OK, there is still the paragraph marking function. The following two
> major items (and some smaller issues) have been addressed:

Please don't add a menu-bar entry for this.  The menu-bar is already too
cluttered.

Also, I'd suggest a couple of tweaks to your docstrings:

> +  "Face used to visualize NEWLINE char mapping.
> +
> + See `blank-display-mappings'."

Don't capitalize "newline".

> + (defvar show-newlines-newline-code
> +   (vector (make-glyph-code 182 'blank-newline) 10))

Add a brief docstring for this.

> + (define-minor-mode show-newlines-mode
> +   "Mark newlines in current buffer"

This should also say something like "Newlines are marked using the glyph
specified by `show-newlines-newline-code'."

If no one objects within the next 2 days, go ahead and check your code
in, with the above docstring fixes and without the menu-bar entry.
You'll also need a proper ChangeLog entry and a brief entry in etc/NEWS.

Re: line-line-move-visual: was line motion problem

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
>> + (defvar show-newlines-newline-code
>> +   (vector (make-glyph-code 182 'blank-newline) 10))
>
> Add a brief docstring for this.

The name `show-newlines-newline-code' seems bizarre though... "code"?

Also having to append the actual newline oneself seems a bit annoying.

How about just:

  (1) Call it something like "show-newlines-marker", and let it be a
      string.  The default value would be only one character long, but
      there seems no reason to limit users.

  (2) When turning on the mode, map the make-glyph over
      `show-newlines-marker', append the actual newline, and turn it
      into a vector.

-Miles

-- 
自らを空にして、心を開く時、道は開かれる

Re: line-line-move-visual: was line motion problem

[Stefan Monnier]

> The name `show-newlines-newline-code' seems bizarre though... "code"?

Of course, since it's in whitespace.el its name should start with
"whitespace-".


        Stefan

Re: line-line-move-visual: was line motion problem

[Miles Bader]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> Of course, since it's in whitespace.el its name should start with
> "whitespace-".

Then please move it out of whitespace.el...

-Miles

-- 
Quidquid latine dictum sit, altum viditur.

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

On 21 Jul 2008, at 12:01, Chong Yidong wrote:
>  Please don't add a menu-bar entry for this.  The menu-bar is  
> already too
> cluttered.

Do we expect a sizeable number of users to look for this?
If so, we should add it to the Show/Hide menu.

As for clutter: the show/hide menu only has 11 entries with this.

(It is a general problem that users can't find functions unless they  
read a big manual, know how to search customizations or read a news  
group.)

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[Dan Nicolaescu]

David Reitter <david.reitter@gmail.com> writes:

  > On 21 Jul 2008, at 00:49, Chong Yidong wrote:
  > Any objections to the patch below.

Some nits below:

  > *** whitespace.el	06 May 2008 03:57:59 -0400	1.80
  > --- whitespace.el	21 Jul 2008 11:04:45 -0400	
  > ***************
  > *** 2352,2357 ****
  > --- 2352,2406 ----
  >         (whitespace-mode -1)))
  >     nil)					; continue standard unloading
  > 
  > + \f
  > + ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  > +
  > +
  > +
  > + ;; Show-newlines-mode
  > + (defface blank-newline
               ^^^^
Everything else in the file uses "whitespace", better not use a new prefix.

  > +  '((((class color) (background dark))
  > +     (:foreground "lightgrey" :bold nil))
  > +    (((class color) (background light))
  > +     ( :foreground "lightgrey" :bold nil))
  > +    (t (:bold nil :underline t)))
  > +  "Face used to visualize NEWLINE char mapping.
  > +
  > + See `blank-display-mappings'."
  > +  :group 'blank)
       ^^^^^^
This group does not exist.

Didn't look at the rest...

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 132 bytes --]

On 21 Jul 2008, at 12:09, Dan Nicolaescu wrote:
>>
>> +  :group 'blank)
>       ^^^^^^
> This group does not exist.

`display' okay?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]

On 21 Jul 2008, at 12:09, Dan Nicolaescu wrote:
>>
>> + ;; Show-newlines-mode
>> + (defface blank-newline
>     +  :group 'blank)
>       ^^^^^^
> This group does not exist.

Actually, how about `whitespace' (like the other whitespace  
customizations) for the face and the two minor modes?
That's more specific than `display'.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[Vinicius Jose Latorre]

David Reitter wrote:
> On 21 Jul 2008, at 00:49, Chong Yidong wrote:
>> If anyone on this list has a patch that is still waiting for approval or
>> further comments, now would be a good time to ping.
>
>
> OK, there is still the paragraph marking function. The following two 
> major items (and some smaller issues) have been addressed:
>
> Stefan Monnier:
>
>> My font doesn't seem to know the char 2230, and UnicodeData.txt doesn't
>> seem to know that char either.  So we should probably use something 
>> else.
>
> On 18 Jul 2008, at 11:30, Dan Nicolaescu wrote:
>>
>> whitespace.el already has many many ways of dealing with whitespaces,
>> wouldn't this mode be a better fit in whitespace.el?
>
>
> Any objections to the patch below.
> Can't put it in simple.el because make-glyph-code can't be autoloaded, 
> and the code is probably happy in whitespace.el.
>
> - D


I have objections to this patch.


> *** whitespace.el    06 May 2008 03:57:59 -0400    1.80
> --- whitespace.el    21 Jul 2008 11:04:45 -0400   
> ***************
> *** 2352,2357 ****
> --- 2352,2406 ----
>         (whitespace-mode -1)))
>     nil)                    ; continue standard unloading
>
> + \f
> + ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> +
> +
> +
> + ;; Show-newlines-mode
> + (defface blank-newline
> +  '((((class color) (background dark))
> +     (:foreground "lightgrey" :bold nil))
> +    (((class color) (background light))
> +     ( :foreground "lightgrey" :bold nil))
> +    (t (:bold nil :underline t)))
> +  "Face used to visualize NEWLINE char mapping.
> +
> + See `blank-display-mappings'."
> +  :group 'blank)

First of all, there is no more blank package, it was replaced by 
whitespace package.

Second, there is already whitespace-newline which is the face used to 
visualize newlines.


> +
> + (defvar show-newlines-newline-code
> +   (vector (make-glyph-code 182 'blank-newline) 10))

No need for this, please, see whitespace-display-mappings option 
documentation.


> +
> + ;;;###autoload
> + (define-minor-mode show-newlines-mode
> +   "Mark newlines in current buffer"
> +   :group 'convenience
> +
> +   (unless buffer-display-table
> +     (setq buffer-display-table
> +       (or standard-display-table (make-display-table))))
> +   (aset buffer-display-table 10
> +     (if show-newlines-mode show-newlines-newline-code)))
> +
> + ;;;###autoload
> + (define-minor-mode global-show-newlines-mode
> +  "Mark newlines in all buffers"
> +  :group 'convenience
> +  :global t
> +
> +  (unless standard-display-table
> +    (setq standard-display-table (make-display-table)))
> +  (if global-show-newlines-mode
> +      (aset standard-display-table 10 show-newlines-newline-code)
> +    (aset standard-display-table 10 nil))
> +  (dolist (buffer (buffer-list))
> +    (with-current-buffer buffer
> +      (if buffer-display-table
> +      (show-newlines-mode
> +       (if global-show-newlines-mode 1 -1))))))
> +
> +
>
>   (provide 'whitespace)

Again, no need for all of these functions.

If it is necessary to have specific functions to display newlines, it 
should be something like this:

(defun whitespace-newline ()
    (let ((whitespace-style '(newline-mark newline)))
       (whitespace-mode 1)))

(defun global-whitespace-newline ()
    (let ((whitespace-style '(newline-mark newline)))
       (global-whitespace-mode 1)))



> *** menu-bar.el    10 Jul 2008 00:27:23 -0400    1.341
> --- menu-bar.el    21 Jul 2008 11:45:01 -0400   
> ***************
> *** 653,659 ****
>     (let ((need-save nil))
>       ;; These are set with menu-bar-make-mm-toggle, which does not
>       ;; put on a customized-value property.
> !     (dolist (elt '(line-number-mode column-number-mode 
> size-indication-mode
>              cua-mode show-paren-mode transient-mark-mode
>              blink-cursor-mode display-time-mode display-battery-mode))
>         (and (customize-mark-to-save elt)
> --- 653,660 ----
>     (let ((need-save nil))
>       ;; These are set with menu-bar-make-mm-toggle, which does not
>       ;; put on a customized-value property.
> !     (dolist (elt '(global-show-newlines-mode line-number-mode
> !            column-number-mode size-indication-mode
>              cua-mode show-paren-mode transient-mark-mode
>              blink-cursor-mode display-time-mode display-battery-mode))
>         (and (customize-mark-to-save elt)
> ***************
> *** 700,705 ****
> --- 701,714 ----
>
>   (defvar menu-bar-showhide-menu (make-sparse-keymap "Show/Hide"))
>
> + (define-key menu-bar-showhide-menu [show-newlines-mode]
> +  (menu-bar-make-mm-toggle global-show-newlines-mode
> +                "Show Newlines"
> +                "Show hard newlines"))
> +
> + (define-key menu-bar-showhide-menu [newlines-separator]
> +   '("--"))
> +
>   (define-key menu-bar-showhide-menu [column-number-mode]
>     (menu-bar-make-mm-toggle column-number-mode
>                  "Column Numbers"

Why should the newline visualization be inserted into menu-bar?


Vinicius

Re: line-line-move-visual: was line motion problem

[Chong Yidong]

Vinicius Jose Latorre <viniciusjl@ig.com.br> writes:

> Second, there is already whitespace-newline which is the face used to
> visualize newlines.
>
> If it is necessary to have specific functions to display newlines, it
> should be something like this:
>
> (defun whitespace-newline ()
>    (let ((whitespace-style '(newline-mark newline)))
>       (whitespace-mode 1)))
>
> (defun global-whitespace-newline ()
>    (let ((whitespace-style '(newline-mark newline)))
>       (global-whitespace-mode 1)))

Aha.  This certainly looks like a much better solution (it will have to
be rewritten properly using define-minor-mode, though).

Thanks.

Re: line-line-move-visual: was line motion problem

[Vinicius Jose Latorre]

Chong Yidong wrote:
> Vinicius Jose Latorre <viniciusjl@ig.com.br> writes:
>
>> Second, there is already whitespace-newline which is the face used to
>> visualize newlines.
>>
>> If it is necessary to have specific functions to display newlines, it
>> should be something like this:
>>
>> (defun whitespace-newline ()
>>    (let ((whitespace-style '(newline-mark newline)))
>>       (whitespace-mode 1)))
>>
>> (defun global-whitespace-newline ()
>>    (let ((whitespace-style '(newline-mark newline)))
>>       (global-whitespace-mode 1)))
>
> Aha.  This certainly looks like a much better solution (it will have to
> be rewritten properly using define-minor-mode, though).
>
> Thanks.

What about the code below?


;;;###autoload
(define-minor-mode whitespace-newline-mode
  "Toggle newline minor mode visualization (\"nl\" on modeline).

If ARG is null, toggle newline visualization.
If ARG is a number greater than zero, turn on visualization;
otherwise, turn off visualization.
Only useful with a windowing system."
  :lighter    " nl"
  :init-value nil
  :global     nil
  :group      'whitespace
  (let ((whitespace-style '(newline-mark newline)))
    (whitespace-mode whitespace-newline-mode)))


;;;###autoload
(define-minor-mode global-whitespace-newline-mode
  "Toggle newline global minor mode visualization (\"NL\" on modeline).

If ARG is null, toggle newline visualization.
If ARG is a number greater than zero, turn on visualization;
otherwise, turn off visualization.
Only useful with a windowing system."
  :lighter    " NL"
  :init-value nil
  :global     t
  :group      'whitespace
  (let ((whitespace-style '(newline-mark newline)))
    (global-whitespace-mode global-whitespace-newline-mode)))

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

On 21 Jul 2008, at 21:58, Vinicius Jose Latorre wrote:

> What about the code below?
>
> (let ((whitespace-style '(newline-mark newline)))
>   (whitespace-mode whitespace-newline-mode)))

Much more elegant.

I would still want the pilcrow to be used by default and the more (s/ 
t)ame colors for the face.
But that may well be the default for whitespace in general.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[Vinicius Jose Latorre]

>> What about the code below?
>>
>> (let ((whitespace-style '(newline-mark newline)))
>>   (whitespace-mode whitespace-newline-mode)))
>
> Much more elegant.
>
> I would still want the pilcrow to be used by default and the more 
> (s/t)ame colors for the face.
> But that may well be the default for whitespace in general.

Well, you can change the whitespace-newline and 
whitespace-display-mappings settings in your ~/.emacs file.

BTW, I also prefer the pilcrow.

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On 22 Jul 2008, at 21:53, Vinicius Jose Latorre wrote:
>>
>> I would still want the pilcrow to be used by default and the more  
>> (s/t)ame colors for the face.
>> But that may well be the default for whitespace in general.
>
> Well, you can change the whitespace-newline and whitespace-display- 
> mappings settings in your ~/.emacs file.

... so we don't have to set sensible defaults?

> BTW, I also prefer the pilcrow.


The default has to be sensible, and this is quite possibly different  
for the full-blown whitespace-mode and for this show-newlines-mode.

Since unicode is no problem, I would suggest to use the pilcrow for  
both modes, and stick to no background color and grey foreground for  
the show-newlines-mode.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[Vinicius Jose Latorre]

David Reitter wrote:
> On 22 Jul 2008, at 21:53, Vinicius Jose Latorre wrote:
>>>
>>> I would still want the pilcrow to be used by default and the more 
>>> (s/t)ame colors for the face.
>>> But that may well be the default for whitespace in general.
>>
>> Well, you can change the whitespace-newline and 
>> whitespace-display-mappings settings in your ~/.emacs file.
>
> ... so we don't have to set sensible defaults?
>
>> BTW, I also prefer the pilcrow.
>
>
> The default has to be sensible, and this is quite possibly different 
> for the full-blown whitespace-mode and for this show-newlines-mode.
>
> Since unicode is no problem, I would suggest to use the pilcrow for 
> both modes, and stick to no background color and grey foreground for 
> the show-newlines-mode.

Well, the current defaults are sensible.

There was a discussion about whitespace settings before whitespace was 
accepted as part of Emacs.

When I said that I also prefer pilcrow, I was expressing my preference, 
but this is not the consensus about these settings.

Anyway, anyone can change these settings in ~/.emacs file to reflect 
personal preferences.

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

On 22 Jul 2008, at 23:19, Vinicius Jose Latorre wrote:
>
> Well, the current defaults are sensible.
>
> There was a discussion about whitespace settings before whitespace  
> was accepted as part of Emacs.
>
> When I said that I also prefer pilcrow, I was expressing my  
> preference, but this is not the consensus about these settings.

The weird color combination makes perfect sense for whitespace-mode,  
but not to just mark paragraphs as a regularly enabled function.   
There, the paragraph marks would have to be a lot less conspicuous.   
Perhaps the show-newlines-mode is really something that needs to be  
implemented more separately from  whitespace.el or at least whitespace- 
mode.

This is the last message from me regarding this topic for lack of time.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[Vinicius Jose Latorre]

> The weird color combination makes perfect sense for whitespace-mode, 
> but not to just mark paragraphs as a regularly enabled function.  
> There, the paragraph marks would have to be a lot less conspicuous.  
> Perhaps the show-newlines-mode is really something that needs to be 
> implemented more separately from  whitespace.el or at least 
> whitespace-mode.
>
> This is the last message from me regarding this topic for lack of time.

Please, could you send two images with the "non-weird" colors, one image 
with light background and another with dark background?

Re: line-line-move-visual: was line motion problem

[Vinicius Jose Latorre]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]


> See attachments.
>
> The idea is to use less contrast for the pilcrow.  The whitespace.el 
> colors do the exact opposite: they emphasize the whitespace over the 
> normal text, which is great if and only if you want to just check 
> whitespace and then turn it off again.


Hmmm, yes, it looks good, but lightgrey is a problem with dark 
background and a white foreground, as lightgrey and white have low contrast.

I made some tests with the following setting:

(defface whitespace-newline
  '((((class color) (background dark))
     (:background "grey22" :foreground "gray" :bold nil))
    (((class color) (background light))
     (:background "floralwhite" :foreground "gray" :bold nil))
    (t (:bold nil :underline t)))
  "Face used to visualize NEWLINE char mapping.

See `whitespace-display-mappings'."
  :group 'whitespace)

See the attached images.



[-- Attachment #2: bg-light.png --]
[-- Type: image/png, Size: 3222 bytes --]

[-- Attachment #3: bg-dark.png --]
[-- Type: image/png, Size: 3160 bytes --]

RE: line-line-move-visual: was line motion problem

[Drew Adams]

FWIW: In Framemaker, text symbols (such as pilcrow and section symbol) have the
same color as the preceding text. I think that is a good convention - the
symbols are then always as readable as the text.

FWIW2: In Framemaker, you can toggle display of all text symbols at once.

Re: line-line-move-visual: was line motion problem

[Vinicius Jose Latorre]

> FWIW: In Framemaker, text symbols (such as pilcrow and section symbol) have the
> same color as the preceding text. I think that is a good convention - the
> symbols are then always as readable as the text.
>
> FWIW2: In Framemaker, you can toggle display of all text symbols at once.
>   

FWIW1: Not only Framemaker, also OpenOffice, Word, etc.

FWIW2: whitespace package visualize tabs, (hard) spaces and newlines via 
display table and/or faces.
To visualize as Framemaker (OpenOffice, Word, etc.), just use display 
table, that is:

(setq whitespace-style '(space-mark tab-mark newline-mark))

FWIW3: whitespace also toggles display of all text symbols at once.

RE: line-line-move-visual: was line motion problem

[Drew Adams]

> FWIW2: whitespace package visualize tabs, (hard) spaces and 
> newlines via display table and/or faces. To visualize as
> Framemaker (OpenOffice, Word, etc.), just use display table,
> that is: (setq whitespace-style '(space-mark tab-mark newline-mark))
> 
> FWIW3: whitespace also toggles display of all text symbols at once.

Sounds good. I didn't try your code; I was just offering some feedback based on
the images you sent, in case it helped.

Re: line-line-move-visual: was line motion problem

[Vinicius Jose Latorre]

>> FWIW2: whitespace package visualize tabs, (hard) spaces and 
>> newlines via display table and/or faces. To visualize as
>> Framemaker (OpenOffice, Word, etc.), just use display table,
>> that is: (setq whitespace-style '(space-mark tab-mark newline-mark))
>>
>> FWIW3: whitespace also toggles display of all text symbols at once.
>>     
>
> Sounds good. I didn't try your code; I was just offering some feedback based on
> the images you sent, in case it helped.
>   

Feedback, like yours and David's, helps to improve whitespace package.

Please, try whitespace and see what could/should be 
improved/extended/generalized.

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On 25 Jul 2008, at 20:15, Vinicius Jose Latorre wrote:

>
>> See attachments.
>>
>> The idea is to use less contrast for the pilcrow.  The  
>> whitespace.el colors do the exact opposite: they emphasize the  
>> whitespace over the normal text, which is great if and only if you  
>> want to just check whitespace and then turn it off again.
>
>
> Hmmm, yes, it looks good, but lightgrey is a problem with dark  
> background and a white foreground, as lightgrey and white have low  
> contrast.

Low contrast is precisely what I wanted to achieve.
The extra paragraph marks don't need to stand out.  The text being  
edited needs to be prominent.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[Vinicius Jose Latorre]

>>> See attachments.
>>>
>>> The idea is to use less contrast for the pilcrow.  The whitespace.el 
>>> colors do the exact opposite: they emphasize the whitespace over the 
>>> normal text, which is great if and only if you want to just check 
>>> whitespace and then turn it off again.
>>
>>
>> Hmmm, yes, it looks good, but lightgrey is a problem with dark 
>> background and a white foreground, as lightgrey and white have low 
>> contrast.
>
> Low contrast is precisely what I wanted to achieve.
> The extra paragraph marks don't need to stand out.  The text being 
> edited needs to be prominent.

What I meant is that lightgray and white colors seem almost the same color.

I've just tried with darkgray instead of lightgray, it seems better, the 
text (white foreground) is more prominent than newline (darkgray 
foreground).

Re: line-line-move-visual: was line motion problem

[T. V. Raman]

1+ on whitespace.el -- it's what I depend on in general to clean
up unnecessary whitespace in various portions of code I write.

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
    Dan> Stefan Monnier <monnier@iro.umontreal.ca> writes:
    >> >> I don't know how many people actually want them in
    >> visual-line-mode >> (I'd like a fringe item at a hard
    >> newline, but until this is >> implemented the next best
    >> thing is a display-table element for \n).
    >> 
    >> > We could leave the continuation glyphs, but make them
    >> less conspicuous.
    >> 
    >> For a mode that expects most lines to be wrapped, I see
    >> not point in leaving continuation marks.
    >> 
    >> > To mark hard newlines, try the code below.  I suggest to
    >> include this.
    >> 
    >> > ;; 2230 = \x8B6 > (defvar show-newlines-newline-code
    >> (vector (make-glyph-code 2230 > blank-newline) 10))
    >> 
    >> [ Too long a line, huh? ]
    >> 
    >> My font doesn't seem to know the char 2230, and
    >> UnicodeData.txt doesn't seem to know that char either.  So
    >> we should probably use something else.
    >> 
    >> > (if show-newlines-mode > (aset buffer-display-table 10
    >> show-newlines-newline-code) > (aset buffer-display-table
    >> 10 nil)))
    >> 
    >> Better write it as:
    >> 
    >> (aset buffer-display-table 10 (if show-newlines-mode
    >> show-newlines-newline-code))
    Dan> 
    Dan> whitespace.el already has many many ways of dealing with
    Dan> whitespaces, wouldn't this mode be a better fit in
    Dan> whitespace.el?

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: line-line-move-visual: was line motion problem

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On 18 Jul 2008, at 11:21, Stefan Monnier wrote:
> My font doesn't seem to know the char 2230, and UnicodeData.txt  
> doesn't
> seem to know that char either.  So we should probably use something  
> else.

It's the standard unicode 182 (U+00B6), "Pilcrow". See also: http://en.wikipedia.org/wiki/Pilcrow

2230 might be wrong for the general case, but it does work for me.  Do  
you know what the right code would be?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: line-line-move-visual: was line motion problem

[Jason Rumney]

David Reitter wrote:
> On 18 Jul 2008, at 11:21, Stefan Monnier wrote:
>> My font doesn't seem to know the char 2230, and UnicodeData.txt doesn't
>> seem to know that char either.  So we should probably use something else.
> 
> It's the standard unicode 182 (U+00B6), "Pilcrow". See also:
> http://en.wikipedia.org/wiki/Pilcrow
> 
> 2230 might be wrong for the general case, but it does work for me.

Are you using 22.2 (or the 22 branch)? 2230 seems to be the code point
for a latin-1 pilcrow in emacs-mule encoding. In the trunk, the code
point should be 182.

Re: line-line-move-visual: was line motion problem

[Chong Yidong]

Miles Bader <miles.bader@necel.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>> Since no one has commented, I've gone ahead and checked in
>> visual-line-mode into CVS.  Problem reports would be welcome.
>
> Seems to work pretty well...
>
> C-k acts a bit strangely, I think because it doesn't delete the
> whitespace at the end of the killed "line"; the result is that the
> cursor always ends up on the end of the previous "line" after using it.
>
> Also, what about dealing with fringe continuation glyphs?  I understand
> that some people want them, even in visual-line-mode, but I think many
> won't want them, so it would be good if there were an easy setting that
> would cause visual-line-mode suppress them.

The following simple patch implements a new variable,
`word-wrap-disable-fringe-indicators', that hides the continuation
indicators when word-wrap is on.  (The variable name is a little long
but I can't think of anything else.)

WDYT?

*** trunk/src/fringe.c.~1.53.~	2008-07-15 14:47:33.000000000 -0400
--- trunk/src/fringe.c	2008-07-18 12:03:55.000000000 -0400
***************
*** 39,44 ****
--- 39,48 ----
  
  Lisp_Object Voverflow_newline_into_fringe;
  
+ /* Non-nil means suppress continuation glyphs for word-wrap.  */
+ 
+ Lisp_Object Vword_wrap_disable_fringe_indicators;
+ 
  /* List of known fringe bitmap symbols.
  
     The fringe bitmap number is stored in the `fringe' property on
***************
*** 958,963 ****
--- 962,968 ----
    Lisp_Object ind = Qnil;
  #define MAX_BITMAP_CACHE (8*4)
    int bitmap_cache[MAX_BITMAP_CACHE];
+   int show_left_continuation, show_right_continuation;
  
    if (w->pseudo_window_p)
      return 0;
***************
*** 1058,1063 ****
--- 1063,1076 ----
     : (bitmap_cache[cache*4+2+partial_p] =			\
        get_logical_fringe_bitmap (w, which, 1, partial_p)))
  
+   show_left_continuation
+     = (NILP (XBUFFER (w->buffer)->word_wrap)
+        || NILP (Vword_wrap_disable_fringe_indicators)
+        || EQ (Vword_wrap_disable_fringe_indicators, Qright));
+   show_right_continuation
+     = (NILP (XBUFFER (w->buffer)->word_wrap)
+        || NILP (Vword_wrap_disable_fringe_indicators)
+        || EQ (Vword_wrap_disable_fringe_indicators, Qleft));
  
    for (y = 0, rn = 0;
         y < yb && rn < nrows;
***************
*** 1089,1095 ****
  		: LEFT_FRINGE (2, Qtop, 0));
        else if (row->indicate_eob_p && EQ (boundary_bot, Qleft))
  	left = LEFT_FRINGE (3, Qbottom, row->ends_at_zv_p);
!       else if (MATRIX_ROW_CONTINUATION_LINE_P (row))
  	left = LEFT_FRINGE (4, Qcontinuation, 0);
        else if (row->indicate_empty_line_p && EQ (empty_pos, Qleft))
  	left = LEFT_FRINGE (5, Qempty_line, 0);
--- 1102,1109 ----
  		: LEFT_FRINGE (2, Qtop, 0));
        else if (row->indicate_eob_p && EQ (boundary_bot, Qleft))
  	left = LEFT_FRINGE (3, Qbottom, row->ends_at_zv_p);
!       else if (MATRIX_ROW_CONTINUATION_LINE_P (row)
! 	       && show_left_continuation)
  	left = LEFT_FRINGE (4, Qcontinuation, 0);
        else if (row->indicate_empty_line_p && EQ (empty_pos, Qleft))
  	left = LEFT_FRINGE (5, Qempty_line, 0);
***************
*** 1116,1122 ****
  		 : RIGHT_FRINGE (2, Qtop, 0));
        else if (row->indicate_eob_p && EQ (boundary_bot, Qright))
  	right = RIGHT_FRINGE (3, Qbottom, row->ends_at_zv_p);
!       else if (row->continued_p)
  	right = RIGHT_FRINGE (4, Qcontinuation, 0);
        else if (row->indicate_top_line_p && EQ (arrow_top, Qright))
  	right = RIGHT_FRINGE (6, Qup, 0);
--- 1130,1137 ----
  		 : RIGHT_FRINGE (2, Qtop, 0));
        else if (row->indicate_eob_p && EQ (boundary_bot, Qright))
  	right = RIGHT_FRINGE (3, Qbottom, row->ends_at_zv_p);
!       else if (row->continued_p
! 	       && show_right_continuation)
  	right = RIGHT_FRINGE (4, Qcontinuation, 0);
        else if (row->indicate_top_line_p && EQ (arrow_top, Qright))
  	right = RIGHT_FRINGE (6, Qup, 0);
***************
*** 1649,1654 ****
--- 1664,1681 ----
  If nil, also continue lines which are exactly as wide as the window.  */);
    Voverflow_newline_into_fringe = Qt;
  
+   DEFVAR_LISP ("word-wrap-disable-fringe-indicators",
+ 	       &Vword_wrap_disable_fringe_indicators,
+     doc: /* *If non-nil, suppress fringe indicators when word-wrap is on.
+ This variable takes effect only if `word-wrap' is non-nil.
+ If its value is nil, the usual fringe indicators associated with
+ continuation lines are displayed for wrapped lines.
+ If its value is `left', the left fringe indicator is not displayed.
+ If its value is `right', the right fringe indicator is not displayed.
+ Any other non-nil value means neither fringe indicator is displayed.
+ This variable does not affect other types of fringe indicators.  */);
+   Vword_wrap_disable_fringe_indicators = Qt;
+ 
    DEFVAR_LISP ("fringe-bitmaps", &Vfringe_bitmaps,
      doc: /* List of fringe bitmap symbols.  */);
    Vfringe_bitmaps = Qnil;

Re: line-line-move-visual: was line motion problem

[Stefan Monnier]

> The following simple patch implements a new variable,
> `word-wrap-disable-fringe-indicators', that hides the continuation
> indicators when word-wrap is on.  (The variable name is a little long
> but I can't think of anything else.)

I think it should not be linked to word-wrap but to visual-line-mode
(or longlines-mode).
A side-benefit is that it can then be all done in Elisp.


        Stefan

Re: line-line-move-visual: was line motion problem

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The following simple patch implements a new variable,
>> `word-wrap-disable-fringe-indicators', that hides the continuation
>> indicators when word-wrap is on.  (The variable name is a little long
>> but I can't think of anything else.)
>
> I think it should not be linked to word-wrap but to visual-line-mode
> (or longlines-mode).  A side-benefit is that it can then be all done
> in Elisp.

You mean, have a variable `continuation-fringe-indicators', and make
visual-line-mode set it?

Re: line-line-move-visual: was line motion problem

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think it should not be linked to word-wrap but to visual-line-mode
> (or longlines-mode).
> A side-benefit is that it can then be all done in Elisp.

Oh I see what you mean: something like this?  (i.e., making
visual-line-mode modify fringe-indicator-alist)?


*** trunk/lisp/simple.el.~1.935.~ 2008-07-18
01:10000 -0400
--- trunk/lisp/simple.el      2008-07-19 23:39:47.000000000
-0400
***************
*** 4482,4490 ****
    (if visual-line-mode
        (progn
        (set (make-local-variable 'line-move-visual) t)
!       (setq word-wrap t))
      (kill-local-variable 'line-move-visual)
!     (kill-local-variable 'word-wrap)))
  
  (defun turn-on-visual-line-mode ()
    (visual-line-mode 1))
--- 4482,4494 ----
    (if visual-line-mode
        (progn
        (set (make-local-variable 'line-move-visual) t)
!       (setq word-wrap t)
!       (setq fringe-indicator-alist (copy-tree fringe-indicator-alist))
!       (setcdr (assq 'continuation fringe-indicator-alist)
!               (list nil nil nil nil)))
      (kill-local-variable 'line-move-visual)
!     (kill-local-variable 'word-wrap)
!     (kill-local-variable 'fringe-indicator-alist)))
  
  (defun turn-on-visual-line-mode ()
    (visual-line-mode 1))

Re: line-line-move-visual: was line motion problem

[Miles Bader]

No need to copy/modify fringe-indicator-alist I think; how about just
doing:

   (push '(continuation) fringe-indicator-alist)

[the display engine only looks at the first entry]

-Miles

-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: line-line-move-visual: was line motion problem

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> No need to copy/modify fringe-indicator-alist I think; how about just
> doing:
>
>    (push '(continuation) fringe-indicator-alist)

Indeed.  I just checked in something to CVS along these lines.

Re: line-line-move-visual: was line motion problem

[Juri Linkov]

>> The following patch implements this approach.  I've taken bits from
>> visual-line.el, and re-written other bits to make use of the new
>> features of vertical-motion in Emacs 23.
>>
>> Could people try it out and see if it DTRT?
>
> Since no one has commented, I've gone ahead and checked in
> visual-line-mode into CVS.  Problem reports would be welcome.

It seems that keys M-[ and M-] are more suitable for moving to the
beginning/end of the real line because similar keys M-{ and M-} are
bound to commands that move point to the beginning/end of the paragraph.

Maybe better keys for moving to the next/previous real line are
M-down and M-up?

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

Re: line-line-move-visual: was line motion problem

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> It seems that keys M-[ and M-] are more suitable for moving to the
> beginning/end of the real line because similar keys M-{ and M-} are
> bound to commands that move point to the beginning/end of the paragraph.

M-[ and M-] are not so good because they are commonly used as a prefix
for terminal function keys.

-Miles

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.

Re: line-line-move-visual: was line motion problem

[Juri Linkov]

> Juri Linkov <juri@jurta.org> writes:
>> It seems that keys M-[ and M-] are more suitable for moving to the
>> beginning/end of the real line because similar keys M-{ and M-} are
>> bound to commands that move point to the beginning/end of the paragraph.
>
> M-[ and M-] are not so good because they are commonly used as a prefix
> for terminal function keys.

Then maybe M-home and M-end to move to the beginning/end of the real line.

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

Re: line-line-move-visual: was line motion problem

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>>> The following patch implements this approach.  I've taken bits from
>>> visual-line.el, and re-written other bits to make use of the new
>>> features of vertical-motion in Emacs 23.
>>>
>>> Could people try it out and see if it DTRT?
>>
>> Since no one has commented, I've gone ahead and checked in
>> visual-line-mode into CVS.  Problem reports would be welcome.
>
> It seems that keys M-[ and M-] are more suitable for moving to the
> beginning/end of the real line because similar keys M-{ and M-} are
> bound to commands that move point to the beginning/end of the paragraph.

That makes sense.

Re: line-line-move-visual: was line motion problem

[T. V. Raman]

I  think changing the behavior of the arrow keys and c-n / c-p to
default to the behavior from visual-line-mode is simply too
drastic a change for Emacs. It should be customizable, and once a
minor mode,  come with a turn-on-visual-mode that users can place
on various hooks. 

>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:
    David> On 16 Jul 2008, at 12:26, Stefan Monnier wrote:
    >> 
    >> Yes, it should be a define-minor-mode (with name ending in
    >> "-mode").  Can someone make this change?
    David> 
    David> 
    David> What do we conclude from the discussion related to
    David> this?
    David> 
    David> My understanding is that we were going to have visual
    David> navigation (arrow keys, C-n, C-p) default to on, and
    David> leave default behavior of C- a and C-e as is, with
    David> some code (from the visual-line-mode that I posted) to
    David> optionally remap C-a and C-e to visual navigation as
    David> it is sensible in text modes.
    David> 
    David> Should this be one minor mode that defaults to on, or
    David> should we have two minor modes then?  Also, should C-a
    David> and C-e default to the visual mode in all text modes?
    David> (Would that just go in text-mode-hook?)
    David> 
    David> 
    David> 

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs