Mouse support does not work

Mouse support does not work

[Aaron Meurer]

Hi.

I can't get mouse support to work in emacs.  I've tried various
things, but neither scrolling nor any kind of clicking or selection
does anything.  I'm using iTerm2 in Mac OS X. I believe it should be
supported, as mouse support works perfectly in vim.  I've tried M-x
mouse-wheel-mode, M-x mouse-sel-mode, and I've tried putting all kinds
of things in .emacs as suggested by various sites, but nothing has
worked.

Does anyone have any suggestions?  I am brand new to emacs, so I'm
afraid I can't give more useful information, though I'd be perfectly
willing to try various things in order to debug and fix the problem.

I tried emacs 22, 23, and I've even compiled the version from the
master branch of the git mirror, and none of them worked.

Here's my .emacs, if it helps:
https://github.com/asmeurer/dotfiles/blob/master/.emacs

Aaron Meurer

Re: Mouse support does not work

[Tassilo Horn]

Aaron Meurer <asmeurer@gmail.com> writes:

> I can't get mouse support to work in emacs.  I've tried various
> things, but neither scrolling nor any kind of clicking or selection
> does anything.  I'm using iTerm2 in Mac OS X.

I'm not exactly sure if mouse commands are supposed to work in terminal
frames.  For me, mouse commands in an emacs inside an xterm have no
effect at all.  Inside a GNOME terminal, the scroll wheel creates <up>
and <down> events (those are actually events usually created by the
arrow keys), so I can at least scroll a bit.  But clicking inside the
terminal doesn't produce an event that's passed to emacs, but it seems
to be captured by the terminal.

That said, I have the same behavior with vim...

Bye,
Tassilo

Re: Mouse support does not work

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Tue, 10 Jan 2012 18:24:04 +0100
> 
> I'm not exactly sure if mouse commands are supposed to work in terminal
> frames.

It is, if asked nicely ;-)

> For me, mouse commands in an emacs inside an xterm have no effect at
> all.

Not even if you load xt-mouse?

But this doesn't necessarily say anything about iTerm2, whatever that
is.  If no one wrote code for supporting mouse on that terminal, like
we have for xterm and for GPM, then no, it won't work.

Re: Mouse support does not work

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> For me, mouse commands in an emacs inside an xterm have no effect at
>> all.
>
> Not even if you load xt-mouse?

Oh, nice.  But it seems loading is not enough but you have to enable
xterm-mouse-mode, too.

  M-: (require 'xt-mouse) RET
  M-x xterm-mouse-mode RET

Then, mouse scrolling, clicking, and even selection work fine in both
xterm as well as GNOME terminal.

And of course, it's also documented in the fine manual. :-)

,----[ (info "(emacs)Text-Only Mouse") ]
| Some text-only terminals support mouse clicks in the terminal window.
| 
|    In a terminal emulator which is compatible with `xterm', you can use
| `M-x xterm-mouse-mode' to give Emacs control over simple uses of the
| mouse--basically, only non-modified single clicks are supported.  The
| normal `xterm' mouse functionality for such clicks is still available
| by holding down the `SHIFT' key when you press the mouse button.  Xterm
| Mouse mode is a global minor mode (*note Minor Modes::).  Repeating the
| command turns the mode off again.
| 
|    In the console on GNU/Linux, you can use `M-x gpm-mouse-mode' to
| enable mouse support.  You must have the gpm server installed and
| running on your system in order for this to work.
`----


> But this doesn't necessarily say anything about iTerm2, whatever that
> is.  If no one wrote code for supporting mouse on that terminal, like
> we have for xterm and for GPM, then no, it won't work.

BTW, while GNOME terminal works just fine, using emacs in an xterm is a
huge mess for me.  C-h generates a DEL, and M-<x> is just x for any key
<x>, and probably there's more...

Bye,
Tassilo

Re: Mouse support does not work

[Peter Dyballa]

Am 10.1.2012 um 22:00 schrieb Tassilo Horn:

> BTW, while GNOME terminal works just fine, using emacs in an xterm is a
> huge mess for me.  C-h generates a DEL, and M-<x> is just x for any key
> <x>, and probably there's more...

Substitute C-h with <f1>!

--
Mit friedvollen Grüßen

  Pete

If all else fails read the instructions.
				- Donald Knuth

Re: Mouse support does not work

[Tassilo Horn]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

Hi Peter,

>> BTW, while GNOME terminal works just fine, using emacs in an xterm is
>> a huge mess for me.  C-h generates a DEL, and M-<x> is just x for any
>> key <x>, and probably there's more...
>
> Substitute C-h with <f1>!

Yes, sure, and M-<x> with ESC <x>.  My question is not how I can work
around that, but if that's an xterm limitation one has to accept.

Bye,
Tassilo

Re: Mouse support does not work

[Peter Dyballa]

Am 11.1.2012 um 09:04 schrieb Tassilo Horn:

> My question is not how I can work
> around that, but if that's an xterm limitation one has to accept.

I think I figured it out! And it's not an xterm limitation but a GNU Emacs default.

With stty you need to make C-h and BS different in xterm etc., for example with

	stty erase '^?'

and in GNU Emacs perform

	(normal-erase-is-backspace-mode 0)

This will inhibit the default behaviour of remapping the two keys. The info node "59.1 If <DEL> Fails to Delete" seems to describe this. Even <ESC> C-h and <ESC> <BS> seem to be distinct.

--
Mit friedvollen Grüßen

  Pete

Im Leben lernt der Mensch als erstes das Gehen und Sprechen.
Später lernt er still zu sitzen und den Mund zu halten.

Re: Mouse support does not work

[Tassilo Horn]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

Hi Peter,

>> My question is not how I can work around that, but if that's an xterm
>> limitation one has to accept.
>
> I think I figured it out! And it's not an xterm limitation but a GNU
> Emacs default.
>
> With stty you need to make C-h and BS different in xterm etc., for
> example with
>
> 	stty erase '^?'
>
> and in GNU Emacs perform
>
> 	(normal-erase-is-backspace-mode 0)

After doing those two, now DEL behaves as C-h, and C-h as DEL.

With only the latter, both act like C-h.  Ditto with only the former.
Hm, I think that was different when I just did "stty erase '^?'" the
first time.  Is that setting persisted across xterm sessions?

> This will inhibit the default behaviour of remapping the two keys. The
> info node "59.1 If <DEL> Fails to Delete" seems to describe this. Even
> <ESC> C-h and <ESC> <BS> seem to be distinct.

Thanks for the pointer.

Bye,
Tassilo

Re: Mouse support does not work

[Peter Dyballa]

Am 12.1.2012 um 08:22 schrieb Tassilo Horn:

> Hm, I think that was different when I just did "stty erase '^?'" the
> first time.  Is that setting persisted across xterm sessions?

No, it has to be invoked in each xterm session, so put that command into the shell's RC file. It needs to be executed even then when the shell is not the login shell.

Interestingly uxterm seems to be immune! In its menu it has "Backarrow Key (BS/DEL)" activated. And this one is the culprit, this setting makes DEL and BS equal. (Maybe one day I'll find which X resource is responsible.) In xterm this resource has no effect.

--
Mit friedvollen Grüßen

  Pete

Stop-and-go:
	Bezeichnung für die vergeblichen Bemühungen der Outomobilistinnen, durch "Stop" schneller zu sein als die Fußgängerinnen durch "Go."

Re: Mouse support does not work

[Tassilo Horn]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

>> Hm, I think that was different when I just did "stty erase '^?'" the
>> first time.  Is that setting persisted across xterm sessions?
>
> No, it has to be invoked in each xterm session, so put that command
> into the shell's RC file. It needs to be executed even then when the
> shell is not the login shell.

Really strange.  I restarted my xterm many times, but I'm pretty sure I
had a different behavior in the first one before I eventually invoked
"stty erase '^?'"...

> Interestingly uxterm seems to be immune!

Not for me.  Both stty and toggeling normal-erase-is-backspace (or both)
make that either both DEL and C-h delete or activate the help menu...

Anyway, there are many good alternatives to xterm (urxvt, GNOME
Terminal, XFCE Terminal, KDE Konsole, ...).

Bye,
Tassilo

Re: Mouse support does not work

[Peter Dyballa]

Am 12.1.2012 um 10:56 schrieb Tassilo Horn:

> Anyway, there are many good alternatives to xterm (urxvt, GNOME
> Terminal, XFCE Terminal, KDE Konsole, ...).

And Apple's Terminal application ... (I tried iTerm2 in the meantime. It has issues with copy&paste – not good for writing a thesis!)

--
Mit friedvollen Grüßen

  Pete

Wer nichts zu verbergen hat, hat schon alles verloren.
				(Juli Zeh)

Re: Mouse support does not work

[Peter Dyballa]

Am 10.1.2012 um 19:29 schrieb Eli Zaretskii:

> iTerm2, whatever that is

Kind of an xterm variant which is a native Mac OS X application that does not need any other windowing environment: http://www.iterm2.com.

--
Greetings

  Pete

Eat the rich – the poor are tough and stringy.

Re: Mouse support does not work

[Peter Dyballa]

Am 10.1.2012 um 10:18 schrieb Aaron Meurer:

> I can't get mouse support to work in emacs.  I've tried various
> things, but neither scrolling nor any kind of clicking or selection
> does anything.  I'm using iTerm2 in Mac OS X. I believe it should be
> supported, as mouse support works perfectly in vim.  I've tried M-x
> mouse-wheel-mode, M-x mouse-sel-mode, and I've tried putting all kinds
> of things in .emacs as suggested by various sites, but nothing has
> worked.

For me not even scrolling in vim/vi works... (could you describe how you achieve this?)

The function mouse-wheel-mode is a toggle. If it's off, then you can type C-h k and then operate the mouse wheel or scroll via the trackpad. In the echo-area ("mini-buffer") you can see that GNU Emacs reports having received multiple <mouse-4> or <mouse-5> events. The function mouse-sel-mode is also a toggle – which I think is not very useful (I have it set off).

In GNU Emacs you have to load the xt-mouse "package":

	(require 'xt-mouse)

and then switch that mode on:

	(xterm-mouse-mode)

It will allow you to select windows (buffers) with the mouse cursor by clicking into one and clicking into the menu bar will show you in a buffer the contents of the selected menu and enable you to make a choice. Clicking onto a file name in dired-mode will open that file for editing in a new window (buffer). GNU Emacs will also receive mouse scroll events. In my rather dumb setup the <mouse-4> and <mouse-5> events are mot bound to any function so that I cannot scroll... (and also in a default setup they're not bound to anything)


This works in xterm – but not in Apple's Terminal. Hopefully if works in iTerm2!

--
Greetings

  Pete

War springs from unseen and generally insignificant causes.
				– Anonymous

Re: Mouse support does not work

[Aaron Meurer]

On Tue, Jan 10, 2012 at 2:29 PM, Peter Dyballa <Peter_Dyballa@web.de> wrote:
>
> Am 10.1.2012 um 10:18 schrieb Aaron Meurer:
>
>> I can't get mouse support to work in emacs.  I've tried various
>> things, but neither scrolling nor any kind of clicking or selection
>> does anything.  I'm using iTerm2 in Mac OS X. I believe it should be
>> supported, as mouse support works perfectly in vim.  I've tried M-x
>> mouse-wheel-mode, M-x mouse-sel-mode, and I've tried putting all kinds
>> of things in .emacs as suggested by various sites, but nothing has
>> worked.
>
> For me not even scrolling in vim/vi works... (could you describe how you achieve this?)

You have to enable it with `set mouse=a`.  But the default .vimrc from
$VIMRUNTIME/vimrc_example.vim enables it.

>
> The function mouse-wheel-mode is a toggle. If it's off, then you can type C-h k and then operate the mouse wheel or scroll via the trackpad. In the echo-area ("mini-buffer") you can see that GNU Emacs reports having received multiple <mouse-4> or <mouse-5> events. The function mouse-sel-mode is also a toggle – which I think is not very useful (I have it set off).
>
> In GNU Emacs you have to load the xt-mouse "package":
>
>        (require 'xt-mouse)
>
> and then switch that mode on:
>
>        (xterm-mouse-mode)
>

Awesome!  That did it. I can scroll, click to move the cursor, and
select.  Right clicking selects from the cursor position (I guess it's
supposed to do that?).  Middle clicking (iTerm2 lets you set three
finger click to middle click) doesn't do anything, though that's
probably because it isn't set to do anything in my tests.  How can I
test this?

Now that this is working, I have some more questions, if you don't mind:

- I have this setting, from customize:

'(mouse-wheel-scroll-amount (quote (1)))

which is supposed to make scrolling go one line at a time.  But it
goes at least two lines at a time. If I change the 1 to 2, it scrolls
by four lines at a time, and so on.  It won't let me enter 0.5.

- I have momentum scrolling enabled, which means that I can "flick"
the scroll, and it will go aways.  But emacs beeps when it is at the
end and cannot scroll any more, which is really annoying in
conjunction with this, as it beeps several times when I "flick" past
the bottom or top.  Is there a way to disable this beeping?

- Is there a way to make scrolling not kill an I-search?

> It will allow you to select windows (buffers) with the mouse cursor by clicking into one and clicking into the menu bar will show you in a buffer the contents of the selected menu and enable you to make a choice. Clicking onto a file name in dired-mode will open that file for editing in a new window (buffer). GNU Emacs will also receive mouse scroll events. In my rather dumb setup the <mouse-4> and <mouse-5> events are mot bound to any function so that I cannot scroll... (and also in a default setup they're not bound to anything)
>
>
> This works in xterm – but not in Apple's Terminal. Hopefully if works in iTerm2!

You can enable it in Apple's Terminal with mouseterm
(https://github.com/brodie/mouseterm).  I just tested it in emacs, and
it works there too, though the selection isn't as good as in iTerm2
(it doesn't show the selection until after you let go of the mouse).
It's kind of a hack (it uses SIMBL), so use at your own risk (and
anyway, this means that you have to reinstall after each OS update).

Now if I can just get scrolling to work in less...

Aaron Meurer

>
> --
> Greetings
>
>  Pete
>
> War springs from unseen and generally insignificant causes.
>                                – Anonymous
>

Re: Mouse support does not work

[Peter Dyballa]

Am 10.1.2012 um 23:06 schrieb Aaron Meurer:

> Middle clicking (iTerm2 lets you set three
> finger click to middle click) doesn't do anything, though that's
> probably because it isn't set to do anything in my tests.  How can I
> test this?

Check it with: C-h k <some mouse event>.

This will open a *Help* buffer with some explanations and possibly hyper-links. I think middle click or mouse-2 is context sensitive and gives different options in different (buffer) modes. Just try it with C-h k in *shell*, *scratch*, other buffers!

> 
> Now that this is working, I have some more questions, if you don't mind:
> 
> - I have this setting, from customize:
> 
> '(mouse-wheel-scroll-amount (quote (1)))
> 
> which is supposed to make scrolling go one line at a time.  But it
> goes at least two lines at a time. If I change the 1 to 2, it scrolls
> by four lines at a time, and so on.  It won't let me enter 0.5.

It might slow down by pressing the Shift button on the keyboard. This works in the X client variant fine, while the NS variant fails to understand this. (The NS variant is a native Mac OS X application using Quartz.) The "AppKit Emacs", a still called experimental hack, is very sane in this respect: very good scroll speed, including "momentum" and no complaints when overshoot, pressing Shift accelerates speed. It is also a native Quartz client, using almost no "external" libraries, i.e., it's something like 100 % Mac OS X, best when you have to use non-Latin scripts.

> 
> - I have momentum scrolling enabled, which means that I can "flick"
> the scroll, and it will go aways.  But emacs beeps when it is at the
> end and cannot scroll any more, which is really annoying in
> conjunction with this, as it beeps several times when I "flick" past
> the bottom or top.  Is there a way to disable this beeping?

Use the above mentioned "AppKit Emacs" – you just need to compile and install it yourself. In the coming weeks we might experience the release of GNU Emacs 24.1 and later of "AppKit Emacs" 24.1 – right now it is based on GNU Emacs 23.3b, the current release of GNU Emacs.

> 
> - Is there a way to make scrolling not kill an I-search?

I don't know! Why do you want to scroll in that "mode"? Because you want to centre the found text at the bottom? Then try C-l! Or press C-l twice. (Or three times...)

--
Greetings

  Pete

I love deadlines. I love the whooshing noise they make as they go by.
				– Douglas Adams

Re: Mouse support does not work

[Aaron Meurer]

On Tue, Jan 10, 2012 at 3:31 PM, Peter Dyballa <Peter_Dyballa@web.de> wrote:
>
> Am 10.1.2012 um 23:06 schrieb Aaron Meurer:
>
>> Middle clicking (iTerm2 lets you set three
>> finger click to middle click) doesn't do anything, though that's
>> probably because it isn't set to do anything in my tests.  How can I
>> test this?
>
> Check it with: C-h k <some mouse event>.
>
> This will open a *Help* buffer with some explanations and possibly hyper-links. I think middle click or mouse-2 is context sensitive and gives different options in different (buffer) modes. Just try it with C-h k in *shell*, *scratch*, other buffers!
>
>>
>> Now that this is working, I have some more questions, if you don't mind:
>>
>> - I have this setting, from customize:
>>
>> '(mouse-wheel-scroll-amount (quote (1)))
>>
>> which is supposed to make scrolling go one line at a time.  But it
>> goes at least two lines at a time. If I change the 1 to 2, it scrolls
>> by four lines at a time, and so on.  It won't let me enter 0.5.
>
> It might slow down by pressing the Shift button on the keyboard. This works in the X client variant fine, while the NS variant fails to understand this. (The NS variant is a native Mac OS X application using Quartz.) The "AppKit Emacs", a still called experimental hack, is very sane in this respect: very good scroll speed, including "momentum" and no complaints when overshoot, pressing Shift accelerates speed. It is also a native Quartz client, using almost no "external" libraries, i.e., it's something like 100 % Mac OS X, best when you have to use non-Latin scripts.

Shift scroll just disables scroll reporting in iTerm2.  Maybe I can
make it report Shift-mouse4/5.  I'll have to look into it.

Even so, based on customize, you can also set how many lines it
scrolls with Shift, and this is also 1 (or it was, but I removed it
because it's pointless).  So I don't actually have much hope for it.
But I'll see if I can get it to work.

I actually don't want to use a GUI version of emacs, for a few reasons:

First, no, it is not 100% Mac OS X.  Aquamacs comes closer, but even
that feels off. For example, neither use Lion scroll bars.  And in M-x
customize, instead of Cocoa controls, you have grey box controls.  I
want my Mac OS X applications to feel like Mac OS X and my terminal
applications to feel like the terminal.  emacs feels like the terminal
(this is kind of fundamental).

Second, starting a gui takes too long.  I want my editor in no more
than a few seconds.  This was one of the motivations to switching to a
command line editor in the first place.  This is especially important
for emacs, as it doesn't seem to work with type-ahead (unlike vim).

Third, now that I have mouse reporting working, I don't really need it.

I might use it when editing LaTeX so I can use the preview mode from
AUCTeX, but other than that, I'd like to stick to the terminal.  Other
than the fact that you're stuck with a mono-spaced font, it's not that
bad (can the GUI version of emacs use a non-monospaced font, btw?).

>
>>
>> - I have momentum scrolling enabled, which means that I can "flick"
>> the scroll, and it will go aways.  But emacs beeps when it is at the
>> end and cannot scroll any more, which is really annoying in
>> conjunction with this, as it beeps several times when I "flick" past
>> the bottom or top.  Is there a way to disable this beeping?
>
> Use the above mentioned "AppKit Emacs" – you just need to compile and install it yourself. In the coming weeks we might experience the release of GNU Emacs 24.1 and later of "AppKit Emacs" 24.1 – right now it is based on GNU Emacs 23.3b, the current release of GNU Emacs.
>
>>
>> - Is there a way to make scrolling not kill an I-search?
>
> I don't know! Why do you want to scroll in that "mode"? Because you want to centre the found text at the bottom? Then try C-l! Or press C-l twice. (Or three times...)

I want to scroll around and see what's highlighted, not press C-s a
bunch of times.  Scrolling gives me visual feedback on where I am in
the file that jump scrolling does not.  This is one of the reasons I
want it to scroll one line at a time.

And anyway, I've done enough customizations in emacs already that I've
learned to not take "no, why would you want to do that anyway" as an
answer.

Aaron Meurer

>
> --
> Greetings
>
>  Pete
>
> I love deadlines. I love the whooshing noise they make as they go by.
>                                – Douglas Adams
>

Re: Mouse support does not work

[Peter Dyballa]

Am 10.1.2012 um 23:50 schrieb Aaron Meurer:

> (can the GUI version of emacs use a non-monospaced font, btw?).

Of course.

>>> - Is there a way to make scrolling not kill an I-search?
>> 
>> I don't know! Why do you want to scroll in that "mode"? Because you want to centre the found text at the bottom? Then try C-l! Or press C-l twice. (Or three times...)
> 
> I want to scroll around and see what's highlighted, not press C-s a
> bunch of times.

Make the window higher! You could have 100 lines displayed.

>  Scrolling gives me visual feedback on where I am in
> the file that jump scrolling does not.

GNU Emacs allows to display line numbers in the mode-line. Put in the customisations section of your init file:

	'(column-number-mode t)

In GNU Emacs 23.3b the variable isearch-mode-map contains some mouse events. Maybe you can add mouse-4 and mouse-5...


>  This is one of the reasons I want it to scroll one line at a time.

The others?

Maybe the developers feel like me that scrolling around is a bit imprecise and you likely lose the place where isearch found the text...

--
Greetings

  Pete

The human animal differs from the lesser primates in his passion for lists of "Ten Best."
				– H. Allen Smith

Re: Mouse support does not work

[Aaron Meurer]

On Tue, Jan 10, 2012 at 4:26 PM, Peter Dyballa <Peter_Dyballa@web.de> wrote:
>
> Am 10.1.2012 um 23:50 schrieb Aaron Meurer:
>
>> (can the GUI version of emacs use a non-monospaced font, btw?).
>
> Of course.
>
>>>> - Is there a way to make scrolling not kill an I-search?
>>>
>>> I don't know! Why do you want to scroll in that "mode"? Because you want to centre the found text at the bottom? Then try C-l! Or press C-l twice. (Or three times...)
>>
>> I want to scroll around and see what's highlighted, not press C-s a
>> bunch of times.
>
> Make the window higher! You could have 100 lines displayed.

I already have my terminal full screen.

>
>>  Scrolling gives me visual feedback on where I am in
>> the file that jump scrolling does not.
>
> GNU Emacs allows to display line numbers in the mode-line. Put in the customisations section of your init file:
>
>        '(column-number-mode t)

I already have this.  That reminds me to look for a way to always show
the line numbers to the left of the text, though.

I just found the answer: http://www.emacswiki.org/emacs/LineNumbers

>
> In GNU Emacs 23.3b the variable isearch-mode-map contains some mouse events. Maybe you can add mouse-4 and mouse-5...

I'll play around with this.  Actually, I'm starting to feel like I
should replace I-search with something else entirely, like maybe
re-builder (though this can be slow in my limited experience with it).
 It does several things I don't like:

- You have to press C-s twice to wrap around.  It's not so bad, but
it's confused me more than once into thinking that there were no
occurrences because they were all before the cursor.

- You can't edit the search buffer with editing commands.  This is the
most annoying.  If I press M-del to delete a search word, it instead
deletes the word under the cursor.  If I want to delete the word, I
have to repeatedly press delete.  It's even worse than that, because
pressing delete by default does a reverse i-search! So I have to
delete until I get back to the first occurrence, and then until I
delete the word.  Or just C-g and restart.

- As I noted, it kills the search when you scroll.  I just checked,
and re-builder doesn't do this.

>
>
>>  This is one of the reasons I want it to scroll one line at a time.
>
> The others?

Because it would be smoother.  Scrolling in the terminal is already
choppy due to the fact that you must scroll in one line increments.
Again, it's all about good visual feedback.

>
> Maybe the developers feel like me that scrolling around is a bit imprecise and you likely lose the place where isearch found the text...

This works fine everywhere else.  For example, try it in your web
browser (I can't imagine you use emacs for that too :).  Search for
something and scroll around.  You don't "lose" the position of the
current search.  If you press C-s or Command-s again, it jumps right
back to the next search.

I just checked, and in vim, you can scroll without loosing the search.
 It doesn't work exactly as I said above, as pressing n gives the
first occurrence on the screen instead of the next one.

Aaron Meurer

>
> --
> Greetings
>
>  Pete
>
> The human animal differs from the lesser primates in his passion for lists of "Ten Best."
>                                – H. Allen Smith
>

RE: Mouse support does not work

[Drew Adams]

> - Is there a way to make scrolling not kill an I-search?

M-x customize-option isearch-allow-scroll

,----
| isearch-allow-scroll is a variable defined in `isearch.el'.
| Its value is nil
| 
| Documentation:
| Whether scrolling is allowed during incremental search.
| If non-nil, scrolling commands can be used in Isearch mode.
| However, the current match will never scroll offscreen.
| If nil, scrolling commands will first cancel Isearch mode.
`----

RE: Mouse support does not work

[Drew Adams]

> Actually, I'm starting to feel like I should replace I-search
> with something else entirely... It does several things I don't like:
> 
> - You can't edit the search buffer with editing commands.  This is the
> most annoying.  If I press M-del to delete a search word, it instead
> deletes the word under the cursor.  If I want to delete the word, I
> have to repeatedly press delete.  It's even worse than that, because
> pressing delete by default does a reverse i-search! So I have to
> delete until I get back to the first occurrence, and then until I
> delete the word.  Or just C-g and restart.

`M-e' in Isearch.  Lets you edit the search string anyway you like.  You have
all of Emacs at your disposal to edit it.

> - As I noted, it kills the search when you scroll.

See previous reply: set `isearch-allow-scroll' to non-nil.

Re: Mouse support does not work

[Aaron Meurer]

On Wed, Jan 11, 2012 at 7:37 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> Actually, I'm starting to feel like I should replace I-search
>> with something else entirely... It does several things I don't like:
>>
>> - You can't edit the search buffer with editing commands.  This is the
>> most annoying.  If I press M-del to delete a search word, it instead
>> deletes the word under the cursor.  If I want to delete the word, I
>> have to repeatedly press delete.  It's even worse than that, because
>> pressing delete by default does a reverse i-search! So I have to
>> delete until I get back to the first occurrence, and then until I
>> delete the word.  Or just C-g and restart.
>
> `M-e' in Isearch.  Lets you edit the search string anyway you like.  You have
> all of Emacs at your disposal to edit it.

Thanks.  Is there a way to make that default? In other words, any edit
command will always edit the search string unless I press RET to end
the search.

>
>> - As I noted, it kills the search when you scroll.
>
> See previous reply: set `isearch-allow-scroll' to non-nil.
>

Great. I've got to remember to make searching M-x customize my first
resort when I want to change something.

Aaron Meurer

RE: Mouse support does not work

[Drew Adams]

> > `M-e' in Isearch.  Lets you edit the search string anyway 
> > you like.  You have all of Emacs at your disposal to edit it.
> 
> Thanks.  Is there a way to make that default? In other words, any edit
> command will always edit the search string unless I press RET to end
> the search.

Not that I know of offhand - never looked for that.  You can check the doc.

But if you really want that then it sounds like you do not want _incremental_
search in the first place.  In that case, just use the non-incremental search
commands: `search-forward' etc.  Transport yourself back to the 1970s and enjoy.
;-)

On the other hand, if you just want to have certain editing commands/keys
automatically initiate Isearch editing (what `M-e' does), then you can customize
option `isearchp-initiate-edit-commands'.  (You need Isearch+ for that
possibility - see below.)

> >> - As I noted, it kills the search when you scroll.
> >
> > See previous reply: set `isearch-allow-scroll' to non-nil.
> 
> Great. I've got to remember to make searching M-x customize my first
> resort when I want to change something.

I recommend the Emacs doc, also.

> - You have to press C-s twice to wrap around.  It's not so bad, but
> it's confused me more than once into thinking that there were no
> occurrences because they were all before the cursor.

If you use Isearch+ then the prompt keywords "Wrapped" and "Overwrapped" are
highlighted in a different face, so you can notice easier that wrapping is
happening.

(Prompt keywords are also highlighted for regexp, word, and multi-buffer
searching.  If you do not want such highlighting then just customize the faces
for any of these to look the same as face `minibuffer-prompt'.)

And in Emacs 24+, the mode-line lighter gets the same face whenever Isearch is
wrapping.

Isearch+ is here:
http://www.emacswiki.org/cgi-bin/wiki/IsearchPlus
http://www.emacswiki.org/emacs/download/isearch%2b.el

Re: Mouse support does not work

[Aaron Meurer]

On Wed, Jan 11, 2012 at 12:10 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > `M-e' in Isearch.  Lets you edit the search string anyway
>> > you like.  You have all of Emacs at your disposal to edit it.
>>
>> Thanks.  Is there a way to make that default? In other words, any edit
>> command will always edit the search string unless I press RET to end
>> the search.
>
> Not that I know of offhand - never looked for that.  You can check the doc.
>
> But if you really want that then it sounds like you do not want _incremental_
> search in the first place.  In that case, just use the non-incremental search
> commands: `search-forward' etc.  Transport yourself back to the 1970s and enjoy.
> ;-)
>
> On the other hand, if you just want to have certain editing commands/keys
> automatically initiate Isearch editing (what `M-e' does), then you can customize
> option `isearchp-initiate-edit-commands'.  (You need Isearch+ for that
> possibility - see below.)

Thanks.  For others interested, it is from that extension (hence the p
in the variable name).  To use it, you should edit the source and
uncomment the commands you want to allow to edit the search (I
uncommented them all).

>
>> >> - As I noted, it kills the search when you scroll.
>> >
>> > See previous reply: set `isearch-allow-scroll' to non-nil.
>>
>> Great. I've got to remember to make searching M-x customize my first
>> resort when I want to change something.
>
> I recommend the Emacs doc, also.

Meh.  I usually just use Google.  If that takes me to the docs, then
fine.  I've found emacswiki to be the most helpful so far, actually.

>
>> - You have to press C-s twice to wrap around.  It's not so bad, but
>> it's confused me more than once into thinking that there were no
>> occurrences because they were all before the cursor.
>
> If you use Isearch+ then the prompt keywords "Wrapped" and "Overwrapped" are
> highlighted in a different face, so you can notice easier that wrapping is
> happening.

The problem is not that I'm unaware that it's wrapping around (though
I do appreciate it letting me know).  The problem is that it doesn't
do it by default, so it appears that there are no matches, unless you
remember to press C-s a second time to check for matches before.  I'm
used to editors that wrap around automatically, so if there are no
matches after the cursor, it will automatically give the first one in
the file without having to press C-s additionally.

I just checked with isearch+. It selects the searches in the text. But
it does not automatically go to the "first" one (the one closest to
the top of the buffer), hence requiring an additional press of C-s.
It also highlights the text with the failing search face and says
"Failing I-Search". I think this is the same as without the extension.

I think all of my other search related problems are solved, though.

>
> (Prompt keywords are also highlighted for regexp, word, and multi-buffer
> searching.  If you do not want such highlighting then just customize the faces
> for any of these to look the same as face `minibuffer-prompt'.)
>
> And in Emacs 24+, the mode-line lighter gets the same face whenever Isearch is
> wrapping.
>
> Isearch+ is here:
> http://www.emacswiki.org/cgi-bin/wiki/IsearchPlus
> http://www.emacswiki.org/emacs/download/isearch%2b.el
>

Re: Mouse support does not work

[Aaron Meurer]

Going back to my scrolling problem, is there a way to echo all
keystrokes?  I mean, something similar to C-h k, except it echos
multiple keystrokes.  I suspect that either my trackpad or iTerm2 may
be reporting a single scroll as two scrolls, hence the multiplying by
two problem.

Aaron Meurer

RE: Mouse support does not work

[Drew Adams]

> Going back to my scrolling problem, is there a way to echo all
> keystrokes?  I mean, something similar to C-h k, except it echos
> multiple keystrokes.  I suspect that either my trackpad or iTerm2 may
> be reporting a single scroll as two scrolls, hence the multiplying by
> two problem.

Not sure what you are asking or what problem you are encountering, but maybe
option `echo-keystrokes' will help?

Re: Mouse support does not work

[Aaron Meurer]

The problem I'm encountering is that when I scroll by the smallest
amount with the mouse, it scrolls by two lines.  I have the
mouse-wheel-scroll-amount set to 1.  If I set it to 2, it scrolls by
4, and so on.  vim does the same thing, so I suspect that what's
happening is that a single scroll is being reported as two. But the
only way to be sure would be to get something that echos all
keystrokes, so I could see if a single scroll is really being reported
as two mouse-5 events.  C-h k won't work for this, because it only
would show the first such event (if my theory is correct).

Actually, I think I figured out that it's correct anyway, because I
did C-h k and then scrolled up, and it showed me the help for mouse-5
*and then* scrolled the document up by exactly one line.

So I'll be reporting this as a bug to iTerm2.  I'll post back here if
I find a solution.

Aaron Meurer

On Sat, Jan 14, 2012 at 9:53 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> Going back to my scrolling problem, is there a way to echo all
>> keystrokes?  I mean, something similar to C-h k, except it echos
>> multiple keystrokes.  I suspect that either my trackpad or iTerm2 may
>> be reporting a single scroll as two scrolls, hence the multiplying by
>> two problem.
>
> Not sure what you are asking or what problem you are encountering, but maybe
> option `echo-keystrokes' will help?
>

RE: Mouse support does not work

[Drew Adams]

> The problem I'm encountering is that when I scroll by the smallest
> amount with the mouse, it scrolls by two lines.  I have the
> mouse-wheel-scroll-amount set to 1.

I'm no expert on this - perhaps someone else can help more.

But if the value of `mouse-wheel-scroll-amount' is 1 (or 2 etc.) then that is
wrong.  It needs to be an alist or a number representing the fraction of the
screen to scroll.

Use `M-x customize-option' to change the option - do not just `setq' it to an
integer value.  Read the variable's doc (`C-h v').

> If I set it to 2, it scrolls by
> 4, and so on.  vim does the same thing, so I suspect that what's
> happening is that a single scroll is being reported as two.

> But the
> only way to be sure would be to get something that echos all
> keystrokes, so I could see if a single scroll is really being reported
> as two mouse-5 events.  C-h k won't work for this, because it only
> would show the first such event (if my theory is correct).

Wrt keystroke echoing, you can use `echo-keystrokes', as I mentioned.
You also have `C-h l', to see the last 100 keystrokes.

> Actually, I think I figured out that it's correct anyway, because I
> did C-h k and then scrolled up, and it showed me the help for mouse-5
> *and then* scrolled the document up by exactly one line.
> 
> So I'll be reporting this as a bug to iTerm2.  I'll post back here if
> I find a solution.

Re: Mouse support does not work

[Aaron Meurer]

On Sat, Jan 14, 2012 at 10:37 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> The problem I'm encountering is that when I scroll by the smallest
>> amount with the mouse, it scrolls by two lines.  I have the
>> mouse-wheel-scroll-amount set to 1.
>
> I'm no expert on this - perhaps someone else can help more.
>
> But if the value of `mouse-wheel-scroll-amount' is 1 (or 2 etc.) then that is
> wrong.  It needs to be an alist or a number representing the fraction of the
> screen to scroll.

OK, it's not literally the integer 1.  It's (mouse-wheel-scroll-amount
(quote (1))), which I did set through customize.

>
> Use `M-x customize-option' to change the option - do not just `setq' it to an
> integer value.  Read the variable's doc (`C-h v').
>
>> If I set it to 2, it scrolls by
>> 4, and so on.  vim does the same thing, so I suspect that what's
>> happening is that a single scroll is being reported as two.
>
>> But the
>> only way to be sure would be to get something that echos all
>> keystrokes, so I could see if a single scroll is really being reported
>> as two mouse-5 events.  C-h k won't work for this, because it only
>> would show the first such event (if my theory is correct).
>
> Wrt keystroke echoing, you can use `echo-keystrokes', as I mentioned.
> You also have `C-h l', to see the last 100 keystrokes.

echo-keystrokes only seems to work within some lisp code, which I
unfortunately am not good enough with yet to do anything useful.  C-h
l doesn't seem to show mouse events.

Aaron Meurer

>
>> Actually, I think I figured out that it's correct anyway, because I
>> did C-h k and then scrolled up, and it showed me the help for mouse-5
>> *and then* scrolled the document up by exactly one line.
>>
>> So I'll be reporting this as a bug to iTerm2.  I'll post back here if
>> I find a solution.
>

RE: Mouse support does not work

[Drew Adams]

> > Wrt keystroke echoing, you can use `echo-keystrokes', as I 
> > mentioned. You also have `C-h l', to see the last 100 keystrokes.
> 
> echo-keystrokes only seems to work within some lisp code, which I
> unfortunately am not good enough with yet to do anything useful.

I think it works always, but it is true that some commands etc. might bind it to
0 so it has no effect in some context. 

> C-h l doesn't seem to show mouse events.

It does for me:

... SPC <down-mouse-1> <mouse-1> C-c C-c y e s <return>
<help-echo> <switch-frame> <switch-frame> <down-mouse-1>
<mouse-movement> <mouse-movement> <drag-mouse-1> <down-mouse-3>
<mouse-3> <down-mouse-1> <mouse-1> <double-down-mouse-1>
<double-mouse-1> <down-mouse-3> <mouse-3> C-h l

And it works whether I use a graphic display or `emacs -nw'.

Re: Mouse support does not work

[Aaron Meurer]

On Sat, Jan 14, 2012 at 11:20 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> > Wrt keystroke echoing, you can use `echo-keystrokes', as I
>> > mentioned. You also have `C-h l', to see the last 100 keystrokes.
>>
>> echo-keystrokes only seems to work within some lisp code, which I
>> unfortunately am not good enough with yet to do anything useful.
>
> I think it works always, but it is true that some commands etc. might bind it to
> 0 so it has no effect in some context.

Maybe I'm missing something then.  M-x echo-keystrokes doesn't work.
How would one run this (without incorporating it into some lisp code)?
 Sorry if this sounds stupid, but I'm still very new to both emacs and
emacs lisp.

>
>> C-h l doesn't seem to show mouse events.
>
> It does for me:
>
> ... SPC <down-mouse-1> <mouse-1> C-c C-c y e s <return>
> <help-echo> <switch-frame> <switch-frame> <down-mouse-1>
> <mouse-movement> <mouse-movement> <drag-mouse-1> <down-mouse-3>
> <mouse-3> <down-mouse-1> <mouse-1> <double-down-mouse-1>
> <double-mouse-1> <down-mouse-3> <mouse-3> C-h l
>
> And it works whether I use a graphic display or `emacs -nw'.
>

Actually, I think maybe it does for me too. But it shows it in the
form of garbage that I don't know how to read:

ESC [ > 0 ; 9 5 ; c ESC x e c TAB DEL DEL ESC [ M a
] E ESC [ M a ] E ESC [ M a ] E ESC [ M a ] E ESC [
M a ] E ESC [ M ` ] E ESC [ M ` ] E ESC [ M ` ] E ESC
[ M ` ] E C-h C-g C-h C-h l ESC [ M a ] E ESC [ M a
] E ESC [ M a ] E ESC [ M ` ] E ESC [ M ` ] E ESC [
M ` ] E ESC [ M ` ] E ESC [ M SPC \300\262 , ESC [
M # \300\262 , ESC [ M SPC \300\243 ) ESC [ M # \300\243
) ESC [ M SPC \300\241 ' ESC [ M # \300\241 ' C-h l
ESC [ M a \300\236 & C-h l

Aaron Meurer

RE: Mouse support does not work

[Drew Adams]

> >> > Wrt keystroke echoing, you can use `echo-keystrokes', as I
> >> > mentioned. You also have `C-h l', to see the last 100 keystrokes.
> >>
> >> echo-keystrokes only seems to work within some lisp code, which I
> >> unfortunately am not good enough with yet to do anything useful.
> >
> > I think it works always, but it is true that some commands 
> > etc. might bind it to 0 so it has no effect in some context.
> 
> Maybe I'm missing something then.  M-x echo-keystrokes doesn't work.
> How would one run this (without incorporating it into some lisp code)?

It is a user option, IOW a variable that you can customize.  It is not a
function, let alone a command (so you cannot invoke it using `M-x').

Use `C-h v echo-keystrokes' to see its doc.

However, the doc string is incomplete - see this bug report:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10503.  For more complete info, see
the Emacs or Elisp manual: use `i echo-keystrokes' in the manual.

The way to make `echo-keystrokes' take effect or not is to use `M-x
customize-option' or `M-x set-variable'.

> >> C-h l doesn't seem to show mouse events.
> >
> > It does for me:
> >
> > ... SPC <down-mouse-1> <mouse-1> C-c C-c y e s <return>
> > <help-echo> <switch-frame> <switch-frame> <down-mouse-1>
> > <mouse-movement> <mouse-movement> <drag-mouse-1> <down-mouse-3>
> > <mouse-3> <down-mouse-1> <mouse-1> <double-down-mouse-1>
> > <double-mouse-1> <down-mouse-3> <mouse-3> C-h l
> >
> > And it works whether I use a graphic display or `emacs -nw'.
> >
> 
> Actually, I think maybe it does for me too. But it shows it in the
> form of garbage that I don't know how to read:
> 
> ESC [ > 0 ; 9 5 ; c ESC x e c TAB DEL DEL ESC [ M a
> ] E ESC [ M a ] E ESC [ M a ] E ESC [ M a ] E ESC [
> M a ] E ESC [ M ` ] E ESC [ M ` ] E ESC [ M ` ] E ESC
> [ M ` ] E C-h C-g C-h C-h l ESC [ M a ] E ESC [ M a
> ] E ESC [ M a ] E ESC [ M ` ] E ESC [ M ` ] E ESC [
> M ` ] E ESC [ M ` ] E ESC [ M SPC \300\262 , ESC [
> M # \300\262 , ESC [ M SPC \300\243 ) ESC [ M # \300\243
> ) ESC [ M SPC \300\241 ' ESC [ M # \300\241 ' C-h l
> ESC [ M a \300\236 & C-h l

Those look like keyboard keys to me, not mouse events.  If you use the mouse
(e.g. click `mouse-1' somewhere, then click `mouse-3' somewhere, to select some
text) you should see mouse events such as I show above.

Re: Mouse support does not work

[Aaron Meurer]

On Sat, Jan 14, 2012 at 1:08 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >> > Wrt keystroke echoing, you can use `echo-keystrokes', as I
>> >> > mentioned. You also have `C-h l', to see the last 100 keystrokes.
>> >>
>> >> echo-keystrokes only seems to work within some lisp code, which I
>> >> unfortunately am not good enough with yet to do anything useful.
>> >
>> > I think it works always, but it is true that some commands
>> > etc. might bind it to 0 so it has no effect in some context.
>>
>> Maybe I'm missing something then.  M-x echo-keystrokes doesn't work.
>> How would one run this (without incorporating it into some lisp code)?
>
> It is a user option, IOW a variable that you can customize.  It is not a
> function, let alone a command (so you cannot invoke it using `M-x').
>
> Use `C-h v echo-keystrokes' to see its doc.
>
> However, the doc string is incomplete - see this bug report:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10503.  For more complete info, see
> the Emacs or Elisp manual: use `i echo-keystrokes' in the manual.
>
> The way to make `echo-keystrokes' take effect or not is to use `M-x
> customize-option' or `M-x set-variable'.

Ah, I see what this is now.  Would that even echo mouse events?

>
>> >> C-h l doesn't seem to show mouse events.
>> >
>> > It does for me:
>> >
>> > ... SPC <down-mouse-1> <mouse-1> C-c C-c y e s <return>
>> > <help-echo> <switch-frame> <switch-frame> <down-mouse-1>
>> > <mouse-movement> <mouse-movement> <drag-mouse-1> <down-mouse-3>
>> > <mouse-3> <down-mouse-1> <mouse-1> <double-down-mouse-1>
>> > <double-mouse-1> <down-mouse-3> <mouse-3> C-h l
>> >
>> > And it works whether I use a graphic display or `emacs -nw'.
>> >
>>
>> Actually, I think maybe it does for me too. But it shows it in the
>> form of garbage that I don't know how to read:
>>
>> ESC [ > 0 ; 9 5 ; c ESC x e c TAB DEL DEL ESC [ M a
>> ] E ESC [ M a ] E ESC [ M a ] E ESC [ M a ] E ESC [
>> M a ] E ESC [ M ` ] E ESC [ M ` ] E ESC [ M ` ] E ESC
>> [ M ` ] E C-h C-g C-h C-h l ESC [ M a ] E ESC [ M a
>> ] E ESC [ M a ] E ESC [ M ` ] E ESC [ M ` ] E ESC [
>> M ` ] E ESC [ M ` ] E ESC [ M SPC \300\262 , ESC [
>> M # \300\262 , ESC [ M SPC \300\243 ) ESC [ M # \300\243
>> ) ESC [ M SPC \300\241 ' ESC [ M # \300\241 ' C-h l
>> ESC [ M a \300\236 & C-h l
>
> Those look like keyboard keys to me, not mouse events.  If you use the mouse
> (e.g. click `mouse-1' somewhere, then click `mouse-3' somewhere, to select some
> text) you should see mouse events such as I show above.
>

No, this is definitely how it is reporting mouse events. I typed "Some
Text" and clicked on the S, and this is what it showed for it:

S o m e SPC T e x t ESC [ M SPC $ ( ESC [ M # $ ( C-h l

It makes sense that it would do that, because just saying
<down-mouse-1> does not tell you where in the text you clicked.

Also, if I type  ESC [ M SPC $ ( ESC [ M # $ ( with the cursor on the
t, it does indeed go back to the S.  It even echos "down-mouse-1" at
the bottom. As for scrolling, it seems that the command is different
depending on where my mouse is (I think), which makes sense because I
set the "Mouse Wheel Follow Mouse" setting from customize to on (I
couldn't figure out what the emacs variable name for that is called).

Aaron Meurer

RE: Mouse support does not work

[Drew Adams]

> Ah, I see what this is now.  Would that even echo mouse events?

No.  It echos unfinished keyboard key sequences.

> >> Actually, I think maybe it does for me too. But it shows it in the
> >> form of garbage that I don't know how to read:
> >>
> >> ESC [ > 0 ; 9 5 ; c ESC x e c TAB DEL DEL ESC [ M a...
> >
> > Those look like keyboard keys to me, not mouse events.  If 
> > you use the mouse (e.g. click `mouse-1' somewhere, then
> > click `mouse-3' somewhere, to select some text) you should
> > see mouse events such as I show above.
> 
> No, this is definitely how it is reporting mouse events. I typed "Some
> Text" and clicked on the S, and this is what it showed for it:
> 
> S o m e SPC T e x t ESC [ M SPC $ ( ESC [ M # $ ( C-h l

Perhaps it is a platform difference.  I'm using MS Windows.  I've never seen
what you see.

> It makes sense that it would do that, because just saying
> <down-mouse-1> does not tell you where in the text you clicked.

And how does what it shows you tell you more about the mouse-click position than
this, which is what I see on a graphic display:

S o m e SPC T e x t <down-mouse-1> <mouse-1> C-h l

Or this, which is what I see with emacs -nw:

S o m e SPC T e x t <down-mouse-1> <mouse-movement> <mouse-1> C-h l

What is shown is not the full mouse event, with all of its position info.  All
that is shown is the name of the mouse event (including modifiers).

> Also, if I type  ESC [ M SPC $ ( ESC [ M # $ ( with the cursor on the
> t,

How do you type that?  Is M the shifted `M' key or Meta (Alt)?  If I hit the
`ESC' key and then the `[' key Emacs just tells me `M-[ is undefined'.

> it does indeed go back to the S.  It even echos "down-mouse-1" at
> the bottom.  As for scrolling, it seems that the command is different
> depending on where my mouse is (I think), which makes sense because I
> set the "Mouse Wheel Follow Mouse" setting from customize to on (I
> couldn't figure out what the emacs variable name for that is called).

Customize `custom-unlispify-tag-names' to nil (off), if you want to see the real
(Lisp) names.

(IMHO that should be the default value.  It is less, not more, helpful to simply
capitalize each word and replace SPC with hyphen.  Misguided, IMO.)

Re: Mouse support does not work

[Aaron Meurer]

On Sat, Jan 14, 2012 at 2:00 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> Ah, I see what this is now.  Would that even echo mouse events?
>
> No.  It echos unfinished keyboard key sequences.
>
>> >> Actually, I think maybe it does for me too. But it shows it in the
>> >> form of garbage that I don't know how to read:
>> >>
>> >> ESC [ > 0 ; 9 5 ; c ESC x e c TAB DEL DEL ESC [ M a...
>> >
>> > Those look like keyboard keys to me, not mouse events.  If
>> > you use the mouse (e.g. click `mouse-1' somewhere, then
>> > click `mouse-3' somewhere, to select some text) you should
>> > see mouse events such as I show above.
>>
>> No, this is definitely how it is reporting mouse events. I typed "Some
>> Text" and clicked on the S, and this is what it showed for it:
>>
>> S o m e SPC T e x t ESC [ M SPC $ ( ESC [ M # $ ( C-h l
>
> Perhaps it is a platform difference.  I'm using MS Windows.  I've never seen
> what you see.
>
>> It makes sense that it would do that, because just saying
>> <down-mouse-1> does not tell you where in the text you clicked.
>
> And how does what it shows you tell you more about the mouse-click position than
> this, which is what I see on a graphic display:

Because it tells you *exactly* where the mouse was clicked, in some
coded internal language.  As I said, when I typed it, it reproduced
what I did with the mouse exactly.

>
> S o m e SPC T e x t <down-mouse-1> <mouse-1> C-h l
>
> Or this, which is what I see with emacs -nw:
>
> S o m e SPC T e x t <down-mouse-1> <mouse-movement> <mouse-1> C-h l
>
> What is shown is not the full mouse event, with all of its position info.  All
> that is shown is the name of the mouse event (including modifiers).
>
>> Also, if I type  ESC [ M SPC $ ( ESC [ M # $ ( with the cursor on the
>> t,
>
> How do you type that?  Is M the shifted `M' key or Meta (Alt)?  If I hit the
> `ESC' key and then the `[' key Emacs just tells me `M-[ is undefined'.

No, I think it's literally "M" (shifted M).  Meta is ESC. And Control
is written as C-letter (with a dash).

>
>> it does indeed go back to the S.  It even echos "down-mouse-1" at
>> the bottom.  As for scrolling, it seems that the command is different
>> depending on where my mouse is (I think), which makes sense because I
>> set the "Mouse Wheel Follow Mouse" setting from customize to on (I
>> couldn't figure out what the emacs variable name for that is called).
>
> Customize `custom-unlispify-tag-names' to nil (off), if you want to see the real
> (Lisp) names.
>
> (IMHO that should be the default value.  It is less, not more, helpful to simply
> capitalize each word and replace SPC with hyphen.  Misguided, IMO.)
>

I agree, though I see where they're coming from (people who use M-x
customize are supposed to be shielded from the lisp side).  Thanks for
the tip!

Aaron Meurer

Re: Mouse support does not work

[Peter Dyballa]

Am 14.1.2012 um 21:08 schrieb Drew Adams:

> Those look like keyboard keys to me, not mouse events.  If you use the mouse
> (e.g. click `mouse-1' somewhere, then click `mouse-3' somewhere, to select some
> text) you should see mouse events such as I show above.

Drew,

Aaron is working with GNU Emacs in non-windows "mode" inside an xterm (variant). The latter is an X client, it exists in a windowing system and it receives key or mouse events. But the things running inside the xterm (iTerm2) terminal emulation can only receive text input, for example ANSI Esc sequences (or codes). It looks as if these codes are produced by the given "mouse events":

	ESC [ M a F Z	= <mouse-4> = scroll-up
	ESC [ M ` u X	= <mouse-5> = scroll-down
	
	ESC [ M e / Q	= S-<mouse-4> = <mouse-8>
	ESC [ M d 5 S	= S-<mouse-5> = <mouse-9>
	
	ESC [ M q - S	= C-<mouse-4> = <mouse-20>
	ESC [ M p 2 T	= C-<mouse-5> = <mouse-21>

Having set in my init file

	  (global-set-key [mouse-4]	(lambda () (interactive) (mwheel-scroll mouse-wheel-up-event)))
	  (global-set-key [mouse-5]	(lambda () (interactive) (mwheel-scroll mouse-wheel-down-event)))

scrolling feels quite OK in xterm and y bit too fast in uxterm... Not as smooth as with a windowing Emacs.

--
Greetings

  Pete

Hard Disk, n.:
	A device that allows users to delete vast quantities of data with simple mnemonic commands.

RE: Mouse support does not work

[Drew Adams]

> Aaron is working with GNU Emacs in non-windows "mode" inside 
> an xterm (variant). The latter is an X client, it exists in a 
> windowing system and it receives key or mouse events. But the 
> things running inside the xterm (iTerm2) terminal emulation 
> can only receive text input, for example ANSI Esc sequences 
> (or codes). It looks as if these codes are produced by the 
> given "mouse events":
> 
> 	ESC [ M a F Z	= <mouse-4> = scroll-up
> 	ESC [ M ` u X	= <mouse-5> = scroll-down
> 	ESC [ M e / Q	= S-<mouse-4> = <mouse-8>
> 	ESC [ M d 5 S	= S-<mouse-5> = <mouse-9>
> 	ESC [ M q - S	= C-<mouse-4> = <mouse-20>
> 	ESC [ M p 2 T	= C-<mouse-5> = <mouse-21>

Thanks for that info.  I figured at first it was maybe `emacs -nw', but that
doesn't have the same behavior.

Re: Mouse support does not work

[Peter Dyballa]

Am 15.1.2012 um 01:58 schrieb Drew Adams:

> I figured at first it was maybe `emacs -nw', but that doesn't have the same behavior.

Could be this is a Mac OS X specific behaviour. I thought of writing the mwheel.el authors an eMail about that...

--
Mit friedvollen Grüßen

  Pete

A lot of people mistake a short memory for a clear conscience.
				– Doug Larson

Re: Mouse support does not work

[Aaron Meurer]

On Sat, Jan 14, 2012 at 5:55 PM, Peter Dyballa <Peter_Dyballa@web.de> wrote:
>
> Am 14.1.2012 um 21:08 schrieb Drew Adams:
>
>> Those look like keyboard keys to me, not mouse events.  If you use the mouse
>> (e.g. click `mouse-1' somewhere, then click `mouse-3' somewhere, to select some
>> text) you should see mouse events such as I show above.
>
> Drew,
>
> Aaron is working with GNU Emacs in non-windows "mode" inside an xterm (variant). The latter is an X client, it exists in a windowing system and it receives key or mouse events. But the things running inside the xterm (iTerm2) terminal emulation can only receive text input, for example ANSI Esc sequences (or codes). It looks as if these codes are produced by the given "mouse events":
>
>        ESC [ M a F Z   = <mouse-4> = scroll-up
>        ESC [ M ` u X   = <mouse-5> = scroll-down
>
>        ESC [ M e / Q   = S-<mouse-4> = <mouse-8>
>        ESC [ M d 5 S   = S-<mouse-5> = <mouse-9>
>
>        ESC [ M q - S   = C-<mouse-4> = <mouse-20>
>        ESC [ M p 2 T   = C-<mouse-5> = <mouse-21>
>

It's not that simple if you have the mouse-wheel-follows-focus set,
because it also keeps track of the cursor location.  Here's an example
scroll up for me:

ESC [ > 0 ; 9 5 ; c ESC [ M a | 8

Aaron Meurer

> Having set in my init file
>
>          (global-set-key [mouse-4]     (lambda () (interactive) (mwheel-scroll mouse-wheel-up-event)))
>          (global-set-key [mouse-5]     (lambda () (interactive) (mwheel-scroll mouse-wheel-down-event)))
>
> scrolling feels quite OK in xterm and y bit too fast in uxterm... Not as smooth as with a windowing Emacs.
>
> --
> Greetings
>
>  Pete
>
> Hard Disk, n.:
>        A device that allows users to delete vast quantities of data with simple mnemonic commands.
>

Re: Mouse support does not work

[Peter Dyballa]

Am 15.1.2012 um 02:13 schrieb Aaron Meurer:

> It's not that simple if you have the mouse-wheel-follows-focus set,
> because it also keeps track of the cursor location.

What is its use? In a buffer you can pick anywhere (where already some text is) with the mouse cursor and then write or delete or correct or mark/select some text...

--
Greetings

  Pete

Perl—the only language that looks the same before and after RSA encryption.
				- Keith Bostic

Re: Mouse support does not work

[Aaron Meurer]

It's because I have the setting enabled for scrolling to follow the
mouse focus (as opposed to the keyboard focus). I didn't check if it
still does all this if I turn the setting off.

Aaron Meurer

On Jan 15, 2012, at 8:28 AM, Peter Dyballa <Peter_Dyballa@web.de> wrote:

>
> Am 15.1.2012 um 02:13 schrieb Aaron Meurer:
>
>> It's not that simple if you have the mouse-wheel-follows-focus set,
>> because it also keeps track of the cursor location.
>
> What is its use? In a buffer you can pick anywhere (where already some text is) with the mouse cursor and then write or delete or correct or mark/select some text...
>
> --
> Greetings
>
>  Pete
>
> Perl—the only language that looks the same before and after RSA encryption.
>                - Keith Bostic
>

Re: Mouse support does not work

[Peter Dyballa]

Am 15.1.2012 um 16:47 schrieb Aaron Meurer:

> It's because I have the setting enabled for scrolling to follow the
> mouse focus (as opposed to the keyboard focus).

Is this variable really existing in non-window "mode"? In X11 it probably enables mouse scroll access to the X client without needing to click to it first...

--
Greetings

  Pete

The next generation of interesting software will be done on the Macintosh, not the IBM PC.
				– Bill Gates, Nov 1984

Re: Mouse support does not work

[Aaron Meurer]

On Sun, Jan 15, 2012 at 9:30 AM, Peter Dyballa <Peter_Dyballa@web.de> wrote:
>
> Am 15.1.2012 um 16:47 schrieb Aaron Meurer:
>
>> It's because I have the setting enabled for scrolling to follow the
>> mouse focus (as opposed to the keyboard focus).
>
> Is this variable really existing in non-window "mode"? In X11 it probably enables mouse scroll access to the X client without needing to click to it first...

Yeah, and it works too. If I have two buffers open side by side, and I
position the mouse over one, it will scroll that buffer, regardless of
which buffer is currently selected. This is in the terminal (iTerm2).

Aaron Meurer

>
> --
> Greetings
>
>  Pete
>
> The next generation of interesting software will be done on the Macintosh, not the IBM PC.
>                                – Bill Gates, Nov 1984
>

Re: Mouse support does not work

[Aaron Meurer]

Actually, I found another program that does what I want.  urwid
(https://github.com/wardi/urwid) has a input_test script that echos
all the keystrokes.  In this script, only one mouse scroll event is
reported per scroll.  So I don't know where the bug is at this point
(though I am convinced that it is indeed a bug somewhere).  Here's the
iTerm2 bug I reported if anyone's interested
(http://code.google.com/p/iterm2/issues/detail?id=1715).

Aaron Meurer

On Sat, Jan 14, 2012 at 10:26 AM, Aaron Meurer <asmeurer@gmail.com> wrote:
> The problem I'm encountering is that when I scroll by the smallest
> amount with the mouse, it scrolls by two lines.  I have the
> mouse-wheel-scroll-amount set to 1.  If I set it to 2, it scrolls by
> 4, and so on.  vim does the same thing, so I suspect that what's
> happening is that a single scroll is being reported as two. But the
> only way to be sure would be to get something that echos all
> keystrokes, so I could see if a single scroll is really being reported
> as two mouse-5 events.  C-h k won't work for this, because it only
> would show the first such event (if my theory is correct).
>
> Actually, I think I figured out that it's correct anyway, because I
> did C-h k and then scrolled up, and it showed me the help for mouse-5
> *and then* scrolled the document up by exactly one line.
>
> So I'll be reporting this as a bug to iTerm2.  I'll post back here if
> I find a solution.
>
> Aaron Meurer
>
> On Sat, Jan 14, 2012 at 9:53 AM, Drew Adams <drew.adams@oracle.com> wrote:
>>> Going back to my scrolling problem, is there a way to echo all
>>> keystrokes?  I mean, something similar to C-h k, except it echos
>>> multiple keystrokes.  I suspect that either my trackpad or iTerm2 may
>>> be reporting a single scroll as two scrolls, hence the multiplying by
>>> two problem.
>>
>> Not sure what you are asking or what problem you are encountering, but maybe
>> option `echo-keystrokes' will help?
>>

Re: Mouse support does not work

[Peter Dyballa]

Am 10.1.2012 um 23:50 schrieb Aaron Meurer:

> Second, starting a gui takes too long.

I've read of GNU Emacs users claiming that their Emacs session had a higher uptime than their system...

Anyway, GNU Emacs also supports working as a server or daemon. By using the little emacsclient utility you can make it open a frame. Or load a new file. (Or execute some Emacs Lisp code.) I haven't used this much – my terminal emulation runs inside GNU Emacs! (Which I also use instead of Xcode.)

--
Greetings

  Pete

One person with a belief is a social power equal to ninety-nine who have only interests.
				– John Stuart Mill

Re: Mouse support does not work

[Jonathan Groll]

On Wed, 11 Jan 2012 00:44:46 +0100, Peter Dyballa <Peter_Dyballa@web.de> wrote:
> 
> Anyway, GNU Emacs also supports working as a server or daemon. By using the little emacsclient utility you can make it open a frame. Or load a new file. (Or execute some Emacs Lisp code.) I haven't used this much – my terminal emulation runs inside GNU Emacs! (Which I also use instead of Xcode.)


Good points about why Emacs can be seen and used as just another
terminal app. However, there is a reason as to why (xterm-mouse-mode)
is not on by default, and that is largely due to the majority using
emacsclient and/or GUI Emacs.

After extended Emacs use a funny kind of thing happened to me, I
wanted to easily edit my mails/IRC/IM/web/twitter/terminal from within
Emacs. And it makes sense to be able to yank and kill terminal
commands into other buffers. So, many of us do indeed run our
terminals from within Emacs.

Cheers,
Jonathan
--
jjg: Jonathan J. Groll : groll co za
has_one { :blog => "http://bloggroll.com" }
I envy paranoids; they actually feel people are paying attention to them
-  Susan Sontag

Re: Mouse support does not work

[Jonathan Groll]

On Tue, 10 Jan 2012 15:50:41 -0700, Aaron Meurer <asmeurer@gmail.com> wrote:

> I want to scroll around and see what's highlighted, not press C-s a
> bunch of times.  Scrolling gives me visual feedback on where I am in
> the file that jump scrolling does not.  This is one of the reasons I
> want it to scroll one line at a time.

Try M-x occur ?

Cheers,
Jonathan
--
jjg: Jonathan J. Groll : groll co za
has_one { :blog => "http://bloggroll.com" }
I envy paranoids; they actually feel people are paying attention to them
-  Susan Sontag