Juri Linkov wrote:
I don't remember what the decision was, but if it was to postpone this
until the next release, then perhaps this should be added to etc/TODO.
We decided to put it off until after the release, because the exact
details of what we really wanted to do were not clear. There
2005/7/2, Juri Linkov <[EMAIL PROTECTED]>:
> > The diff-mode colors on a dark-background terminal (gnome-terminal or
> > generic xterm) are:
...
> > These colors work very well and should not be changed
>
> Bold text is unreadable on terminals with small fonts.
I have not found this to be the cas
> I fixed these bugs in crm.el. Thanks.
There are still three more bugs. Typing TAB with no more completions
moves point into the read-only area. This happens, for example,
after evaluating
(completing-read-multiple "Prompt: " '(("hi") ("there")))
and typing `h TAB TAB'.
The second bug doesn
>> Something has to be done about colors of diff context, because
>> currently it is white on black for dark backgrounds, and yellow
>> on white for light backgrounds.
>
> The diff-mode colors on a dark-background terminal (gnome-terminal or
> generic xterm) are:
>
>Changed lines: yellow+bold
>> On TTY it classifies colors as follows:
>>
>> Dark: black red green blue
>> Light: magenta yellow cyan white
>>
>> But on xterm it is quite different:
>>
>> Dark: black red green blue magenta yellow cyan
>> Light: white
>>
>> That anomaly could be worth fixing.
>
>
> According to this classification, yellow is a dark color,
> as it were suitable as a foreground color for light backgrounds.
>
> I think that is a non-issue. Emacs never chooses foreground colors
> based on such a classification. The only thing Eacs does based on
> this classification i
> Your patch looks good to me. Please install it.
>
> One drawback of such approach is that it
>doesn't allow completion for multiple face names (there is the file
>emacs-lisp/crm.el distribued with Emacs that could be used here but
>it is not up-to-date).
>
> Could y
> Someone spoke of working on the task of updating info.texi.
> Has that job been done?
I started looking into updating info.texi and have a few questions.
Two new Info features are marked in etc/NEWS file with ---. Those are
new user options `Info-fontify-visited-nodes' and `Info-isearch-search
>> so why wouldn't it also run a setter specified
>> by the `:set' custom keyword?
>
>It probably should. I'll take a look at it. I'm not custom expert,
>though; I hardly use the stuff.
>
> I have not been following this thread. Are you discussing making
> set-variable calling any
2005/7/2, Richard M. Stallman <[EMAIL PROTECTED]>:
> (defun new-file (filename)
> (interactive)
> (let ((find-file-confirm-existing t))
> (find-file filename)))
>
> Would you like to implement this?
Er, sure.
-Miles
--
Do not taunt Happy Fun Ball.
_
Markus Gritsch wrote:
I am using the prebuilt CVS Emacs for Windows from
http://www.crasseux.com/emacs/. Can someone on another platform please
try to reproduce the bug, to see if it is specific to the Win32 version
or a general problem?
I have reproduced it on today's CVS, my mingw build, W
Lennart Borgman wrote:
Cvs just checked out. GnuWin32 Make. No sh. MinGW:
...
Emacs successfully configured.
Run `gmake' to build, then run `gmake install' to install.
D:\ecvs\bld\emacs\nt>make bootstrap
', needed by `addsection'. Stop.`oo-spd/i386/addsection.exe
Eh..., sorry, this was just
On 7/2/05, Lennart Borgman <[EMAIL PROTECTED]> wrote:
> Cvs just checked out. GnuWin32 Make. No sh. MinGW:
Works for me with:
- make 3.80 (from UnxUtils)
- no sh
- MinGW (GCC 3.4.2)
--
/L/e/k/t/u
___
Emacs-devel mailing lis
2005/7/2, Ilya Zakharevich <[EMAIL PROTECTED]>:
> > That is, apply all Emacs changes since the last merge point to your
> > current version, and resolve any conflicts.
>
> My point is that most edits must be removed, since they introduce much
> more problems than they fix.
Maybe you are right, bu
Juri Linkov wrote:
What about such a patch? I have tested it on GNU/Linux, but the
change in w32term.c is untested. I hope someone will test it
on Windows.
FWIW, the patch looks okay on Windows. I customized vertical-border to make a
pink window border. (I don't know why, but more importan
Cvs just checked out. GnuWin32 Make. No sh. MinGW:
...
Emacs successfully configured.
Run `gmake' to build, then run `gmake install' to install.
D:\ecvs\bld\emacs\nt>make bootstrap
', needed by `addsection'. Stop.`oo-spd/i386/addsection.exe
___
Ema
Miles Bader wrote:
So unless there are strong objections, I'll implement that by default
(well unless somebody else wants to implement it; David?).
Go for it. Work has been keeping me otherwise occupied.
Are there funny names for backtab other than those mentioned in this thread?
Look for
On 7/2/05, Jason Rumney <[EMAIL PROTECTED]> wrote:
> Juanma Barranquero <[EMAIL PROTECTED]> writes:
> How common is it to have FF FE or FE FF as the first two characters in
> text in any other encoding?
Pretty uncommon. I haven't said otherwise. I'm just pointing out what
I suppose is the origina
C-mouse-2 brings up the Text Properties menu, but only when the pointer is
over text in a buffer.
Currently, this menu uses the position of point for its position-oriented
commands, but I suggested that it might better use the pointer position. If
that were done, then there are additional, non-buf
On Fri, Jul 01, 2005 at 10:20:31AM +0900, Miles Bader wrote:
> Ilya Zakharevich <[EMAIL PROTECTED]> writes:
> > *Something* must be done in this situation.
>
> Sure, it sounds like a proper merge is in order.
>
> That is, apply all Emacs changes since the last merge point to your
> current versio
On 7/1/05, Gaëtan LEURENT <[EMAIL PROTECTED]> wrote:
> Well, a Latin-1 file is quite unlikely to begin with «þÿ» or «ÿþ».
Sure. But "quite unlikely" is not "imposible".
> I think it's the case on MS Windows.
Well, I use MS Windows and most of my files are ASCII, Latin-1,
Latin-9, a few UTF-8. O
FWIW, Fedora core 2 works OK with this change.
Does that mean we can delete the other PROBLEMS item?
(The one about exec_shield, that is.)
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
> The test may pass any linux kernel which has personality system call.
> I guess there is no way to test.
>
> It is easy to test whether that system call exists.
> That is what Autoconf is good at.
>
> If that is all we need to test, let's do it.
No. The test whether that system call ex
I thought about this, but the thing is: the external bug reporting
facility will run the mail client and cause it to start a new message
editor. If we changed sendmail.el, we would present users with the
internal editor first (for bug-reporting), then show them the same e-
(defun new-file (filename)
(interactive)
(let ((find-file-confirm-existing t))
(find-file filename)))
That is a fine way, but the variable find-file-confirm-existing
doesn't seem to exist yet.
Would you like to implement this?
> I think it's only ambiguous if you used symbols in a _mixed_ list --
> one with both plain symbols and cons-cells with a symbol as their car.
> If the elements of the list are consistently one or the other, the
> pattern (lambda (arg ...) ...) can never occur.
And the lambda
The test may pass any linux kernel which has personality system call.
I guess there is no way to test.
It is easy to test whether that system call exists.
That is what Autoconf is good at.
If that is all we need to test, let's do it.
___
Emacs
I think that a soft newline, most particularly so in the context of
longlines.el, should pretty much be a space with a display property of
newline on it, so search and replace would not even see it as anything
but space.
That could be too drastic--I don't think that commands that
n
With the current code, they do _not_ get reloaded when already loaded.
If I would re-implement it, they would be reloaded.
If that's the easiest way to get correct functioning, please do it.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http
Nikhil Nair <[EMAIL PROTECTED]> writes:
> I've now had a chance to play with Windows emacs, and, with this feature
> enabled, it works very nicely with JAWS (a popular screen reader).
> However, if it's supposed to be autodetecting screen readers, this isn't
> working at all: I had to add (setq w3
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> Well, yeah, but FF and FE *are* valid characters in many encodings.
How common is it to have FF FE or FE FF as the first two characters in
text in any other encoding? Is it acceptable for Emacs to ignore the
most common case where those two bytes w
> Kim F. Storm wrote
> Sounds like the cvs / ssh problem described in INSTALL.CVS.
> Yes. However, the bug was discussed a long time ago.
> vc-annotate (or cvs or ssh) should have been fixed by now.
IIUC the general "consensus" is that it's a problem in SSH but that the SSH
people don't acce
> Date: Fri, 1 Jul 2005 17:50:54 +0100 (BST)
> From: Nikhil Nair <[EMAIL PROTECTED]>
>
> However, if it's supposed to be autodetecting screen readers, this isn't
> working at all: I had to add (setq w32-use-visible-system-caret t) to my
> .emacs.
>
> Although I don't really use it any more, I hav
Juanma Barranquero wrote on 01 Jul 2005 20:01:14 +0200:
>> Shouldn't the utf-x files with signature be quite in front of the list
>> of detected coding systems? I mean, that's what the signature is good
>> for in the first place, right?
>
> Well, yeah, but FF and FE *are* valid characters in man
As you had a recipe for reproducing this, it is probably the œ
character
that is either miscoded in the string argument (the penultimate
argument,
an XChar2b *) or it is missing in the font used for bold. If you
can print
the values in the XChar2b* (the last argument to XDrawImageString
On 7/1/05, David Kastrup <[EMAIL PROTECTED]> wrote:
> Shouldn't the utf-x files with signature be quite in front of the list
> of detected coding systems? I mean, that's what the signature is good
> for in the first place, right?
Well, yeah, but FF and FE *are* valid characters in many encodings
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> On 7/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> Can you give me any advice how to achive this?
>
> Try
>
> C-x RET c utf-16-le RET
>
> (that's `universal-coding-system-argument'), then:
>
> C-x C-f yourfile RET
>
> and you should be a
Kim F. Storm wrote
Sounds like the cvs / ssh problem described in INSTALL.CVS.
Yes. However, the bug was discussed a long time ago.
vc-annotate (or cvs or ssh) should have been fixed by now.
--
Robert J. Chassell
[EMAIL PROTECTED]
Lennart Borgman wrote:
Which make me think that these two things would overlap if the key
bindings where defined through define-minor-mode.
It is easier to use the current, standard customization mechanism.
Simply load a .emacs file.
In it, you can define global keybindings, local keybind
On Wed, 29 Jun 2005, Emilio Lopes wrote:
> [...]
> Here is the documentation of the relevant user option:
>
>w32-use-visible-system-caret's value is nil
>
>Flag to make the system caret visible.
>When this is non-nil, Emacs will indicate the position of point by
>using the system c
>From my earlier message:
The local map (usually the major mode map) overrides the
global map, but not the substitutions to the global map provided by
the theme minor mode. This could potentially mess up some major modes.
I guess that once the problem is noticed, it can be corrected usi
Lennart Borgman wrote:
Which make me think that these two things would overlap if the key
bindings where defined through define-minor-mode.
In a certain sense, global minor modes can be thought of as keybinding
themes (if the main thing they do is activate a keymap). However,
there is a c
> As you had a recipe for reproducing this, it is probably the œ character
> that is either miscoded in the string argument (the penultimate argument,
> an XChar2b *) or it is missing in the font used for bold. If you can print
> the values in the XChar2b* (the last argument to XDrawImageStrin
>> cvs diff -r Ilya_5_0 lisp/progmodes/cperl-mode.el
>>
>> Note that a rapid glance indicates that the "cperl-foo-face => cperl-foo"
>> conversion was probably not done quite right.
> Any pointers? I did actually test the result a bit... :-)
My impression is that the result still works but not
>> since the following change made relatively recently (I thought we were
>> in a feature freeze, but anyway):
>>
>> 2005-02-22 Kim F. Storm <[EMAIL PROTECTED]>
>>
>> * minibuf.c (Ftry_completion, Fall_completions): Allow
>> both string and symbol keys in alists and hash tables.
>>
>> Again I
> If you google for old versions of diff-mode.el, you'll see that it
> also had a minor mode.
> Why suggest using a search engine to find old versions of a file in Emacs?
> They are all on savannah.
IIRC the minor mode was only present in diff-mode versions prior to
inclusion in Emacs. B
Luc Teirlinck wrote:
David Kastrup wrote:
The following announcement seems like an excellent reason to get
custom themes working. While I have not looked at it yet, such
customization sets might be desirable to be available in the core
Emacs.
That announcement is talking about key bin
David Kastrup wrote:
The following announcement seems like an excellent reason to get
custom themes working. While I have not looked at it yet, such
customization sets might be desirable to be available in the core
Emacs.
That announcement is talking about key bindings. The current
On 7/1/05, Mathias Dahl <[EMAIL PROTECTED]> wrote:
> Why cannot Emacs handle this automatically?
See `(emacs)Recognize Coding' on the Emacs manual. Basically, there's
no universal ordering of coding systems that would satisfy every
user's needs, so Emacs assumes a default order according to your
David Kastrup <[EMAIL PROTECTED]> writes
The following announcement seems like an excellent reason to get
custom themes working. ...
Yes. The advantages of a customize theme command are two fold:
writing customizations becomes more usual for those who have learned
differently than writi
"Robert J. Chassell" <[EMAIL PROTECTED]> writes:
> Today's GNU Emacs CVS snapshot, Fri, 2005 Jul 1 10:39 UTC
> GNU Emacs 22.0.50.34 (i686-pc-linux-gnu, GTK+ Version 2.6.8)
> started with
>
> src/emacs -Q -D
>
> The lisp/loadhist.el file is 232 lines long. However, after visiting
> it, and r
[EMAIL PROTECTED] writes:
> Thank you all very much for your help. With the given information and the
> Emacs
> ducumentation I have now added the following lines to my .emacs file, which
> makes editing exportet registry files less painfull:
>
> (setq file-coding-system-alist
> (append '(
Today's GNU Emacs CVS snapshot, Fri, 2005 Jul 1 10:39 UTC
GNU Emacs 22.0.50.34 (i686-pc-linux-gnu, GTK+ Version 2.6.8)
started with
src/emacs -Q -D
The lisp/loadhist.el file is 232 lines long. However, after visiting
it, and running `vc-annotate' (C-x v g) to produce
*Annotate loadhis
> >
> > I find the way to fix the problem in C source code level.
> > I have already installed the fix.
> > Please, try to run make without setarch.
>
> Is there no #define in some header-file you can look for?
Good question. The answer is no.
> A configure test would be preferrable to hardcodin
Can you print out the error string (error parameter to
x_error_handler)?
77 is just XDrawImageString16 which is in the second backtrace as
expected.
But it can generate different errors. I think it is a BadMatch,
which
usually indicates bad input to XDrawImageString16. You should be
On 30 Jun 2005, at 22:29, Richard M. Stallman wrote:
What is the difference between your report-emacs-bug-internally
function and the standard report-emacs-bug function? Is it just that
some of the code has been moved into a subroutine
report-emacs-bug-print-debug-log? That change would be fin
Thank you all very much for your help. With the given information and the Emacs
ducumentation I have now added the following lines to my .emacs file, which
makes editing exportet registry files less painfull:
(setq file-coding-system-alist
(append '(("\\.reg\\'" . utf-16le-with-signature))
I find the way to fix the problem in C source code level.
I have already installed the fix.
Please, try to run make without setarch.
Is there no #define in some header-file you can look for? A
configure test would be preferrable to hardcoding OS specific
constants into Emacs.
/
> From: "Richard M. Stallman" <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org,
> merlyn@stonehenge.com
> Date: Thu, 30 Jun 2005 17:30:23 -0400
>
> On TTY it classifies colors as follows:
>
> Dark: black red green blue
> Light: magenta yellow
Hello,
> Can you give me any advice how to achive this? When I load
> such a file it is
> displayed like in the attached screen shot.
1. Open the file in Emacs (normal file open).
2. Use the following key strokes: C-x Ret r
3. Type utf-16le at the prompt
4. Accept the file reverting...
You can
Miles Bader <[EMAIL PROTECTED]> writes:
> 2005/7/1, Richard M. Stallman <[EMAIL PROTECTED]>:
>> Let's recall how this came up: as a side effect of the change to allow
>> symbols as the car of cons cells in an alist. We could allow symbols
>> when they come from the car of an element, and not allo
Quoting Stefan Monnier <[EMAIL PROTECTED]>:
> > when I export part of the registry on MS Windows to a .reg file, it is
> > a Unicode file (little-endian) encoded with BOM (FF FE) as the first
> bytes.
>
> You mean, it's utf-16-le
>
> > Is it possible to edit such a file with Emacs?
>
> Yes,
Ca
On 7/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Can you give me any advice how to achive this?
Try
C-x RET c utf-16-le RET
(that's `universal-coding-system-argument'), then:
C-x C-f yourfile RET
and you should be able to edit the file.
--
/L/e/k/t/u
___
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> The only real solution would be to add a first element that's neither
> a symbol nor a string, nor a cons cell whose car is a symbol or a
> string. Such as 0 or []. That is sort of ugly. It would be cleaner
> to say that lists of symbols can't
>> You mean, it's utf-16-le
>
> Can you give me any advice how to achive this? When I load such a file it is
> displayed like in the attached screen shot.
C-u C-m c utf-16-le RET C-x C-f FILENAME RET
-Miles
--
"Whatever you do will be insignificant, but it is very important that
you do it."
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> since the following change made relatively recently (I thought we were
> in a feature freeze, but anyway):
>
> 2005-02-22 Kim F. Storm <[EMAIL PROTECTED]>
>
> * minibuf.c (Ftry_completion, Fall_completions): Allow
> both string
Miles Bader <[EMAIL PROTECTED]> writes:
> 2005/7/1, Richard M. Stallman <[EMAIL PROTECTED]>:
>> Let's recall how this came up: as a side effect of the change to allow
>> symbols as the car of cons cells in an alist. We could allow symbols
>> when they come from the car of an element, and not allo
The following announcement seems like an excellent reason to get
custom themes working. While I have not looked at it yet, such
customization sets might be desirable to be available in the core
Emacs. And there are also things like "Aquamacs" which change a lot
of default settings. Having those
David Kastrup <[EMAIL PROTECTED]> writes:
>> If the elements of the list are consistently one or the other, the
>> pattern (lambda (arg ...) ...) can never occur.
>
> (lambda nil t) is a valid function.
Not in this case -- the completion function is passed 3 arguments.
-Miles
--
"Nah, there's n
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> What do people think of the idea of making . match soft newlines?
> That would fix problems where various features get confused
> by longlines.el.
I think that a soft newline, most particularly so in the context of
longlines.el, should pretty mu
Quoting Stefan Monnier <[EMAIL PROTECTED]>:
> > when I export part of the registry on MS Windows to a .reg file, it is
> > a Unicode file (little-endian) encoded with BOM (FF FE) as the first
> bytes.
>
> You mean, it's utf-16-le
>
> > Is it possible to edit such a file with Emacs?
>
> Yes,
Ca
71 matches
Mail list logo
