Shall I go ahead and undo the part of my changes that enabled it by
default?
Yes, please do.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Richard Stallman wrote:
Its a question of giving priority to Emacs features or Xterm
features. Within Emacs, the mouse is used more often for Emacs
so it seems more natural that Emacs gets priority there.
It is a big incompatibility with usual xterm functionality,
and i
Its a question of giving priority to Emacs features or Xterm features.
Within
Emacs, the mouse is used more often for Emacs so it seems more natural that
Emacs gets priority there.
It is a big incompatibility with usual xterm functionality,
and it isn't very compatible with non-xterm
Eli Zaretskii wrote:
What's wrong with testing x-show-tip for being fboundp?
and Kim Storm wrote:
Since x-show-tip is only defined with X/W32/MAC, this should work:
(if (fboundp 'x-show-tip)
(load "tooltip"))
OK, I have installed that.
Sincerely,
Luc.
__
editing. I've tried
xterm-mouse-mode on and off, and I find I prefer "off", largely for
the reasons stated in this thread [the default xterm "interapp
cut-n-paste" behavior is more useful; the xterm-mouse-mode behavior
generally quite clunky feeling, esp. the lack of region
Nick Roberts <[EMAIL PROTECTED]> writes:
> > Because the a selection done with the mouse when xterm-mouse-mode is
> > active is not available to X. It is only available to Emacs, so it is
> > possible to use the mouse to copy between 2 emacs windows r
> Because the a selection done with the mouse when xterm-mouse-mode is
> active is not available to X. It is only available to Emacs, so it is
> possible to use the mouse to copy between 2 emacs windows running in
> the same terminal frame, but X know nothi
Because the a selection done with the mouse when xterm-mouse-mode is
active is not available to X. It is only available to Emacs, so it is
possible to use the mouse to copy between 2 emacs windows running in
the same terminal frame, but X know nothing about the selection.
I did
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Unless somebody knows how to accurately test whether Emacs was
> compiled --without-x in loadup.el.
Since x-show-tip is only defined with X/W32/MAC, this should work:
(if (fboundp 'x-show-tip)
(load "tooltip"))
--
Kim F. Storm <[EMAIL PROTECTED]>
On Friday 15 April 2005 11:23, Miles Bader wrote:
> On 4/15/05, Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> > (How many people compile Emacs `--without-x'?)
Well I do. Because Xlib/Gtk+ interface is not as good as cli one ( interface
wise ) imho.
ismail
_
> Date: Thu, 14 Apr 2005 21:04:31 -0500 (CDT)
> From: Luc Teirlinck <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
>
> One possibility is to only avoid preloading tooltip on MSDOS and not
> worry about `--without-x'. (How many people compile Emacs
> `--without
On 4/15/05, Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> (How many people compile Emacs `--without-x'?)
I do (on a system I only access remotely via ssh).
-Miles
--
Do not taunt Happy Fun Ball.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://li
Richard Stallman wrote:
It seems reasonable. But don't forget to update SOME_MACHINE_LISP.
I did that:
SOME_MACHINE_LISP = ${dotdot}/lisp/mouse.elc \
${dotdot}/lisp/select.elc ${dotdot}/lisp/scroll-bar.elc \
${dotdot}/lisp/vmsproc.elc ${dotdot}/lisp/vms-patch.elc \
${dotdot}/lisp/ls-li
Kim Storm wrote:
Since loadup.el is run in --batch mode, I would assume that
(display-graphic-p) is always false in that context.
Indeed, I should have tested my patches better. And window-system is
always nil too.
One possibility is to only avoid preloading tooltip on MSDOS and not
worry
>From my previous message:
If Xterm mouse mode is on, the user can not see the region
being selected, there is no highlighting until you release the mouse.
Unless you hold down the SHIFT key, of course, because then you get
the xterm functionality.
Sincerely,
a
lot more "usual" with Xterm Mouse mode _disabled_.
Anybody who uses Xterm Mouse mode _needs_ to know about the SHIFT
functionality. That is, needs to have read either the
xterm-mouse-mode docstring or `(emacs)XTerm Mouse'. Otherwise, the
m
xterm/another application. Not being able to do this makes the mouse
> > not very useful, and the user would blame emacs for this.
> >
> > Why would they not be able to do this?
> > It isn't obvious.
>
> Because the a selection done with the mouse whe
Richard Stallman <[EMAIL PROTECTED]> writes:
> Doesn't Xterm Mouse mode communicate selections to X in the usual way?
It can't, since Emacs does not know how to contact the X server.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Max
Did you try out Xterm Mouse mode for any prolonged period of time,
performing non-trivial tasks?
No, I have never used it. I normally use Emacs on text consoles, and
the last thing I want to do is use the mouse. It is supposed to make
Emacs handle the mouse in the usual way when running
The argument is like this: a lot of users ONLY use the mouse in an xterm
to select text and then use mouse-2 to paste it in another
xterm/another application. Not being able to do this makes the mouse
not very useful, and the user would blame emacs for this.
Why would they not be
The C and Lisp conditions for loading tooltip in the patches below are
not completely equivalent, but I believe I understood that this does
not matter too much. I saw everything else that was conditionally
loaded use a FOO_SUPPORT macro, so I defined a TOOLTIP_SUPPORT macro.
It se
not very useful, and the user would blame emacs for this.
>
> Why would they not be able to do this?
> It isn't obvious.
Because the a selection done with the mouse when xterm-mouse-mode is
active is not available to X. It is only available to Emacs, so it is
possible to use t
Hi Kai.
[EMAIL PROTECTED] (Kai Großjohann) said:
> How about providing an option to reverse this? Then shifted clicks
> would access the special xterm mouse mode function, and unshifted
> clicks would do as if xterm mouse mode was off.
This is not possible to do from within emacs beca
Currently, when xterm mouse mode is on, unshifted clicks do something
special, and shifted clicks do as if xterm mouse mode was off.
How about providing an option to reverse this? Then shifted clicks
would access the special xterm mouse mode function, and unshifted
clicks would do as if xterm
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> ===File ~/loadup-diff===
> *** loadup.el 19 Mar 2005 13:28:44 -0600 1.135
> --- loadup.el 13 Apr 2005 20:15:24 -0500
> ***
> *** 192,197
> --- 192,200
>
> (load "vc-hooks")
> (lo
> Date: Wed, 13 Apr 2005 21:16:40 -0500 (CDT)
> From: Luc Teirlinck <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> + #if defined (HAVE_WINDOW_SYSTEM) && !defined (MSDOS)
You don't need to test for MSDOS here, since the MSDOS port doesn't
define HAVE_WINDOW_SYSTEM.
> From: Ismail Donmez <[EMAIL PROTECTED]>
> Date: Wed, 13 Apr 2005 22:08:15 +0300
> Cc: emacs-devel@gnu.org
>
> Thanks also can you document the change in Changelog so people can see whats
> going on.
This change _is_ documented in Changelog (and in NEWS, where users
should look for such changes
The C and Lisp conditions for loading tooltip in the patches below are
not completely equivalent, but I believe I understood that this does
not matter too much. I saw everything else that was conditionally
loaded use a FOO_SUPPORT macro, so I defined a TOOLTIP_SUPPORT macro.
I can only test this
Richard Stallman wrote:
I don't follow the logic. While the failure to implement some mouse
features is clearly a drawback, why would it be better to implement
none than to implement some? I don't see it.
Did you try out Xterm Mouse mode for any prolonged period of time,
I see that xterm-mouse-mode is now enabled by default I see one
problem with it. Adding (xterm-mouse-mode -1) in .emacs doesn't
disable it because it seems like the added code in startup.el does
no config check ( I don't know any idea about lisp I am just
judging fro
On Wednesday 13 April 2005 21:53, you wrote:
>I see that xterm-mouse-mode is now enabled by default I see one problem
> with it. Adding (xterm-mouse-mode -1) in .emacs doesn't disable it because
> it seems like the added code in startup.el does no config check ( I don't
&g
I see that xterm-mouse-mode is now enabled by default I see one problem with
it. Adding (xterm-mouse-mode -1) in .emacs doesn't disable it because it
seems like the added code in startup.el does no config check ( I don't know
any idea about lisp I am just judging fro
Richard Stallman <[EMAIL PROTECTED]> writes:
> xterm-mouse-mode is missing some very useful functionality (at least
> IMO):
> - it is not possible to double-click to select a word/line/etc.
> - it is not possible to select text with the mouse
Hi all,
I see that xterm-mouse-mode is now enabled by default I see one problem with
it. Adding (xterm-mouse-mode -1) in .emacs doesn't disable it because it
seems like the added code in startup.el does no config check ( I don't know
any idea about lisp I am just judging fro
xterm-mouse-mode is missing some very useful functionality (at least
IMO):
- it is not possible to double-click to select a word/line/etc.
- it is not possible to select text with the mouse in emacs and then
use mouse-2 to paste in another xterm, or emacs. How would you
The main reason for wanting to click on the mode line is to resize the
window. Should we not disable all the other fireworks in the mode
line when we can not warn the user about them, that is, when not
running under a window system?
That is a good idea. For those features that do
Richard Stallman <[EMAIL PROTECTED]> writes:
> In the case of define-minor-mode, perhaps it could be arranged that, for
> example, (tooltip-mode 2) sets tooltip-mode to the standard value.
>
> It would be a mistake to change a general Enacs convention just to
> save some lines in startup.e
> Cc: emacs-devel@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
> From: "Jan D." <[EMAIL PROTECTED]>
> Date: Wed, 13 Apr 2005 06:58:04 +0200
>
> > But how do you check whether configure was invoked with `--without-x'
> > from Lisp and from C?
>
> #ifndef HAVE_X_WINDOWS
Actually, I'd suggest
#i
> Date: Tue, 12 Apr 2005 20:24:49 -0500 (CDT)
> From: Luc Teirlinck <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> I guess that you check for MSDOS with `(eq system-type 'ms-dos)' from
> Lisp and with `#ifdef MSDOS' from C.
Only if no other good method exists. Usually, test
In the case of define-minor-mode, perhaps it could be arranged that, for
example, (tooltip-mode 2) sets tooltip-mode to the standard value.
It would be a mistake to change a general Enacs convention just to
save some lines in startup.el. Quite the contrary; I would gladly pay
the price of
2I guess that you check for MSDOS with `(eq system-type 'ms-dos)' from
Lisp and with `#ifdef MSDOS' from C.
But how do you check whether configure was invoked with `--without-x'
from Lisp and from C?
#ifndef HAVE_X_WINDOWS
You can check window-system in Lisp (it is nil), but it doesn't tell if
the
On 4/13/05, Dan Nicolaescu <[EMAIL PROTECTED]> wrote:
> A lot of users use these features, so IMO it is not a good idea to
> turn on xterm-mouse-mode by default at this point.
FWIW, the "native" xterm mouse behavior can still be used even when
emacs xterm-mouse-mode is enabl
> I have now enabled Xterm Mouse mode by default in xterm style terminal
> emulators, as requested. As I pointed out before, this is not without
> problems.
Indeed, xterm-mouse-mode is a nice hack, but it has rough edges and I'd
rather not see it turned on by default.
A lot of users use these features, so IMO it is not a good idea to
turn on xterm-mouse-mode by default at this point.
I was the one who enabled Xterm Mouse mode by default. But I did it
on request, because I knew how to do it without confusing Custom. I
personally recommended against it
with Xterm Mouse
mode, you do not get their replacement, echo area messages either.
That is the problem. And there is no mouse face.
The "fireworks" are not destructive and usually deliver a text message
what happened. I don't see much of a problem here.
A not very experienc
It seems that xterm-mouse-mode is on by default now.
xterm-mouse-mode is missing some very useful functionality (at least
IMO):
- it is not possible to double-click to select a word/line/etc.
- it is not possible to select text with the mouse in emacs and then
use mouse-2 to paste in
I guess that you check for MSDOS with `(eq system-type 'ms-dos)' from
Lisp and with `#ifdef MSDOS' from C.
But how do you check whether configure was invoked with `--without-x'
from Lisp and from C?
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> I have now enabled Xterm Mouse mode by default in xterm style
> terminal emulators, as requested. As I pointed out before, this is
> not without problems.
>
> One of the worst kind of problems occurs when you click on the mod
I have now enabled Xterm Mouse mode by default in xterm style terminal
emulators, as requested. As I pointed out before, this is not without
problems.
One of the worst kind of problems occurs when you click on the mode
line. You get no tooltips or echo area messages to tell you what is
going to
Ok, please install.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Conditionally and explictly preloading it will not get rid of the
code duplication. I would have to preload it _after_ startup.el, to
avoid making the code more complicated with boundp's and fboundp's, to
prevent errors for variables and functions that might not yet be
defined
two need
That was a typo. Meant was: in the xterm-mouse-mode defcustom.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
The following patches would enable Xterm Mouse mode when it makes
sense, without confusing Custom. *Note* however, that there are some
additional problems I discovered (while testing the patches) with
enabling it. Clicking mouse-1 can do all kinds of unexpected stuff,
without the usual mouse
>From my previous message:
Conditionally and explictly preloading it will not get rid of the
code duplication.
Actually, preloading tooltip.el _before_ startup.el might avoid some
code duplication for the standard value code (which is small anyway),
but it would actually increase the total
Richard Stallman wrote:
Please do preload tooltip, except in the two conditions that Eli
identified. Since it will nearly always be used, it's good to have
it preloaded.
Conditionally and explictly preloading it will not get rid of the
code duplication. I would have to preload it _afte
Problem is, xterm.el is loaded after .emacs, so doing it in xterm.el makes
it difficult for users to turn it off.
In that case, I agree let's handle it Luc's way.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/l
Please do preload tooltip, except in the two conditions that Eli
identified. Since it will nearly always be used, it's good to have
it preloaded.
However, xt-mouse should never be preloaded.
Please go ahead and adapt your change to that decision, and install it.
___
Nick Roberts wrote:
I don't know how to access the standard value (:init-value?), what
would happen if its not set, etc, but if its a sensible idea, I
could look at it.
The standard value is the _unevaluated_ expression given as value in
the defcustom. In the case of define-minor-mode,
> > confusion with some prior similar cases. The only drawback of not
> > preloading it is that we need to duplicate the same code in the
> > defcustom and in startup.el and make sure that the two stay exactly in
> > sync.
>
> There are other ways to avoid this duplication. See patch below.
Stefan Monnier wrote:
There are other ways to avoid this duplication. See patch below.
Stefan
--- startup.el 08 avr 2005 10:38:07 -0400 1.344
+++ startup.el 10 avr 2005 10:35:33 -0400
@@ -737,7 +737,8 @@
emacs-quick-startup
> confusion with some prior similar cases. The only drawback of not
> preloading it is that we need to duplicate the same code in the
> defcustom and in startup.el and make sure that the two stay exactly in
> sync.
There are other ways to avoid this duplication. See patch below.
Stefan
> I don't like preloading xt-mouse, since most users don't want it.
> Could you make lisp/term/xterm.el load it instead?
Problem is, xterm.el is loaded after .emacs, so doing it in xterm.el makes
it difficult for users to turn it off.
Stefan
stall if desired.
xterm-mouse-mode could be taken care of in a similar fashion (without
preloading) if that would be what we want to do.
===File ~/startup.el-diff===
*** startup.el 08 Apr 2005 19:21:40 -0500 1.344
--- startup.el 10 Apr 2005 07:28:30
> From: Richard Stallman <[EMAIL PROTECTED]>
> Date: Sat, 09 Apr 2005 21:54:53 -0400
> Cc: emacs-devel@gnu.org
>
> Preloading tooltip is ok, since that usually will not be wasted.
Except in Emacs compiled with --without-x and on MSDOS. So please
let's not preload tooltip in those cases.
__
Also is it necessary to explain explicitly in the manual how to turn each
mode
off?
It isn't an absolute rule that we must always document turning off
everything, but in this case some people might want it.
___
Emacs-devel mailing list
Emacs-d
ted.
Also, please don't forget to mention in etc/NEWS that xterm-mouse-mode
will be enabled by default.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
>I'm not sure what should be done for customize though. Luc?
>
> I could handle that. However, I really start to doubt that enabling
> xterm-mouse-mode by default in all terminals for which we believe it
> makes sense is a good idea. As we have seen, Xterm Mous
Nick Roberts wrote:
I'm not sure what should be done for customize though. Luc?
I could handle that. However, I really start to doubt that enabling
xterm-mouse-mode by default in all terminals for which we believe it
makes sense is a good idea. As we have seen, Xterm Mouse mode has a
> Yes. See also the various calls to (getenv "TERM") in startup.el,
> xterm.el and rxvt.el: there are a few more terminal names that could
> benefit from this change, which the code there mentions.
Right. So xterm-mouse-mode shouldn't be enabled in xterm.el b
> From: Nick Roberts <[EMAIL PROTECTED]>
> Date: Sat, 9 Apr 2005 17:22:29 +1200
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> You don't explain the reasoning behind loading xt-mouse in loadup.el. I
> imagine it doesn't get used very often and I thought Richard said it should be
> loaded/enabled
> The following patches enable xterm-mouse-mode by default in xterm type
> terminals, document this in the Emacs manual (I would also document it
> in the NEWS) and fix the Custom related bug for tooltip-mode.
>
> I can install if desired.
You don't explain the reasoni
The following patches enable xterm-mouse-mode by default in xterm type
terminals, document this in the Emacs manual (I would also document it
in the NEWS) and fix the Custom related bug for tooltip-mode.
I can install if desired.
===File ~/man-frames.texi-diff
Nick Roberts wrote:
I recently changed tooltip-mode to a minor-mode which previously used a
function and a variable and keywords like:
:initialize 'custom-initialize-default
Have I created problems for customize here?
No, I believe the problem was already there before that change.
>The natural place to do it is in lisp/term/xterm.el.
>Would someone please install (xterm-mouse-mode 1) there?
>
> It is a little bit more complex than that. It has to be done in the
> right way for the defcustom. Just writing (xterm-mouse-mode 1) in
> term/xt
Richard Stallman wrote:
So I think it is a good idea.
The natural place to do it is in lisp/term/xterm.el.
Would someone please install (xterm-mouse-mode 1) there?
It is a little bit more complex than that. It has to be done in the
right way for the defcustom. Just writing (xterm
Nick Roberts <[EMAIL PROTECTED]> writes:
> By when needed, I mean "when Emacs is started in an xterm" i.e putting
> something like:
>
> (if (string= "xterm" (getenv "TERM")) (xterm-mouse-mode 1))
This should use string-match since there are many
putting
something like:
(if (string= "xterm" (getenv "TERM")) (xterm-mouse-mode 1))
in startup.el
This would only cause a problem for a user who wants to use the
ordinary xterm mouse commands even when an Emacs is running there.
I doubt many users find that par
Richard Stallman <[EMAIL PROTECTED]> writes:
> There are embedded Linux systems that are most definitely not GNU, and
> for example the system at http://www.skarnet.org/poweredby.html>
> runs Linux, but not the GNU system.
>
> Emacs is evidently not included, nor could it run without G
There are embedded Linux systems that are most definitely not GNU, and
for example the system at http://www.skarnet.org/poweredby.html>
runs Linux, but not the GNU system.
Emacs is evidently not included, nor could it run without GNU libc.
We can't demand correctness from others w
I think calling it the GNU/Linux console could harm
the GNU Project: it could create a backlash from kernel developers who are
currently sympathetic to the use of GNU/Linux to describe the system.
In 20 years I have learned that it is a mistake to worry too much
about the possibility o
I mean enable not load.
Nick
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
>I've only found it helpful to have "Mouse" in the mode-line so I know it
>has actually loaded. If it is removed, might it make sense to
>conditionally load xt-mouse in startup.el to ensure its always loaded
> when needed?
>
> `xterm-mouse-
Nick Roberts wrote:
I only enable xterm-mouse-mode in an xterm:
I enabled it through Custom, and I assume that is what most users who
want to set it are going to do. I do not believe that there is a lot
of harm or inefficiency in that, since `xterm-mouse-mode' does nothing
if window-s
e "Mouse" just seems too waste precious space in the mode line.
I only enable xterm-mouse-mode in an xterm:
(if (eq window-system 'nil)
(if (string= "xterm" (getenv "TERM"))
(progn
(xterm-mouse-mode 1)
(load-library "t-mouse"
> The "Linux kernel console" -- as the user sees it on a GNU/Linux system--
> is typically just a process started by the kernel which runs "/bin/sh".
>
> So when the user interacts with the console, he is interacting with
> GNU software (e.g. bash), not the kernel.
In this context the user i
[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> Richard Stallman <[EMAIL PROTECTED]> writes:
>>
>>> The console clearly is exclusively a feature of the kernel.
>>>
>>> The console is implemented by the kernel, but you use it to log in
>>> to the whole
Kim F. Storm wrote:
> Does Emacs run on those systems?
>
> The "Linux kernel console" -- as the user sees it on a GNU/Linux
> system-- is typically just a process started by the kernel which
> runs "/bin/sh".
>
> So when the user interacts with the console, he is interacting
> with GNU software (e.
David Kastrup <[EMAIL PROTECTED]> writes:
> Richard Stallman <[EMAIL PROTECTED]> writes:
>
>> The console clearly is exclusively a feature of the kernel.
>>
>> The console is implemented by the kernel, but you use it to log in
>> to the whole system.
>
> There are embedded Linux systems that a
ce in the mode line.
===File ~/xt-mouse-diff-b===
*** xt-mouse.el 03 Apr 2005 19:34:53 -0500 1.25
--- xt-mouse.el 06 Apr 2005 14:47:20 -0500
***
*** 156,165
With prefix arg, turn XTerm mouse mode on iff arg is positive.
Turn it o
Richard Stallman <[EMAIL PROTECTED]> writes:
> The console clearly is exclusively a feature of the kernel.
>
> The console is implemented by the kernel, but you use it to log in
> to the whole system.
There are embedded Linux systems that are most definitely not GNU, and
for example the syste
The console clearly is exclusively a feature of the kernel.
The console is implemented by the kernel, but you use it to log in to
the whole system. Thus, both "Linux console" and "GNU/Linux console"
are justifiable.
If we call it the "Linux console", everyone who isn't a wizard will
misunder
Richard Stallman <[EMAIL PROTECTED]> writes:
> > The GNU/Linux console currently does not appear to support
> > `xterm-mouse-mode'.
>
> I think this should just say Linux console although I don't
> really understand where the kernel ends
> ! This works in terminal emulators compatible with xterm. Only
> ! non-modified single clicks are supported. When turned on, the
> ! normal xterm mouse functionality for such clicks is still available
> ! by holding down the SHIFT key while pressing the mouse button."
Its a bit more quirky
> The GNU/Linux console currently does not appear to support
> `xterm-mouse-mode'.
I think this should just say Linux console although I don't really
understand
where the kernel ends and the operating system begins.
Neither "Linux console"
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Nick Roberts wrote:
>
>> The GNU/Linux console currently does not appear to support
> > `xterm-mouse-mode'.
>
>I think this should just say Linux console although I don't
>really understand whe
Nick Roberts wrote:
>The GNU/Linux console currently does not appear to support
>`xterm-mouse-mode'.
I think this should just say Linux console although I don't really
understand where the kernel ends and the operating system begins.
Neither do I, but Ric
> The GNU/Linux console currently does not appear to support
> `xterm-mouse-mode'.
I think this should just say Linux console although I don't really understand
where the kernel ends and the operating system begins.
> The normal `xterm' mouse functionali
Nick Roberts wrote:
> ! The Linux console supports this mode if it has support for the mouse
> ! enabled, for instance using the gpm daemon."
Is this true? I couldn't get it to work in a Linux console and I
can't see how it could work outside the context of X (xt-mouse
knows
> ! The Linux console supports this mode if it has support for the mouse
> ! enabled, for instance using the gpm daemon."
Is this true? I couldn't get it to work in a Linux console and I can't see how
it could work outside the context of X (xt-mouse knows nothing about gpm).
The original autho
`xterm-mouse-mode' relies on a bogus default :group, chosen by
define-minor-mode, xterm-mouse, that does not have one of the major
groups as an ancestor (in fact, that does not even have a parent
group). As a result, users can never find it while browsing Custom
using `customize-brows
100 matches
Mail list logo
