* Re: Selection changes
@ 2010-07-16 1:00 Angelo Graziosi
2010-07-16 9:33 ` David De La Harpe Golden
2010-07-16 12:14 ` Angelo Graziosi
0 siblings, 2 replies; 14+ messages in thread
From: Angelo Graziosi @ 2010-07-16 1:00 UTC (permalink / raw)
To: emacs
Chong Yidong wrote:
> I believe that this change should be pretty much seamless, but let me
> know if there is any problems.
>
After these changes something is not working rightly with Copy/Paste.
Nor on GNU/Linux Kubuntu nor on Cygwin (both GTK build of trunk).
On Kubuntu often it paste the wrong test (both using C-y and mouse-2).
Only after playing with it some time, it seems to work.
On Cygwin, *usually*, using C-y is slower. If I select some test with
the mouse then, when I type C-y to paste it, I get 'Mark set' in the
minibuffer, and the text is pasted only after 5-10 second (the 'clock'
shows up). Using mouse-2, instead, seems to work fine.
Not always, one can reproduce the above exactly :(.
In both systems I have started Emacs with 'emacs -Q'.
Ciao,
Angelo.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Selection changes
2010-07-16 1:00 Selection changes Angelo Graziosi
@ 2010-07-16 9:33 ` David De La Harpe Golden
2010-07-17 23:49 ` Angelo Graziosi
2010-07-16 12:14 ` Angelo Graziosi
1 sibling, 1 reply; 14+ messages in thread
From: David De La Harpe Golden @ 2010-07-16 9:33 UTC (permalink / raw)
To: emacs; +Cc: Chong Yidong, Angelo Graziosi
On 16/07/10 02:00, Angelo Graziosi wrote:
> Nor on GNU/Linux Kubuntu nor on Cygwin (both GTK build of trunk).
>
> On Kubuntu often it paste the wrong test (both using C-y and mouse-2).
At the moment there is a known issue which will cause the wrong text to
be pasted in sometimes as per my other recent mail.
Just in case: also note C-y and mouse-2 should now be behaving more like
C-v and mouse-2 in non-emacs, it will require a more precise
reproduction recipe to determine if "wrong" is really-wrong or
correct-but-different-to-prior-defaults behaviour (or right now, the
known issue).
> On Cygwin, *usually*, using C-y is slower. If I select some test with
> the mouse then, when I type C-y to paste it, I get 'Mark set' in the
> minibuffer, and the text is pasted only after 5-10 second (the 'clock'
> shows up).
You mean you were - starting from "emacs -Q" - selecting some text with
the mouse, _without_ hitting C-w/M-w to cut/copy it, then successfully
inserting it with C-y?
If so, that shouldn't have worked at all (!).
...I see the reporter of #6637 appears to have been using cygwin's x11.
In this instance, the problem _might_ not be on emacs' side, especially
given the long pause you describe: cygwin's x11 server may be doing
something peculiar in its handling of x11 clipboard and/or primary,
especially since it probably tries to integrate somehow with the w32
native clipboard facilities.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Selection changes
2010-07-16 1:00 Selection changes Angelo Graziosi
2010-07-16 9:33 ` David De La Harpe Golden
@ 2010-07-16 12:14 ` Angelo Graziosi
1 sibling, 0 replies; 14+ messages in thread
From: Angelo Graziosi @ 2010-07-16 12:14 UTC (permalink / raw)
To: emacs; +Cc: tim.vanholder
On Cygwin, I can confirm all is desribed here [*]. Another recipe, for
Cygwin, is:
emacs -Q &
double click (mouse-1) on a word, for example 'buffer'. With the down
arrow go to the bottom of the buffer and then C-y: it takes about 4-5
second, and the mouse cursor switches to its "please wait" (clock).
On *Kubuntu 10.04* the things are a little different but wrong in any
case. Following the step described here[*], at point 4) it pastes casual
text, usually what is found in the clipboard. For example, adding the
step 0):
0) with your browser, copy a link address with mouse-3 | 'Copy link
address' menu item.
At step 4), it pastes the link, not the scartch buffer comment!
As described here [*], all seems to work as expected, if one adds
(setq x-select-clipboard-enable nil)
to .emacs file.
Ciao,
Angelo.
---
[*] http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-07/msg00429.html
Il 16/07/2010 3.00, Angelo Graziosi ha scritto:
> Chong Yidong wrote:
>> I believe that this change should be pretty much seamless, but let me
>> know if there is any problems.
>>
>
> After these changes something is not working rightly with Copy/Paste.
> Nor on GNU/Linux Kubuntu nor on Cygwin (both GTK build of trunk).
>
> On Kubuntu often it paste the wrong test (both using C-y and mouse-2).
> Only after playing with it some time, it seems to work.
>
> On Cygwin, *usually*, using C-y is slower. If I select some test with
> the mouse then, when I type C-y to paste it, I get 'Mark set' in the
> minibuffer, and the text is pasted only after 5-10 second (the 'clock'
> shows up). Using mouse-2, instead, seems to work fine.
>
> Not always, one can reproduce the above exactly :(.
>
> In both systems I have started Emacs with 'emacs -Q'.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Selection changes
2010-07-16 9:33 ` David De La Harpe Golden
@ 2010-07-17 23:49 ` Angelo Graziosi
2010-07-18 1:54 ` angle-bracket notation for keys (was: Selection changes) Drew Adams
2010-07-18 19:28 ` Selection changes David De La Harpe Golden
0 siblings, 2 replies; 14+ messages in thread
From: Angelo Graziosi @ 2010-07-17 23:49 UTC (permalink / raw)
To: David De La Harpe Golden; +Cc: Chong Yidong, emacs
On the way of changes...
In the menu 'Edit', I read:
[...]
Cut C-w
Copy <C-insertchar>
[...]
If I have understood what means 'insertchar', I would suggest:
'Copy C-INS'
it looks better, I think, or the more symmetric
'Copy M-w'
Ciao,
Angelo.
PS. '<...-insertchar>' is very ugly and... unattractive!
^ permalink raw reply [flat|nested] 14+ messages in thread
* angle-bracket notation for keys (was: Selection changes)
2010-07-17 23:49 ` Angelo Graziosi
@ 2010-07-18 1:54 ` Drew Adams
2010-07-18 2:07 ` angle-bracket notation for keys Miles Bader
` (2 more replies)
2010-07-18 19:28 ` Selection changes David De La Harpe Golden
1 sibling, 3 replies; 14+ messages in thread
From: Drew Adams @ 2010-07-18 1:54 UTC (permalink / raw)
To: 'Angelo Graziosi', 'David De La Harpe Golden'
Cc: 'Chong Yidong', 'emacs'
> '<...-insertchar>' is very ugly and... unattractive!
And unnecessary. `<S-tab>' etc. used to (sometimes) be written `S-tab' or
`S-TAB'. But, sigh, function keys have always been written in Emacs (e.g. in
Info) using angle brackets, IIRC. Even Emacs 20's Info uses `<F1>' to represent
the `f1' key, though it at least writes `f1' or f1 in *Help*. Emacs 22 was
"improved" to make this consistent - consistently ugly.
The angle-bracket notation is unnecessary because multi-character key names such
as `delete' could be written just like that. `delete', `C-delete', `C-delete
insert', `C-insert M-delete' etc. This is an unambiguous notation, but we don't
use it, unfortunately.
We do sometimes represent user input by separating keys in a sequence with
whitespace, e.g. in instructions: "Type `h e l l o'". But we are not consistent
in that, writing sometimes "Type `hello'" to also mean type those five keys.
And we still treat some keys differently, using angle brackets: "Type `hello
<S-tab>'" (where the space is not necessary but is typically present).
There is no ambiguity between `delete' and `d e l e t e', given consistent use
of the simple convention that whitespace separates keys in a sequence. The
former is a single key named "delete"; that latter is a sequence of six keys.
It doesn't matter whether it's a new function key that you never heard of, `foo'
or one such as `delete' that is well-known. The convention is crystal clear and
foolproof. You know that `foo' means a key and `f o o' means a sequence of
three keys.
Even when multi-character key names are used in representations of user input
(e.g. instructions) there is no problem: "Type `C-insert h e l l o C-RET'".
Whitespace can be used to separate keystrokes this way because we have `SPC' to
represent hitting the space bar: "Type `d o g , SPC c a t'".
And sequences of many keys like that are relatively rare in the doc anyway, so
the admittedly less readable "Type `h e l l o'" (vs "Type `hello'") would not be
a big deal in practice. And it's not just about the doc (Info). It's also
about the UI: *Help*, messages, etc. It's about the way Emacs talks about
itself.
If we used this simpler convention consistently, we would gain in clarity. And
we would reduce the number of extra chars that just represent noise: <> plus a
space vs just a space. `<f1> <S-tab> <C-delete>' vs `f1 S-tab C-delete'. (A
no-brainer, wouldn't you say?)
Not to mention that all keys would be treated the same way - there is nothing
special about `f1' and `TAB' vs `a' and `C-a'. There's no reason to write
`<f1>' and `<TAB>' but also write `a' and `C-a' (not `<a>' and `<C-a>'). The
angle brackets serve no useful purpose. If they are noise in the case of
`<C-a>' then they are just as much noise in the case of `<f1>'.
And even though angle brackets separate keys (presumably that's their raison
d'etre), they are so ugly and unclear that we typically use whitespace as well!
We often write `<a> b <c>', not `<a>b<c>', even though the latter is also
unambiguous. Why? Because of the ugliness factor. Because angle brackets are
not very readable.
Our convention uses at least two chars, and more often three, to separate two
keys - even when some of those key representations use angle brackets: `<a> <b>'
(3 chars: >, SPC, <). This is just not necessary.
Anyway, no, I do not really intend to open this discussion again. My suggestion
about this was rejected long ago. I just wanted to say that (a) yes, what we
use is ugly, (b) it does not have to be that ugly, and (c) we've been around the
block on this question before.
If you are interested, see these old threads, which deal with the question in
some detail (examples, arguments, etc.):
http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg00142.html
http://lists.gnu.org/archive/html/emacs-devel/2006-09/msg00732.html
http://lists.gnu.org/archive/html/emacs-devel/2006-09/msg00984.html
http://lists.gnu.org/archive/html/emacs-devel/2006-10/msg00213.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: angle-bracket notation for keys
2010-07-18 1:54 ` angle-bracket notation for keys (was: Selection changes) Drew Adams
@ 2010-07-18 2:07 ` Miles Bader
2010-07-18 3:05 ` angle-bracket notation for keys (was: Selection changes) Eli Zaretskii
2010-07-18 9:51 ` Angelo Graziosi
2 siblings, 0 replies; 14+ messages in thread
From: Miles Bader @ 2010-07-18 2:07 UTC (permalink / raw)
To: Drew Adams
Cc: 'Chong Yidong', 'David De La Harpe Golden',
'emacs', 'Angelo Graziosi'
FWIW, I agree with you, the <> notation is ugly and seems unnecessary.
-Miles
--
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
'Allahu akbar!' are, in spirit, not actually all that different."
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: angle-bracket notation for keys (was: Selection changes)
2010-07-18 1:54 ` angle-bracket notation for keys (was: Selection changes) Drew Adams
2010-07-18 2:07 ` angle-bracket notation for keys Miles Bader
@ 2010-07-18 3:05 ` Eli Zaretskii
2010-07-18 5:42 ` Drew Adams
2010-07-18 9:51 ` Angelo Graziosi
2 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2010-07-18 3:05 UTC (permalink / raw)
To: Drew Adams; +Cc: cyd, david, emacs-devel, angelo.graziosi
> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 17 Jul 2010 18:54:28 -0700
> Cc: 'Chong Yidong' <cyd@stupidchicken.com>, 'emacs' <emacs-devel@gnu.org>
>
> > '<...-insertchar>' is very ugly and... unattractive!
<FOO> is what makeinfo produces from @key{FOO}. The purpose of @key
is to distinguish between a single keypress and typing the keys F, O,
and O in that order. In the printed manual, @key produces a picture
of a key with a label.
If you want to suggest a change in what @key produces in the on-line
Info manual, this isn't the right forum. You need to write to
bug-texinfo@gnu.org.
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: angle-bracket notation for keys (was: Selection changes)
2010-07-18 3:05 ` angle-bracket notation for keys (was: Selection changes) Eli Zaretskii
@ 2010-07-18 5:42 ` Drew Adams
2010-07-18 17:21 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Drew Adams @ 2010-07-18 5:42 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: cyd, david, emacs-devel, angelo.graziosi
> > > '<...-insertchar>' is very ugly and... unattractive!
>
> <FOO> is what makeinfo produces from @key{FOO}. The purpose of @key
> is to distinguish between a single keypress and typing the keys F, O,
> and O in that order. In the printed manual, @key produces a picture
> of a key with a label.
>
> If you want to suggest a change in what @key produces in the on-line
> Info manual, this isn't the right forum. You need to write to
> bug-texinfo@gnu.org.
I believe this was all discussed in those old threads, and I really do not wish
to reopen the discussion - that wasn't my purpose, as I said. If others want to
pursue it, fine - I've already summarized what I think about it. If there's
another tour around the block I'll sit this one out.
To be clear, however, I'm not really concerned about what appears in the printed
manual. My concern (really, my _only_ concern wrt this question) is the UI and
online doc (Info). I made that clear before, as well.
And I have nothing to say about the tools we use to create Info or the printed
manual.
My point was only about how Emacs talks about itself when you use it: help,
messages, Info. The format we use is unnecessarily ugly and noisy. A better
notation is possible (more than one, no doubt). That's all.
Whether moving to such a better notation would be difficult in terms of tools
used I cannot say. I'm not interested in pursuing such tool changes, myself.
If others want to do that, and if bug-texinfo@gnu.org is the place to do it, be
my guest.
To repeat, however, it is not only, or even primarily, about the manual, even
the online one (Info). The UI is not created by makeinfo, AFAIK. We've decided
to use angle brackets for named keys throughout the UI. The Lisp functions that
we've written intentionally return the angle-bracket syntax: `<mouse-2>' vs
`mouse-2'. That's not the fault of makeinfo. See the old threads for info
about some of those functions.
The result gets an `A' for consistency, but an `<<F>>' for readability, IMO.
FWIW, I use Emacs 20 quite often (testing libraries etc.), and even though its
use of key notation is inconsistent (`<F1>' and `TAB') it is far better than the
consistent interface of Emacs 22+ - easier on the eyes and brain (parsing).
Fewer unnecessary brackets gives you a welcome break.
You know the tired joke about LISP meaning Lots of Irritating, Superfluous
Parentheses. Well, they aren't superfluous, but our angle brackets surely are.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: angle-bracket notation for keys
2010-07-18 1:54 ` angle-bracket notation for keys (was: Selection changes) Drew Adams
2010-07-18 2:07 ` angle-bracket notation for keys Miles Bader
2010-07-18 3:05 ` angle-bracket notation for keys (was: Selection changes) Eli Zaretskii
@ 2010-07-18 9:51 ` Angelo Graziosi
2 siblings, 0 replies; 14+ messages in thread
From: Angelo Graziosi @ 2010-07-18 9:51 UTC (permalink / raw)
To: Drew Adams
Cc: 'Chong Yidong', 'emacs',
'David De La Harpe Golden'
Il 18/07/2010 3.54, Drew Adams ha scritto:
> [...]
> And unnecessary. `<S-tab>' etc. used to (sometimes) be written `S-tab' or
> `S-TAB'. But, sigh, function keys have always been written in Emacs (e.g. in
> Info) using angle brackets, IIRC. Even Emacs 20's Info uses `<F1>' to represent
> the `f1' key, though it at least writes `f1' or f1 in *Help*. Emacs 22 was
> "improved" to make this consistent - consistently ugly.
> [...]
C-INS
C-DEL
C-LEFT
C-RIGHT
F1-...
S-TAB
etc. etc.
Since *you*, developers, have spent much time discussing on the
'attractiveness' of Emacs, this would be a simple step toward that :-).
Ciao,
Angelo.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: angle-bracket notation for keys (was: Selection changes)
2010-07-18 5:42 ` Drew Adams
@ 2010-07-18 17:21 ` Eli Zaretskii
2010-07-18 19:15 ` Drew Adams
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2010-07-18 17:21 UTC (permalink / raw)
To: Drew Adams; +Cc: cyd, david, emacs-devel, angelo.graziosi
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <angelo.graziosi@alice.it>, <david@harpegolden.net>,
> <cyd@stupidchicken.com>, <emacs-devel@gnu.org>
> Date: Sat, 17 Jul 2010 22:42:26 -0700
>
> > > > '<...-insertchar>' is very ugly and... unattractive!
> >
> > <FOO> is what makeinfo produces from @key{FOO}. The purpose of @key
> > is to distinguish between a single keypress and typing the keys F, O,
> > and O in that order. In the printed manual, @key produces a picture
> > of a key with a label.
> >
> > If you want to suggest a change in what @key produces in the on-line
> > Info manual, this isn't the right forum. You need to write to
> > bug-texinfo@gnu.org.
>
> I believe this was all discussed in those old threads, and I really do not wish
> to reopen the discussion
<Shrug> who can remember all those discussions?
> To be clear, however, I'm not really concerned about what appears in the printed
> manual. My concern (really, my _only_ concern wrt this question) is the UI and
> online doc (Info). I made that clear before, as well.
Consistency with the manual is important, IMO.
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: angle-bracket notation for keys (was: Selection changes)
2010-07-18 17:21 ` Eli Zaretskii
@ 2010-07-18 19:15 ` Drew Adams
2010-07-18 22:05 ` angle-bracket notation for keys Harald Hanche-Olsen
0 siblings, 1 reply; 14+ messages in thread
From: Drew Adams @ 2010-07-18 19:15 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: cyd, david, emacs-devel, angelo.graziosi
> > I believe this was all discussed in those old threads
>
> <Shrug> who can remember all those discussions?
`Shrug', yourself. ;-)
I provided links to them. Who is interested? No sense repeating everything
here/now, even in the case where someone might actually be interested.
> > To be clear, however, I'm not really concerned about what
> > appears in the printed manual. My concern (really, my
> > _only_ concern wrt this question) is the UI and
> > online doc (Info). I made that clear before, as well.
>
> Consistency with the [printed] manual is important, IMO.
It is important, but not all-important.
And the printed manual's notation for keys is anyway _inconsistent_ with the
UI's notation. As you pointed out, the printed manual uses little icons for key
names - what you called "a picture of a key with a label". Not so, the UI.
What is most important is clarity. After that, consistency within each
medium/context is important (it aids clarity). Consistency across all
media/contexts (print, Info, *Help*, messages,...) can be helpful but less
important than the previous.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Selection changes
2010-07-17 23:49 ` Angelo Graziosi
2010-07-18 1:54 ` angle-bracket notation for keys (was: Selection changes) Drew Adams
@ 2010-07-18 19:28 ` David De La Harpe Golden
2010-07-18 22:39 ` Angelo Graziosi
1 sibling, 1 reply; 14+ messages in thread
From: David De La Harpe Golden @ 2010-07-18 19:28 UTC (permalink / raw)
To: Angelo Graziosi, Emacs developers
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
On 18/07/10 00:49, Angelo Graziosi wrote:
> On the way of changes...
>
> In the menu 'Edit', I read:
>
> [...]
> Cut C-w
> Copy <C-insertchar>
> [...]
>
Sorry, you mean out of box on "emacs -Q" ?
On what platform and emacs version?
C-insertchar seems unlikely, though maybe you mean
with cua-mode enabled (even then I don't get it, though
nor does it show C-x/C-c, though it does change paste to C-v.
Hmm.)
Cut C-w
Copy M-w
Paste C-y
is in fact what I see out of box, as attached.
[Of course maybe it was fixed after your report]
[-- Attachment #2: emacs_edit_menu1.png --]
[-- Type: image/png, Size: 24614 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: angle-bracket notation for keys
2010-07-18 19:15 ` Drew Adams
@ 2010-07-18 22:05 ` Harald Hanche-Olsen
0 siblings, 0 replies; 14+ messages in thread
From: Harald Hanche-Olsen @ 2010-07-18 22:05 UTC (permalink / raw)
To: emacs-devel
How hard would it be to make keys show like ⟨this⟩ instead, with a
fallback to <this> on ASCII terminals and the like?
- Harald
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Selection changes
2010-07-18 19:28 ` Selection changes David De La Harpe Golden
@ 2010-07-18 22:39 ` Angelo Graziosi
0 siblings, 0 replies; 14+ messages in thread
From: Angelo Graziosi @ 2010-07-18 22:39 UTC (permalink / raw)
To: David De La Harpe Golden; +Cc: Emacs developers
Il 18/07/2010 21.28, David De La Harpe Golden ha scritto:
> On 18/07/10 00:49, Angelo Graziosi wrote:
>> On the way of changes...
>>
>> In the menu 'Edit', I read:
>>
>> [...]
>> Cut C-w
>> Copy <C-insertchar>
>> [...]
>>
>
> Sorry, you mean out of box on "emacs -Q" ?
> On what platform and emacs version?
It occurs on Kubuntu 10.04 and Cygwin, *WITH*
(pc-selection-mode t)
in ~/.emacs file :(.
Anyway, I do not see the reasons for which it uses 'Copy <C-insertchar>'
and not, the better, 'Copy C-INS' :-O
Usually, on keyboard, I have find: Home, End, PagUp, PagDown and _INS_
keys, not 'insertchar'.
As I said, I find '<>', 'insertchar' etc. very ugly!
Omitting (pc-selection-mode t) from ~/.emacs works as you
> Cut C-w
> Copy M-w
> Paste C-y
Ciao,
Angelo.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-07-18 22:39 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-16 1:00 Selection changes Angelo Graziosi
2010-07-16 9:33 ` David De La Harpe Golden
2010-07-17 23:49 ` Angelo Graziosi
2010-07-18 1:54 ` angle-bracket notation for keys (was: Selection changes) Drew Adams
2010-07-18 2:07 ` angle-bracket notation for keys Miles Bader
2010-07-18 3:05 ` angle-bracket notation for keys (was: Selection changes) Eli Zaretskii
2010-07-18 5:42 ` Drew Adams
2010-07-18 17:21 ` Eli Zaretskii
2010-07-18 19:15 ` Drew Adams
2010-07-18 22:05 ` angle-bracket notation for keys Harald Hanche-Olsen
2010-07-18 9:51 ` Angelo Graziosi
2010-07-18 19:28 ` Selection changes David De La Harpe Golden
2010-07-18 22:39 ` Angelo Graziosi
2010-07-16 12:14 ` Angelo Graziosi
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.