keymap in yank-excluded-properties

keymap in yank-excluded-properties

[Tak Ota]

Since the following change was made to yank's underpinning, a table
created by `table.el' becomes dead after copying because keymap text
property is stripped off at yank.

2002-04-29  Kim F. Storm  <storm@cua.dk>

	* subr.el (remove-yank-excluded-properties): New helper function.
	(insert-for-yank, insert-buffer-substring-as-yank): Use it.

	* simple.el (yank-excluded-properties): Added help-echo to list.

Is it generally a good idea not to copy keymap text property?  If
majority of you agree that yank normally should not copy keymap
property, is the following modification to the function
`remove-yank-excluded-properties' acceptable?  The idea is if a
special text property `yank-preserve-all-properties' exists in the
region and its value is non-nil then yank will not strip any text
properties off.

-Tak

*** ../../pure/emacs-21.3.50/lisp/subr.el	Fri Aug  2 21:26:30 2002
--- subr.el	Thu Aug 22 15:59:53 2002
***************
*** 1415,1441 ****
  (defun remove-yank-excluded-properties (start end)
    "Remove `yank-excluded-properties' between START and END positions.
  Replaces `category' properties with their defined properties."
!   (let ((inhibit-read-only t))
!     ;; Replace any `category' property with the properties it stands for.
!     (unless (memq yank-excluded-properties '(t nil))
!       (save-excursion
! 	(goto-char start)
! 	(while (< (point) end)
! 	  (let ((cat (get-text-property (point) 'category))
! 		run-end)
! 	    (when cat
  	      (setq run-end
  		    (next-single-property-change (point) 'category nil end))
! 	      (remove-list-of-text-properties (point) run-end '(category))
! 	      (add-text-properties (point) run-end (symbol-plist cat))
! 	      (goto-char (or run-end end)))
! 	    (setq run-end
! 		  (next-single-property-change (point) 'category nil end))
! 	    (goto-char (or run-end end))))))
!     (if (eq yank-excluded-properties t)
! 	(set-text-properties start end nil)
!       (remove-list-of-text-properties start end
! 				      yank-excluded-properties))))
  
  (defun insert-for-yank (&rest strings)
    "Insert STRINGS at point, stripping some text properties.
--- 1415,1442 ----
  (defun remove-yank-excluded-properties (start end)
    "Remove `yank-excluded-properties' between START and END positions.
  Replaces `category' properties with their defined properties."
!   (unless (text-property-any start end 'yank-preserve-all-properties t)
!     (let ((inhibit-read-only t))
!       ;; Replace any `category' property with the properties it stands for.
!       (unless (memq yank-excluded-properties '(t nil))
! 	(save-excursion
! 	  (goto-char start)
! 	  (while (< (point) end)
! 	    (let ((cat (get-text-property (point) 'category))
! 		  run-end)
! 	      (when cat
! 		(setq run-end
! 		      (next-single-property-change (point) 'category nil end))
! 		(remove-list-of-text-properties (point) run-end '(category))
! 		(add-text-properties (point) run-end (symbol-plist cat))
! 		(goto-char (or run-end end)))
  	      (setq run-end
  		    (next-single-property-change (point) 'category nil end))
! 	      (goto-char (or run-end end))))))
!       (if (eq yank-excluded-properties t)
! 	  (set-text-properties start end nil)
! 	(remove-list-of-text-properties start end
! 					yank-excluded-properties)))))
  
  (defun insert-for-yank (&rest strings)
    "Insert STRINGS at point, stripping some text properties.

Re: keymap in yank-excluded-properties

[Miles Bader]

Tak Ota <Takaaki.Ota@am.sony.com> writes:
> Is it generally a good idea not to copy keymap text property?

Yes

> If majority of you agree that yank normally should not copy keymap
> property, is the following modification to the function
> `remove-yank-excluded-properties' acceptable?  The idea is if a
> special text property `yank-preserve-all-properties' exists in the
> region and its value is non-nil then yank will not strip any text
> properties off.

I think a better question is `Should tables (and more importantly,
_parts_ of tables) really remain "active" after yanking?'.  It sounds
rather annoying to me for the same reason that yanked keymap properties
usually are.

[BTW, if it's decided that this _is_ a good feature, please call the
property something like `yank-preserved-properties' (actually I'm rather
fond of `yankable-properties') and make it a list of property names or t.]

Thanks,

-Miles
-- 
Fast, small, soon; pick any 2.

Re: keymap in yank-excluded-properties

[Kim F. Storm]

Tak Ota <Takaaki.Ota@am.sony.com> writes:

> Since the following change was made to yank's underpinning, a table
> created by `table.el' becomes dead after copying because keymap text
> property is stripped off at yank.
> 
> 2002-04-29  Kim F. Storm  <storm@cua.dk>
> 
> 	* subr.el (remove-yank-excluded-properties): New helper function.
> 	(insert-for-yank, insert-buffer-substring-as-yank): Use it.
> 
> 	* simple.el (yank-excluded-properties): Added help-echo to list.

I cannot take all the credit for this :-)  It was actually Richard who
added the yank-excluded-properties feature in the first place.

> Is it generally a good idea not to copy keymap text property? 

Definitely!

Depending on the target, keeping a keymap text property is like
burying a landmine waiting for someone to step on it.


> If
> majority of you agree that yank normally should not copy keymap
> property, is the following modification to the function
> `remove-yank-excluded-properties' acceptable?  The idea is if a
> special text property `yank-preserve-all-properties' exists in the
> region and its value is non-nil then yank will not strip any text
> properties off.

Again, it depends on what the target is.  I would say that if the
source and target buffers are the same, or have the same major-mode,
then probably keeping (more) text properties when yanking might be
acceptable.  But doing that requires saving some context info with
each kill, so its not trivial to do.


An alternative would be to have a simple function:

(defun yank-with-properties (&optional arg)
  "Like `yank', but does not remove text properties from inserted text."
  (interactive "*P")
  (let ((yank-excluded-properties nil))
    (yank arg)))        

Then you can make an alias if you like.

(defalias 'yank-table 'yank-with-properties)

Of course, the problem is how to put this functionality on C-y ...

Maybe something like this could be used:

(defun yank-keep-tables (&optional arg)
  "Like `yank' but knows about tables."
  (interactive ...)
  (let ((start (point)) end)
    (let ((yank-excluded-properties nil))
      (yank nil)
      (setq end (point)))
    (unless (table-recognize-table start end)  ;; <--- new function
      (remove-yank-excluded-properties start end))
    (if arg
      (goto-char start))))



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

Re: keymap in yank-excluded-properties

[Tak Ota]

23 Aug 2002 10:55:47 +0900: Miles Bader <miles@lsi.nec.co.jp> wrote:

> I think a better question is `Should tables (and more importantly,
> _parts_ of tables) really remain "active" after yanking?'.  It sounds
> rather annoying to me for the same reason that yanked keymap properties
> usually are.

Table mode does not use global map or local map.  Its special behavior
solely depends on keymap text property.  It does not provide copying
and pasting of table cells/rows/columns because it depends on standard
emacs features to accomplish those tasks provided keymap properties
are intact with the copied text.

> [BTW, if it's decided that this _is_ a good feature, please call the
> property something like `yank-preserved-properties' (actually I'm rather
> fond of `yankable-properties') and make it a list of property names or t.]

Sorry that the diff makes the change look complicated but what I
proposed was an introduction of a new text property
`yank-preserve-all-properties' instead of a new variable
`yankable-properties' that holds properties to preserve.  The actual
proposed change is an insertion of the following single line with a
corresponding closing parenthesis at the end.

   (unless (text-property-any start end 'yank-preserve-all-properties t)

Introduction of a new variable that holds what properties to preserve
is effective globally or at least across the entire buffer.  I want to
avoid this.  Instead, what I am proposing is if the subject region
contains a special text property let yank allow preserving all text
properties.  That is the intention of the naming of the new property.

-Tak


*** ../../pure/emacs-21.3.50/lisp/subr.el	Fri Aug  2 21:26:30 2002
--- subr.el	Thu Aug 22 15:59:53 2002
***************
*** 1415,1441 ****
  (defun remove-yank-excluded-properties (start end)
    "Remove `yank-excluded-properties' between START and END positions.
  Replaces `category' properties with their defined properties."
!   (let ((inhibit-read-only t))
!     ;; Replace any `category' property with the properties it stands for.
!     (unless (memq yank-excluded-properties '(t nil))
!       (save-excursion
! 	(goto-char start)
! 	(while (< (point) end)
! 	  (let ((cat (get-text-property (point) 'category))
! 		run-end)
! 	    (when cat
  	      (setq run-end
  		    (next-single-property-change (point) 'category nil end))
! 	      (remove-list-of-text-properties (point) run-end '(category))
! 	      (add-text-properties (point) run-end (symbol-plist cat))
! 	      (goto-char (or run-end end)))
! 	    (setq run-end
! 		  (next-single-property-change (point) 'category nil end))
! 	    (goto-char (or run-end end))))))
!     (if (eq yank-excluded-properties t)
! 	(set-text-properties start end nil)
!       (remove-list-of-text-properties start end
! 				      yank-excluded-properties))))
  
  (defun insert-for-yank (&rest strings)
    "Insert STRINGS at point, stripping some text properties.
--- 1415,1442 ----
  (defun remove-yank-excluded-properties (start end)
    "Remove `yank-excluded-properties' between START and END positions.
  Replaces `category' properties with their defined properties."
!   (unless (text-property-any start end 'yank-preserve-all-properties t)
!     (let ((inhibit-read-only t))
!       ;; Replace any `category' property with the properties it stands for.
!       (unless (memq yank-excluded-properties '(t nil))
! 	(save-excursion
! 	  (goto-char start)
! 	  (while (< (point) end)
! 	    (let ((cat (get-text-property (point) 'category))
! 		  run-end)
! 	      (when cat
! 		(setq run-end
! 		      (next-single-property-change (point) 'category nil end))
! 		(remove-list-of-text-properties (point) run-end '(category))
! 		(add-text-properties (point) run-end (symbol-plist cat))
! 		(goto-char (or run-end end)))
  	      (setq run-end
  		    (next-single-property-change (point) 'category nil end))
! 	      (goto-char (or run-end end))))))
!       (if (eq yank-excluded-properties t)
! 	  (set-text-properties start end nil)
! 	(remove-list-of-text-properties start end
! 					yank-excluded-properties)))))
  
  (defun insert-for-yank (&rest strings)
    "Insert STRINGS at point, stripping some text properties.

Re: keymap in yank-excluded-properties

[Stefan Monnier]

> > [BTW, if it's decided that this _is_ a good feature, please call the
> > property something like `yank-preserved-properties' (actually I'm rather
> > fond of `yankable-properties') and make it a list of property names or t.]
> 
> Sorry that the diff makes the change look complicated but what I
> proposed was an introduction of a new text property
> `yank-preserve-all-properties' instead of a new variable
> `yankable-properties' that holds properties to preserve.  The actual

Miles didn't propose a variable.  He just suggested a more general
property with a different name and which includes yours as a special case.

> proposed change is an insertion of the following single line with a
> corresponding closing parenthesis at the end.
> 
>    (unless (text-property-any start end 'yank-preserve-all-properties t)

Use the -b and -w switches to diff to make the diff more human
readable (and a bit less computer-usable, but it's OK in this case).


	Stefan

Re: keymap in yank-excluded-properties

[Tak Ota]

Fri, 23 Aug 2002 18:29:49 -0400: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> > > [BTW, if it's decided that this _is_ a good feature, please call the
> > > property something like `yank-preserved-properties' (actually I'm rather
> > > fond of `yankable-properties') and make it a list of property names or t.]
> > 
> > Sorry that the diff makes the change look complicated but what I
> > proposed was an introduction of a new text property
> > `yank-preserve-all-properties' instead of a new variable
> > `yankable-properties' that holds properties to preserve.  The actual
> 
> Miles didn't propose a variable.  He just suggested a more general
> property with a different name and which includes yours as a special case.

I see.  Thanks for correcting my understanding.  That makes sense.  So
in case of table the value of `yankable-properties' property should be
like (keymap)?  That is a good idea I think.  The implementation
probably is a bit more elaborate than what I proposed though.

> Use the -b and -w switches to diff to make the diff more human
> readable (and a bit less computer-usable, but it's OK in this case).

Yes, it looks much better.  Thanks.

*** ../../pure/emacs-21.3.50/lisp/subr.el	Fri Aug  2 21:26:30 2002
--- subr.el	Fri Aug 23 13:54:44 2002
***************
*** 1415,1420 ****
--- 1415,1421 ----
  (defun remove-yank-excluded-properties (start end)
    "Remove `yank-excluded-properties' between START and END positions.
  Replaces `category' properties with their defined properties."
+   (unless (text-property-any start end 'yank-preserve-all-properties t)
      (let ((inhibit-read-only t))
        ;; Replace any `category' property with the properties it stands for.
        (unless (memq yank-excluded-properties '(t nil))
***************
*** 1435,1441 ****
      (if (eq yank-excluded-properties t)
  	(set-text-properties start end nil)
        (remove-list-of-text-properties start end
! 				      yank-excluded-properties))))
  
  (defun insert-for-yank (&rest strings)
    "Insert STRINGS at point, stripping some text properties.
--- 1436,1442 ----
        (if (eq yank-excluded-properties t)
  	  (set-text-properties start end nil)
  	(remove-list-of-text-properties start end
! 					yank-excluded-properties)))))
  
  (defun insert-for-yank (&rest strings)
    "Insert STRINGS at point, stripping some text properties.

-Tak

Re: keymap in yank-excluded-properties

[Richard Stallman]

    Is it generally a good idea not to copy keymap text property?

Yes--very much so.  In most cases that leads to very confusing
results.

What's correct to do for yanking a table?  Yanking the whole table
ought to preserve its properties so that the table still functions as
one.  Yanking a part of the table which can act as a complete table in
itself should also do that.  However, yanking some of the text within
the table, which is less than a whole table entry, should forget that
it came from a table and treat it like any ordinary text.

Does that make sense to you?  If so, can you look for a design to
achieve those results?

Re: keymap in yank-excluded-properties

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Is it generally a good idea not to copy keymap text property?
> 
> Yes--very much so.  In most cases that leads to very confusing
> results.
> 
> What's correct to do for yanking a table?  Yanking the whole table
> ought to preserve its properties so that the table still functions as
> one.  Yanking a part of the table which can act as a complete table in
> itself should also do that.  However, yanking some of the text within
> the table, which is less than a whole table entry, should forget that
> it came from a table and treat it like any ordinary text.
> 
> Does that make sense to you?  If so, can you look for a design to
> achieve those results?

Perhaps a new text property `yank-function' which takes a function as value.

`yank' will look for that property on kill-ring elements and call the
function with one argument: the string (or rectangle?) to yank.  The
function is then responsible for inserting the string in the buffer
and remove any unwanted properties [i.e. it is expected to do the
actual insertion].

A table could have this property set to a function which check that 
the string to insert is really a complete table -- and keep the 
properties in that case [using insert] -- or remove the properties 
otherwise [using insert-for-yank].

This is a simple, but flexible concept which may be used for other
purposes as well; for example, text killed by a "special" function
[e.g. kill-rectangle] may be later inserted using plain C-y by another
special function [e.g. insert-rectangle].

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

Re: keymap in yank-excluded-properties

[Tak Ota]

26 Aug 2002 00:49:44 +0200: storm@cua.dk (Kim F. Storm) wrote:

> Perhaps a new text property `yank-function' which takes a function as value.
> 
> `yank' will look for that property on kill-ring elements and call the
> function with one argument: the string (or rectangle?) to yank.  The
> function is then responsible for inserting the string in the buffer
> and remove any unwanted properties [i.e. it is expected to do the
> actual insertion].
> 
> A table could have this property set to a function which check that 
> the string to insert is really a complete table -- and keep the 
> properties in that case [using insert] -- or remove the properties 
> otherwise [using insert-for-yank].
> 
> This is a simple, but flexible concept which may be used for other
> purposes as well; for example, text killed by a "special" function
> [e.g. kill-rectangle] may be later inserted using plain C-y by another
> special function [e.g. insert-rectangle].

I think this is a neat idea.  However, there is a discussion whether
we want `yank-function' that takes over whole `yank' operation or
`yank-insert-function' that replaces only `insert-for-yank' part of
`yank'.  `insert-for-yank' is the one that actually strips off the
undesired text properties.

I prefer later from `table.el' application point of view but the
former is more generic and flexible.  But then that flexibility
involves the relationship with command replacement which is out of the
scope of this discussion.

-Tak

Re: keymap in yank-excluded-properties

[Richard Stallman]

Before designing the mechanism to solve this problem, we need to be
clear on what behavior is right.

Could people please turn their attention to these questions that
I asked about a week ago?

======================================================================
What's correct to do for yanking a table?  Yanking the whole table
ought to preserve its properties so that the table still functions as
one.  Yanking a part of the table which can act as a complete table in
itself should also do that.  However, yanking some of the text within
the table, which is less than a whole table entry, should forget that
it came from a table and treat it like any ordinary text.

Does that make sense to you?  If so, can you look for a design to
achieve those results?

Re: keymap in yank-excluded-properties

[Richard Stallman]

    `yank' will look for that property on kill-ring elements and call the
    function with one argument: the string (or rectangle?) to yank.  The
    function is then responsible for inserting the string in the buffer
    and remove any unwanted properties [i.e. it is expected to do the
    actual insertion].

    A table could have this property set to a function which check that 
    the string to insert is really a complete table -- and keep the 
    properties in that case [using insert] -- or remove the properties 
    otherwise [using insert-for-yank].

That solution could work.

Does anyone see a more narrowly targeted solution to suggest?

Re: keymap in yank-excluded-properties

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> What's correct to do for yanking a table?  Yanking the whole table
> ought to preserve its properties so that the table still functions as
> one.  Yanking a part of the table which can act as a complete table in
> itself should also do that.  However, yanking some of the text within
> the table, which is less than a whole table entry, should forget that
> it came from a table and treat it like any ordinary text.
> 
> Does that make sense to you?

Yes, it makes a lot of sense to me.

The decision what to do must be taken when doing the yank (or
yank-rectangle), rather than the kill or copy, as there just too many
ways to get the (partial) table into the kill-ring, so the only place
where it makes sense to determine whether "the thing" is really a
table is when we yank it.

>   If so, can you look for a design to
> achieve those results?

The design must provide for easily recognizing a table as a table.

It should not recognize something which might look like a table if
that wasn't actually part of a table before

It should recognize partial, but still valid tables, as tables.


I still think that my proposal for a yank-function text property (set
on the original table text, and used by yank and yank-rectangle to do
the yank) would do be a simple, yet powerful approach, as it would use
automatically copy that property to the kill-ring, so there is nothing
we need to add to basic functionality to achieve this.

I think the yank-function property should be removed from the inserted
text before yank calls that function; if necessary, that function is
responsible for adding the yank-function property again if that makes
sense.


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

Re: keymap in yank-excluded-properties

[Richard Stallman]

    The decision what to do must be taken when doing the yank (or
    yank-rectangle), rather than the kill or copy, as there just too many
    ways to get the (partial) table into the kill-ring, so the only place
    where it makes sense to determine whether "the thing" is really a
    table is when we yank it.

That seems plausible.

    I still think that my proposal for a yank-function text property (set
    on the original table text, and used by yank and yank-rectangle to do
    the yank) would do be a simple, yet powerful approach, as it would use
    automatically copy that property to the kill-ring, so there is nothing
    we need to add to basic functionality to achieve this.

How about if the two of you together try implementing the yank-function feature
and a suitable function to handle yanking of tables?  That way, we will see
if the feature really can do the job at hand.

Re: keymap in yank-excluded-properties

[Tak Ota]

Sun, 01 Sep 2002 09:14:35 -0400: Richard Stallman <rms@gnu.org> wrote:

> Could people please turn their attention to these questions that
> I asked about a week ago?
> 
> ======================================================================
> What's correct to do for yanking a table?  Yanking the whole table
> ought to preserve its properties so that the table still functions as
> one.  Yanking a part of the table which can act as a complete table in
> itself should also do that.  However, yanking some of the text within
> the table, which is less than a whole table entry, should forget that
> it came from a table and treat it like any ordinary text.
> 
> Does that make sense to you?  If so, can you look for a design to
> achieve those results?

Tue, 03 Sep 2002 09:26:46 -0400: Richard Stallman <rms@gnu.org> wrote:

> How about if the two of you together try implementing the yank-function feature
> and a suitable function to handle yanking of tables?  That way, we will see
> if the feature really can do the job at hand.

I'm sorry I forgot to reply to your suggested yanking behavior for
table.  What you suggested above made perfect sense.  I'll start
working on how to implement it as `yank-function'.  I expect it is not
as easy to implement as conceptually described above though.

-Tak

Re: keymap in yank-excluded-properties

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> I still think that my proposal for a yank-function text property (set
> on the original table text, and used by yank and yank-rectangle to do
> the yank) would do be a simple, yet powerful approach, as it would use
> automatically copy that property to the kill-ring, so there is nothing
> we need to add to basic functionality to achieve this.

It would be great if this could be used to make the whole rectangle
system less wierd.  E.g., cut onto the normal kill-ring, and use a
`yank-function' property to properly deal with yanking them.

It would be nice to have a special `rectangle-mode' which would make
_all_ the normal kill/copy commands such as C-w and M-w deal in
`rectangles' (and use a highlighting hack to make an active region
really look like a rectangle).  Maybe it could be a temporary mode
activated when you gave a special `set-rectangle-mark' command.

[I guess CUA mode already has something like this, but it'd be nice to
have it for everyone.]

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: keymap in yank-excluded-properties

[Juanma Barranquero]

On 04 Sep 2002 10:11:10 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:

> [I guess CUA mode already has something like this, but it'd be nice to
> have it for everyone.]

It'd be cool to be able to use the wonderful rectangle support from CUA
mode without having to activate all the rest.


                                                           /L/e/k/t/u

Re: keymap in yank-excluded-properties

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > > [I guess CUA mode already has something like this, but it'd be nice to
> > > have it for everyone.]
> > 
> > It'd be cool to be able to use the wonderful rectangle support from CUA
> > mode without having to activate all the rest.
> 
> Isn't that exactly what you get by setting cua-enable-cua-keys to nil ?
> If not, what's wrong with it?

It still leaves other wierd CUA stuff enabled, e.g., shift-key-selection
(maybe that's what Juanma wants but I don't).

Also, it's quite ugly to have to explicitly disable parts of CUA mode
and then turn on CUA mode to get nice rectangle support -- as far as I
can tell there's no _reason_ to intertwine the two except history.

It would be cleaner to have two separate modes, with CUA using rectangle
mode if appropriate (is it?  I almost never use a real CUA system, so I
don't know if they have such a thing...).  [and also for other cua
features that probably should as well; I don't remember which ones there
are, but we discussed this a while ago.]

Of course it would take some work to disentangle them, and I'm not
suggesting that you have to do it... but it would be nice if someone
did.  :-)

-miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: keymap in yank-excluded-properties

[Kim F. Storm]

Juanma Barranquero <lektu@terra.es> writes:

> On 04 Sep 2002 10:11:10 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:
> 
> > [I guess CUA mode already has something like this, but it'd be nice to
> > have it for everyone.]
> 
> It'd be cool to be able to use the wonderful rectangle support from CUA
> mode without having to activate all the rest.

Isn't that exactly what you get by setting cua-enable-cua-keys to nil ?
If not, what's wrong with it?

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

Re: keymap in yank-excluded-properties

[Juanma Barranquero]

On 04 Sep 2002 10:45:12 +0200, storm@cua.dk (Kim F. Storm) wrote:

> Isn't that exactly what you get by setting cua-enable-cua-keys to nil ?

No, you still have Transient Mark mode, shift-key selection, etc. I like
seeing rectangles highlighted, but I don't like transient mark mode even
if I use shift keys to select a region.

> If not, what's wrong with it?

Nothing "wrong", of course. But rectangle support and CUA keys are
very different issues, so it's a bit strange to have them so intertwined.

That said, I'm *not* complaining. CUA-mode is a wonderful piece of work
and I'm very grateful for it.


                                                           /L/e/k/t/u

Re: keymap in yank-excluded-properties

[Juanma Barranquero]

On 04 Sep 2002 17:52:17 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:

> Of course it would take some work to disentangle them, and I'm not
> suggesting that you have to do it... but it would be nice if someone
> did.  :-)

My sentiments exactly.


                                                           /L/e/k/t/u

Re: keymap in yank-excluded-properties

[Per Abrahamsen]

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

> Isn't that exactly what you get by setting cua-enable-cua-keys to nil ?
> If not, what's wrong with it?

Mostly it feels wrong, who looks in a CUA package without being
interested in CUA?

I believe splitting it in two packages would make the rectangle part
much more popular.

Re: keymap in yank-excluded-properties

[Kim F. Storm]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > Isn't that exactly what you get by setting cua-enable-cua-keys to nil ?
> > If not, what's wrong with it?
> 
> Mostly it feels wrong, who looks in a CUA package without being
> interested in CUA?

True.

> 
> I believe splitting it in two packages would make the rectangle part
> much more popular.

If you look at the version included with CVS emacs, you'll find that I
actually have split off most of the rectangle support and global mark
support into separate files.

The reason it is still associated with cua-mode as such is that it still
need the fundamental command remapping which cua-mode does.  I found it
very difficult to separate the two and still maintain the CUA functionality.

Of course, one could take the cua-base.el file and make a new file which
only contains the code necessary to make the new rectangle support work.

Hm, shouldn't be that difficult...  Only "problem" will be that the
commands and variables for the new rectangle supports still uses the cua-
prefix ...

.. but that should be OK, as it just shows the origin of the new
rectangle support [just like ange-ftp does, IIUC].


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

Re: keymap in yank-excluded-properties

[Kim F. Storm]

Juanma Barranquero <lektu@terra.es> writes:

> On 04 Sep 2002 10:45:12 +0200, storm@cua.dk (Kim F. Storm) wrote:
> 
> > Isn't that exactly what you get by setting cua-enable-cua-keys to nil ?
> 
> No, you still have Transient Mark mode, shift-key selection, etc. I like
> seeing rectangles highlighted, but I don't like transient mark mode even
> if I use shift keys to select a region.

I think there should be ways to customize the use of these features.

> 
> > If not, what's wrong with it?
> 
> Nothing "wrong", of course. But rectangle support and CUA keys are
> very different issues, so it's a bit strange to have them so intertwined.

They are not so intertwined as they used to be.  Most of the functionality
is now in a separate file cua-rect.el, so the amount of work needed to
be able to use cua-style rectangles without enabling cua-mode should be
reasonable.

> 
> That said, I'm *not* complaining. CUA-mode is a wonderful piece of work
> and I'm very grateful for it.
> 
Tanx!

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

Re: keymap in yank-excluded-properties

[Juanma Barranquero]

On 04 Sep 2002 14:48:01 +0200, storm@cua.dk (Kim F. Storm) wrote:

> I think there should be ways to customize the use of these features.

Yes.

> They are not so intertwined as they used to be.

I know. But before the integration of CUA into Emacs I used rect-mark.el
(or whatever its name) and didn't use the old CUA module, so from my
point of view they're more intertwined that they were ;-) (Obviously
I've gained *much* functionality.)

                                                           /L/e/k/t/u

Re: keymap in yank-excluded-properties

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> If you look at the version included with CVS emacs, you'll find that I
> actually have split off most of the rectangle support and global mark
> support into separate files.
> 
> The reason it is still associated with cua-mode as such is that it still
> need the fundamental command remapping which cua-mode does.  I found it
> very difficult to separate the two and still maintain the CUA functionality.

Is that something that can be made generic too (and then used by CUA)?
[sorry I haven't looked at the code]

> Hm, shouldn't be that difficult...  Only "problem" will be that the
> commands and variables for the new rectangle supports still uses the cua-
> prefix ...

It's not hard to change the prefix.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: keymap in yank-excluded-properties

[Richard Stallman]

    It would be great if this could be used to make the whole rectangle
    system less wierd.  E.g., cut onto the normal kill-ring, and use a
    `yank-function' property to properly deal with yanking them.

This could be a good thing, especially if we make register
commands handle `yank-function' also.

    It would be nice to have a special `rectangle-mode' which would make
    _all_ the normal kill/copy commands such as C-w and M-w deal in
    `rectangles' (and use a highlighting hack to make an active region
    really look like a rectangle).

I don't think this makes sense as a mode.  I think that operating on a
rectangle is something that many users want to do once in a while, not
something certain users want to do all the time or that you always want
in certain files.

      Maybe it could be a temporary mode
    activated when you gave a special `set-rectangle-mark' command.

That interface could be a good one for rectangles.

Re: keymap in yank-excluded-properties

[Robert J. Chassell]

   storm@cua.dk (Kim F. Storm) writes:
   > If you look at the version included with CVS emacs, you'll find that I
   > actually have split off most of the rectangle support ...

Good!

   > Hm, shouldn't be that difficult...  Only "problem" will be that the
   > commands and variables for the new rectangle supports still uses the cua-
   > prefix ...

Miles:

   It's not hard to change the prefix.

Please change the prefix.  

I see no reason to study changes in cua, but might be interested in
something involving rectangles.  Did someone say that the code
highlights rectangles, but does not involve transient mark mode?  If
so, your feature might be very nice!

By putting the new rectangle supports in a cua package you are,
effectively, hiding them.  I am sure that few would think of looking
for rectangle support in a cua package.  I can imagine a conversation:

    First hacker: 

        Oh, I want some new rectangle support.

    Second hacker: 

        Look into the cua package, remove all the stuff associated with
        cua, except its new rectangle support.

This is not the way to increase use of rectangle support!

But if my understanding is correct, you have written a really nice feature!

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

Re: keymap in yank-excluded-properties

[Per Abrahamsen]

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

> Why is the prefix important?

Psychology.

> Does it matter whether the function bound to S-RET is named
> cua-set-rectangle-mark or set-rectangle-mark?

Yes.

Re: keymap in yank-excluded-properties

[Robert J. Chassell]

       It would be nice to have a special `rectangle-mode' which would make
       _all_ the normal kill/copy commands such as C-w and M-w deal in
       `rectangles' (and use a highlighting hack to make an active region
       really look like a rectangle).

   I don't think this makes sense as a mode.  

It could be a `context specific minor mode', as proposed for table.el,
activated, perhaps, when you give a special `set-rectangle-mark'
command.  

Hmmm .... Emacs Calc embedded mode creates what is, in effect, a
`context specific minor mode' for the appropriate region in a non-Calc
buffer.  This concept is a good way to think about what goes on.

Below is an example of Calc embedded mode.  I am actually using Calc
embedded mode in this Mail mode buffer to write this message.

What I am trying to say is that I think it is useful to think of Calc
as creating a `context specific minor mode' when you run the embedded
mode commands, and that in talking about table.el and the new
rectangle support commands, the idea of a `context specific minor
mode' is useful.

   (To calculate the length of the hypotenuse of a right triangle.
    Press `M-# u' (`calc-embedded-update-formula') within each region
    delimited by $ pairs.)

    If the two short side of the triangle are

       $ a := 3.1 $

       $ b := 4.1 $

    then the length of the hypotenuse is

       $ c := sqrt(a^2 + b^2) => $.

    which, when you press `M-# u' a third time, becomes:

       $ c := sqrt(a^2 + b^2) => 5.14003891036 $.

    (Sometimes 5.14003891036 is shown as sqrt(26.42); that depends on
    your settings.  The floating point number should be the default.)

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

Re: keymap in yank-excluded-properties

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    storm@cua.dk (Kim F. Storm) writes:
>    > If you look at the version included with CVS emacs, you'll find that I
>    > actually have split off most of the rectangle support ...
> 
> Good!
> 
>    > Hm, shouldn't be that difficult...  Only "problem" will be that the
>    > commands and variables for the new rectangle supports still uses the cua-
>    > prefix ...
> 
> Miles:
> 
>    It's not hard to change the prefix.
> 
> Please change the prefix.  

Why is the prefix important?

Does it matter whether the function bound to S-RET is named
cua-set-rectangle-mark or set-rectangle-mark?


> 
> I see no reason to study changes in cua, but might be interested in
> something involving rectangles.  Did someone say that the code
> highlights rectangles, but does not involve transient mark mode?  If
> so, your feature might be very nice!
> 
> By putting the new rectangle supports in a cua package you are,
> effectively, hiding them. 

Well, that is how it evolved ...  Basic CUA support , a little
rectangle support, more rectangle support, better CUA support,
rectangle highlighting, register support, global mark support, even
better CUA support, sign papers, split _most functionality_ into
base/rectangle/global-mark modules, install in CVS emacs.

A next step would be to make the rectangle and global mark features
completely self-contained, and then interface CUA to them.

> But if my understanding is correct, you have written a really nice feature!

Try it out for yourself:

Options->CUA-style cut and paste
S-RET
..

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

Re: keymap in yank-excluded-properties

[Robert J. Chassell]

   > Please change the prefix.  

   Why is the prefix important?

   Does it matter whether the function bound to S-RET is named
   cua-set-rectangle-mark or set-rectangle-mark?

Yes!  Because I am not likely to pay any attention to 
cua-set-rectangle-mark but might be curious about
set-rectangle-mark.  This is because I have no interest in cua
bindings.  I am sure others a similar.  Someone writing in CC mode,
for example, will not look there for Gnus related commands.

   > By putting the new rectangle supports in a cua package you are,
   > effectively, hiding them. 

   Well, that is how it evolved ...  

I understand that.  It makes sense.  But now that I have learned about
this neat feature, I would like to try it.  However, I should not have
to worry that if it is part of the cua package it might change
keybindings on me; and I should not have to depend on reading this
list to discover a new, neat feature!

   A next step would be to make the rectangle and global mark features
   completely self-contained, and then interface CUA to them.

Right!

   > But if my understanding is correct, you have written a really nice feature!

   Try it out for yourself:

   Options->CUA-style cut and paste
   S-RET

Please understand, since I do not trust CUA packages, I am going to
start a new instance of Emacs and experiment in that.  [time passes]

.... And I am glad I started a new instance, since the menu item says
it changed my keybindings on me.  (Which is fine if I want to change
my keybinding, but I don't.)

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

Re: keymap in yank-excluded-properties

[Miles Bader]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
>        It would be nice to have a special `rectangle-mode' which would make
>        _all_ the normal kill/copy commands such as C-w and M-w deal in
>        `rectangles' (and use a highlighting hack to make an active region
>        really look like a rectangle).
> 
>    I don't think this makes sense as a mode.  
> 
> It could be a `context specific minor mode', as proposed for table.el,
> activated, perhaps, when you give a special `set-rectangle-mark'
> command.  

That was what I meant.  It would be a minor-mode that got turned on
temporarily when you did `set-rectangle-mark', and presumably turned
off when you do a C-w or hit C-g, or whatever (the minor-mode indicator
would provide a hint that things were slightly different than normal).

[However, sometimes when I'm rearranging a table or something, I'd like
C-SPC to set the rectangle mark instead of the normal mark]

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: keymap in yank-excluded-properties

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > > Hm, shouldn't be that difficult...  Only "problem" will be that
> > > the commands and variables for the new rectangle supports still
> > > uses the cua- prefix ...
> > 
> > It's not hard to change the prefix.
> > 
> > Please change the prefix.  
> 
> Why is the prefix important?

Because the less random noise in user-visible (or programmer-visible,
for that matter) command names, the better.  If rectangle mode is
separated from CUA mode, then the `cua-' prefix becomes random noise.
`Historical interest' is not sufficient reason to retain it; that sort
of thing is better served by comments in the source file.

Anyway, if you don't think it's important, you don't mind if it's
changed, right?

-Miles
-- 
97% of everything is grunge

Re: keymap in yank-excluded-properties

[Andreas Schwab]

Miles Bader <miles@lsi.nec.co.jp> writes:

|> "Robert J. Chassell" <bob@rattlesnake.com> writes:
|> >        It would be nice to have a special `rectangle-mode' which would make
|> >        _all_ the normal kill/copy commands such as C-w and M-w deal in
|> >        `rectangles' (and use a highlighting hack to make an active region
|> >        really look like a rectangle).
|> > 
|> >    I don't think this makes sense as a mode.  
|> > 
|> > It could be a `context specific minor mode', as proposed for table.el,
|> > activated, perhaps, when you give a special `set-rectangle-mark'
|> > command.  
|> 
|> That was what I meant.  It would be a minor-mode that got turned on
|> temporarily when you did `set-rectangle-mark', and presumably turned
|> off when you do a C-w or hit C-g, or whatever (the minor-mode indicator
|> would provide a hint that things were slightly different than normal).

Sorta like transient-mark-mode.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Modes: major, minor, context specific

[Robert J. Chassell]

It turns out that the concept of `modes' provides a useful tool for
thinking about Emacs user interfaces:

    Major mode:  topic related mode,
                 such as whether you are reading email or editing Fortran

    Minor mode:  user-interface related mode, 
                 such as whether you want or do not want auto-fill,
                 provided at a less general level than the difference
                 between VI and Emacs

    Context Specific Minor mode:
                 a user-interface related mode for a particular region
                 that is different in some regular way
                 from the rest of the buffer, 
                 such as an entry for a table, a rectangle, or a
                 mathematical expression

The VI - Emacs difference: among other things, 
  an interface mode difference 
  that is so basic it is not called a difference in `modes':

  * VI presumes the user will write a fair amount in one go (say a
    paragraph or an expression) and then edit

  * Emacs presumes the user will edit every word or two

Re: keymap in yank-excluded-properties

[Richard Stallman]

    > It could be a `context specific minor mode', as proposed for table.el,
    > activated, perhaps, when you give a special `set-rectangle-mark'
    > command.  

    That was what I meant.  It would be a minor-mode that got turned on
    temporarily

Let's not think of every flag in Emacs as a "minor mode".

Re: keymap in yank-excluded-properties

[Kim F. Storm]

Some time ago, I wrote:

    I still think that my proposal for a yank-function text property (set
    on the original table text, and used by yank and yank-rectangle to do
    the yank) would do be a simple, yet powerful approach, as it would use
    automatically copy that property to the kill-ring, so there is nothing
    we need to add to basic functionality to achieve this.


Tue, 03 Sep 2002 09:26:46 -0400: Richard Stallman <rms@gnu.org> wrote:

> How about if the two of you together try implementing the yank-function feature
> and a suitable function to handle yanking of tables?  That way, we will see
> if the feature really can do the job at hand.


Tak Ota <Takaaki.Ota@am.sony.com> responded:

> I'm sorry I forgot to reply to your suggested yanking behavior for
> table.  What you suggested above made perfect sense.  I'll start
> working on how to implement it as `yank-function'.  I expect it is not
> as easy to implement as conceptually described above though.

Tak,

Have you made any progress on this?

I didn't want to make any changes to emacs basics to support the
yank-function property until I had heard from you whether it was
possible to handle table(-fragment) yanking as suggested.

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

Re: keymap in yank-excluded-properties

[Tak Ota]

23 Oct 2002 15:53:17 +0200: storm@cua.dk (Kim F. Storm) wrote:

> Some time ago, I wrote:
> 
>     I still think that my proposal for a yank-function text property (set
>     on the original table text, and used by yank and yank-rectangle to do
>     the yank) would do be a simple, yet powerful approach, as it would use
>     automatically copy that property to the kill-ring, so there is nothing
>     we need to add to basic functionality to achieve this.
> 
> 
> Tue, 03 Sep 2002 09:26:46 -0400: Richard Stallman <rms@gnu.org> wrote:
> 
> > How about if the two of you together try implementing the yank-function feature
> > and a suitable function to handle yanking of tables?  That way, we will see
> > if the feature really can do the job at hand.
> 
> 
> Tak Ota <Takaaki.Ota@am.sony.com> responded:
> 
> > I'm sorry I forgot to reply to your suggested yanking behavior for
> > table.  What you suggested above made perfect sense.  I'll start
> > working on how to implement it as `yank-function'.  I expect it is not
> > as easy to implement as conceptually described above though.
> 
> Tak,
> 
> Have you made any progress on this?
> 
> I didn't want to make any changes to emacs basics to support the
> yank-function property until I had heard from you whether it was
> possible to handle table(-fragment) yanking as suggested.
> 
> -- 
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

Kim,

I know it's been on my TODO list for sometime together with table
documentation.  I am really tied down to my bread-n-butter work.  I'll
get back to you when I'm ready.  Sorry.

-Tak