Nick Alexander wrote:
In GNU Emacs 22.0.95.1 (powerpc-apple-darwin8.9.0, Carbon Version 1.6.0)
of 2007-03-15 on g5.tokyo.stp.isas.jaxa.jp
Windowing system distributor `Apple Inc.', version 10.4.9
configured using `configure
'--prefix=/Applications/Emacs.app/Contents/Resources' '--with-carbon'
Eli Zaretskii wrote:
Date: Fri, 15 Jun 2007 21:43:08 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: Emacs-Pretest-Bug emacs-pretest-bug@gnu.org
Drew Adams wrote:
I think this is specific to w32. Yes needs to be escaped there.
I hope you mean that Emacs or Emacs W32 should do
Drew Adams wrote:
emacs -Q
Bind a command `foo' in a minibuffer completion map to `M-'.
Add `foo' to the Minibuf menu:
(define-key map [menu-bar minibuf foo] '(menu-item Foo It foo))
In the Minibuf menu, the item appears with the wrong binding:
Foo It (M-)
The `' was removed - it should
Drew Adams wrote:
I think this is specific to w32. Yes needs to be escaped there.
I hope you mean that Emacs or Emacs W32 should do the escaping. These
binding indications are added automatically.
I am not sure I understand you, but is the character you put before a
character in the menu
Drew Adams wrote:
I think this is specific to w32. Yes needs to be escaped there.
I hope you mean that Emacs or Emacs W32 should do the escaping. These
binding indications are added automatically.
I am not sure I understand you, but is the character you put before a
character in the menu
Dired sorts the file case sensitive on w32. I do not think that is what
users on w32 expects since file names are case insensitive on w32
(except for the display of the names).
In GNU Emacs 22.0.990.1 (i386-mingw-nt5.1.2600)
of 2007-05-31
___
Drew Adams wrote:
Elisp manual node Special Properties says this about `intangible':
If a group of consecutive characters have equal and non-`nil'
`intangible' properties, then you cannot place point between them.
If you try to move point forward into the group, point actually
Thanks Nelson, I am not sure whether this is a bug or not, but I am
forwarding this to the pretest bug list so others who knows more about
this can decide what to do.
To emacs-pretest-bug readers: Is this a bug, or? Is there some setting
that can generally be used to avoid this problem?
Rainer Stengele wrote:
David Kastrup schrieb:
Rainer Stengele [EMAIL PROTECTED] writes:
Hi.
M-x dired
//server/sharename
crashes my emacs w32 repeatable. Emacs asks to attach the gdb debugger
but that doesn't really help.
The crash happens independently of having the share on a linux
Richard Stallman wrote:
It seems to me that idlwave.el loads cl only at compile time.
Why do you think otherwise?
Yes, there is a second (require 'cl) on line 4157.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Lennart Borgman (gmail) wrote:
Some libraries (iswitchb.el for example) does
(require 'cl)
without (eval-when-compile ...). Is not that incorrect?
In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600)
of 2007-05-06
More files doing this:
lucid.el
viper.el
gnus-registry.el
spam
Gary Lawrence Murphy wrote:
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
Please describe exactly what actions triggered the bug
It looks to me like iswitchb-mode matches too much. To show this do
emacs -Q
Then find some files beginning with m and n. Now do
M-x iswitchb-mode
C-x b m
For me that matches both buffers beginning with m and n.
In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600)
of 2007-05-06
Richard Stallman wrote:
Some libraries (iswitchb.el for example) does
(require 'cl)
without (eval-when-compile ...). Is not that incorrect?
It is incorrect, in general. However, in the case of iswitchb,
it is a no-op:
;; CL needed for cadr and last
(if (not (and
Juanma Barranquero wrote:
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Sorry, I was using -n too, forgot that. With -n you do not see the error
anywhere.
That's what I would expect. You're saying to emacsclient to no expect
any answer, after all.
You can always do
Juanma Barranquero wrote:
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Would it not be easier if you get a normal backtrace if debug-on-error
is t?
Perhaps. OTOH, it is an error in an emacsclient-sent string to
evaluate an Error *in* Emacs?
Eh, you lost me on this one
Juanma Barranquero wrote:
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Eh, you lost me on this one ;-) -- I do not understand the context. Can
you please explain?
Why would emacsclient --eval BIG-MISTAKE cause a traceback on Emacs,
even if debug-on-error is t? It already
Juanma Barranquero wrote:
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
- It is not necessarily emacsclient -e BIG-COMMAND-LINE-MISTAKE, it
could equally well be somewhere in the elisp libraries.
Fair enough, though if you set debug-on-error to debug the problem
Juanma Barranquero wrote:
Perhaps you're right, but I'd like to see some examples of things that
are much easier to debug from --eval than directly.
I have no examples at hand, but the context where the functions are
running is slightly different when they are called from emacsclient. Is
Juanma Barranquero wrote:
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
the context where the functions are
running is slightly different when they are called from emacsclient. Is
not that enough?
I'm not sure. On one hand, if there's no trouble, there's no need to
complicate
Juanma Barranquero wrote:
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
The complication seems very minor as I see it.
Sure. That's why real examples will easily win the day.
Yes, the important thing is of course that there is a way to make it
easy to debug
It seems like errors are not handled as I expect them too when using
Emacs client. If I do something like
emacsclient -e (my-bad-fun)
where my-bad-fun is not defined or contains an error I see no backtrace
even if debug-on-error is t. In fact I see nothing.
In GNU Emacs 22.1.50.1
Juanma Barranquero wrote:
On 5/15/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
If I do something like
emacsclient -e (my-bad-fun)
where my-bad-fun is not defined or contains an error I see no backtrace
even if debug-on-error is t. In fact I see nothing.
C:\ emacsclient -e (my
Richard Stallman wrote:
If show-paren-mode is turned on I see a strange visual distortion in
*Customize Browser*, see attached image.
I looked at it, but I don't see the problem.
The highlighted parens characters are broader than the non-highlighted.
If show-paren-mode is turned on I see a strange visual distortion in
*Customize Browser*, see attached image.
In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600)
of 2007-05-06
inline: show-paren-mode-and-customize.png___
emacs-pretest-bug mailing list
The variable compilation-finish-functions is said to be a hook. However
using add-hook to make a local value results later in an error:
(add-hook 'compilation-finish-functions 'my-fun nil t)
This gives the hook variables the value '(my-fun t).
compilation-handle-exit tries to run t as a
Eli Zaretskii wrote:
Date: Sun, 06 May 2007 21:19:53 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
The reason for the problem is that the Emacs window (frame) is not
really maximized on MS Windows.
That's true, but I'm not sure it's relevant. Even
Eli Zaretskii wrote:
Date: Sun, 06 May 2007 22:40:52 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
I believe Windows is beeing fooled by the way Emacs tries to make a
semi-maximized window.
How can Emacs fool Windows? All we do
Jason Rumney wrote:
Eivind Midtgård wrote:
In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600)
of 2007-01-01 on DTOP
Please try the latest pretest before reporting bugs in old unreleased
versions.
I just tried the latest pretest (unpatched) and indeed AFAICS Emacs now
behave as it should
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
I just tried the latest pretest (unpatched) and indeed AFAICS Emacs
now behave as it should with a maximized window, at least on Windows XP.
That is very nice! When was that change made?
Apparently there is no such change, as Eivind can
I have just seen a state problem with regexps. I am not able to isolate
the problem completely at the moment, but here is a sketch of it:
I have this regexp:
(defconst mumamo-script-tag-start-regex
(rx script
(1+ space)
type
(0+ space)
=
(0+ space)
?\
Richard Stallman wrote:
A globalized minor mode can be customized. There is currently no link to
custom from the doc string that is generated.
What do you mean by that?
Please show concretely what you mean.
Ah, it is me beeing a bit confused. I looked at the documentation for
the
Stefan Monnier wrote:
The attached file is valid XHTML 1.1 but indents badly because of the inte
?php ... ? part. I paste it here for simplicity too:
Hmm... does the patch below fix it for you?
If you put a ? inside your PHP code, it seems it would still be valid
XML, but indentation will
Stefan Monnier wrote:
Maybe if magic-mode-alist were combined into auto-mode-alist it'd be
easier to control conflicts or precedence among content vs filename
tests. (Not that you want to get too fancy about such things ...)
Agreed.
I think the most important thing is getting something
A globalized minor mode can be customized. There is currently no link to
custom from the doc string that is generated. I think there should be
one, just as there is one for a minor mode defined with define-minor-mode.
In GNU Emacs 22.0.99.1 (i386-mingw-nt5.1.2600)
of 2007-04-24
I had some trouble with Emacs hanging and a globalized minor mode so I
checked `define-globalized-minor-mode'. It looks a bit strange to me.
Why should a globalized mode check every buffer after a change in major
mode in one buffer, for example?
Or am I misreading the macro?
In GNU Emacs
Lennart Borgman (gmail) wrote:
I had some trouble with Emacs hanging and a globalized minor mode so I
checked `define-globalized-minor-mode'. It looks a bit strange to me.
Why should a globalized mode check every buffer after a change in major
mode in one buffer, for example?
Or am I
Glenn Morris wrote:
Lennart Borgman (gmail) wrote:
In the attached images I have one overlay one character long that has a
red underline.
[...]
In the second picture I have added another overlay, with a slightly blue
background. This overlay is 10 characters long and includes a new line
Stefan Monnier wrote:
In a recent build of the cvs, visiting the file minimal.html below
selects sgml-mode, where I hoped to get html-mode. According to the
Again, the best fix seems to be to make sure the .html extension
is heeded.
I agree. If you look at EmacsWiki for example you can see
Jason Rumney wrote:
Thanks, but I should have sent some code in addition to my
explanation. The above works for me to, but can you please test the
code below. That code gives the error. The important thing is the
newline characters.
The behaviour is the same on w32 as it is on X. What made
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
In the attached images I have one overlay one character long that has
a red underline.
In the code you provide, the overlay is two characters long, not one.
If you make the overlay span 3 to 4, everything works fine.
Ah
I just saw a very strange undo problem. I have no simple way to
reproduce it, but I can frame it a bit. Lock at the backtrace below:
Debugger entered--Lisp error: (wrong-type-argument
number-or-marker-p nil)
rng-error-modified(#overlay in no buffer t 777 777 85)
primitive-undo(2
martin rudalics wrote:
If those calls are done in different buffers it looks like trouble to
me. Should not pending-undo-list be buffer local?
Not by default. If you want to write a function which say, tries to
undo changes simultaneously in two or more buffers in some lock-step
fashion,
Lennart Borgman (gmail) wrote:
I just saw a very strange undo problem. I have no simple way to
reproduce it, but I can frame it a bit. Lock at the backtrace below:
Debugger entered--Lisp error: (wrong-type-argument
number-or-marker-p nil)
rng-error-modified(#overlay in no buffer t
Lennart Borgman (gmail) wrote:
Lennart Borgman (gmail) wrote:
I just saw a very strange undo problem. I have no simple way to
reproduce it, but I can frame it a bit. Lock at the backtrace below:
Debugger entered--Lisp error: (wrong-type-argument
number-or-marker-p nil)
rng-error
Lennart Borgman (gmail) wrote:
So there are two bugs here, one in nxml-mode and one in the elisp Info
manual.
And BTW the bug in nxml-mode was that the variable rng-error-count did
not have the property 'permanent-local t. And that was what my code
needed
Johan Bockgård wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
And in elisp Info:
That is, (info (elisp)Special Properties)
`modification-hooks'
If a character has the property `modification-hooks', then its
value should be a list of functions; modifying that character
The attached file is valid XHTML 1.1 but indents badly because of the
inte ?php ... ? part. I paste it here for simplicity too:
?xml version=1.0 encoding=iso-8859-1?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;
html
In the attached images I have one overlay one character long that has a
red underline. In the first picture there is only this overlay at that
point and the display is correct.
In the second picture I have added another overlay, with a slightly blue
background. This overlay is 10 characters
Richard Stallman wrote:
So there are two bugs here, one in nxml-mode and one in the elisp Info
manual.
What do you think is a bug in the Emacs Lisp Reference Manual?
Where is it?
There is no bug in the manual. Johan Bockgård pointed out I was reading
the wrong section in the
The link to Extended Menu Items in the doc string for define-key is broken.
In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600)
of 2007-04-17
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
The bottom part of (info (elisp) Extended Menu Items) is badly
formatted which makes it quite hard to understand. The very last
paragraph should belong to :filter.
In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600)
of 2007-04-19
___
The variable pending-undo-list is used by for example undo-start and
undo-more. The doc strings says that you should first call undo-start
and then you can call one or several times undo-more later.
If those calls are done in different buffers it looks like trouble to
me. Should not
Stefan Monnier wrote:
I agree that this situation should be improved, but as long as the position
is chosen arbitrarily anyway, I don't see it as a big problem if this
arbitrary choice happens to be occasionally in the middle of the display
string rather than at one of its ends.
My weak
Eli Zaretskii wrote:
Date: Mon, 16 Apr 2007 22:58:47 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: Juanma Barranquero [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
But let me turn the table around, Lennart, and ask you: what arguments
will actually convince _you_ to change your
Eli Zaretskii wrote:
Date: Tue, 17 Apr 2007 22:08:06 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
But let me turn the table around, Lennart, and ask you: what arguments
will actually convince _you_ to change your mind
Eli Zaretskii wrote:
Date: Tue, 17 Apr 2007 23:29:12 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
I am not the easiest one to convince, but it is in no way impossible.
You again are not answering the question. I think we should end
Eli Zaretskii wrote:
Date: Mon, 16 Apr 2007 03:14:13 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Then what arguments are actually convincing to you?
Did you ever managed release of some software product, Lennart?
Because if you didn't, then there's
Juanma Barranquero wrote:
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
We are getting closer to a serious discussion, thanks.
Because you're the arbiter of when a discussion is serious enough?
Yes, I do have an opinion about that. Disrespect is not one of the
things I
Juanma Barranquero wrote:
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Yes, I do have an opinion about that. Disrespect is not one of the
things I respect.
Disrespect is often in the eye of the beholder. I certainly have no
trouble detecting disrespect in some of your
David Kastrup wrote:
I will not be surprised at all if we will see after the release a
flood of problem reports currently held back by a large release pain
threshold.
Uhm. At least I have tried to avoid reporting some bugs now just because
it seems useless. We all want a release I guess.
Juanma Barranquero wrote:
I was not offended, but saying to your opponent I suggested reading
my arguments is not keep[ing your] own opinion, for example. I
point it out merely to show that it is easy to cross the line without
being aware.
Oh, yes it is easy. And I know you have told me
Eli Zaretskii wrote:
Then what arguments are actually convincing to you?
At this point in time, just days short of the intented release? Either
the bug crashes Emacs, or it does cause trouble for some really major
package, or it is very common and/or confusing for many users.
And such bugs
Eli Zaretskii wrote:
Date: Mon, 16 Apr 2007 10:38:14 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
Eli Zaretskii wrote:
Date: Mon, 16 Apr 2007 03:14:13 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Just another note if someone else is trying this. Having coming back
to this several times today I am starting to believe that the way to
fix this is to change cursor_row_p. This was the original way that Kim
tried to solve
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Here is a version that I believe works. It just does local changes to
cursor_row_p. I seems to me that is sufficient. I have not seen any
problems with the display of 'display property parts, only with cursor
positioning
Eli Zaretskii wrote:
From: Richard Stallman [EMAIL PROTECTED]
Date: Sun, 15 Apr 2007 09:59:10 -0400
Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
It seems that you and I define serious in a different way. My
criterion says that a bug where an important feature does something
that is
Nick Roberts wrote:
In other words: I have seen this bug.
I'm not questioning that you have seen it, just the wisdom of ignoring the
advice of those who are experts in that part of the code and say that it is
dangerous to fix shortly before the release.
I am not ignoring Kim's advice,
Juanma Barranquero wrote:
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
If you read my messages carefully you will see why I do not think this
is dangerous to fix the way I have suggested.
That you don't think it is dangerous doesn't make it harmless or safe.
I really did
Juanma Barranquero wrote:
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
I really did not say so of course. I suggested reading my arguments.
I did. I've read this thread in full. I know nothing about the
redisplay code (I've taken a few looks at it and that's all), but
AFAIK
Chong Yidong wrote:
Richard Stallman [EMAIL PROTECTED] writes:
You could add code inside a conditional which tests for that case.
Then you know it won't affect any other cases.
I don't have a clue to how to write the conditional which tests for that
case.
Have you tried to
Lennart Borgman (gmail) wrote:
B) Moving with right arrow across the 'display part on the screen moves
point across the part of the buffer that has the 'display property. In
contrast moving with left arrow make point stop at the first of the
characters that has the overlay with the 'display
Lennart Borgman (gmail) wrote:
A) It looks like set_cursor_from_row gets called over and over again in
some circumstances. I might have done something stupid that triggers
this, I am not sure at the moment, but if I move to the end of the file
with right error this happens. If stops when I
Just another note if someone else is trying this. Having coming back to
this several times today I am starting to believe that the way to fix
this is to change cursor_row_p. This was the original way that Kim tried
to solve it. Maybe Kim's solution with an added test of if the string
has the
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Just another note if someone else is trying this. Having coming back
to this several times today I am starting to believe that the way to
fix this is to change cursor_row_p. This was the original way that Kim
tried to solve
Stefan Monnier wrote:
selecting a keymap (e.g. when changing minor-mode, creating 'keymap
overlays, setting overriding-local-map, use-local-map) in a
run-with-timer or run-with-idle-timer event doesn't take immediate
effect.
Consider the following example:
(run-with-timer 3 nil '(lambda ()
Lennart Borgman (gmail) wrote:
Another little question: On w32 I failed to apply this patch with the
patch program from gnuwin32 (version 2.5.9). I wonder if this is a
problem with that patch program or something else. How do I continue
when patch fails?
Most of the patch where applied
Eli Zaretskii wrote:
Date: Wed, 11 Apr 2007 22:48:34 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: Chong Yidong [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Looking at the logic it seems like it perhaps should be like below
instead? This at least works in my case. The current test just seems
useless. Or perhaps I am just very bad at reading C code?
The useless code you refer
Kim F. Storm wrote:
At this stage of the release cycle, a grave bug is one that makes Emacs
crash, or causes really bad redisplay behaviour.
As you said yourself, this is a corner case, so it is not a grave error.
Ok, but with a corner case I meant a logical corner case. Those +-1 you
often
Chong Yidong wrote:
I think the current code is mistaken. The ChangeLog entry and the
comments both say that we want to set cursor_row_p to a non-zero value
in the case where the display string starts in this row. But that's
not what it's doing; Lennart is correct in pointing out that it's
Chong Yidong wrote:
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
Lennart Borgman (gmail) wrote:
This works for me and for Kim's test case as far as I can see. However
as can be seen from the fprintf output with my test case it starts
looping when I go to the first character and then press left arrow.
This was wrong. The looping occurs without my changes
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Lennart Borgman (gmail) wrote:
This works for me and for Kim's test case as far as I can
see. However as can be seen from the fprintf output with my test
case it starts looping when I go to the first character
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
With current CVS, I do not observe any infloop for the test case you
sent. If you think you have observed one, please send a precise
recipe.
Could you please recompile with the fprint part of the code I sent
before
Chong Yidong wrote:
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
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,
Eli Zaretskii wrote:
From: Chong Yidong [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 13:46:37 -0400
Cc: emacs-pretest-bug@gnu.org
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
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
Juanma Barranquero wrote:
On 4/11/07, Richard Matthew Stallman [EMAIL PROTECTED] wrote:
Should Emacs users always turn off use of ClearType?
No. ClearType improves readability, and the problems depend on the
font used and perhaps other factors. In my setup, for example,
ClearType is quite
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Yes, I looked at the code but decided it takes me too long time at the
moment. Kim, is this easy for you?
Changes to redisplay are NEVER easy ...
I made a seemingly trivial change to fix one bug ... and two years
later
Lennart Borgman (gmail) wrote:
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Yes, I looked at the code but decided it takes me too long time at the
moment. Kim, is this easy for you?
Changes to redisplay are NEVER easy ...
I made a seemingly trivial change to fix
Lennart Borgman (gmail) wrote:
I looked a bit at the code. (First time I used tags, quite nice.) Is it
in set_point_both in intervals.c that the magic happens? It looks from
that code like internally an intangible property is used in cases like
this.
And that was totally wrong of course
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts
Eli Zaretskii wrote:
Date: Wed, 11 Apr 2007 22:53:18 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], Kim F. Storm [EMAIL PROTECTED]
Maybe it would help users and save developers some time if the problems
specific to common fonts where mentioned too?
What problems
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
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
1 - 100 of 195 matches
Mail list logo
