Re: Selection changes

Re: Selection changes

[Angelo Graziosi]

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.

Re: Selection changes

[David De La Harpe Golden]

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.

Re: Selection changes

[Angelo Graziosi]

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'.

Re: Selection changes

[Angelo Graziosi]

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!

angle-bracket notation for keys (was: Selection changes)

[Drew Adams]

> '<...-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

Re: angle-bracket notation for keys

[Miles Bader]

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."

Re: angle-bracket notation for keys (was: Selection changes)

[Eli Zaretskii]

> 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.

RE: angle-bracket notation for keys (was: Selection changes)

[Drew Adams]

> > > '<...-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.

Re: angle-bracket notation for keys

[Angelo Graziosi]

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.

Re: angle-bracket notation for keys (was: Selection changes)

[Eli Zaretskii]

> 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.

RE: angle-bracket notation for keys (was: Selection changes)

[Drew Adams]

> > 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.

Re: Selection changes

[David De La Harpe Golden]

[-- 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 --]

Re: angle-bracket notation for keys

[Harald Hanche-Olsen]

How hard would it be to make keys show like ⟨this⟩ instead, with a
fallback to <this> on ASCII terminals and the like?

- Harald

Re: Selection changes

[Angelo Graziosi]

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.