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 `
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 go
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 U
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
http://lists.gnu.
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
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
To make reliable judgement about the display state, line-move must
call sit-for which does redisplay.
That is a really bad problem. We need to redesign this.
In the past, functions such as compute-motion did the job.
But they have not yet been upgraded to handle computations
involving va
> 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 som
>>> 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 synta
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 Emac
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
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 t
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 somewh
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, (# 269 (94 . 75) 0
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 cod
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 shoul
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
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
-I/Users/
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] (is
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 bui
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.
Thi
Frederik Fouvry <[EMAIL PROTECTED]> writes:
> 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.
Thanks.
I have installed a fix for this.
--
Kim F. Storm <[EMAIL PROTECTED]> http://www
,-- 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
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-0
,-- 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 b
> 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
Emacs
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
> 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, sor
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
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 mailin
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, b
30 matches
Mail list logo