[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Patches: copy/paste and selection handling.
From: |
Norbert Nemec |
Subject: |
Re: [Texmacs-dev] Patches: copy/paste and selection handling. |
Date: |
Fri, 06 Feb 2009 10:45:09 +0100 |
-------- Original-Nachricht --------
> Datum: Thu, 05 Feb 2009 12:59:00 -0800
> Von: Daniel Bump <address@hidden>
> An: address@hidden
> CC: address@hidden
> Betreff: Re: [Texmacs-dev] Patches: copy/paste and selection handling.
>
> > My question to Emacs-mode users: Should the kill-ring simply be
> > identical with the primary buffer as it is right now or is there a need
> > for a separate mechanism?
>
> In emacs the kill-ring contains not only the most recent
> kill but previous ones also. In TeXmacs, I don't think
> more than the most recent kill is saved. If you want
> to access an earlier kill, you have to undo.
True. The full functionality of a kill-"ring" is not implemented in TeXmacs.
Implementing this cleanly would be major surgery, so we will have to do with
just one kill-buffer (i.e. TeXmacs primary buffer, aka. X11-clipboard) which is
lost when new content is copied or cut.
>
> > a) the [delete] key should delete the text without touching the buffer.
> > (This is what my patch intends to do)
> > b) the [ctrl-k] keys should kill the text, i.e. put it into the buffer
> > (the "cut" operation)
>
> How would you bind [ctrl-w]? I would recommend not changing the
> behavior of either [ctrl-k] or [ctrl-w], both of which cut
> to the buffer.
I fully agree. Both keys are Emacs-style kill-keys, so they should act as
cut-keys in TeXmacs.
> In practice, I seldom use the delete key, so
> it would not bother me if it's behavior changed. But the only
> case where you wanted to delete something without disturbing
> the contents of the kill buffer would be if you kill something
> you want to use later, then do some other operations before
> you do the paste. I don't think this is how most people work.
Maybe not in Emacs. Windows/KDE/Gnome users would most likely work like this.
One expects the clipboard content to be protected until the next explicit
copy/cut command.
One different issue, concerning emacs vs. windows mode:
a) In original Emacs, the mark is remembered until it is set in some other
location (via ctrl-space). In TeXmacs, the mark is forgotten as soon as any
editing command is issued. Does this bother anyone in practice? Do emacs-people
usually expect the mark to be remembered through text editing?
b) In Windows/KDE/Gnome, when you have text selected and then enter/paste new
text, the selected text is replaced. In TeXmacs, the text is unselected, but
the content of the selection remains in place.
To fully follow the standard in Windows mode, selected text should be replaced
when entering/pasting new text. This would clearly annoy Emacs-mode users, so
the behavior should depend on the mode.
Does anyone disagree here?
Greetings,
Norbert
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
- Re: [Texmacs-dev] Patches: copy/paste and selection handling., (continued)
Re: [Texmacs-dev] Patches: copy/paste and selection handling., Norbert Nemec, 2009/02/05
Re: [Texmacs-dev] Patches: copy/paste and selection handling., Daniel Bump, 2009/02/05
Re: [Texmacs-dev] Patches: copy/paste and selection handling., Bas Spitters, 2009/02/05
Re: [Texmacs-dev] Patches: copy/paste and selection handling., Daniel Bump, 2009/02/05
Re: [Texmacs-dev] Patches: copy/paste and selection handling.,
Norbert Nemec <=
Re: [Texmacs-dev] Patches: copy/paste and selection handling., Todd Wilson, 2009/02/06
Re: [Texmacs-dev] Patches: copy/paste and selection handling., Norbert Nemec, 2009/02/07
Re: [Texmacs-dev] Patches: copy/paste and selection handling., Daniel Bump, 2009/02/07
Re: [Texmacs-dev] Patches: copy/paste and selection handling., Norbert Nemec, 2009/02/07
Re: [Texmacs-dev] Patches: copy/paste and selection handling., Lukasz Stafiniak, 2009/02/06
Re: [Texmacs-dev] Patches: copy/paste and selection handling., Joris van der Hoeven, 2009/02/06