I think the default value of keyboard-coding-system in Carbon Emacs
has been source of annoyance. Users have to set an appropriate value
to input non-ASCII characters using external input methods or
combinations with the option key.
The patch below is an attempt to solve such a problem by dynamic
> ! 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
It is intended to be an option turn off all "extra features".
On what criterion are these features "extra"?
But most important, running emacs -Q when debugging redisplay problems
makes it much easier to know what's going on.
Why does the blinking cursor relate to this?
Just beca
> 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" nor "GNU/Linux console" is incorrect
If you find it works, please install it.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
> On Fri, 01 Apr 2005 16:32:41 +0200, Sébastien Kirche <[EMAIL PROTECTED]>
> said:
> Hi, while building Emacs for OS9 (non-Carbon), I noticed that the
> version number displayed in the info window of the Finder was not up
> to date.
I've just changed version strings and other related fie
The included patch to src/macterm.c extends Carbon Emacs' drag-n-drop
to handle directories, URLs, and text. To use it, the included Lisp
code also needs to be added to the appropriate Lisp file, probably
lisp/term/mac-win.el. This is my first foray into Emacs C-hackery, so
although it's been wor
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 where the kernel ends and the operating system
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 Richard asked me to refe
I asked Zajcev Evgeny what limitations prevents running XWEM
under GNU Emacs. Perhaps something to work on after the release...
Zajcev Evgeny <[EMAIL PROTECTED]> writes:
I did not looked too close to GNU Emacs, but at a time when i was
trying to port xwem to GNU Emacs i was faced to those probl
Cian Hughes <[EMAIL PROTECTED]> writes:
> Hi, I'm currently running Mac OS X 10.4 which is currently
> unreleased commercial software, so having agreed to an NDA I really
> have no right to ask for your help.
The problem is rather that you have no right to _offer_ your help.
What goes into Emacs,
Hi, I'm currently running Mac OS X 10.4 which is currently unreleased commercial software, so having agreed to an NDA I really have no right to ask for your help. However I have discovered a very serious issue with emacs on Mac OS X 10.4 (tiger) and due to a change in carbon, emacs (latest CVS vers
- Original Message -
From: "Richard Stallman" <[EMAIL PROTECTED]>
> Meanwhile, we could afford to maintain this for one set of widgets,
> such as GTK. But if the idea were to use the native widget set of
> every system, you're talking about a tremendous amount of work.
What about wxwidg
From a UI and an OS X perspective, customization buffers should
definitely go into proper dialogues with native widgets.
Most cases, perhaps nearly all, would be easily handled with those
native widgets. But it might be hard to make this support everything
that Emacs customizations actu
Lute Kamstra <[EMAIL PROTECTED]> writes:
> generic.el currently contains two facilities:
>
> 1. Defining major modes by means of define-generic-mode.
>
> 2. The definition of default-generic-mode and some setup code to use
>it automatically for some files.
>
> I think 2. is a strange side-effe
> I don't know if an out-of-the-box configuration for the default Emacs is
> needed - the idea of a distribution like what we demonstrate with Aquamacs
> might already do the job. People with other needs - a cross-platform
> compatible Emacs - will then be happy to use the 'conservative'
> version
> +(add-to-list 'auto-mode-alist '("\\.gcov$" . compilation-mode))
^^^
\\'
-- Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listi
David Kastrup <[EMAIL PROTECTED]> writes:
> --stripped-down
--naked :-)
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> --stripped-down
>
> --naked :-)
Too close to --flashing.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
___
Emacs-devel mailing list
Emacs-devel@gnu.org
htt
[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> --basic-defaults
>>
>> would be another possibility.
>
> Still, "defaults" is non-informative in this context.
>
> IMO --minimal would be good, but is too close to --minimize.
>
> Some synonymes are:
>
> --ba
David Kastrup <[EMAIL PROTECTED]> writes:
> --basic-defaults
>
> would be another possibility.
Still, "defaults" is non-informative in this context.
IMO --minimal would be good, but is too close to --minimize.
Some synonymes are:
--basic
--slim
--mean
--reduced
--nominal
--
Kim F. Storm <[EM
Reiner Steib <[EMAIL PROTECTED]> writes:
[...]
> I have committed the changes to Gnus v5-10 branch. If anyone want to
> handle the compiler differently, feel free to change it.
I'd prefer to handle it like in the patch below. If the function
message-make-date or nnimap-date-days-ago is called
"Robert J. Chassell" <[EMAIL PROTECTED]> writes:
>> -Q
>
>It is intended to be an option turn off all "extra features".
>
> Yes. The option is helpful and should be kept.
>
> It is easier than evoking Emacs with an equivalent long string of
> options, which are:
>
> emacs -q
> -Q
It is intended to be an option turn off all "extra features".
Yes. The option is helpful and should be kept.
It is easier than evoking Emacs with an equivalent long string of
options, which are:
emacs -q \
--no-site-file \
--no-blinking-cursor \
--
Miles Bader <[EMAIL PROTECTED]> writes:
> On Apr 5, 2005 7:27 PM, Miles Bader <[EMAIL PROTECTED]> wrote:
>>emacs -Q -N
>>
>> where -Q means "no init files or site-init files"
>> and -N means turn off all frame features
>
> I should add that doing so is more flexible for debugging too -- for
>
I have written a regexp to handle a gcov output in compile.el.
2005-04-05 Masatake YAMATO <[EMAIL PROTECTED]>
* progmodes/compile.el (compilation-error-regexp-alist-alist): Add
regexp for gcov.
2005-04-05 Masatake YAMATO <[EMAIL PROTECTED]>
* compilation.txt (symbol)
On Apr 5, 2005 7:27 PM, Miles Bader <[EMAIL PROTECTED]> wrote:
>emacs -Q -N
>
> where -Q means "no init files or site-init files"
> and -N means turn off all frame features
I should add that doing so is more flexible for debugging too -- for
instance, for reporting a bug with menus, you don't
On Apr 5, 2005 7:04 PM, Kim F. Storm <[EMAIL PROTECTED]> wrote:
> > There seems no reason not to split it into a couple of more coherent
> > options though.
>
> So instead of "emacs -Q" I have to ask a user to please try
> "emacs -q -A -T --no-bla-bla -V --no-blinking-cursor"
That's a strawman.
Miles Bader <[EMAIL PROTECTED]> writes:
> On Apr 5, 2005 4:14 PM, Kim F. Storm <[EMAIL PROTECTED]> wrote:
>> >> Can't you move this closer to the definition of message-make-date?
>> >> It's only necessary to suppress compiler warnings for that function.
>> >
>> > I put it inside the defun.
>>
>>
Miles Bader <[EMAIL PROTECTED]> writes:
> On Apr 5, 2005 4:31 PM, Kim F. Storm <[EMAIL PROTECTED]> wrote:
>> Just because we cannot find a long name for it -- that's silly, IMO!
>> Please keep the option. It serves the purpose it was added for very
>> well!!
>
> There seems no reason not to split
On Apr 5, 2005 4:31 PM, Kim F. Storm <[EMAIL PROTECTED]> wrote:
> Just because we cannot find a long name for it -- that's silly, IMO!
> Please keep the option. It serves the purpose it was added for very
> well!!
There seems no reason not to split it into a couple of more coherent
options though
On Apr 5, 2005 4:14 PM, Kim F. Storm <[EMAIL PROTECTED]> wrote:
> >> Can't you move this closer to the definition of message-make-date?
> >> It's only necessary to suppress compiler warnings for that function.
> >
> > I put it inside the defun.
>
> Doing that will slow down the function, so if tha
Richard Stallman <[EMAIL PROTECTED]> writes:
> The patch is trivial, but we should probably add a long name for it.
>
> I guess so--if we keep it. But the set of things it does is not
> really coherent.
>
> It turns off all init files; it also turns off various frame features
> such as the me
Reiner Steib <[EMAIL PROTECTED]> writes:
>> Can't you move this closer to the definition of message-make-date?
>> It's only necessary to suppress compiler warnings for that function.
>
> I put it inside the defun.
Doing that will slow down the function, so if that function is used
a lot, I think
34 matches
Mail list logo
