Discussion:
Patches: copy/paste and selection handling.
(too old to reply)
Norbert Nemec
2009-01-23 23:07:00 UTC
Permalink
Hi there,

following the bugfix two days ago, I have now finally sat down and tried
to clean out the annoyingly non-standard behavior of TeXmacs in terms of
selection handling and cut-and-paste. Resulting are the three attached
patches that handle mostly independent issues. Each patch has an
explanation included in the header.

To begin with: I am used to the Windows/KDE/Gnome standard behavior
which is very different from that of Emacs. I believe the patches in
their current form will work in Emacs mode as well, but I would ask some
of the true Emacs users to try these patches.

The first patch should be pretty much invisible if you don't use
X11-style mouse-select-and-middle-button-paste. If you do use this, you
should find the new behavior identical to that in other common editors.
If you have xclipboard, klipper or any similar clipboard manager
running, please check how it might interfere with the inter-program
cut-and-paste.

The second patch makes selections generally non-persistent (i.e. text is
unselected as soon as cursor is moved). This is the standard set by
Windows and adopted by freedesktop.org (i.e. KDE, Gnome, etc.). If
anybody has a good reason for supporting persistent selections, please
bring it forward.

The third patch does away with the annoying habit of TeXmacs overwriting
the clipboard when you press <delete> on a selection. I know that some
Emacs users prefer to have their <delete> key bound to perform a <cut>
operation. If anybody out there thinks this kind of behavior should be
configurable (or even default in Emacs mode), could you please contact
me, so we could try to figure out at which place I should put a switch.

Please, test these patches thoroughly and give your feedback. This is
something that will affect every user every day, so it should be polished.

Greeting,
Norbert
Daniel Bump
2009-01-31 00:29:00 UTC
Permalink
TeXmacs does not compile for me on Ubuntu 8.10. Hardware
is a new Macbook Pro. On the same hardware it builds OK with
Ubunto 8.0.4. Ubuntu 8.10 ships with GCC 4.3.2.

I get this:

g++ -ISystem -ISystem/Boot -ISystem/Classes -ISystem/Files -ISystem/Link
-ISystem/Misc -ISystem/Language -IKernel/Abstractions -IKernel/Containers
-IKernel/Types -IData/Convert -IData/Drd -IData/Observers -IData/String
-IData/Tmfs -IData/Tree -IGuile -IGraphics/Bitmap_fonts -IGraphics/Fonts
-IGraphics/Gui -IGraphics/Mathematics -IGraphics/Renderer -IPlugins -ITypeset
-ITypeset/Bridge -ITypeset/Concat -ITypeset/Page -IEdit -IPlugins -ITexmacs
-IEdit/Editor -IEdit/Interface -IEdit/Modify -I/usr/include/freetype2 -pthread
-Wall -Wno-return-type -O3 -fexpensive-optimizations -fno-rtti -fno-exceptions
-c ./Edit/Editor/edit_typeset.cpp -o Objects/edit_typeset.o
Kernel/Containers/hashmap_extra.cpp: In constructor ‘hashmap<T, U>::hashmap(U, tree) [with T = string, U = tree]’:
./Edit/Editor/edit_typeset.cpp:358: instantiated from here
Kernel/Containers/hashmap_extra.cpp:126: error: no matching function for call to ‘copy(tree&)’
Kernel/Abstractions/basic.hpp:99: note: candidates are: int copy(int)
Kernel/Types/string.hpp:50: note: string copy(string)
make: *** [Objects/edit_typeset.o] Error 1

This with both TeXmacs 1.0.7.1 and 1.0.6.15.

I get the same error with Guile 1.8.5 or Guile 1.6.

Is this a known problem?

Daniel Bump
Joris van der Hoeven
2009-02-06 23:51:09 UTC
Permalink
Dear Daniel,

No, the problem is not known; I will go after it when back home;
it is probably a new incompatability in your new version of g++.
They are introducing this kind of things quite often currently.

Best wishes, Joris
Post by Daniel Bump
TeXmacs does not compile for me on Ubuntu 8.10. Hardware
is a new Macbook Pro. On the same hardware it builds OK with
Ubunto 8.0.4. Ubuntu 8.10 ships with GCC 4.3.2.
g++ -ISystem -ISystem/Boot -ISystem/Classes -ISystem/Files -ISystem/Link
-ISystem/Misc -ISystem/Language -IKernel/Abstractions -IKernel/Containers
-IKernel/Types -IData/Convert -IData/Drd -IData/Observers -IData/String
-IData/Tmfs -IData/Tree -IGuile -IGraphics/Bitmap_fonts -IGraphics/Fonts
-IGraphics/Gui -IGraphics/Mathematics -IGraphics/Renderer -IPlugins -ITypeset
-ITypeset/Bridge -ITypeset/Concat -ITypeset/Page -IEdit -IPlugins -ITexmacs
-IEdit/Editor -IEdit/Interface -IEdit/Modify -I/usr/include/freetype2 -pthread
-Wall -Wno-return-type -O3 -fexpensive-optimizations -fno-rtti -fno-exceptions
-c ./Edit/Editor/edit_typeset.cpp -o Objects/edit_typeset.o
./Edit/Editor/edit_typeset.cpp:358: instantiated from here
Kernel/Containers/hashmap_extra.cpp:126: error: no matching function for call to ‘copy(tree&)’
Kernel/Abstractions/basic.hpp:99: note: candidates are: int copy(int)
Kernel/Types/string.hpp:50: note: string copy(string)
make: *** [Objects/edit_typeset.o] Error 1
This with both TeXmacs 1.0.7.1 and 1.0.6.15.
I get the same error with Guile 1.8.5 or Guile 1.6.
Is this a known problem?
Daniel Bump
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Norbert Nemec
2009-02-05 15:44:56 UTC
Permalink
Just for curiosity: Has anybody out there looked at these patches at
all? I'm a bit surprised about the silence over this issue that I
believe to be rather central to the every day user experience.

Greetings,
Norbert
Post by Norbert Nemec
Hi there,
following the bugfix two days ago, I have now finally sat down and
tried to clean out the annoyingly non-standard behavior of TeXmacs in
terms of selection handling and cut-and-paste. Resulting are the three
attached patches that handle mostly independent issues. Each patch has
an explanation included in the header.
To begin with: I am used to the Windows/KDE/Gnome standard behavior
which is very different from that of Emacs. I believe the patches in
their current form will work in Emacs mode as well, but I would ask
some of the true Emacs users to try these patches.
The first patch should be pretty much invisible if you don't use
X11-style mouse-select-and-middle-button-paste. If you do use this,
you should find the new behavior identical to that in other common
editors. If you have xclipboard, klipper or any similar clipboard
manager running, please check how it might interfere with the
inter-program cut-and-paste.
The second patch makes selections generally non-persistent (i.e. text
is unselected as soon as cursor is moved). This is the standard set by
Windows and adopted by freedesktop.org (i.e. KDE, Gnome, etc.). If
anybody has a good reason for supporting persistent selections, please
bring it forward.
The third patch does away with the annoying habit of TeXmacs
overwriting the clipboard when you press <delete> on a selection. I
know that some Emacs users prefer to have their <delete> key bound to
perform a <cut> operation. If anybody out there thinks this kind of
behavior should be configurable (or even default in Emacs mode), could
you please contact me, so we could try to figure out at which place I
should put a switch.
Please, test these patches thoroughly and give your feedback. This is
something that will affect every user every day, so it should be polished.
Greeting,
Norbert
------------------------------------------------------------------------
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Bas Spitters
2009-02-05 16:01:44 UTC
Permalink
I have been using them happily ever since you posted them! Thanks.


While I am writing, maybe it is good to note that ^k (kill line) behaves like
a cut, while I would expect delete instead.

Another issue: when I paste a math formula in a math invironment, I obtain
nested math environments.




An unrelated matter: F3 is sometimes bound to "search-again", sometimes to
"save". Is this intended?

Best,

Bas
Post by Norbert Nemec
Just for curiosity: Has anybody out there looked at these patches at
all? I'm a bit surprised about the silence over this issue that I
believe to be rather central to the every day user experience.
Greetings,
Norbert
Marc Lalaude-Labayle
2009-02-05 16:54:23 UTC
Permalink
Hi,

a maybe stupid question. How do i apply these patches to see the
difference ?

Marc
Post by Bas Spitters
I have been using them happily ever since you posted them! Thanks.
While I am writing, maybe it is good to note that ^k (kill line) behaves like
a cut, while I would expect delete instead.
Another issue: when I paste a math formula in a math invironment, I obtain
nested math environments.
An unrelated matter: F3 is sometimes bound to "search-again", sometimes to
"save". Is this intended?
Best,
Bas
Post by Norbert Nemec
Just for curiosity: Has anybody out there looked at these patches at
all? I'm a bit surprised about the silence over this issue that I
believe to be rather central to the every day user experience.
Greetings,
Norbert
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Bas Spitters
2009-02-05 17:06:19 UTC
Permalink
Post by Marc Lalaude-Labayle
Hi,
a maybe stupid question. How do i apply these patches to see the
difference ?
In unix:
Put the files in the same place where you have the directory src where you
have the sources of texmacs then do:
patch -p1 <filename

The -p option tells patch how many directories it has to strip from the path.
So, if you put the patch files *in* the directory src you need -p2.

Bas
Marc Lalaude-Labayle
2009-02-05 17:14:50 UTC
Permalink
I mainly use binary (deb) versions. I have a compiled texmacs version,
but i don't want to use it that much : too lazy !

Is it possible to enable the patches with theses binary versions ?

Marc
Post by Bas Spitters
Post by Marc Lalaude-Labayle
Hi,
a maybe stupid question. How do i apply these patches to see the
difference ?
Put the files in the same place where you have the directory src where you
patch -p1 <filename
The -p option tells patch how many directories it has to strip from the path.
So, if you put the patch files *in* the directory src you need -p2.
Bas
Norbert Nemec
2009-02-05 17:37:51 UTC
Permalink
The patches affect the C sources, so you will need to recompile the code
yourself.

Greetings,
Norbert
Post by Marc Lalaude-Labayle
I mainly use binary (deb) versions. I have a compiled texmacs version,
but i don't want to use it that much : too lazy !
Is it possible to enable the patches with theses binary versions ?
Marc
Post by Bas Spitters
Post by Marc Lalaude-Labayle
Hi,
a maybe stupid question. How do i apply these patches to see the
difference ?
Put the files in the same place where you have the directory src where you
patch -p1 <filename
The -p option tells patch how many directories it has to strip from the path.
So, if you put the patch files *in* the directory src you need -p2.
Bas
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Norbert Nemec
2009-02-05 17:28:51 UTC
Permalink
Post by Bas Spitters
I have been using them happily ever since you posted them! Thanks.
While I am writing, maybe it is good to note that ^k (kill line) behaves like
a cut, while I would expect delete instead.
This is exactly the point where I need the input of emacs-mode users. I
can only try to understand the written documentation:

http://www.gnu.org/software/emacs/manual/html_node/emacs/Killing.html

According to this, there is a clear distinction between "killing" and
"deleting". A "kill" places the removed text into the "kill-ring" from
where it can be "yanked". In my understanding this actually is a "cut"
operation. A "delete" on the other hand eliminates the marked text
without a trace.

Even the interaction with other applications is described in detail:


http://www.gnu.org/software/emacs/manual/html_node/emacs/Cut_002fPaste-Other-App.html

To me, this means that the last entry of the "kill-ring" should actually
be synchronised with the X11-clipboard and the TeXmacs primary buffer.

However, the text in

http://www.gnu.org/software/emacs/manual/html_node/emacs/Clipboard.html

seems to contradict this.

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 any case, it seems clear to me that in emacs mode:
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)

This is emacs behavior as I understand it.
Post by Bas Spitters
Another issue: when I paste a math formula in a math invironment, I obtain
nested math environments.
When you copy a part of a formula, TeXmacs views this as math content:
math("a+b")
Pasting it into another formula works fine without nesting environment
<math|c=a+b>

When you copy a complete formula, TeXmacs views it as text content
containing a math environment:
text("<math|a+b>")
Pasting this into a formula results in "encapsulating" the text content:
<math|c=<with|mode|text|<math|a+b>>>

To me this seems logical, but one might indeed add a bit of intelligence
to unpack the nested code when possible.

A helpful solution for the time being is the [ctrl-backspace] sequence
that deletes the innermost enclosing tag. Hitting this twice removes the
double encapsulation.
Post by Bas Spitters
An unrelated matter: F3 is sometimes bound to "search-again", sometimes to
"save". Is this intended?
This should clearly be fixed. In Windows mode, F3 should be search again
and ctrl-S should be save. I fear that this is just one out of many key
sequences that should be sorted out for standard conformance...

Greetings,
Norbert
Bas Spitters
2009-02-05 20:41:02 UTC
Permalink
Post by Norbert Nemec
Post by Bas Spitters
An unrelated matter: F3 is sometimes bound to "search-again", sometimes
to "save". Is this intended?
This should clearly be fixed. In Windows mode, F3 should be search again
and ctrl-S should be save. I fear that this is just one out of many key
sequences that should be sorted out for standard conformance...
Are these key-bindings localized in one file or scattered over the sources?
In the first case, one could hope that this is not too difficult to fix.

Oh, and a key-binding for Redo is missing (ctrl+shift+Z).

Best,

Bas
Norbert Nemec
2009-02-06 09:54:34 UTC
Permalink
Post by Bas Spitters
Are these key-bindings localized in one file or scattered over the sources?
In the first case, one could hope that this is not too difficult to fix.
Oh, and a key-binding for Redo is missing (ctrl+shift+Z).
The bindings are collected in
TeXmacs/progs/texmacs/keyboard/
split into a few files.

I believe the tricky part is less doing the changes than deciding what the key-bindings should actually be in the two different modes...
--
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
Bas Spitters
2009-02-06 21:17:40 UTC
Permalink
Post by Norbert Nemec
Post by Bas Spitters
Are these key-bindings localized in one file or scattered over the sources?
In the first case, one could hope that this is not too difficult to fix.
Oh, and a key-binding for Redo is missing (ctrl+shift+Z).
The bindings are collected in
TeXmacs/progs/texmacs/keyboard/
split into a few files.
OK. It is as easy is adding:
(kbd-map ("C-Z" (redo)))
to
my-init-texmacs.scm

Bas
Daniel Bump
2009-02-05 20:59:00 UTC
Permalink
Post by Norbert Nemec
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.
Post by Norbert Nemec
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. 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.

Daniel Bump
Bas Spitters
2009-02-05 21:35:21 UTC
Permalink
Post by Daniel Bump
How would you bind [ctrl-w]?
Currently, it closes the window! (in KDE mode that is...)

Bas
Daniel Bump
2009-02-05 22:25:55 UTC
Permalink
Post by Bas Spitters
Post by Daniel Bump
How would you bind [ctrl-w]?
Currently, it closes the window! (in KDE mode that is...)
I'm running TeXmacs in Emacs mode, and C-w cuts text to
the kill buffer. (Just as in emacs.) In emacs A-w saves
text to the buffer without deleting it, and I think it
used to do that in TeXmacs too. Currently (e.g. in
TeXmacs 1.0.6.14) it seems I have to Esc-w to get that
effect.

Dan
Norbert Nemec
2009-02-06 09:45:09 UTC
Permalink
-------- Original-Nachricht --------
Datum: Thu, 05 Feb 2009 12:59:00 -0800
Betreff: Re: [Texmacs-dev] Patches: copy/paste and selection handling.
Post by Norbert Nemec
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.
Post by Norbert Nemec
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
Todd Wilson
2009-02-06 16:18:29 UTC
Permalink
Post by Norbert Nemec
-------- Original-Nachricht --------
Datum: Thu, 05 Feb 2009 12:59:00 -0800 Von: Daniel Bump
and selection handling.
Post by Norbert Nemec
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.
That's too bad: I'd long hoped that the full kill-ring functionality
would be a part of TeXmacs.
Post by Norbert Nemec
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?
As a user of Emacs for over two decades, and someone who was initially
drawn to TeXmacs because of its similarity to Emacs, my preference would
be to have the emacs mode be as close to Emacs as possible, as least
from the point of view of the interface (the fact that TeXmacs functions
are named differently from their Emacs counterparts doesn't bother me at
all).
Post by Norbert Nemec
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.
It wouldn't annoy some Emacs users, for example the ones that use
delete-selection-mode (or pending-delete-mode in XEmacs).

Todd Wilson
Norbert Nemec
2009-02-07 08:48:21 UTC
Permalink
Post by Todd Wilson
Post by Norbert Nemec
-------- Original-Nachricht --------
Datum: Thu, 05 Feb 2009 12:59:00 -0800 Von: Daniel Bump
and selection handling.
Post by Norbert Nemec
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.
That's too bad: I'd long hoped that the full kill-ring functionality
would be a part of TeXmacs.
If someone wants to look into this, it should be possible. It is just
that my resources are extremely limited and emacs-mode is not my
personal top-priority. I want to make sure that my changes do not
degrade emacs-mode behavior and am happy to change little details to
improve it. Otherwise, my focus is on Windows mode which is what I use
personally.
Post by Todd Wilson
Post by Norbert Nemec
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?
As a user of Emacs for over two decades, and someone who was initially
drawn to TeXmacs because of its similarity to Emacs, my preference would
be to have the emacs mode be as close to Emacs as possible, as least
from the point of view of the interface (the fact that TeXmacs functions
are named differently from their Emacs counterparts doesn't bother me at
all).
This is exactly the intention.
Post by Todd Wilson
Post by Norbert Nemec
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.
It wouldn't annoy some Emacs users, for example the ones that use
delete-selection-mode (or pending-delete-mode in XEmacs).
Following this line would mean that TeXmacs would need to be as
configurable as Emacs to satisfy every user. I don't think we can
achieve this. What would you suggest as a general policy? Aim for exact
emacs *default* behaviour? Or might this actually annoy the majority of
emacs-users, because nearly every emacs-user has their personalized
settings and is annoyed when TeXmacs does not offer the same
personalization option?

Greetings,
Norbert
Daniel Bump
2009-02-07 17:11:16 UTC
Permalink
On this thread, the single thing that seems to me to
be most important to change is that highlighted
text is persistent. You can select (red highlight)
some text and scroll away until the marked
text is not even on the screen. Then if you hit
backspace, it is deleted off-stage. So it is
possible to accidentally delete something.
Selection can also happen unintentially just
moving the mouse around, especially with a
trackpad that sometimes can generate spurious
mouseclicks. This would be less annoying if
it were easier to unselect, but in fact my
usual way of removing an undesirable selection
is to hit the space bar (then delete the space).
And since selected text can be accidentally
deleted, it is important to do this.
Post by Norbert Nemec
The second patch makes selections generally non-persistent (i.e. text is
unselected as soon as cursor is moved). This is the standard set by
Windows and adopted by freedesktop.org (i.e. KDE, Gnome, etc.). If
anybody has a good reason for supporting persistent selections, please
bring it forward.
I haven't tried the patches but if I understand
correctly this would address the above-mentioned
problem, which I think is serious.

Daniel Bump
Norbert Nemec
2009-02-07 22:36:46 UTC
Permalink
In fact, this was exactly the point that started me off in changing the
selection handling as well. The core idea behind my changes is that the
selection should *always* be at the position of the cursor. In the
patched version, there is no way to move the cursor without either
unselecting or changing the size of the selection. Also, when you select
using the mouse, the cursor is always placed at the last position where
the mouse is released.

B.t.w.: It still is possible to scroll away using the mouse so that both
cursor and selection are off screen. This is standard behavior and is
fairly safe as you typically would not press delete without seeing the
cursor anyway.
Post by Daniel Bump
On this thread, the single thing that seems to me to
be most important to change is that highlighted
text is persistent. You can select (red highlight)
some text and scroll away until the marked
text is not even on the screen. Then if you hit
backspace, it is deleted off-stage. So it is
possible to accidentally delete something.
Selection can also happen unintentially just
moving the mouse around, especially with a
trackpad that sometimes can generate spurious
mouseclicks. This would be less annoying if
it were easier to unselect, but in fact my
usual way of removing an undesirable selection
is to hit the space bar (then delete the space).
And since selected text can be accidentally
deleted, it is important to do this.
Post by Norbert Nemec
The second patch makes selections generally non-persistent (i.e. text is
unselected as soon as cursor is moved). This is the standard set by
Windows and adopted by freedesktop.org (i.e. KDE, Gnome, etc.). If
anybody has a good reason for supporting persistent selections, please
bring it forward.
I haven't tried the patches but if I understand
correctly this would address the above-mentioned
problem, which I think is serious.
Daniel Bump
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Lukasz Stafiniak
2009-02-06 12:03:13 UTC
Permalink
Post by Daniel Bump
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.
I do this, e.g. I copy/cut a thing, paste it in one place, "massage"
it somewhat, and repeat this in other places. For this, I've
implemented in my Emacs a second kill-ring which collects snippets
only from two specific copy cut key-bindings (I still use the first
kill-ring for "local editing", e.g. moving a word).
Bas Spitters
2009-03-03 13:52:15 UTC
Permalink
Any news on applying these patches? I did not find them in svn yet.

BTW: Is there any documentation on extending the latex export, there are some
bugs I would like to fix, but it seems that I am missing something obvious.

Bas
Post by Norbert Nemec
Just for curiosity: Has anybody out there looked at these patches at
all? I'm a bit surprised about the silence over this issue that I
believe to be rather central to the every day user experience.
Greetings,
Norbert
Post by Norbert Nemec
Hi there,
following the bugfix two days ago, I have now finally sat down and
tried to clean out the annoyingly non-standard behavior of TeXmacs in
terms of selection handling and cut-and-paste. Resulting are the three
attached patches that handle mostly independent issues. Each patch has
an explanation included in the header.
To begin with: I am used to the Windows/KDE/Gnome standard behavior
which is very different from that of Emacs. I believe the patches in
their current form will work in Emacs mode as well, but I would ask
some of the true Emacs users to try these patches.
The first patch should be pretty much invisible if you don't use
X11-style mouse-select-and-middle-button-paste. If you do use this,
you should find the new behavior identical to that in other common
editors. If you have xclipboard, klipper or any similar clipboard
manager running, please check how it might interfere with the
inter-program cut-and-paste.
The second patch makes selections generally non-persistent (i.e. text
is unselected as soon as cursor is moved). This is the standard set by
Windows and adopted by freedesktop.org (i.e. KDE, Gnome, etc.). If
anybody has a good reason for supporting persistent selections, please
bring it forward.
The third patch does away with the annoying habit of TeXmacs
overwriting the clipboard when you press <delete> on a selection. I
know that some Emacs users prefer to have their <delete> key bound to
perform a <cut> operation. If anybody out there thinks this kind of
behavior should be configurable (or even default in Emacs mode), could
you please contact me, so we could try to figure out at which place I
should put a switch.
Please, test these patches thoroughly and give your feedback. This is
something that will affect every user every day, so it should be polished.
Greeting,
Norbert
------------------------------------------------------------------------
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Joris van der Hoeven
2009-03-03 20:10:08 UTC
Permalink
Hi Bas,
Post by Bas Spitters
Any news on applying these patches? I did not find them in svn yet.
I am just back from abroad; should be able to find some time next week...

Best wishes, Joris
Post by Bas Spitters
BTW: Is there any documentation on extending the latex export, there are some
bugs I would like to fix, but it seems that I am missing something obvious.
Bas
Post by Norbert Nemec
Just for curiosity: Has anybody out there looked at these patches at
all? I'm a bit surprised about the silence over this issue that I
believe to be rather central to the every day user experience.
Greetings,
Norbert
Post by Norbert Nemec
Hi there,
following the bugfix two days ago, I have now finally sat down and
tried to clean out the annoyingly non-standard behavior of TeXmacs in
terms of selection handling and cut-and-paste. Resulting are the three
attached patches that handle mostly independent issues. Each patch has
an explanation included in the header.
To begin with: I am used to the Windows/KDE/Gnome standard behavior
which is very different from that of Emacs. I believe the patches in
their current form will work in Emacs mode as well, but I would ask
some of the true Emacs users to try these patches.
The first patch should be pretty much invisible if you don't use
X11-style mouse-select-and-middle-button-paste. If you do use this,
you should find the new behavior identical to that in other common
editors. If you have xclipboard, klipper or any similar clipboard
manager running, please check how it might interfere with the
inter-program cut-and-paste.
The second patch makes selections generally non-persistent (i.e. text
is unselected as soon as cursor is moved). This is the standard set by
Windows and adopted by freedesktop.org (i.e. KDE, Gnome, etc.). If
anybody has a good reason for supporting persistent selections, please
bring it forward.
The third patch does away with the annoying habit of TeXmacs
overwriting the clipboard when you press <delete> on a selection. I
know that some Emacs users prefer to have their <delete> key bound to
perform a <cut> operation. If anybody out there thinks this kind of
behavior should be configurable (or even default in Emacs mode), could
you please contact me, so we could try to figure out at which place I
should put a switch.
Please, test these patches thoroughly and give your feedback. This is
something that will affect every user every day, so it should be polished.
Greeting,
Norbert
------------------------------------------------------------------------
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Joris van der Hoeven
2009-02-06 23:48:48 UTC
Permalink
Hi Norbert,

I will examine your patches as soon as possible;
I am currently abroad for a few weeks and
deal with all TeXmacs-related stuff when back (march).

Best wishes, Joris
Post by Norbert Nemec
Hi there,
following the bugfix two days ago, I have now finally sat down and tried
to clean out the annoyingly non-standard behavior of TeXmacs in terms of
selection handling and cut-and-paste. Resulting are the three attached
patches that handle mostly independent issues. Each patch has an
explanation included in the header.
To begin with: I am used to the Windows/KDE/Gnome standard behavior
which is very different from that of Emacs. I believe the patches in
their current form will work in Emacs mode as well, but I would ask some
of the true Emacs users to try these patches.
The first patch should be pretty much invisible if you don't use
X11-style mouse-select-and-middle-button-paste. If you do use this, you
should find the new behavior identical to that in other common editors.
If you have xclipboard, klipper or any similar clipboard manager
running, please check how it might interfere with the inter-program
cut-and-paste.
The second patch makes selections generally non-persistent (i.e. text is
unselected as soon as cursor is moved). This is the standard set by
Windows and adopted by freedesktop.org (i.e. KDE, Gnome, etc.). If
anybody has a good reason for supporting persistent selections, please
bring it forward.
The third patch does away with the annoying habit of TeXmacs overwriting
the clipboard when you press <delete> on a selection. I know that some
Emacs users prefer to have their <delete> key bound to perform a <cut>
operation. If anybody out there thinks this kind of behavior should be
configurable (or even default in Emacs mode), could you please contact
me, so we could try to figure out at which place I should put a switch.
Please, test these patches thoroughly and give your feedback. This is
something that will affect every user every day, so it should be polished.
Greeting,
Norbert
Make copy-and-paste compliant with freedesktop standards
From: <>
XA_CLIPBOARD: Windows like via Ctrl-C and Ctrl-V (XA_CLIPBOARD)
XA_PRIMARY: mouse-shortcut by marking with mouse and pressing middle button in some other place
Formerly, both methods were mapped to TeXmacs "primary" buffer, causing some strange behavior.
Now, the mouse selection is copied to a new "mouse" buffer and middle-click pastes from
this special buffer. The regular "primary" buffer is unaffected by mouse selection. Of
course the mouse-selection can also be copied to the "primary" buffer as well.
The naming is a bit confusing to avoid changing too much code
* The "primary" buffer is mapped to XA_CLIPBOARD
* The "mouse" buffer is mapped to XA_PRIMARY
The handling of the "primary" is encapsulated by QClipboard. The "mouse"
cut-and-paste should work TeXmacs internally. No idea how to get it to work
properly with other applications.
All other GUIs should work as before with the "primary" selection and should work
following the freedesktop standard within TeXmacs. Whether a inter-application
mechanism exists and can be used for mouse copy-paste depends on the system.
============
* added function 'bool contains(list<T>,T)' to list.hpp
* created symbols XA_CLIPBOARD and XA_TARGETS in x_gui initialized at startup to standard XAtom values.
* changed edit_interface_rep::mouse_select to select into "mouse" instead of "primary" buffer
* changed edit_interface_rep::mouse_paste to
a) go_to position of mouse click
b) paste from "mouse" instead of "primary" buffer
* removed x_gui_rep::selection variable - do conversion from selection_s on the fly in
x_loop instead
* changed x_gui_rep::set_selection to handle "mouse" (pointing to XA_PRIMARY) and "primary" (pointing to XA_CLIPBOARD)
* completely restructured x_gui_rep::get_selection to achieve the same here
* handle SelectionRequestEvent and SelectionClearEvent for either XA_PRIMARY or XA_CLIPBOARD
---
src/src/Edit/Interface/edit_mouse.cpp | 10 +++--
src/src/Edit/Replace/edit_select.cpp | 2 +
src/src/Kernel/Containers/list.cpp | 5 +++
src/src/Kernel/Containers/list.hpp | 1 +
src/src/Plugins/X11/x_drawable.hpp | 2 +
src/src/Plugins/X11/x_gui.cpp | 62 ++++++++++++++++++++-------------
src/src/Plugins/X11/x_gui.hpp | 4 ++
src/src/Plugins/X11/x_init.cpp | 9 +++--
src/src/Plugins/X11/x_loop.cpp | 32 +++++++++++------
src/src/Plugins/X11/x_window.hpp | 2 +
10 files changed, 80 insertions(+), 49 deletions(-)
diff --git a/src/src/Edit/Interface/edit_mouse.cpp b/src/src/Edit/Interface/edit_mouse.cpp
index bf6eebc..3af1018 100644
--- a/src/src/Edit/Interface/edit_mouse.cpp
+++ b/src/src/Edit/Interface/edit_mouse.cpp
@@ -56,7 +56,7 @@ edit_interface_rep::mouse_any (string type, SI x, SI y, int mods, time_t t) {
dragging= true;
}
else if (dragging && (type == "move"))
- type2= "dragging";
+ type2= "dragging";
if (dragging && (type == "release-left"))
type2= "end-drag";
@@ -66,7 +66,7 @@ edit_interface_rep::mouse_any (string type, SI x, SI y, int mods, time_t t) {
right_dragging= true;
}
else if (right_dragging && (type == "move"))
- type2= "right-dragging";
+ type2= "right-dragging";
if (right_dragging && (type == "release-right"))
type2= "end-right-drag";
@@ -180,14 +180,14 @@ edit_interface_rep::mouse_select (SI x, SI y, int mods) {
eval ("(graphics-reset-context 'exit)");
}
if (selection_active_any ())
- selection_set ("primary", selection_get (), true);
+ selection_set ("mouse", selection_get (), true);
}
void
edit_interface_rep::mouse_paste (SI x, SI y) { (void) x; (void) y;
if (eb->action ("paste", x, y, 0) != "") return;
- selection_copy ();
- selection_paste ();
+ go_to (x, y);
+ selection_paste ("mouse");
}
void
diff --git a/src/src/Edit/Replace/edit_select.cpp b/src/src/Edit/Replace/edit_select.cpp
index 7eb32ee..9b0fd6f 100644
--- a/src/src/Edit/Replace/edit_select.cpp
+++ b/src/src/Edit/Replace/edit_select.cpp
@@ -557,7 +557,7 @@ edit_select_rep::selection_set (string key, tree t, bool persistant) {
nicely copying graphics into text, text into graphics, etc.
*/
string s;
- if (key == "primary") {
+ if (key == "primary" || key == "mouse") {
if (selection_export == "verbatim") t= exec_texmacs (t, tp);
if (selection_export == "html") t= exec_html (t, tp);
if (selection_export == "latex") t= exec_latex (t, tp);
diff --git a/src/src/Kernel/Containers/list.cpp b/src/src/Kernel/Containers/list.cpp
index 4efd8c4..faa1bcf 100644
--- a/src/src/Kernel/Containers/list.cpp
+++ b/src/src/Kernel/Containers/list.cpp
@@ -194,4 +194,9 @@ remove (list<T> l, T what) {
else return list<T> (l->item, remove (l->next, what));
}
+template<class T> bool
+contains (list<T> l, T what) {
+ return (!is_nil(l) && (l->item == what || contains(l->next, what)));
+}
+
#endif // defined LIST_CC
diff --git a/src/src/Kernel/Containers/list.hpp b/src/src/Kernel/Containers/list.hpp
index 2a82d01..1df1dff 100644
--- a/src/src/Kernel/Containers/list.hpp
+++ b/src/src/Kernel/Containers/list.hpp
@@ -70,6 +70,7 @@ TMPL T& access_last (list<T>& l);
TMPL list<T>& suppress_last (list<T>& l);
TMPL list<T> reverse (list<T> l);
TMPL list<T> remove (list<T> l, T what);
+TMPL bool contains (list<T> l, T what);
TMPL ostream& operator << (ostream& out, list<T> l);
TMPL list<T>& operator << (list<T>& l, T item);
diff --git a/src/src/Plugins/X11/x_drawable.hpp b/src/src/Plugins/X11/x_drawable.hpp
index a877a6f..088a3b5 100644
--- a/src/src/Plugins/X11/x_drawable.hpp
+++ b/src/src/Plugins/X11/x_drawable.hpp
friend class x_gui_rep;
friend class x_window_rep;
- friend Bool my_predicate (Display* dpy, XEvent* ev, XPointer arg);
+ friend Bool my_selnotify_predicate (Display* dpy, XEvent* ev, XPointer arg);
};
#endif // defined X_DRAWABLE_H
diff --git a/src/src/Plugins/X11/x_gui.cpp b/src/src/Plugins/X11/x_gui.cpp
index e99254f..13ceb7a 100644
--- a/src/src/Plugins/X11/x_gui.cpp
+++ b/src/src/Plugins/X11/x_gui.cpp
@@ -188,7 +188,7 @@ x_gui_rep::has_mouse_grab (widget w) {
******************************************************************************/
Bool
-my_predicate (Display* dpy, XEvent* ev, XPointer arg) { (void) dpy;
+my_selnotify_predicate (Display* dpy, XEvent* ev, XPointer arg) { (void) dpy;
x_window win= (x_window) arg;
return (win->win==ev->xany.window) && (ev->type==SelectionNotify);
}
@@ -212,29 +212,41 @@ bool
x_gui_rep::get_selection (string key, tree& t, string& s) {
t= "none";
s= "";
+ bool res=false;
+
if (selection_t->contains (key)) {
t= copy (selection_t [key]);
s= copy (selection_s [key]);
- return true;
+ res=true;
}
- if (key != "primary") return false;
- if (XGetSelectionOwner (dpy, XA_PRIMARY) == None) return false;
- if (is_nil (windows_l)) return false;
+ Atom xsel;
+ if(key == "primary")
+ xsel = XA_CLIPBOARD;
+ else if (key == "mouse")
+ xsel = XA_PRIMARY;
+ else
+ return res;
+
+ Window selown = XGetSelectionOwner(dpy, xsel);
+ if (selown == None
+ || is_nil (windows_l)
+ || contains(windows_l,selown)) return res;
+
Window win= windows_l->item;
x_window x_win= (x_window) Window_to_window[win];
- Atom data= XInternAtom (dpy, "MY_STRING_SELECTION", false);
- XConvertSelection (dpy, XA_PRIMARY, XA_STRING, data, win, CurrentTime);
+ Atom prop= XInternAtom (dpy, "MY_STRING_SELECTION", false);
+ XConvertSelection (dpy, xsel, XA_STRING, prop, win, CurrentTime);
int i;
XEvent ev;
for (i=0; i<1000000; i++)
- if (XCheckIfEvent (dpy, &ev, my_predicate, (XPointer) x_win))
+ if (XCheckIfEvent (dpy, &ev, my_selnotify_predicate, (XPointer) x_win))
break;
- if (i==1000000) return false;
+ if (i==1000000) return res;
XSelectionEvent& sel= ev.xselection;
- if (sel.property!=None) {
+ if (sel.property==prop) {
long offset=0;
Atom type;
int fm;
@@ -249,23 +261,27 @@ x_gui_rep::get_selection (string key, tree& t, string& s) {
offset += (n >> 2);
XFree (ret);
} while (remains>0);
- }
- t= tuple ("extern", s);
- return true;
+ t= tuple ("extern", s);
+ return true;
+ } else
+ return res;
}
bool
x_gui_rep::set_selection (string key, tree t, string s) {
selection_t (key)= copy (t);
selection_s (key)= copy (s);
- if (key == "primary") {
- if (is_nil (windows_l)) return false;
- Window win= windows_l->item;
- if (selection!=NULL) tm_delete_array (selection);
- XSetSelectionOwner (dpy, XA_PRIMARY, win, CurrentTime);
- if (XGetSelectionOwner(dpy, XA_PRIMARY)==None) return false;
- selection= as_charp (s);
- }
+ Atom xsel;
+ if(key == "primary") {
+ xsel = XA_CLIPBOARD;
+ } else if (key == "mouse") {
+ xsel = XA_PRIMARY;
+ } else
+ return true;
+ if (is_nil (windows_l)) return false;
+ Window win= windows_l->item;
+ XSetSelectionOwner (dpy, xsel, win, CurrentTime);
+ if (XGetSelectionOwner(dpy, xsel)==None) return false;
return true;
}
@@ -273,10 +289,6 @@ void
x_gui_rep::clear_selection (string key) {
selection_t->reset (key);
selection_s->reset (key);
- if ((key == "primary") && (selection != NULL)) {
- tm_delete_array (selection);
- selection= NULL;
- }
}
bool
diff --git a/src/src/Plugins/X11/x_gui.hpp b/src/src/Plugins/X11/x_gui.hpp
index c1abfd6..24840fa 100644
--- a/src/src/Plugins/X11/x_gui.hpp
+++ b/src/src/Plugins/X11/x_gui.hpp
hashmap<int,string> upper_key;
list<Window> windows_l;
- char* selection;
hashmap<string,tree> selection_t;
hashmap<string,string> selection_s;
+ Atom XA_CLIPBOARD;
+ Atom XA_TARGETS;
+
x_gui_rep (int argc, char** argv);
~x_gui_rep ();
diff --git a/src/src/Plugins/X11/x_init.cpp b/src/src/Plugins/X11/x_init.cpp
index adae260..0294337 100644
--- a/src/src/Plugins/X11/x_init.cpp
+++ b/src/src/Plugins/X11/x_init.cpp
@@ -443,9 +443,9 @@ x_gui_rep::initialize_keyboard_pointer () {
Map (XK_Cyrillic_E, "\xdd");
Map (XK_Cyrillic_YU, "\xde");
Map (XK_Cyrillic_YA, "\xdf");
-
+
//Ukrainian letters in T2A encoding
- Map (XK_Ukrainian_i, "i"); // Fall back!
+ Map (XK_Ukrainian_i, "i"); // Fall back!
Map (XK_Ukrainian_I, "I"); // Fall back!
Map (XK_Ukrainian_yi, "\xa8");
Map (XK_Ukrainian_YI, "\x88");
character_bitmap (NULL), character_pixmap ((pointer) 0),
xpm_bitmap (0), xpm_pixmap (0),
lower_key (""), upper_key (""),
- selection (NULL), selection_t ("none"), selection_s ("")
+ selection_t ("none"), selection_s ("")
{
the_gui= this;
if ((dpy= XOpenDisplay (NULL)) == NULL)
interrupted = false;
interrupt_time = texmacs_time ();
+ XA_CLIPBOARD = XInternAtom (dpy, "CLIPBOARD", false);
+ XA_TARGETS = XInternAtom (dpy, "TARGETS", false);
+
if (XMatchVisualInfo (dpy, scr, depth, TrueColor, &visual) != 0) {
if (visual.red_mask == (255 << 16) &&
visual.green_mask == (255 << 8) &&
diff --git a/src/src/Plugins/X11/x_loop.cpp b/src/src/Plugins/X11/x_loop.cpp
index 17919e3..def6a40 100644
--- a/src/src/Plugins/X11/x_loop.cpp
+++ b/src/src/Plugins/X11/x_loop.cpp
@@ -273,8 +273,7 @@ x_gui_rep::process_event (x_window win, XEvent* ev) {
if (N(key)>0) win->key_event (key);
break;
}
- {
+ case SelectionRequest: {
XSelectionRequestEvent& req= ev->xselectionrequest;
XSelectionEvent sel;
sel.type = SelectionNotify;
@@ -282,10 +281,14 @@ x_gui_rep::process_event (x_window win, XEvent* ev) {
sel.selection = req.selection;
sel.target = req.target;
sel.time = req.time;
- Atom XA_TARGETS = XInternAtom(dpy, "TARGETS", False);
- if (selection==NULL)
+ string key = "none";
+ if(req.selection == XA_PRIMARY) {
+ key = "mouse";
+ } else if(req.selection == XA_CLIPBOARD)
+ key = "primary";
+ if (!selection_s->contains(key)) {
sel.property = None;
- else if (req.target==XA_TARGETS) {
+ } else if (req.target==XA_TARGETS) {
Atom targets[2];
targets[0] = XA_TARGETS;
targets[1] = XA_STRING;
@@ -294,19 +297,24 @@ x_gui_rep::process_event (x_window win, XEvent* ev) {
(unsigned char*)&targets[0],2);
sel.property = req.property;
} else if ((req.target==AnyPropertyType) || (req.target==XA_STRING)) {
+ char *txt = as_charp (selection_s(key));
XChangeProperty (dpy, req.requestor, req.property, XA_STRING,
8, PropModeReplace,
- (unsigned char*) selection,
- strlen (selection));
+ (unsigned char*) txt,
+ strlen (txt));
+ tm_delete_array (txt);
sel.property = req.property;
} else
sel.property = None;
XSendEvent (dpy, sel.requestor, false, 0, (XEvent*) &sel);
- break;
- }
- clear_selection ("primary");
- break;
+ } break;
+ case SelectionClear: {
+ XSelectionClearEvent& req= ev->xselectionclear;
+ if(req.selection == XA_PRIMARY) {
+ clear_selection("mouse");
+ } else if(req.selection == XA_CLIPBOARD)
+ clear_selection ("primary");
+ } break;
{
Atom wm_protocols = XInternAtom(win->dpy, "WM_PROTOCOLS", 1);
diff --git a/src/src/Plugins/X11/x_window.hpp b/src/src/Plugins/X11/x_window.hpp
index a4631e9..56ad01b 100644
--- a/src/src/Plugins/X11/x_window.hpp
+++ b/src/src/Plugins/X11/x_window.hpp
friend class x_gui_rep;
friend class x_drawable_rep;
- friend Bool my_predicate (Display* dpy, XEvent* ev, XPointer arg);
+ friend Bool my_selnotify_predicate (Display* dpy, XEvent* ev, XPointer arg);
friend int get_identifier (window w);
};
Makes selections non-persistent following Windows (KDE etc.) standard.
From: <>
The selection is deactivated as soon as the cursor is moved by keys or mouse click.
This solves the annoying problem that a selection might still exist somewhere
off-screen, being replaced unnoticed when new text is entered. Now a selection may only
exist at the position of the cursor. (Clipboard and mouse-copy-paste buffer are
preserved beyond the life of the selection itself.)
---
src/src/Edit/Interface/edit_mouse.cpp | 11 ++++++++++-
src/src/Edit/Replace/edit_select.cpp | 34 +++++++++++++++++++++------------
2 files changed, 32 insertions(+), 13 deletions(-)
diff --git a/src/src/Edit/Interface/edit_mouse.cpp b/src/src/Edit/Interface/edit_mouse.cpp
index 3af1018..5639f19 100644
--- a/src/src/Edit/Interface/edit_mouse.cpp
+++ b/src/src/Edit/Interface/edit_mouse.cpp
@@ -132,6 +132,8 @@ edit_interface_rep::mouse_extra_click (SI x, SI y) {
get_selection (p1, p2);
if ((p1==p2) || path_less (tp, p1) || path_less (p2, tp)) select (tp, tp);
select_enlarge ();
+ if (selection_active_any ())
+ selection_set ("mouse", selection_get (), true);
return false;
}
@@ -139,6 +141,7 @@ void
edit_interface_rep::mouse_drag (SI x, SI y) {
if (inside_graphics ()) return;
if (eb->action ("drag", x, y, 0) != "") return;
+ go_to (x, y);
end_x = x;
end_y = y;
selection_visible ();
@@ -150,8 +153,8 @@ edit_interface_rep::mouse_drag (SI x, SI y) {
p1= p2;
p2= temp;
}
- set_selection (p1, p2);
if ((p1 == p2) && start_drag) return;
+ set_selection (p1, p2);
start_drag= start_right_drag= false;
notify_change (THE_SELECTION);
}
@@ -179,6 +182,12 @@ edit_interface_rep::mouse_select (SI x, SI y, int mods) {
invalidate_graphical_object ();
eval ("(graphics-reset-context 'exit)");
}
+ if(start_drag) {
+ path sp= find_innermost_scroll (eb, tp);
+ path p0= tree_path (sp, x, y, 0);
+ set_selection (p0, p0);
+ notify_change (THE_SELECTION);
+ }
if (selection_active_any ())
selection_set ("mouse", selection_get (), true);
}
diff --git a/src/src/Edit/Replace/edit_select.cpp b/src/src/Edit/Replace/edit_select.cpp
index 9b0fd6f..c99a2fb 100644
--- a/src/src/Edit/Replace/edit_select.cpp
+++ b/src/src/Edit/Replace/edit_select.cpp
@@ -98,21 +98,31 @@ edit_select_rep::select_line () {
void
edit_select_rep::select_from_cursor () {
- if (!(selecting || shift_selecting)) return;
- if (path_less (mid_p, tp)) {
- start_p= copy (mid_p);
- end_p = copy (tp);
- }
- else {
- start_p= copy (tp);
- end_p = copy (mid_p);
+ if (selecting) {
+ if (path_less (mid_p, tp)) {
+ start_p= copy (mid_p);
+ end_p = copy (tp);
+ } else {
+ start_p= copy (tp);
+ end_p = copy (mid_p);
+ }
+ notify_change (THE_SELECTION);
+ if (shift_selecting) selecting = false;
}
- notify_change (THE_SELECTION);
}
void
edit_select_rep::select_from_cursor_if_active () {
- if (selecting) select_from_cursor ();
+ if (selecting) {
+ if (path_less (mid_p, tp)) {
+ start_p= copy (mid_p);
+ end_p = copy (tp);
+ } else {
+ start_p= copy (tp);
+ end_p = copy (mid_p);
+ }
+ notify_change (THE_SELECTION);
+ } else selection_cancel ();
}
void
@@ -128,10 +138,10 @@ edit_select_rep::select_from_shift_keyboard () {
if ((!shift_selecting) || (end_p == start_p) ||
((tp != start_p) && (tp != end_p)))
{
- selecting= false;
- shift_selecting= true;
mid_p= copy (tp);
}
+ selecting= true;
+ shift_selecting= true;
}
/******************************************************************************
Make delete act without touching the clipboard.
From: <>
Formerly, pressing the <delete> key with an active selection would perform a "cut" operation,
placing the deleted text in the clipboard.
Now, <delete> does actually only delete the selected text following Windows (KDE etc.) standards.
---
src/TeXmacs/progs/generic/generic-edit.scm | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/TeXmacs/progs/generic/generic-edit.scm b/src/TeXmacs/progs/generic/generic-edit.scm
index 8dc9d92..c5d5d70 100644
--- a/src/TeXmacs/progs/generic/generic-edit.scm
+++ b/src/TeXmacs/progs/generic/generic-edit.scm
@@ -41,7 +41,8 @@
(tm-define (kbd-remove forward?) (remove-text forward?))
(tm-define (kbd-remove forward?)
(:mode with-active-selection?)
- (clipboard-cut "primary"))
+ (clipboard-cut "nowhere")
+ (clipboard-clear "nowhere"))
(tm-define (kbd-tab)
(if (not (complete-try?))
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Joris van der Hoeven
2009-04-17 10:13:13 UTC
Permalink
Dear Norbert,

I am just resuming my work on TeXmacs... starting with your pending patches.
Thanks for the good work ! This makes cut-and-paste behaviour far more standard.
I applied all patches. A few remarks:

1) I changed the "mouse" selection into "visible" selection and
also use the "visible" selection for the current keyboard selection
(made using control space in Emacs mode or shifted cursor keys otherwise).

2) I am fine with removing the current selection on mouse clicks,
except for one potential drawback: when pasting using middle click,
the cursor has not yet been positioned in a very precise manner.
This is important in TeXmacs contrary to emacs, because different
cursor position may be very (even infinitely) close graphically.
Anyway, I do not see any appropriate fix, so we probably have
to live with this drawback.

3) Since the visible selections become much less persistant
(they are only used in combination with middle clicks),
it makes sense to replace the selection on keyboard or paste events,
as is usual under Windows / MacOS, at least if we are not in Emacs mode.

4) I don't think that the new implementation of delete is a problem
for users of the Emacs mode: in Emacs, one rather uses C-w anyway.

5) Did you check whether the behaviour is correct for the Qt version?

6) In the future, we should implement kill rings and multiple selections.
This is on the list since a while, but, well...

Best wishes, Joris
Pablo Angulo
2009-04-17 10:29:19 UTC
Permalink
Post by Joris van der Hoeven
2) I am fine with removing the current selection on mouse clicks,
except for one potential drawback: when pasting using middle click,
the cursor has not yet been positioned in a very precise manner.
This is important in TeXmacs contrary to emacs, because different
cursor position may be very (even infinitely) close graphically.
Anyway, I do not see any appropriate fix, so we probably have
to live with this drawback.
How about the following?: when the middle button is pressed, you show
the cursor position in a special color, then if the mouse moves with the
middle button still pressed, the position of the cursor changes to show
the final paste position, and when the middle button is released, you paste.

And thanks for this important patch!!
Joris van der Hoeven
2009-04-17 11:21:12 UTC
Permalink
Post by Pablo Angulo
Post by Joris van der Hoeven
2) I am fine with removing the current selection on mouse clicks,
except for one potential drawback: when pasting using middle click,
the cursor has not yet been positioned in a very precise manner.
This is important in TeXmacs contrary to emacs, because different
cursor position may be very (even infinitely) close graphically.
Anyway, I do not see any appropriate fix, so we probably have
to live with this drawback.
How about the following?: when the middle button is pressed, you show
the cursor position in a special color, then if the mouse moves with the
middle button still pressed, the position of the cursor changes to show
the final paste position, and when the middle button is released, you paste.
This does not solve the problem of cursor positions of zero width,
it would just provide an additional visual aid.
But it would probably be useful if someone has time to implement it... ;^)

Best wishes, Joris
Andrea Gamba
2009-04-17 10:40:02 UTC
Permalink
Dear Joris,

Are you possibly implementing also the patch I suggested here:

http://savannah.gnu.org/bugs/?25938

It solves a minor but annoying problem for Gnome/Ubuntu users.

Andrea
Kamaraju Kusumanchi
2009-04-17 13:42:27 UTC
Permalink
Post by Andrea Gamba
Dear Joris,
http://savannah.gnu.org/bugs/?25938
It solves a minor but annoying problem for Gnome/Ubuntu users.
Andrea
Andrea,

This is Raju. I will try to include your fix in the next Debian
upload. If Joris decides to put it in the upstream, then I will remove
it from the Debian version.

Does that sound reasonable?

raju
Joris van der Hoeven
2009-04-17 14:30:13 UTC
Permalink
Post by Kamaraju Kusumanchi
Post by Andrea Gamba
Dear Joris,
http://savannah.gnu.org/bugs/?25938
It solves a minor but annoying problem for Gnome/Ubuntu users.
Andrea
Andrea,
This is Raju. I will try to include your fix in the next Debian
upload. If Joris decides to put it in the upstream, then I will remove
it from the Debian version.
Does that sound reasonable?
The problem is that the fix contains several shell commands to be executed
in order to update the database, so I do not know yet what to do here.
Also, please use another icon for TeXmacs documents,
since they should be distinguished from TeX documents.

Best wishes, Joris
Andrea Gamba
2009-04-17 21:05:01 UTC
Permalink
Post by Joris van der Hoeven
The problem is that the fix contains several shell commands to be executed
in order to update the database, so I do not know yet what to do here.
Also, please use another icon for TeXmacs documents,
since they should be distinguished from TeX documents.
Best wishes, Joris
Joris, it would be enough to add the files

/usr/share/mime/packages/texmacs.xml
/usr/share/icons/gnome/scalable/mimetypes/text-texmacs.svg

the shell commands

update-mime-database /usr/share/mime
update-desktop-database
gtk-update-icon-cache --force /usr/share/icons/gnome

should be taken care of by the post-installation script in the .deb package:

http://www.debian-administration.org/articles/251

The needed files can be found here:

https://savannah.gnu.org/file/texmacs.xml?file_id=17944
https://savannah.gnu.org/file/text-texmacs.svg?file_id=17942

I have modified the image to avoid confusion between TeX and TeXmacs.

Andrea
Kamaraju S Kusumanchi
2009-04-18 02:42:49 UTC
Permalink
Post by Andrea Gamba
Post by Joris van der Hoeven
The problem is that the fix contains several shell commands to be
executed in order to update the database, so I do not know yet what to do
here. Also, please use another icon for TeXmacs documents,
since they should be distinguished from TeX documents.
Best wishes, Joris
Joris, it would be enough to add the files
/usr/share/mime/packages/texmacs.xml
/usr/share/icons/gnome/scalable/mimetypes/text-texmacs.svg
Joris,

If you can add those files like Andrea Gamba suggested, I will take care of
the shell commands in the post-installation script. The post-installation
script is distribution specific. You do not need to worry about them.
Post by Andrea Gamba
the shell commands
update-mime-database /usr/share/mime
update-desktop-database
gtk-update-icon-cache --force /usr/share/icons/gnome
thanks
raju
--
Kamaraju S Kusumanchi
http://malayamaarutham.blogspot.com/
Joris van der Hoeven
2009-04-18 08:49:07 UTC
Permalink
Post by Kamaraju S Kusumanchi
If you can add those files like Andrea Gamba suggested, I will take care of
the shell commands in the post-installation script. The post-installation
script is distribution specific. You do not need to worry about them.
OK, done. --Joris
Norbert Nemec
2009-04-17 19:35:34 UTC
Permalink
Dear Joris,

great news. Let's just hope that I remember all my work a few months
ago... :-)

I just checked the changes that you put on top of my patches and I am
not sure whether I agree. The name "mouse" selection was chosen very
intentionally: As far as I understood the various documents and comments
on the web, the mouse-buffer on X-Windows should really work exclusively
for selections made with the mouse. A mouse-middle-click should just
paste the last mouse-selection, no matter what you did with the keyboard
in between. This is also the behavior that I observed in several other
applications, so at least on X-Windows this seems to be standard. Of
course, this means that the content of the mouse-buffer should be
preserved beyond the lifetime of the visible selection. If you select by
mouse and then move around with the keyboard or the scrollbars or even
click on the text to place the cursor (without dragging) the
mouse-buffer should still contain the content of the original selection
and paste it on middle-click.

Therefore, changing the meaning from "mouse" to "visible" is confusing
in two ways: It allows keyboard actions to interfer with what is
supposed to be a pure mouse mechanism by FreeDesktop standards, and it
suggests that the content of this buffer might be lost once the
selection is not visible any more, which should not be the case either.

As for the imprecise positioning of the cursor on middle-click: This is
exactly what happens in any other editor as well. The positioning on
middle-click is just as sensitive to the exact mouse position as the
positioning on left-click. I don't quite understand why you worry about
this specifically. What is the connection to the removal of selections
on mouse click?

So far, I never to the Qt version running stable to test it (every time
I compiled it over the past months it would crash and burn for other
reasons...) I fixed all issues that I found from reading the sources but
could not try it out.

Greetings,
Norbert
Post by Joris van der Hoeven
Dear Norbert,
I am just resuming my work on TeXmacs... starting with your pending patches.
Thanks for the good work ! This makes cut-and-paste behaviour far more standard.
1) I changed the "mouse" selection into "visible" selection and
also use the "visible" selection for the current keyboard selection
(made using control space in Emacs mode or shifted cursor keys otherwise).
2) I am fine with removing the current selection on mouse clicks,
except for one potential drawback: when pasting using middle click,
the cursor has not yet been positioned in a very precise manner.
This is important in TeXmacs contrary to emacs, because different
cursor position may be very (even infinitely) close graphically.
Anyway, I do not see any appropriate fix, so we probably have
to live with this drawback.
3) Since the visible selections become much less persistant
(they are only used in combination with middle clicks),
it makes sense to replace the selection on keyboard or paste events,
as is usual under Windows / MacOS, at least if we are not in Emacs mode.
4) I don't think that the new implementation of delete is a problem
for users of the Emacs mode: in Emacs, one rather uses C-w anyway.
5) Did you check whether the behaviour is correct for the Qt version?
6) In the future, we should implement kill rings and multiple selections.
This is on the list since a while, but, well...
Best wishes, Joris
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Joris van der Hoeven
2009-04-18 08:24:22 UTC
Permalink
Post by Norbert Nemec
I just checked the changes that you put on top of my patches and I am
not sure whether I agree. The name "mouse" selection was chosen very
intentionally: As far as I understood the various documents and comments
on the web, the mouse-buffer on X-Windows should really work exclusively
for selections made with the mouse. A mouse-middle-click should just
paste the last mouse-selection, no matter what you did with the keyboard
in between. This is also the behavior that I observed in several other
applications, so at least on X-Windows this seems to be standard. Of
course, this means that the content of the mouse-buffer should be
preserved beyond the lifetime of the visible selection. If you select by
mouse and then move around with the keyboard or the scrollbars or even
click on the text to place the cursor (without dragging) the
mouse-buffer should still contain the content of the original selection
and paste it on middle-click.
OK, I reverted to your implementation.
Post by Norbert Nemec
As for the imprecise positioning of the cursor on middle-click: This is
exactly what happens in any other editor as well. The positioning on
middle-click is just as sensitive to the exact mouse position as the
positioning on left-click. I don't quite understand why you worry about
this specifically. What is the connection to the removal of selections
on mouse click?
The "standard" middle-click behaviour (also implemented in Emacs)
is evil in many ways and especially in the context of TeXmacs:
1) The cursor position where you paste is not indicated when pasting.
2) This could be fixed by displaying a cursor on mouse press, but this is
still not nice: as soon as you click, you are obliged to paste,
even if you are unable to position at the correct position by mouse.
This lack of robustness bad independently from 1).
3) Impossible to paste at certain logical positions which correspond
to the same graphical positions (TeXmacs specific, does not occur in Emacs).
So there are many motivations behind the original behaviour of
the middle mouse click. But well, if it is not standard...
The new implementation will just make middle mouse clicking
useless for myself.

Now we are talking about copy and paste, I also got a request
for better CJK support. I will send a sample file which demonstrates
how it should work. If someone wants to take a look...

Best wishes, Joris
Joris van der Hoeven
2009-04-18 08:25:49 UTC
Permalink
Here is the CJK sample file for copy & paste.
Norbert Nemec
2009-04-18 08:57:58 UTC
Permalink
Hmm - I never considered the mouse-middle-button as "evil". Maybe it is
not as useful as it could be in the current definition of the standard.
Post by Joris van der Hoeven
The "standard" middle-click behaviour (also implemented in Emacs)
1) The cursor position where you paste is not indicated when pasting.
Some editors offer something like a "phantom-cursor" that moves along
with the mouse cursor as a gray "shadow" to indicate the place where the
cursor would be placed on a left-click. This would also help greatly for
a middle click. Of course, this would mean major surgery in TeXmacs.
Otherwise, however, I do not see how you would want to improve the
situation here.
Post by Joris van der Hoeven
2) This could be fixed by displaying a cursor on mouse press, but this is
still not nice: as soon as you click, you are obliged to paste,
even if you are unable to position at the correct position by mouse.
This lack of robustness bad independently from 1).
3) Impossible to paste at certain logical positions which correspond
to the same graphical positions (TeXmacs specific, does not occur in Emacs).
OK, the impossibilty to paste certain content in certain positions is
specific to TeXmacs. I don't see, however, why this makes the
middle-click evil. On middle click, the cursor is first positioned just
like with the left-click and then the content it attempted to be pasted.
If this is impossible, it is simply not done and the middle-click simply
has the same effect as a left-click.
Post by Joris van der Hoeven
So there are many motivations behind the original behaviour of
the middle mouse click. But well, if it is not standard...
The new implementation will just make middle mouse clicking
useless for myself.
Maybe the following idea would help:

How about making Shift-middle-click perform a mouse-paste without cursor
repositioning? You could then first place the cursor exactly where you
want and shift-middle-click anywhere in the TeXmacs-window to paste to
this position.

I don't think that this violates any standards. It even follows the
behavior of text-mode editors run in a xterm/konsole window. Personally,
I would really appreciate this feature.
Post by Joris van der Hoeven
Now we are talking about copy and paste, I also got a request
for better CJK support. I will send a sample file which demonstrates
how it should work. If someone wants to take a look...
I think, this falls into the much broader category of content
translation at copy-paste. The standard actually allows quite a bit of
intelligence that we do not use so far. I have not really touched this,
yet, with my work. I don't want to promise anything on that soon.

Greetings,
Norbert
Joris van der Hoeven
2009-04-18 09:12:37 UTC
Permalink
Post by Norbert Nemec
Post by Joris van der Hoeven
The "standard" middle-click behaviour (also implemented in Emacs)
1) The cursor position where you paste is not indicated when pasting.
Some editors offer something like a "phantom-cursor" that moves along
with the mouse cursor as a gray "shadow" to indicate the place where the
cursor would be placed on a left-click. This would also help greatly for
a middle click. Of course, this would mean major surgery in TeXmacs.
Otherwise, however, I do not see how you would want to improve the
situation here.
The old behaviour was: first position your mouse with a left click or
the keyboard and then middle click. This is safe: you know beforehand
where the material gets pasted.

Another drawback of the standard: pasting is a quite critical editing
operations, because it alters a lot of content. Now positioning with
the mouse is delicate: if you are in a train, then it easily occurs
that you move the mouse by a few pixels. Therefore, it is not nice that
a quite critical editing operations requires very precise user control
over the mouse.
Post by Norbert Nemec
Post by Joris van der Hoeven
2) This could be fixed by displaying a cursor on mouse press, but this is
still not nice: as soon as you click, you are obliged to paste,
even if you are unable to position at the correct position by mouse.
This lack of robustness bad independently from 1).
3) Impossible to paste at certain logical positions which correspond
to the same graphical positions (TeXmacs specific, does not occur in Emacs).
OK, the impossibilty to paste certain content in certain positions is
specific to TeXmacs. I don't see, however, why this makes the
middle-click evil. On middle click, the cursor is first positioned just
like with the left-click and then the content it attempted to be pasted.
If this is impossible, it is simply not done and the middle-click simply
has the same effect as a left-click.
No, the situation is worse: when you position the mouse wrongly,
pasting might still be a valid operation, just giving the wrong result.
I was not referring to the impossibilty to paste certain content in
certain positions, but rather the impossibility to position the cursor
at certain points using the mouse. For instance, in the markup

Hi <strong|<em|there>>,

you can position the cursor inside stong but not emphasized text
using the keyboard, but not using the mouse. Also, in mathematical
formulas with lots of scripts, it can be hard to position the cursor
using the mouse.
Post by Norbert Nemec
Post by Joris van der Hoeven
So there are many motivations behind the original behaviour of
the middle mouse click. But well, if it is not standard...
The new implementation will just make middle mouse clicking
useless for myself.
How about making Shift-middle-click perform a mouse-paste without cursor
repositioning? You could then first place the cursor exactly where you
want and shift-middle-click anywhere in the TeXmacs-window to paste to
this position.
Yes, this would be OK.
Norbert Nemec
2009-04-18 11:16:36 UTC
Permalink
OK, I understand your concerns now. The positioning issue may not be
unique to TeXmacs, but it certainly is far more pronounced here, due to
the complexity of the structured text in comparison to a plain text editor.

I believe, the Shift-middle-click offers just the solution that we seek:
a standard-conform and quick paste that works sufficiently precise in
many cases and a more precise paste that gives access to the
mouse-buffer with precise control of the position.

Greetings,
Norbert
Post by Joris van der Hoeven
Post by Norbert Nemec
Post by Joris van der Hoeven
The "standard" middle-click behaviour (also implemented in Emacs)
1) The cursor position where you paste is not indicated when pasting.
Some editors offer something like a "phantom-cursor" that moves along
with the mouse cursor as a gray "shadow" to indicate the place where the
cursor would be placed on a left-click. This would also help greatly for
a middle click. Of course, this would mean major surgery in TeXmacs.
Otherwise, however, I do not see how you would want to improve the
situation here.
The old behaviour was: first position your mouse with a left click or
the keyboard and then middle click. This is safe: you know beforehand
where the material gets pasted.
Another drawback of the standard: pasting is a quite critical editing
operations, because it alters a lot of content. Now positioning with
the mouse is delicate: if you are in a train, then it easily occurs
that you move the mouse by a few pixels. Therefore, it is not nice that
a quite critical editing operations requires very precise user control
over the mouse.
Post by Norbert Nemec
Post by Joris van der Hoeven
2) This could be fixed by displaying a cursor on mouse press, but this is
still not nice: as soon as you click, you are obliged to paste,
even if you are unable to position at the correct position by mouse.
This lack of robustness bad independently from 1).
3) Impossible to paste at certain logical positions which correspond
to the same graphical positions (TeXmacs specific, does not occur in Emacs).
OK, the impossibilty to paste certain content in certain positions is
specific to TeXmacs. I don't see, however, why this makes the
middle-click evil. On middle click, the cursor is first positioned just
like with the left-click and then the content it attempted to be pasted.
If this is impossible, it is simply not done and the middle-click simply
has the same effect as a left-click.
No, the situation is worse: when you position the mouse wrongly,
pasting might still be a valid operation, just giving the wrong result.
I was not referring to the impossibilty to paste certain content in
certain positions, but rather the impossibility to position the cursor
at certain points using the mouse. For instance, in the markup
Hi <strong|<em|there>>,
you can position the cursor inside stong but not emphasized text
using the keyboard, but not using the mouse. Also, in mathematical
formulas with lots of scripts, it can be hard to position the cursor
using the mouse.
Post by Norbert Nemec
Post by Joris van der Hoeven
So there are many motivations behind the original behaviour of
the middle mouse click. But well, if it is not standard...
The new implementation will just make middle mouse clicking
useless for myself.
How about making Shift-middle-click perform a mouse-paste without cursor
repositioning? You could then first place the cursor exactly where you
want and shift-middle-click anywhere in the TeXmacs-window to paste to
this position.
Yes, this would be OK.
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Andrea Gamba
2009-05-25 10:38:04 UTC
Permalink
Dear Joris,

I have checked that the mime-type patch applied to the .deb package

http://www.nabble.com/Patches%3A-copy-paste-and-selection-handling.-td21634429i20.html#a23108890

works in Ubuntu 9.04. Now the texmacs package has an icon for texmacs
documents, files created by texmacs are recognized and shown on the
desktop with that icon, and they are correctly opened with texmacs when
clicking on them.

Even if everything appears to be working as it should, I have noticed a
slight incoherence: the mime type for a texmacs file is *text/texmacs*
in /etc/mime.types and texmacs.xml

http://wiki.debian.org/MIME/etc/mime.types

but it is *text/x-texmacs* in texmacs.desktop:

***@rama:~$ cat /etc/mime.types | grep texmacs
text/texmacs tm ts
***@rama:~$ cat /usr/share/applications/texmacs.desktop | grep texmacs
MimeType=text/x-texmacs;text/plain;text/x-tex;
Exec=texmacs %f
***@rama:~$ cat /usr/share/mime/packages/texmacs.xml | grep texmacs
<mime-type type="text/texmacs">

Can you tell which is the correct label for texmacs files? I guess all
the three files should contain one and the same definition.

The file /etc/mime.types comes from the package mime-support, which
appears in Debian-derived distributions:

http://packages.debian.org/lenny/mime-support
http://packages.ubuntu.com/it/jaunty/mime-support

and contains already (i.e., before texmacs installation) a line with
text/texmacs.

So possibly it is texmacs.desktop that should be changed to contain
/text/texmacs instead of /text/x-texmacs. Or it could contain both.


Andrea
Post by Andrea Gamba
the shell commands
update-*mime*-database /usr/share/*mime*
update-desktop-database
gtk-update-icon-cache --force /usr/share/icons/gnome
should be taken care of by the post-installation script in the .deb
Joris van der Hoeven
2009-05-25 16:48:21 UTC
Permalink
Dear Andrea,

No idea about what the conventions are.
I content myself to apply any patches for mime types
as soon as they are sufficiently consensual ;^)

Best wishes, Joris
Post by Andrea Gamba
Dear Joris,
I have checked that the mime-type patch applied to the .deb package
http://www.nabble.com/Patches%3A-copy-paste-and-selection-handling.-td21634429i20.html#a23108890
works in Ubuntu 9.04. Now the texmacs package has an icon for texmacs
documents, files created by texmacs are recognized and shown on the
desktop with that icon, and they are correctly opened with texmacs when
clicking on them.
Even if everything appears to be working as it should, I have noticed a
slight incoherence: the mime type for a texmacs file is *text/texmacs*
in /etc/mime.types and texmacs.xml
http://wiki.debian.org/MIME/etc/mime.types
text/texmacs tm ts
MimeType=text/x-texmacs;text/plain;text/x-tex;
Exec=texmacs %f
<mime-type type="text/texmacs">
Can you tell which is the correct label for texmacs files? I guess all
the three files should contain one and the same definition.
The file /etc/mime.types comes from the package mime-support, which
http://packages.debian.org/lenny/mime-support
http://packages.ubuntu.com/it/jaunty/mime-support
and contains already (i.e., before texmacs installation) a line with
text/texmacs.
So possibly it is texmacs.desktop that should be changed to contain
/text/texmacs instead of /text/x-texmacs. Or it could contain both.
Andrea
Post by Andrea Gamba
the shell commands
update-*mime*-database /usr/share/*mime*
update-desktop-database
gtk-update-icon-cache --force /usr/share/icons/gnome
should be taken care of by the post-installation script in the .deb
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
David Allouche
2009-05-25 19:01:47 UTC
Permalink
Post by Joris van der Hoeven
Dear Andrea,
No idea about what the conventions are.
I content myself to apply any patches for mime types
as soon as they are sufficiently consensual ;^)
The correct one is text/x-texmacs.

The non-x names are assigned by the IANA:
http://www.iana.org/assignments/media-types/

As you can see, there is no text/texmacs media type name registered by
IANA: http://www.iana.org/assignments/media-types/text/

The x-names are reserved for non-standard types not assigned by the
IANA.
Andrea Gamba
2009-05-25 19:15:45 UTC
Permalink
But then why the packages

http://packages.debian.org/lenny/mime-support

http://packages.ubuntu.com/it/jaunty/mime-support

contain a file /etc/mime.types with text/texmacs?

***@rama:~$ cat /etc/mime.types |grep texmacs
text/texmacs tm ts

Is that an error?


Andrea
Post by David Allouche
The correct one is text/x-texmacs.
http://www.iana.org/assignments/media-types/
As you can see, there is no text/texmacs media type name registered by
IANA: http://www.iana.org/assignments/media-types/text/
The x-names are reserved for non-standard types not assigned by the
IANA.
David Allouche
2009-05-25 20:08:08 UTC
Permalink
Post by Andrea Gamba
But then why the packages
http://packages.debian.org/lenny/mime-support
http://packages.ubuntu.com/it/jaunty/mime-support
contain a file /etc/mime.types with text/texmacs?
text/texmacs tm ts
Is that an error?
I cannot say whether that is intentional, but that is certainly not
standard-compliant.

This issue is one of those fortunate areas of software engineering where
there is one and only one correct choice, and this is "text/x-texmacs".
Andrea Gamba
2009-05-25 20:22:34 UTC
Permalink
Post by David Allouche
I cannot say whether that is intentional, but that is certainly not
standard-compliant.
This issue is one of those fortunate areas of software engineering where
there is one and only one correct choice, and this is "text/x-texmacs".
So the correct solution would be to ask to the people maintaining
mime-support on Debian and Ubuntu to change text/texmacs to
text/x-texmacs, then to perform the same change in all texmacs and
texmacs-common files.

Perhaps it is not worthwhile, since everything seems to be working
perfectly at the moment...

Andrea
David Allouche
2009-05-26 08:42:45 UTC
Permalink
Post by Andrea Gamba
So the correct solution would be to ask to the people maintaining
mime-support on Debian and Ubuntu to change text/texmacs to
text/x-texmacs, then to perform the same change in all texmacs and
texmacs-common files.
Kamaraju S Kusumanchi
2009-06-15 01:47:19 UTC
Permalink
<posted & mailed>
Post by Andrea Gamba
So the correct solution would be to ask to the people maintaining
mime-support on Debian and Ubuntu to change text/texmacs to
text/x-texmacs, then to perform the same change in all texmacs and
texmacs-common files.
Andrea,

Have you by any chance filed any bug reports regarding this? If not, no
sweat. I will look into this before we upload the next Debian release.

BTW, the text/texmacs was not intentional. I can change it to text/x-texmacs
if necessary.

Thanks for bringing up the issue.
You only need to get fixes in two source packages: mime-support and
texmacs. All the arch-dependent texmacs, and the arch-independent
texmacs-common package are all built from the single texmacs source
package.
Thanks David for all the explanations.

thanks
raju
--
Kamaraju S Kusumanchi
http://malayamaarutham.blogspot.com/
Andrea Gamba
2009-06-15 08:10:07 UTC
Permalink
Dear Raju,

since everything works at the moment I didn't open any bug. It is true
that if we like consistency, text/texmacs should be substituted wherever
with text/x-texmacs.

If I am not missing other points, the substitution should be done in

/etc/mime.types
/usr/share/texmacs/TeXmacs/misc/mime/texmacs.xml
/usr/share/mime/packages/texmacs.xml
/usr/share/mime/text/texmacs.xml

(of course the last two are copies of the second one).
Hope this doesn't break anything, possibly one can give it a try before
applying the change.

Andrea
Post by Kamaraju S Kusumanchi
<posted & mailed>
Post by Andrea Gamba
So the correct solution would be to ask to the people maintaining
mime-support on Debian and Ubuntu to change text/texmacs to
text/x-texmacs, then to perform the same change in all texmacs and
texmacs-common files.
Andrea,
Have you by any chance filed any bug reports regarding this? If not, no
sweat. I will look into this before we upload the next Debian release.
BTW, the text/texmacs was not intentional. I can change it to text/x-texmacs
if necessary.
Thanks for bringing up the issue.
You only need to get fixes in two source packages: mime-support and
texmacs. All the arch-dependent texmacs, and the arch-independent
texmacs-common package are all built from the single texmacs source
package.
Thanks David for all the explanations.
thanks
raju
Philippe Joyez
2009-12-03 19:27:57 UTC
Permalink
Hi all,

I was disappointed to realize that the handling of the selection in the
Qt-texmacs I compiled a few days ago is still not completely conforming to
standards. For instance, when I have an active selection, if I start typing
text or if I paste something, the selection is not replaced by the new text.
Instead, the selection is merely canceled and the text entered next to it.
Also the "insert" key does not seem to toggle the usual insert/overwrite
mode, at least in my configuration.

Is this the intended behavior, or is there a configuration switch I missed
somewhere? If it is normal, would it be hard to change the code in order to
(at least as an option) delete any existing selection when something is
inserted from the keyboard or the clipboard?

Philippe
--
View this message in context: http://old.nabble.com/Patches%3A-copy-paste-and-selection-handling.-tp21634429p26631713.html
Sent from the Gnu - Texmacs - Dev mailing list archive at Nabble.com.
Norbert Nemec
2009-12-04 00:24:16 UTC
Permalink
Post by Philippe Joyez
I was disappointed to realize that the handling of the selection in the
Qt-texmacs I compiled a few days ago is still not completely conforming to
standards. For instance, when I have an active selection, if I start typing
text or if I paste something, the selection is not replaced by the new text.
Instead, the selection is merely canceled and the text entered next to it.
Indeed, this is one detail that is still left to do in the selection
mechanism of TeXmacs. It should not be too hard to implement - I don't
know when I might get to it. It is not high priority for me, but I agree
that it would be nice to have.
Post by Philippe Joyez
Also the "insert" key does not seem to toggle the usual insert/overwrite
mode, at least in my configuration.
I don't think TeXmacs has an "overwrite" mode at all. The problem may be
already finding a proper definition for the behavior. All is easy while
editing plain text, but what should happen to formatting information or
any non-text elements when you "overwrite" them?

Personally, I find overwrite mode quite handy in text editors in plain
ASCII, fixed-character width setting. I don't think I have ever used it
in a variable-width font. It might be nice to have in preformatted
environments within TeXmacs. Otherwise, I think it is not really worth
the trouble.
Post by Philippe Joyez
Is this the intended behavior, or is there a configuration switch I missed
somewhere? If it is normal, would it be hard to change the code in order to
(at least as an option) delete any existing selection when something is
inserted from the keyboard or the clipboard?
I am not sure. Should be straighforward but it might be non-trivial to
get the behavior "quite right". In my experience it takes a lot of
tweaking until such a change has exactly the effect that you intend in
all the possible different cases.
Philippe Joyez
2009-12-05 12:15:16 UTC
Permalink
Dear Norbert,
Post by Norbert Nemec
I am not sure. Should be straighforward but it might be non-trivial to
get the behavior "quite right". In my experience it takes a lot of
tweaking until such a change has exactly the effect that you intend in
all the possible different cases.
I have tried this minimalistic change:

**************************
diff -u 'src/Edit/Modify/edit_text.cpp.0' 'src/Edit/Modify/edit_text.cpp'
--- src/Edit/Modify/edit_text.cpp.0 2009-11-19 20:43:01.000000000 +0100
+++ src/Edit/Modify/edit_text.cpp 2009-12-05 12:39:55.000000000 +0100
@@ -197,6 +197,7 @@

void
edit_text_rep::insert_tree (tree t, path p_in_t) {
+ selection_get_cut () ; // delete existing selection to get overwrite
behavior
if (is_atomic (t) && (p_in_t == end (t)) &&
is_atomic (subtree (et, path_up (tp))))
insert (tp, t);

******************************

It seems to to the trick (deleting any existing selection prior to adding
stuff to the document). I have not yet extensively tested it, though.
Moreover, since I don't know the overall architecture of the project, it may
introduce really bad side effects in some cases. So, it's better to have it
checked by an "architect".

best,
Philippe


_______________________________________________
Texmacs-dev mailing list
Texmacs-***@gnu.org
http://lists.gnu.org/mailman/listinfo/texmacs-dev
--
View this message in context: http://old.nabble.com/Patches%3A-copy-paste-and-selection-handling.-tp21634429p26655064.html
Sent from the Gnu - Texmacs - Dev mailing list archive at Nabble.com.
Norbert Nemec
2009-12-08 17:41:03 UTC
Permalink
selection_cut("none") is preferable to selection_get_cut() as it avoids
copying the data which is then ignored anyway.

Otherwise, it seems fine to me. I have put it into my private repo and
will test it.

Greetings,
Norbert
Post by Joris van der Hoeven
Dear Norbert,
Post by Norbert Nemec
I am not sure. Should be straighforward but it might be non-trivial to
get the behavior "quite right". In my experience it takes a lot of
tweaking until such a change has exactly the effect that you intend in
all the possible different cases.
**************************
diff -u 'src/Edit/Modify/edit_text.cpp.0' 'src/Edit/Modify/edit_text.cpp'
--- src/Edit/Modify/edit_text.cpp.0 2009-11-19 20:43:01.000000000 +0100
+++ src/Edit/Modify/edit_text.cpp 2009-12-05 12:39:55.000000000 +0100
@@ -197,6 +197,7 @@
void
edit_text_rep::insert_tree (tree t, path p_in_t) {
+ selection_get_cut () ; // delete existing selection to get overwrite
behavior
if (is_atomic (t) && (p_in_t == end (t)) &&
is_atomic (subtree (et, path_up (tp))))
insert (tp, t);
******************************
It seems to to the trick (deleting any existing selection prior to adding
stuff to the document). I have not yet extensively tested it, though.
Moreover, since I don't know the overall architecture of the project, it may
introduce really bad side effects in some cases. So, it's better to have it
checked by an "architect".
best,
Philippe
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Philippe Joyez
2009-12-08 21:58:17 UTC
Permalink
Post by Norbert Nemec
selection_cut("none") is preferable to selection_get_cut() as it avoids
copying the data which is then ignored anyway.
Otherwise, it seems fine to me. I have put it into my private repo and
will test it.
Of course, you're absolutely right. Thanks.

unrelated stuff:
I think your "table editing" patch will really improve user experience.
Previously you had to more or less guess what the structure of the table you
were editing was (or look carefully at the message line).

Lately, I was working on a version dated nov. 19 and appearing as V.
1.0.7.2. The one I downloaded today appears as 1.0.7.3 and is really
sluggish compared to the previous one (both qt builds)... About 1/2 to 1
second second lag when I press a key before the character is on the screen!
Has anyone noticed it?

best,
Philippe
--
View this message in context: http://old.nabble.com/Patches%3A-copy-paste-and-selection-handling.-tp21634429p26701546.html
Sent from the Gnu - Texmacs - Dev mailing list archive at Nabble.com.
Gubinelli Massimiliano
2009-12-08 22:07:43 UTC
Permalink
Hi,
Post by Philippe Joyez
Of course, you're absolutely right. Thanks.
I think your "table editing" patch will really improve user
experience.
Previously you had to more or less guess what the structure of the table you
were editing was (or look carefully at the message line).
Lately, I was working on a version dated nov. 19 and appearing as V.
1.0.7.2. The one I downloaded today appears as 1.0.7.3 and is really
sluggish compared to the previous one (both qt builds)... About
1/2 to 1
second second lag when I press a key before the character is on the screen!
Has anyone noticed it?
there have been a lot of changes lately to TeXmacsQt in order to
correcly support the graphics mode and event interruptions during
repainting.
This afternoon (gmt) I've commited some more changes which should help
in perceived performace (current svn revision is 2863). Please check
if it is the case for you.

Thanks
massimiliano
Post by Philippe Joyez
best,
Philippe
--
View this message in context: http://old.nabble.com/Patches%3A-copy-paste-and-selection-handling.-tp21634429p26701546.html
Sent from the Gnu - Texmacs - Dev mailing list archive at Nabble.com.
_______________________________________________
Texmacs-dev mailing list
http://lists.gnu.org/mailman/listinfo/texmacs-dev
Loading...