Jan Djärv wrote:
Richard Stallman skrev:
** Most important:
- Alt-Tab, Alt-Shift-Tab
- Ctrl-Esc, Ctrl-Shift-Esc
- Ctrl-Alt-Delete
- Ctrl-Tab, Ctrl-Shift-Tab
- Ctrl-C, Ctrl-X, Ctrl-V, Ctrl-Z
- Ctrl-A
- Alt-Space
- Esc
- Tab,
Jason Rumney wrote:
Lennart Borgman wrote:
It is a very good idea to document those keys. Here is a preliminary
list for w32:
- Ctrl-Tab, Ctrl-Shift-Tab
- Ctrl-C, Ctrl-X, Ctrl-V, Ctrl-Z
- Ctrl-A
- Alt-Space
- Esc
- Tab, Shift-Tab
** Also very important:
- Ctrl-arrow key
-
Eli Zaretskii wrote:
From: Richard Stallman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
emacs-pretest-bug@gnu.org
Date: Tue, 26 Dec 2006 12:22:34 -0500
** Most important:
- Alt-Tab, Alt-Shift-Tab
- Ctrl-Esc, Ctrl-Shift-Esc
-
Eli Zaretskii wrote:
Date: Wed, 27 Dec 2006 12:02:14 +0100
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
I wanted to point out that we should mention these clashes with the
UI guidelines on w32.
Done.
Thanks, but where? I just grabbed
Eli Zaretskii wrote:
Where did you look? The text I added is right in the second paragraph
of the section.
Thanks, I see it now. It is good, but it is too terse I believe. However
placing it at the beginning of the node as you did is a good idea.
I still believe a node about Emacs
Richard Stallman wrote:
Or, perhaps, you are misunderstanding what I wrote. But I admit I was
not very clear. I wanted to point out that we should mention these
clashes with the UI guidelines on w32.
We spit on Windows' guidelines. Emacs came first!
Could one say that the
Eli Zaretskii wrote:
Date: Thu, 28 Dec 2006 04:22:40 +0100
From: Lennart Borgman [EMAIL PROTECTED]
In *Shell* using cmdproxy.exe on w32 a character shows up as \377:
2006-12-10 16:14 6\377588\377879 emacs.exe
I cannot reproduce this with your recipe. What is shown by DIR
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
In *Shell* using cmdproxy.exe on w32 a character shows up as \377:
2006-12-10 16:14 6\377588\377879 emacs.exe
It is actually from a directory list where emacs.exe is shown:
2006-12-10 16:14 6 588 879 emacs.exe
We never made any decision on this issue. Most of the answers pointed to
that GetUserDefaultUILanguage is the correct function to use. Or am I
just misinterpreting to confirm what I said at the beginning ;-)
___
emacs-pretest-bug mailing list
Kenichi Handa wrote:
It seems that default-process-coding-system is not setup
properly on Windows. When I run Emacs on my Windows,
default-buffer-file-coding-system is set correctly to:
japanese-shift-jis-dos
but default-process-coding-system is:
(undecided-dos . undecided-unix)
On the
The description of DEF in the docstring for define-key does not cover
the form it can have in menus.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Eli Zaretskii wrote:
Date: Thu, 28 Dec 2006 14:07:59 +0100
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Kenichi Handa wrote:
It seems that default-process-coding-system is not setup
properly on Windows. When I run Emacs on my Windows,
default-buffer-file
Eli Zaretskii wrote:
Date: Thu, 28 Dec 2006 14:03:45 +0100
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc:
We never made any decision on this issue. Most of the answers pointed to
that GetUserDefaultUILanguage is the correct function to use. Or am I
just misinterpreting to confirm what I
Jason Rumney wrote:
I am sorry, but I do not at all understand what you mean. What do you
mean with that I don't think we should limit ourselves to the
languages that Windows has been translated to? Have we discussed
that at all? Is not this discussion about how to choose the correct
language
Kevin Rodgers wrote:
Lennart Borgman wrote:
I just noticed that \\[COMMAND] just shows RET for something that was
bound like
(define-key map [(control ?\r)] 'nxhtml-complete-and-insert)
That's because (where-is-internal 'nxhtml-complete-and-insert nil t
nil t)
returns [13] when called
Juanma Barranquero wrote:
On 12/31/06, Lennart Borgman [EMAIL PROTECTED] wrote:
Would it perhaps be better to have default t on systems where file name
case does not matter?
You should've read the docstring...
Yes, or I should have just understood it probably had been made this way
;-)
Leo wrote:
Hi all,
To reproduce,
1. compile and install Emacs in dir ~/packages/emacs22
2. go to ~/packages/emacs22/bin and run Emacs with ./emacs
3. Quit Emacs and executable emacs is gone.
What did you expect? You quitted Emacs, didn't you
;-)
Can't reproduce this on w32,
Chris Moore wrote:
I have bound M-k to bury-buffer.
Typing C-h t to see the tutorial shows me these 2 lines (and lots of
other, expected text):
M-k Kill to the end of the current sentence
** M-k has been rebound, but you can use instead [More] **
The bug I'm reporting is
Chris Moore wrote:
Run
$ emacs -Q
and type:
escape x iswitchb-mode return C-h t C-s more C-b return
to see:
The following key bindings used in the tutorial had been changed
from the Emacs default in the TUTORIAL (English) buffer:
Key Standard BindingIs Now On
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I guess this does not interfere with the normal C-x handling (from a
users point of view)? Cua mode does something similar. (Are there any
collisions?)
Should this be treated like the corresponding Cua mode case
Francis Wright wrote:
When emacsclient needs to start Emacs as an alternate editor it now
outputs an error message that says there is, in fact, no error. It then
starts Emacs correctly. If run again, while Emacs is still running,
there is no problem. The error message is illustrated below.
Lennart Borgman (gmail) wrote:
Francis Wright wrote:
When emacsclient needs to start Emacs as an alternate editor it now
outputs an error message that says there is, in fact, no error. It
then starts Emacs correctly. If run again, while Emacs is still
running, there is no problem
Juanma Barranquero wrote:
On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote:
emacsclient -a runemacs Tablet Buttons.txt
emacsclient: connect: No error
I don't see that. runemacs.exe is run normally.
Are you using a CVS Emacs, or Lennart's prebuilt binary? (I ask
because Lennart's contains
Mathias Dahl wrote:
Yes, we discussed that before. However, I feel that is a clean up
with should do after the release (Lennart won't agree with me
though... :)
I would say that it is not clean up. It is fixing real bugs.
___
emacs-pretest-bug
I do not know if this is a bug, but it could be. I am a bit surprised
that let symbols get interned. Try this:
(intern-soft this-was-no-symbol)
It returns nil. Now evaluate this
(let (this-was-no-symbol))
Then evaluate the intern-soft line again. Now the variable is interned.
Should let
Eli Zaretskii wrote:
Date: Sat, 20 Jan 2007 03:49:55 +0100
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
(let (this-was-no-symbol))
Then evaluate the intern-soft line again. Now the variable is interned.
Should let symbols be interned this way?
Maybe it looks strange at 3:49am
We have previously on the developers list discussed coding systems for
*Shell* buffers on w32. I have sent some suggestions, but I do not think
any changes have been done yet. Could we please try to fix this?
For cmdproxy *Shell* buffers I think we have a good solution (not yet
installed,
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
We have previously on the developers list discussed coding systems for
*Shell* buffers on w32. I have sent some suggestions, but I do not
think any changes have been done yet. Could we please try to fix this?
There are two parts
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
We have also discussed the tab file name completion in a cmdproxy
*Shell* buffer. This is currently broken. I sent a suggestion to fix
it, but I have got no feedback whatsoever on this.
http://lists.gnu.org/archive/html/emacs-devel/2006-12
If cua-mode is enabled and you define a minor mode using C-c as a prefix
key you describe-bindings wrongly says that C-c is shadowed. This is
quite disturbing since C-c by some of the punctuation characters is what
a minor mode is supposed to use (my example uses C-c RET which is a bit
bad).
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
We have also discussed the tab file name completion in a cmdproxy
*Shell* buffer. This is currently broken. I sent a suggestion to
fix it, but I have got no feedback whatsoever
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
There is a problem with spaces in the names too in the current code.
And the output is quite confusing as it looks now.
Spaces in file names seems to be a problem for all platforms. What about
the output is confusing?
If I remember
Stefan Monnier wrote:
Then evaluate the intern-soft line again. Now the variable is interned.
You're confusing variables and symbols.
Stefan
Thanks, yes, I should of course have written symbol is interned.
However the real question was of course if the same obarray is used for
Juanma Barranquero wrote:
On 1/22/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
However the real question was of course if the same obarray is used for
symbols created by let variable declarations (did I get everything right
now?;-) as for symbols created by defvar variables.
(progn
Juanma Barranquero wrote:
On 1/22/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Thanks, but I did not mean on this level. On this level I would expect
it to be transparent to the user/programmer.
Please, explain that.
/L/e/k/t/u
I tried to, but it seems like I
Juanma Barranquero wrote:
On 1/22/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Then perhaps it would make sense to have a small obarray for let
variables.
You've said that you would expect my example to be transparent to the
user/programmer. For that to be true, anything that uses
Stefan Monnier wrote:
I rest my case: you're confusing variables and symbols.
Symbols are fundamentally nothing more than hash-consed strings.
Symbols are created by the lexer, not by the evaluator, so insertion into
a big obarray only affects the performance of the lexer/parser.
Miles Bader wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
However the real question was of course if the same obarray is used for
symbols created by let variable declarations (did I get everything right
now?;-) as for symbols created by defvar variables. I was surprised
Eli Zaretskii wrote:
Date: Mon, 22 Jan 2007 02:07:12 +0100
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
I believe however that it takes more time to insert a symbol in big
obarray than in a small. But that depends on how the internal structure
of an obarray
Miles Bader wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
(let ((#1=#:my-uninterned-var 5))
(+ #1# 3))
Thanks. I have never seent that syntax. I guess it is unofficial?
I'm not really sure what you mean; it's real reader syntax, and it's
perfectly fine to use
Michaël Cadilhac wrote:
David Kastrup [EMAIL PROTECTED] writes:
If I do
C-x C-f somefile.txt RET C-x C-s
in order to create and save an empty file, Emacs replies
No changes need to be saved
and does not actually save the file, even though saving the file would
change the state on disk.
I
Drew Adams wrote:
emacs -Q
Help Emacs Tutorial
You see this, in red, at the top:
NOTICE: The main purpose of the Emacs tutorial is to teach you
the most important standard Emacs commands (key bindings).
However, your Emacs has been customized by changing some of
these basic editing
Chris Moore wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Drew Adams wrote:
Clicking either of the more info links leads to further incorrect
information...
Please tell what the incorrect information is.
I'm guessing it's this:
The default Emacs binding for the key M
Markus Triska wrote:
Here is a simple widget example:
(require 'widget)
(require 'wid-edit)
(defvar tw-value-field nil)
(defun test-widgets ()
Create some widgets.
(interactive)
(switch-to-buffer *Widget Example*)
(kill-all-local-variables)
(let
Lennart Borgman (gmail) wrote:
Testing this I found that if I tab to the field and do
M-: (marker-insertion-type (widget-get (widget-at (point)) :from))
it returns t which I believe mean that the marker at the field beginning
moves forward when inserting text there.
But that is the same
Stefan Monnier wrote:
Which creates an empty file named Test at 12 and no error occurs.
Initially I didn't notice that the filename was truncated.
Once I did I realized that : is illegal in a file name.
Some kind of error must be occurring that isn't being reported.
If you run
Kim F. Storm wrote:
But the main reason for lgrep is it's interface is modelled after the rgrep
interface, prompting (and using different input histories) for each argument.
So some of the specific aspects of rgrep also applies to lgrep
(such as the grep-files-aliases feature).
lgrep and
Drew Adams wrote:
As I mentioned, I first ran into this problem on the Emacs Wiki (with the
same em-dash character, in a library that is derived from buff-menu.el).
Simply uploading or downloading the code on the Wiki changes the characters
(in the same way, BTW). Here, the downloading user has
Eli Zaretskii wrote:
Date: Sun, 18 Feb 2007 23:32:01 +0100
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
I wonder if this has something to do with the mime codes? I do not know
anything about it, but could it be that the web
Drew Adams wrote:
You can upload a file to the wiki using the alternative method, instead of
editing a wiki page, and in that case there is no problem. But in that case
there is also no syntactic highlighting of the code on the page.
It seems to me you have to know a lot here to be able to
Kim F. Storm wrote:
As far as I remember scrolling was always problematic (in the same
way?) in W32 Emacses, so this is not a new bug?
I just installed some changes to _improve_ on those scroll-bar issues.
Can you -- and other W32 users -- please try out the latest CVS
and tell me ASAP if
Eli Zaretskii wrote:
Date: Sun, 18 Feb 2007 23:48:29 +0100
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
Eli Zaretskii wrote:
Date: Sun, 18 Feb 2007 23:32:01 +0100
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: Eli Zaretskii [EMAIL
Jason Rumney wrote:
I wonder if this has something to do with the mime codes? I do not
know anything about it, but could it be that the web server changes
something in the output?
Web servers don't change anything (at least, no web server I've ever
seen does, and I've worked with most of
There still seems to be some problems with refreshing buffer contents.
In the example below the buffer gets refreshed before the first popup
menu, but not before the second popup menu.
Do
emacs -Q
Paste the code into *scratch* and eval it:
(defun temp-test1()
(interactive)
(goto-char
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
I consider this bug and I can see other bugs here that seems related.
Though I do not know if these bugs are only related to the w32 port.
I can't comment, because I don't know which bugs you are referring to.
This particular one is specific
martin rudalics wrote:
Because your model of what happens is incorrect. The menu is
processed in its entirety by the Windows menu-handling API, and Emacs
never sees anything until the menu is popped down.
In Lennart's example there are _two_ menus. The one popped by
`temp-test1' and the
Kim F. Storm wrote:
martin rudalics [EMAIL PROTECTED] writes:
In Lennart's example there are _two_ menus. The one popped by
`temp-test1' and the other popped by `temp-test2'. In between he does
(insert ;; SOME STRING 2\n)
which should get displayed before popping up the second menu.
Using C-h k to check mouse bindings does not work for text property keymaps.
To show this do
emacs -Q
then paste the following code in the *Scratch* buffer and eval it:
(defun temp-test-mouse-ctrl-h-k()
(interactive)
(switch-to-buffer-other-window (get-buffer-create test mouse buffer))
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
In that case, use (redisplay t) instead of (sit-for 0) to _force_ a redisplay.
Thanks, I just tested, but unfortunately it did not help.
It was a bug in the update_frame logic.
I have just installed a fix in CVS.
Thank
Kim F. Storm wrote:
Another small problem seem to be that (sit-for n) still does not work
if I call it before the second popup-menu. Is that a bug?
No. There is no guarantee that sit-for will update the display.
I meant that it does not wait n seconds.
Jason Rumney wrote:
There are two possible solutions to this:
1) Make the popup menu signal an error if it is used reentrantly.
2) Wait for Windows to destroy the menu before running any lisp code
associated with the chosen action.
Of course I think 2 is best if that can be done. Is it
Jason Rumney wrote:
The problem is that there is only one copy of the menu structure kept.
So when the second menu is created, it overwrites the first one. This
causes two bugs:
1) A memory leak, since the first menu structure is never freed.
2) The menu structure for the second menu is
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Kim F. Storm wrote:
Another small problem seem to be that (sit-for n) still does not work
if I call it before the second popup-menu. Is that a bug?
No. There is no guarantee that sit-for will update the display.
I meant
Jason Rumney wrote:
Here is the end of x-popup-menu in w32menu.c. It looks to me like the
menu structure is freed before selection is used. Obviously you
think otherwise, Jason. Can you explain to me what is happening here?
Does perhaps w32_menu_show do more than the name suggests?
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
Do you mean that the second menu is created before returning from the
first w32_menu_show. It does not look so to me, but I might be
misreading the code. Is not selection that is returned from the
first w32_menu_show what is used to decide
Lennart Borgman (gmail) wrote:
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
Do you mean that the second menu is created before returning from the
first w32_menu_show. It does not look so to me, but I might be
misreading the code. Is not selection that is returned from the
first
martin rudalics wrote:
I have the same problem with a popup-menu and a toggle-styled entry.
Can you show us some code?
I guess you are using w32 too?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
Ah, then should not menu_kill_timer be called from within
w32_free_menu_strings (or always before that)?
I have fixed it now. I moved the freeing of strings earlier for popup
menus, so we can guarantee they are freed even when a signal
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
I know one should not expect anything if there is no guarantee, but
should all doc strings be read that way?
The doc string for sit-for explicitly states both
The function `map-y-or-n-p' does not use minibuffer-prompt face.
To show this start Emacs with
emacs -Q
then do
M-x customize-face RET minibuffer-prompt RET
Set Foreground to red and click Set for Current Session. Just to check
that the prompt is colored do
M-x
Cancel the prompt
Lennart Borgman (gmail) wrote:
The function `map-y-or-n-p' does not use minibuffer-prompt face.
To show this start Emacs with
emacs -Q
then do
M-x customize-face RET minibuffer-prompt RET
Set Foreground to red and click Set for Current Session. Just to check
that the prompt
There is something wrong with the initialization of
minibuffer-prompt-properties. Custom complains that it is
CHANGED outside Customize; ...
To see this start Emacs with
emacs -Q
then do
M-x customize-option RET minibuffer-prompt-properties RET
In GNU Emacs 22.0.94.1
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
There is something wrong with the initialization of
minibuffer-prompt-properties. Custom complains that it is
CHANGED outside Customize; ...
I don't understand why minibuffer-prompt-properties need to be
a defcustom
Kim F. Storm wrote:
Well, I would consider that to be rather obscure.
By definition, minibuffer-prompt is the face for minibuffer prompts,
and it should be safe to assume that, and not have to wade through
minibuffer-prompt-properties to see if the user has specified a
different face for the
Inserting text in another buffer than the current can deactivate the
mark in the current buffer. To see this start emacs with
emacs -Q
then paste this code into the *scratch* buffer and evaluate it:
(global-set-key [f9] 'temp-save)
(defun temp-save(start end)
(interactive r)
`browse-url-file-url' returns an URL that looks like
file:c:/full/path-to-file.css
at least on w32. Such an URL does not work in for example a
link href=... rel=StyleSheet /
tag in Firefox in an xhtml file. I would expect this to be a bug in
Emacs and not in Firefox, but I am not sure.
Chris Moore wrote:
Sometimes the *shell* buffer's directory tracking gets out of sync
with its inferior shell process. In such cases, M-x dirs RET
usually fixes the problem, but this doesn't work if there is a space
in the directory's name:
M-x shell RET
$ cd /tmp
$ mkdir 'one two'
$ X='one
Original Message
Subject: Re: Question about font-lock faces
Date: Thu, 01 Mar 2007 18:33:50 +0100
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
To: Drew Adams [EMAIL PROTECTED]
CC: help-gnu-emacs@gnu.org
References: [EMAIL PROTECTED]
Drew Adams wrote:
Is it possible
Katsumi Yamaoka wrote:
In [EMAIL PROTECTED] Kim F. Storm wrote:
Thanks. I have reverted the patch.
Thank you for fixing it so quickly.
In [EMAIL PROTECTED] Lennart Borgman wrote:
Thanks Kim. Emacs is full of surprises. I would be glad for an
explanation of what happens with non-ASCII
Stefan Monnier wrote:
Now I try to use emacsclient to open something else, but since isearch
is running the new buffer does not appear on top.
Hmm... indeed, I can reproduce it. Not sure why, yet.
emacsclient seems to interrupt find-file, swith-to-buffer and areas
marked to be copied, so I
... but define-global-minor-mode is in emacs-lisp-mode.
In GNU Emacs 22.0.95.1 (i386-mingw-nt5.1.2600)
of 2007-03-08
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
David Kastrup wrote:
[EMAIL PROTECTED] (Kim F. Storm) writes:
Juanma Barranquero [EMAIL PROTECTED] writes:
On 3/13/07, Richard Stallman [EMAIL PROTECTED] wrote:
I don't think that an action from outside Emacs is comparable to one
done by typing Emacs commands.
It could be argued (and I
A minor mode defined by define-minor-mode does not get added to the
customization group given. To show this evaluate this code:
(defgroup the-temp-group nil
doc string)
(define-minor-mode the-temp-mode nil
doc string
:group 'the-temp-group
)
(defcustom temp-var nil
doc string
Stefan Monnier wrote:
A minor mode defined by define-minor-mode does not get added to the
customization group given. To show this evaluate this code:
(define-minor-mode the-temp-mode nil
doc string
:group 'the-temp-group)
What would you want to be added to the group?
This only defines a
Miles Bader wrote:
Yup. Emacs newbies I've observed seem quite happy with the menus (which
are actually quite a bit easier to understand than the toolbar; the
whole concept of irritatingly slow to use doesn't seem to be a problem
for some reason... :-)
I think in fact a big fancy toolbar is
Miles Bader wrote:
Lennart Borgman [EMAIL PROTECTED] writes:
It looks like the height of an italic font is different from a
non-italic, at least on w32.
Er, so what?
[It's nice when variants of a mono-spaced font are sized consistently
with it, but I think it's up to the font creator to do
Miles Bader wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I get the feeling that the massive extended toolbars really serve
somewhat the same role in a typical MS app that keybindings do in Emacs:
both are somewhat cryptic and take a fair bit of time to remember, but
are probably
Juanma Barranquero wrote:
On 3/26/07, LENNART BORGMAN [EMAIL PROTECTED] wrote:
Do you have ClearType on?
Yes
Does it happen also with ClearType off? (I think you could've tried
this without me asking it ;-)
Ehum, no. I thought there was no use in trying that, but no, it does not
happen
Juanma Barranquero wrote:
There are issues with ClearType; see for example this item from
admin/FOR-RELEASE:
** Drew Adams 12 Aug bug rpt: overlay display artifact: trace left behind
Windows only bug. Bug appears only when Cleartype enabled, probably related
to the hack introduced on
Juanma Barranquero wrote:
On 3/26/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Yes, I have seen some traces of background coloring remaining on the
screen, but I wonder whether that is an overlay only thing.
What do you mean with an overlay only thing? That only happens
I just tried from the menus
Edit - Text Properties - Face - Italic
This is entry is enabled even when fontification-functions is non nil in
the buffer. That seems a bit too optimistic to me.
In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600)
of 2007-03-21
Juanma Barranquero wrote:
Ok, I have downloaded and installed the Dejavu LGC TT fonts. But what do
I do now? In Emacs on w32?
What I do is to define a fontset in the registry
(HKLM\Software\GNU\Emacs), i.e., an Emacs.Fontset-0 string value with
-*-DejaVu Sans
The variable above is marked as obsolete but used in font-core.el.
Should it be that way?
In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600)
of 2007-03-21
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Stefan Monnier wrote:
The variable above is marked as obsolete but used in font-core.el. Should
it be that way?
Obviously even obsolete variables have to be used _somewhere_, else
they are not just obsolete but totally useless. Can you elaborate on
your question?
The variable is marked
Glenn Morris wrote:
Lennart Borgman (gmail) wrote:
The variable is marked obsolete in the same file where it is used. I
would expect that the new name where used in that file instead of
the old.
I would even expect the new name to be used everywhere in Emacs,
leaving the old obsolete name
jpff wrote:
I attempted to create a new frame from the File menu.
The frame is created but I always get this error:
Debugger entered--Lisp error: (wrong-number-of-arguments #[nil
=8c0=8c1!=83
=8c1=8c2!=88=8c0=8c3!=85=8c3=8c2!=87 [functionp tool-bar-mode -1
blink-cursor-mode] 2] 1)
#[nil
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1 at point 1 with a
'before-string property to do this.
Doing this I see some strange display problems when moving point to the
beginning of buffer. When (point) is 1 I want the
Glenn Morris wrote:
Stefan Monnier wrote:
The iff idiom is sufficiently common that we don't want to shy
away from it just at this one place. So either we rule it out
everywhere, or we use it liberally.
Sufficiently common in Emacs (~ 600 instances); I've never seen it
anywhere else as far
Lennart Borgman (gmail) wrote:
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1 at point 1 with a
'before-string property to do this.
Doing this I see some strange display problems when moving point to the
beginning
Richard Matthew Stallman wrote:
The Windows system was using ClearType. Changing that setting fixed
the problem. Thanks Eli.
Should Emacs users always turn off use of ClearType?
If so, can Emacs do it automatically?
If not, is this documented in PROBLEMS or somewhere suitable?
No,
1 - 100 of 195 matches
Mail list logo
