Miles Bader [EMAIL PROTECTED] writes:
On Wed, 9 Mar 2005 20:24:47 -0600 (CST), Luc Teirlinck
[EMAIL PROTECTED] wrote:
So why is `next-line' so sub-optimal?
It calls line-move.
Er, Ok, so then why is line-move so sub-optimal? It might be a bit
slower than forward-line, but surely it
Glenn Morris writes:
This save-excursion can't do anything meaningful to preserve
point in the calendar buffer can it?
No, it's complete rubbish! As you and Stefan pointed (ahem) out,
I'm saving point in the calling buffer, not the calendar. Being
extra dim this week, sorry.
But
Richard Stallman [EMAIL PROTECTED] writes:
It is not very dangerous, since it asks the user for confirmation.
I just have been bitten by something even worse: namely rename-file.
I wanted to move a file into some other directory. So I did
M-x rename-file RET somefilename RET /tmp RET
then I
Matt Hodges writes:
Anyway, I've briefly tested the attached patch (including your
calendar-redrawing stuff), and it seems OK, so far.
The change to cal-move.el in that patch is extraneous. Sorry.
___
Emacs-pretest-bug mailing list
,-- On Wed, 09 Mar 2005 00:39:35 +, Glenn Morris wrote:
|
|
| I think this is basically something that Alan Shutko reported to me by
| mail. If you use #includes, the calendar gets redrawn every time one
| is processed, and you only get the diary marks appropriate to the last
| one. Should
Symptoms:
$ emacs -q --no-site-file
Type a, then RET, then SPC. Then type C-a. The cursor is before
the a. I think it should be one line lower.
(The input is also what is shown in Recent input below.)
In GNU Emacs 22.0.50.18 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2005-03-10
,-- On Wed, 09 Mar 2005 00:36:28 +, Glenn Morris wrote:
|
|
| I think this is all caused by the moving point issue reported by Matt
| Hodges on 08/03/05 (point gets moved off a valid date,
| calendar-cursor-to-date returns nil, mark-visible-calendar-date
| barfs); I don't think there is any
From: Jan D. [EMAIL PROTECTED]
To: emacs user [EMAIL PROTECTED]
CC: emacs-pretest-bug@gnu.org
Subject: Re: gtk scrollbar problem
Date: Fri, 04 Mar 2005 18:27:26 +0100
emacs user wrote:
problem: quite often the gtk scrollbars don't readjust to the size of
windows. Please see attached jpg.
This
problem: quite often the gtk scrollbars don't readjust to the size of
windows. Please see attached jpg.
This problem is not easily reproducible. It mostly happens when I
quite the vm mail reader. I'd be happy to run diagnostics if someone
is willing to guide me.
Can you test with a non-gtk
In GNU Emacs 22.0.50.10 (i686-pc-linux-gnu, GTK+ Version 2.6.2)
of 2005-03-09 on dugong
Distributor `The XFree86 Project, Inc', version 11.0.4031
configured using `configure '--with-gtk''
The attached patch fixes a typo in the goto-line documentation,
changes C-u to \\[universal-argument]
Am 08.03.2005 um 16:15 schrieb Jake Bowers:
I made make-package get beyond the getopt error by copying getopt.*
Hello!
I remember again that case! It's that end in make-package:
gcc -I/sw/include -L/sw/lib -fpascal-strings -fno-common -DMAC_OSX
-I../mac/src -DHAVE_CONFIG_H -I. -I../src
emacs user wrote:
From: Jan D. [EMAIL PROTECTED]
To: emacs user [EMAIL PROTECTED]
CC: emacs-pretest-bug@gnu.org
Subject: Re: gtk scrollbar problem
Date: Fri, 04 Mar 2005 18:27:26 +0100
emacs user wrote:
problem: quite often the gtk scrollbars don't readjust to the size of
windows. Please see
Jay,
It works now -- Wow -- that was a fast fix.
Thanks,
Chris Kuklewicz
On Mar 10, 2005, at 2:31 AM, Jay Belanger wrote:
ChrisK [EMAIL PROTECTED] writes:
...
What it should look like:
foo := 1
foo + 1 = 2
What it does look like:
foo := 1
foo + 1 = foo + 1
Thanks for pointing this out.
It should
Hello!
After having solved a few days ago the early death of make I updated
the sources from CVS because Ken'ichi HANDA has fixed a problem with
ispell. Now making stops here (is this the same error that you found
before, Jake?):
echo dispnew.o frame.o scroll.o xdisp.o window.o charset.o
Moving the mouse pointer over the splash screen, items in dired,
inverting text in the *Apropos* buffer, etc. results in a beep/bell and
messages of the following sort in the minibuffer (and in the *Messages*
buffer):
mouse-on-link-p: Wrong type argument: integer-or-marker-p, (#window 14
on
Kenichi Handa [EMAIL PROTECTED] writes:
Stefan Monnier [EMAIL PROTECTED] writes:
Maybe a workaround is to give them generic string fence syntax (aka |)?
[That hasn't got to me.]
It seems to be a good idea. Are there any objection?
That isn't correct. There is a comment somewhere in the
Reiner Steib [EMAIL PROTECTED] writes:
\glq, \glqq, ... are defined in the babel LaTeX package (see texdoc
babel, table 4 or babel/babel.def and babel/*.ldf).
Ah, that explains why I couldn't find them under texmf/tex/latex --
it's years since I looked at Babel.
Yes, a menu similar to the
The following entries could usefully be added to
`locale-language-names' (taken from recent glibc):
aa_DJ Latin-1
aa UTF-8
az UTF-8
kn Kannada
ml Malayalam
mn UTF-8
se UTF-8
so_ET UTF-8
so Latin-1
st Latin-1
ta Tamil
ti UTF-8
tt UTF-8
ur UTF-8
zu
I have to admit that things like those described in my previous eMail
happen when one forgets to 'make clean!'
Having cleaned my X11 build, make-package went fine -- except that I
did not remove or save the old EmacsInstaller.dmg! This was my chance
to remove the -L. hack too -- and Carbon
Maybe a workaround is to give them generic string fence syntax (aka |)?
[That hasn't got to me.]
It seems to be a good idea. Are there any objection?
That isn't correct. There is a comment somewhere in the doc or code
about quotation marks intentionally _not_ having string syntax in text
However, as far as I remember, it needn't be confined to GTK. I think
the Lucid and Motif menus should be able to display utf-8 in a utf-8
locale, at least with recent enough XFree86/X.org for Lucid. I don't
recall the details, though, and I think the Lucid menu code needs
fixing in some
I found a way to fix this to do what people want.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
One reason for this is that I am sometimes not releasing the mouse
button fast enough.
Perhaps we should increase the default time threshold.
The second reason is the delay until the action associated with the
click is actually performed and that one has to keep the mouse pointer
Animate used next-line instead of forward-line. I have fixed that.
Performance is now comparable to 21.3, and I even run 22.x without
optimizations.
Thank you.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
In article [EMAIL PROTECTED], Dave Love [EMAIL PROTECTED] writes:
The following entries could usefully be added to
`locale-language-names' (taken from recent glibc):
aa_DJ Latin-1
aa UTF-8
az UTF-8
kn Kannada
ml Malayalam
mn UTF-8
se UTF-8
so_ET UTF-8
so
In article [EMAIL PROTECTED], Dave Love [EMAIL PROTECTED] writes:
Kenichi Handa [EMAIL PROTECTED] writes:
Stefan Monnier [EMAIL PROTECTED] writes:
Maybe a workaround is to give them generic string fence syntax (aka |)?
[That hasn't got to me.]
It seems to be a good idea. Are there
On GNU Emacs 21.3.50.1 (i386-mingw-windows98.3000) of 2005-01-30 on
NONIQPC I write the following variant of `clone-indirect-buffer':
(defun my-clone-buffer ()
(interactive)
(make-indirect-buffer
(current-buffer) (generate-new-buffer-name (buffer-name)) t))
I now open a larger file say
27 matches
Mail list logo
