After starting Emacs with -Q I start flyspell-mode in the
*scratch* buffer. I then paste some text into the buffer and
turn CUA mode on from the [options] menu. If I try to select
text using shifted arrow keys the selection is erratic. That is,
sometimes text will be selected and sometimes not.
It looks like an infinite recursion in functions project-am-makefile,
project-am-load-makefile, project-rescan, and eieio-generic-call.
Those are in add-on packages not included in Emacs. I think you
need to talk with the people who maintain them.
___
The problem is that the buffer is put in C mode (because of the mode:C in
the file local variables) and that the font-lock-keywords of C mode are very
complex nowadays and they end up parsing the whole file.
That seems like a bug. Aside from stealth fontification, Font-Lock
mode is on
> Does this give good results?
Yes. That seems to do the right thing.
Nick
> --- compile.el 24 Sep 2005 22:42:54 -0400 1.384
> +++ compile.el 27 Sep 2005 22:21:08 -0400
> @@ -899,7 +899,7 @@
>:group 'compilation)
>
>
> -(defun compilation-buffer-name (mode
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> When I look at (standard-case-table) I see a
> sequence which looks as if it is used for converting to uppercase,
> containing the following subsequence: 65 66 67 68 69 70 71 72 331856
> 74 75 76 77 78 79 80 81 82 83 84
Thank you for your response which helped me locate the offending code. I
had in my .emacs file the following customization setting left over from
version 21:
'(enable-multibyte-characters nil)
Now that I have removed it for 22 the problem has gone away. I don't
understand why this enable
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> *** src/cm.c7 Aug 2005 12:33:16 - 1.20
> --- src/cm.c27 Sep 2005 19:11:04 -
> *** Boston, MA 02110-1301, USA. */
> *** 33,39
> #if defined HAVE_TERMCAP_H && 0
> #incl
Does this give good results?
*** compile.el 24 Sep 2005 22:42:54 -0400 1.384
--- compile.el 27 Sep 2005 22:21:08 -0400
***
*** 899,905
:group 'compilation)
! (defun compilation-buffer-name (mode-name name-function)
"Return the name of a compilation buffe
*** src/cm.c7 Aug 2005 12:33:16 - 1.20
--- src/cm.c27 Sep 2005 19:11:04 -
*** Boston, MA 02110-1301, USA. */
*** 33,39
#if defined HAVE_TERMCAP_H && 0
#include
#else
! extern void tputs P_ ((const char *, int, in
When I look at (standard-case-table) I see a
sequence which looks as if it is used for converting to uppercase,
containing the following subsequence: 65 66 67 68 69 70 71 72 331856
74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90. The 331856 should
be a 73 to yield an 'I',
Recently there a strange interaction between flyspell mode and
selecting test with the mouse or using transient-mark-mode:
(0) Create this file:
echo "# This is a Makefile foo bar" > Makefile
(The problem is not specific to GNUmakefile mode; I also see it
in other modes, e.g. mess
>> You can still see the same problem with the above if right after opening
>> the file you do M->
> Yes, I can. In fact if I leave y-or-n-p defined as it should be, I see the
> long pause twice - once when I visit the file and once again when I do
> "M->". Is Emacs font-lockifying the buffer twi
"Переговоры
о цене и возврате дебиторской задолженности"
5-6 октября. тренинг
Как обосновать и удержать цену и вернуть долг?
Как противостоять манипуляциям покупателя?
Как понять, когда можно пойти на уступки, а когда не стоит?
Как преодолеть дискомфорт, который возникает при разговоре
On 28 Sep 2005, at 11:23, Miles Bader wrote:
2005/7/21, David Reitter <[EMAIL PROTECTED]>:
As the attached screenshot shows, the letter spacing is bad in Emacs.
If you don't like it, you can set the variable `line-spacing' to
change it...
1. letter spacing != line spacing
2. the proble
2005/9/28, David Reitter <[EMAIL PROTECTED]>:
> 1. letter spacing != line spacing
My mistake (the mac text api thing seems to be well known; from the
messages I've seen posted here, apparently things are screwy enough
that it's not going to change tomorrow).
-Miles
--
Do not taunt Happy Fun Ball.
2005/7/21, David Reitter <[EMAIL PROTECTED]>:
> As the attached screenshot shows, the letter spacing is bad in Emacs.
If you don't like it, you can set the variable `line-spacing' to change it...
-miles
--
Do not taunt Happy Fun Ball.
___
Emacs-prete
> On Sat, 16 Jul 2005 16:57:13 +0200, "Jan D." <[EMAIL PROTECTED]> said:
> In order to make resizing consistent, Emacs keeps the scroll bar at
> the same width as the character width. But the GTK scroll bars have
> a fixed width, which only sometimes are the same width as the Emacs
> characte
On 4 Jul 2005, at 04:34, YAMAMOTO Mitsuharu wrote:
I couldn't reproduce that on Mac OS 10.3. Either of them failed with
"No fonts match" in evaluation of create-fontset-from-mac-roman-font.
I also tried with the asterisk example with existing font families,
but there's no problem.
Right, I've
(I'm not subscribed so please CC me replies that you want me to reply
to.)
Recently I've found a problem with emacs where gcc optimizes a
function to be inline where it shouldn't be. The emacs developers use
a macro like this:
#define NO_INLINE __attribute__((noinline))
that would normally work
problem: when I have several windows open and then kill some of them (this
mostly occurs when I exit reading mail in vm), the scrollbars are not
updated and appear only where one of the previous windows was. Please see
attached jpg file for a screenshot. I cannot reproduce this in a simple
te
The main point of this is the last two changes in the log entry. I
wanted to be able to send the subprocess output to a normally-readonly
*Help* buffer. This happens asynchronously, so you more-or-less have
to put a hook into Comint. I've implemented something based on this
for Python, and I thi
On Mon, 03 Mar 2003, [EMAIL PROTECTED] wrote:
>> From: robert <[EMAIL PROTECTED]>
>> Date: Sun, 2 Mar 2003 23:07:37 +
>>
>> I guess this may put a question mark against the X protocol errors
>> I've been having too?
>
> I don't think this is related, but who knows?
Just to confirm that afte
> From: robert <[EMAIL PROTECTED]>
> Date: Sun, 2 Mar 2003 23:07:37 +
>
> I guess this may put a question mark against the X protocol errors
> I've been having too?
I don't think this is related, but who knows?
___
Emacs-pretest-bug mailing list
E
This is a reimplementation of error locating in Emacs `compile'. The full
comment is at the beginning of the downloadable
http://dapfy.bei.t-online.de/compile.el
A lot has changed and some thing may currently not work. I would be very
grateful to hear of your experience, especially with some
24 matches
Mail list logo
