GNU bug report logs -
#16382
Cut/Copy tool-bar icons issue
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16382 in the body.
You can then email your comments to 16382 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Tue, 07 Jan 2014 14:08:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Angelo Graziosi <angelo.graziosi <at> alice.it>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 07 Jan 2014 14:08:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Starting
$ emacs -Q &
I notice that when I select some text in the scratch buffer with the
mouse the tool-bar icons for "cut" and "copy" remain grayed, i.e. not
active and I cannot cut or copy the selected text clicking those icons,
but the keys combination, C-w and M-w work as expected.
This occurs with recent trunk with my GTK builds on Cygwin and GNU/Linux
Kubuntu 12.04.
It occurs also with Windows binaries from
http://sourceforge.net/projects/emacs-bin (rev. 115804)
Ciao,
Angelo.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Tue, 07 Jan 2014 17:28:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 16382 <at> debbugs.gnu.org (full text, mbox):
Hello.
7 jan 2014 kl. 15:07 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
> Starting
>
> $ emacs -Q &
>
> I notice that when I select some text in the scratch buffer with the mouse the tool-bar icons for "cut" and "copy" remain grayed, i.e. not active and I cannot cut or copy the selected text clicking those icons, but the keys combination, C-w and M-w work as expected.
>
> This occurs with recent trunk with my GTK builds on Cygwin and GNU/Linux Kubuntu 12.04.
>
> It occurs also with Windows binaries from http://sourceforge.net/projects/emacs-bin (rev. 115804)
It is the same on NS. redisplay_tool_bar in xdisp.c does not get called when marking text for some reason.
Jan D.
Reply sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
You have taken responsibility.
(Thu, 09 Jan 2014 02:01:04 GMT)
Full text and
rfc822 format available.
Notification sent
to
Angelo Graziosi <angelo.graziosi <at> alice.it>:
bug acknowledged by developer.
(Thu, 09 Jan 2014 02:01:07 GMT)
Full text and
rfc822 format available.
Message #13 received at 16382-done <at> debbugs.gnu.org (full text, mbox):
>> I notice that when I select some text in the scratch buffer with the mouse
>> the tool-bar icons for "cut" and "copy" remain grayed, i.e. not active and
>> I cannot cut or copy the selected text clicking those icons, but the keys
>> combination, C-w and M-w work as expected.
>>
>> This occurs with recent trunk with my GTK builds on Cygwin and
>> GNU/Linux Kubuntu 12.04.
Indeed, the toolbar needs to be re-computed, and nothing causes it so
far (it might have worked earlier as a side-effect of something else,
but with the more refined choice of what to redisplay this doesn't
happen any more).
I've installed a patch which calls force-mode-line-update when the mark
is (de)activated.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Sun, 12 Jan 2014 11:28:02 GMT)
Full text and
rfc822 format available.
Message #16 received at submit <at> debbugs.gnu.org (full text, mbox):
Il 09/01/2014 3.00, Stefan Monnier ha scritto:
>
> I've installed a patch which calls force-mode-line-update when the mark
> is (de)activated.
Hmm... it seems there are still problems, mainly with "cut" icon...
With a recent trunk build (GTK build on Cygwin, two days ago), I see this:
$ emacs -Q &
1. Now with the mouse I select the word "create" on second row of
scratch buffer. The "cut" and "copy" icons in tool-bar are active.
2. I click the "cut" icon and the word "create" is removed and the "cut"
and "copy" icons are grayed (disabled).
3. Then I move the mouse pointer on the letter "b" of the word "buffer"
on third row and...
4. ...I click the mouse-2 (wheel) to paste.. but it doesn't work, only
the cursor is moved over the "b".
The same happens if in step 3., after moving the mouse pointer, I click
with mouse-1 to move the cursor over the "b" before step 4.
If I repeat all the above steps changing the "cut" icon with "copy"
icon, all works as expected.
Ciao,
Angelo.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Sun, 12 Jan 2014 18:04:01 GMT)
Full text and
rfc822 format available.
Message #19 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello.
Copy does save in PRIMARY, but cut does not for some reason.
Jan D.
2014-01-12 12:26, Angelo Graziosi skrev:
> Il 09/01/2014 3.00, Stefan Monnier ha scritto:
>>
>> I've installed a patch which calls force-mode-line-update when the mark
>> is (de)activated.
>
> Hmm... it seems there are still problems, mainly with "cut" icon...
>
> With a recent trunk build (GTK build on Cygwin, two days ago), I see this:
>
> $ emacs -Q &
>
> 1. Now with the mouse I select the word "create" on second row of scratch
> buffer. The "cut" and "copy" icons in tool-bar are active.
>
> 2. I click the "cut" icon and the word "create" is removed and the "cut" and
> "copy" icons are grayed (disabled).
>
> 3. Then I move the mouse pointer on the letter "b" of the word "buffer" on
> third row and...
>
> 4. ...I click the mouse-2 (wheel) to paste.. but it doesn't work, only the
> cursor is moved over the "b".
>
> The same happens if in step 3., after moving the mouse pointer, I click with
> mouse-1 to move the cursor over the "b" before step 4.
>
>
> If I repeat all the above steps changing the "cut" icon with "copy" icon, all
> works as expected.
>
>
> Ciao,
> Angelo.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Tue, 14 Jan 2014 09:05:02 GMT)
Full text and
rfc822 format available.
Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):
Should we open a new bug report for this?
Ciao,
Angelo.
Il 12/01/2014 19.03, Jan Djärv ha scritto:
> Hello.
>
> Copy does save in PRIMARY, but cut does not for some reason.
>
> Jan D.
>
>
> 2014-01-12 12:26, Angelo Graziosi skrev:
>> Il 09/01/2014 3.00, Stefan Monnier ha scritto:
>>>
>>> I've installed a patch which calls force-mode-line-update when the mark
>>> is (de)activated.
>>
>> Hmm... it seems there are still problems, mainly with "cut" icon...
>>
>> With a recent trunk build (GTK build on Cygwin, two days ago), I see
>> this:
>>
>> $ emacs -Q &
>>
>> 1. Now with the mouse I select the word "create" on second row of scratch
>> buffer. The "cut" and "copy" icons in tool-bar are active.
>>
>> 2. I click the "cut" icon and the word "create" is removed and the
>> "cut" and
>> "copy" icons are grayed (disabled).
>>
>> 3. Then I move the mouse pointer on the letter "b" of the word
>> "buffer" on
>> third row and...
>>
>> 4. ...I click the mouse-2 (wheel) to paste.. but it doesn't work, only
>> the
>> cursor is moved over the "b".
>>
>> The same happens if in step 3., after moving the mouse pointer, I
>> click with
>> mouse-1 to move the cursor over the "b" before step 4.
>>
>>
>> If I repeat all the above steps changing the "cut" icon with "copy"
>> icon, all
>> works as expected.
>>
>>
>> Ciao,
>> Angelo.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Tue, 14 Jan 2014 16:08:01 GMT)
Full text and
rfc822 format available.
Message #25 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello.
14 jan 2014 kl. 10:03 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
> Should we open a new bug report for this?
>
This report is fine. The omission to copy to PRIMARY looks intended, because when text is read-only and cut acts like copy, text is copied to PRIMARY.
I wonder if there is some thought behind this we don't see.
Jan D.
> Ciao,
> Angelo.
>
> Il 12/01/2014 19.03, Jan Djärv ha scritto:
>> Hello.
>>
>> Copy does save in PRIMARY, but cut does not for some reason.
>>
>> Jan D.
>>
>>
>> 2014-01-12 12:26, Angelo Graziosi skrev:
>>> Il 09/01/2014 3.00, Stefan Monnier ha scritto:
>>>>
>>>> I've installed a patch which calls force-mode-line-update when the mark
>>>> is (de)activated.
>>>
>>> Hmm... it seems there are still problems, mainly with "cut" icon...
>>>
>>> With a recent trunk build (GTK build on Cygwin, two days ago), I see
>>> this:
>>>
>>> $ emacs -Q &
>>>
>>> 1. Now with the mouse I select the word "create" on second row of scratch
>>> buffer. The "cut" and "copy" icons in tool-bar are active.
>>>
>>> 2. I click the "cut" icon and the word "create" is removed and the
>>> "cut" and
>>> "copy" icons are grayed (disabled).
>>>
>>> 3. Then I move the mouse pointer on the letter "b" of the word
>>> "buffer" on
>>> third row and...
>>>
>>> 4. ...I click the mouse-2 (wheel) to paste.. but it doesn't work, only
>>> the
>>> cursor is moved over the "b".
>>>
>>> The same happens if in step 3., after moving the mouse pointer, I
>>> click with
>>> mouse-1 to move the cursor over the "b" before step 4.
>>>
>>>
>>> If I repeat all the above steps changing the "cut" icon with "copy"
>>> icon, all
>>> works as expected.
>>>
>>>
>>> Ciao,
>>> Angelo.
>>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Tue, 14 Jan 2014 17:27:02 GMT)
Full text and
rfc822 format available.
Message #28 received at submit <at> debbugs.gnu.org (full text, mbox):
Il 14/01/2014 17.07, Jan Djärv ha scritto:
> Hello.
>
> 14 jan 2014 kl. 10:03 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>
>> Should we open a new bug report for this?
>>
>
> This report is fine. The omission to copy to PRIMARY looks intended, because when text is read-only and cut acts like copy, text is copied to PRIMARY.
"intended" ? If it is intended, which is its usefulness?
If one wants to move text from a place to another, this doesn't work
using the mouse and the "cut" icon on the tool-bar...
1. select the text with mouse-1 (dragging over the text)
2. click the "cut" icon on the tool-bar: the text is removed
3. now move the mouse pointer where you want the text to reappear
4. click mouse-2 to paste: nothing happens
So, newly, which the usefulness of the above "intended" omission?
> I wonder if there is some thought behind this we don't see.
ah..
Ciao,
Angelo.
>>
>> Il 12/01/2014 19.03, Jan Djärv ha scritto:
>>> Hello.
>>>
>>> Copy does save in PRIMARY, but cut does not for some reason.
>>>
>>> Jan D.
>>>
>>>
>>> 2014-01-12 12:26, Angelo Graziosi skrev:
>>>> Il 09/01/2014 3.00, Stefan Monnier ha scritto:
>>>>>
>>>>> I've installed a patch which calls force-mode-line-update when the mark
>>>>> is (de)activated.
>>>>
>>>> Hmm... it seems there are still problems, mainly with "cut" icon...
>>>>
>>>> With a recent trunk build (GTK build on Cygwin, two days ago), I see
>>>> this:
>>>>
>>>> $ emacs -Q &
>>>>
>>>> 1. Now with the mouse I select the word "create" on second row of scratch
>>>> buffer. The "cut" and "copy" icons in tool-bar are active.
>>>>
>>>> 2. I click the "cut" icon and the word "create" is removed and the
>>>> "cut" and
>>>> "copy" icons are grayed (disabled).
>>>>
>>>> 3. Then I move the mouse pointer on the letter "b" of the word
>>>> "buffer" on
>>>> third row and...
>>>>
>>>> 4. ...I click the mouse-2 (wheel) to paste.. but it doesn't work, only
>>>> the
>>>> cursor is moved over the "b".
>>>>
>>>> The same happens if in step 3., after moving the mouse pointer, I
>>>> click with
>>>> mouse-1 to move the cursor over the "b" before step 4.
>>>>
>>>>
>>>> If I repeat all the above steps changing the "cut" icon with "copy"
>>>> icon, all
>>>> works as expected.
>>>>
>>>>
>>>> Ciao,
>>>> Angelo.
>>>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Tue, 14 Jan 2014 17:49:02 GMT)
Full text and
rfc822 format available.
Message #31 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello.
14 jan 2014 kl. 18:25 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
> Il 14/01/2014 17.07, Jan Djärv ha scritto:
>> Hello.
>>
>> 14 jan 2014 kl. 10:03 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>>
>>> Should we open a new bug report for this?
>>>
>>
>> This report is fine. The omission to copy to PRIMARY looks intended, because when text is read-only and cut acts like copy, text is copied to PRIMARY.
>
> "intended" ? If it is intended, which is its usefulness?
>
> If one wants to move text from a place to another, this doesn't work using the mouse and the "cut" icon on the tool-bar...
>
> 1. select the text with mouse-1 (dragging over the text)
This should already put the text in PRIMARY.
> 2. click the "cut" icon on the tool-bar: the text is removed
> 3. now move the mouse pointer where you want the text to reappear
> 4. click mouse-2 to paste: nothing happens
>
> So, newly, which the usefulness of the above "intended" omission?
>
>
>> I wonder if there is some thought behind this we don't see.
>
> ah..
>
Does it work if you use C-w instead of cut?
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Tue, 14 Jan 2014 17:55:01 GMT)
Full text and
rfc822 format available.
Message #34 received at submit <at> debbugs.gnu.org (full text, mbox):
Il 14/01/2014 18.47, Jan Djärv ha scritto:
> Hello.
>
> 14 jan 2014 kl. 18:25 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>
>> Il 14/01/2014 17.07, Jan Djärv ha scritto:
>>> Hello.
>>>
>>> 14 jan 2014 kl. 10:03 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>>>
>>>> Should we open a new bug report for this?
>>>>
>>>
>>> This report is fine. The omission to copy to PRIMARY looks intended, because when text is read-only and cut acts like copy, text is copied to PRIMARY.
>>
>> "intended" ? If it is intended, which is its usefulness?
>>
>> If one wants to move text from a place to another, this doesn't work using the mouse and the "cut" icon on the tool-bar...
>>
>> 1. select the text with mouse-1 (dragging over the text)
>
> This should already put the text in PRIMARY.
>
>> 2. click the "cut" icon on the tool-bar: the text is removed
>> 3. now move the mouse pointer where you want the text to reappear
>> 4. click mouse-2 to paste: nothing happens
>>
>> So, newly, which the usefulness of the above "intended" omission?
>>
>>
>>> I wonder if there is some thought behind this we don't see.
>>
>> ah..
>>
>
> Does it work if you use C-w instead of cut?
C-w and C-y work as expected. C-y works also if used at step 4 above. It
is with the mouse and tool-bar "cut" icon that it doesn't work..
Ciao,
Angelo.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Tue, 14 Jan 2014 18:00:02 GMT)
Full text and
rfc822 format available.
Message #37 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello.
14 jan 2014 kl. 18:54 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
> Il 14/01/2014 18.47, Jan Djärv ha scritto:
>> Hello.
>>
>> 14 jan 2014 kl. 18:25 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>>
>>> Il 14/01/2014 17.07, Jan Djärv ha scritto:
>>>> Hello.
>>>>
>>>> 14 jan 2014 kl. 10:03 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>>>>
>>>>> Should we open a new bug report for this?
>>>>>
>>>>
>>>> This report is fine. The omission to copy to PRIMARY looks intended, because when text is read-only and cut acts like copy, text is copied to PRIMARY.
>>>
>>> "intended" ? If it is intended, which is its usefulness?
>>>
>>> If one wants to move text from a place to another, this doesn't work using the mouse and the "cut" icon on the tool-bar...
>>>
>>> 1. select the text with mouse-1 (dragging over the text)
>>
>> This should already put the text in PRIMARY.
>>
>>> 2. click the "cut" icon on the tool-bar: the text is removed
>>> 3. now move the mouse pointer where you want the text to reappear
>>> 4. click mouse-2 to paste: nothing happens
>>>
>>> So, newly, which the usefulness of the above "intended" omission?
>>>
>>>
>>>> I wonder if there is some thought behind this we don't see.
>>>
>>> ah..
>>>
>>
>> Does it work if you use C-w instead of cut?
>
> C-w and C-y work as expected. C-y works also if used at step 4 above. It is with the mouse and tool-bar "cut" icon that it doesn't work..
Ok, so if nobody remember why the current implementation is the way it is in a couple of days or so, I'll fix this. C-w and cut should be equivalent in this case.
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Sat, 18 Jan 2014 15:14:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 16382-done <at> debbugs.gnu.org (full text, mbox):
Hello.
I think the rationale was that with cut the selection is gone, so PRIMARY
should be empty, i.e. PRIMARY reflects what is selected on screen.
However, this is not in line with the freedesktop guidelines
http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt:
" - a selection becoming unselected should never unset PRIMARY"
So I checked in a fix in trunk so PRIMARY is not reset.
Jan D.
2014-01-14 18:59, Jan Djärv skrev:
> Hello.
>
> 14 jan 2014 kl. 18:54 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>
>> Il 14/01/2014 18.47, Jan Djärv ha scritto:
>>> Hello.
>>>
>>> 14 jan 2014 kl. 18:25 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>>>
>>>> Il 14/01/2014 17.07, Jan Djärv ha scritto:
>>>>> Hello.
>>>>>
>>>>> 14 jan 2014 kl. 10:03 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>>>>>
>>>>>> Should we open a new bug report for this?
>>>>>>
>>>>>
>>>>> This report is fine. The omission to copy to PRIMARY looks intended, because when text is read-only and cut acts like copy, text is copied to PRIMARY.
>>>>
>>>> "intended" ? If it is intended, which is its usefulness?
>>>>
>>>> If one wants to move text from a place to another, this doesn't work using the mouse and the "cut" icon on the tool-bar...
>>>>
>>>> 1. select the text with mouse-1 (dragging over the text)
>>>
>>> This should already put the text in PRIMARY.
>>>
>>>> 2. click the "cut" icon on the tool-bar: the text is removed
>>>> 3. now move the mouse pointer where you want the text to reappear
>>>> 4. click mouse-2 to paste: nothing happens
>>>>
>>>> So, newly, which the usefulness of the above "intended" omission?
>>>>
>>>>
>>>>> I wonder if there is some thought behind this we don't see.
>>>>
>>>> ah..
>>>>
>>>
>>> Does it work if you use C-w instead of cut?
>>
>> C-w and C-y work as expected. C-y works also if used at step 4 above. It is with the mouse and tool-bar "cut" icon that it doesn't work..
>
> Ok, so if nobody remember why the current implementation is the way it is in a couple of days or so, I'll fix this. C-w and cut should be equivalent in this case.
>
> Jan D.
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16382; Package
emacs.
(Sat, 18 Jan 2014 16:20:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 16382-done <at> debbugs.gnu.org (full text, mbox):
Il 18/01/2014 16.13, Jan Djärv ha scritto:
> Hello.
>
> I think the rationale was that with cut the selection is gone, so
> PRIMARY should be empty, i.e. PRIMARY reflects what is selected on screen.
> However, this is not in line with the freedesktop guidelines
> http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt:
>
> " - a selection becoming unselected should never unset PRIMARY"
>
> So I checked in a fix in trunk so PRIMARY is not reset.
This seems reasonable to me.. :)
Thanks,
Angelo.
>
> Jan D.
>
> 2014-01-14 18:59, Jan Djärv skrev:
>> Hello.
>>
>> 14 jan 2014 kl. 18:54 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>>
>>> Il 14/01/2014 18.47, Jan Djärv ha scritto:
>>>> Hello.
>>>>
>>>> 14 jan 2014 kl. 18:25 skrev Angelo Graziosi <angelo.graziosi <at> alice.it>:
>>>>
>>>>> Il 14/01/2014 17.07, Jan Djärv ha scritto:
>>>>>> Hello.
>>>>>>
>>>>>> 14 jan 2014 kl. 10:03 skrev Angelo Graziosi
>>>>>> <angelo.graziosi <at> alice.it>:
>>>>>>
>>>>>>> Should we open a new bug report for this?
>>>>>>>
>>>>>>
>>>>>> This report is fine. The omission to copy to PRIMARY looks
>>>>>> intended, because when text is read-only and cut acts like copy,
>>>>>> text is copied to PRIMARY.
>>>>>
>>>>> "intended" ? If it is intended, which is its usefulness?
>>>>>
>>>>> If one wants to move text from a place to another, this doesn't
>>>>> work using the mouse and the "cut" icon on the tool-bar...
>>>>>
>>>>> 1. select the text with mouse-1 (dragging over the text)
>>>>
>>>> This should already put the text in PRIMARY.
>>>>
>>>>> 2. click the "cut" icon on the tool-bar: the text is removed
>>>>> 3. now move the mouse pointer where you want the text to reappear
>>>>> 4. click mouse-2 to paste: nothing happens
>>>>>
>>>>> So, newly, which the usefulness of the above "intended" omission?
>>>>>
>>>>>
>>>>>> I wonder if there is some thought behind this we don't see.
>>>>>
>>>>> ah..
>>>>>
>>>>
>>>> Does it work if you use C-w instead of cut?
>>>
>>> C-w and C-y work as expected. C-y works also if used at step 4 above.
>>> It is with the mouse and tool-bar "cut" icon that it doesn't work..
>>
>> Ok, so if nobody remember why the current implementation is the way it
>> is in a couple of days or so, I'll fix this. C-w and cut should be
>> equivalent in this case.
>>
>> Jan D.
>>
>>
>>
>
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 16 Feb 2014 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 94 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.