(Sorry, failed to copy the list on this reply)
On 12/5/06, Richard Stallman <[EMAIL PROTECTED]> wrote:
With M-x cd, entering "/t" TAB completes to "/top-dir/" like it should,
but "/top-dir/s" TAB does NOT complete to "/top-dir/sub-dir/" even though
there is only 1 matching directory
Richard Stallman wrote:
> On this subject, was it ever decided whether "2001" (the year 21.1 was
> released) should be added to all files that were present in Emacs at
> that time?
>
> Yes, it should be.
Marvellous. It is missing from a large number of files. I just fixed
lisp/*.el, w
Corrected message:
It's a consequence of the recent change to `beginning-of-defun-raw'.
Compare the threads "font-locking and open parens in column 0" and
"emacs hangs in jit-lock".
What sort of text causes this error in scan_lists?
We want to do something to prevent C mode from alw
On this subject, was it ever decided whether "2001" (the year 21.1 was
released) should be added to all files that were present in Emacs at
that time?
Yes, it should be.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://li
> That is because Emacs has no way of telling how big it is
> until after uncompressing it.
That's not really true: GNU zip has the --list option, which generates
output like:
compressed uncompr. ratio uncompressed_name
12574759 58689536 78.5% foo.txt
1. How long doe
> What about providing an option and keep the current recursive as
> default? See the patch below (`gnus-sort-threads-loop' is your
> function).
I think this is a good approach.
Why do we want to keep the recursive version?
Why add an option?
We know that the loop works, so let'
Tim's report is about `M-x cd' (not `M-x dired'),
Indeed, it is. Several of us mistook this for being about Dired.
which already reads
its argument using read-directory-name.
No it doesn't; that was the point we were talking about.
With M-x cd, entering "/t" TAB completes to "/top-dir/" like it should,
but "/top-dir/s" TAB does NOT complete to "/top-dir/sub-dir/" even though
there is only 1 matching directory (TAB TAB shows only "sub-dir" as only
alternative); it's necessary to disambiguate the directory name
It's a consequence of the recent change to `beginning-of-defun-raw'.
Compare the threads "font-locking and open parens in column 0" and
"emacs hangs in jit-lock".
What sort of text causes this error in scan_lists?
We want to do something to prevent C mode from always scanning from
the
> Those should not query. When you ask to revert a buffer, you are
> unlikely to want to stick with the old version just because the new
> one is large.
I'm thinking of an example where I visited a log file shortly after
starting some server. Then a few hours later I ask to r
You need to upgrade Makeinfo.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Don't the copyright years need to be updated to include all years from
2001-2006 inclusive, the period over which they have been available
from the Emacs CVS repository?
Yes, they should be.
___
emacs-pretest-bug mailing list
emacs-pretest-
Maybe we should add a few more menu bar items to toggle things for the
current buffer, analogous to Truncate Long Lines in This Buffer.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
On this subject, was it ever decided whether "2001" (the year 21.1 was
released) should be added to all files that were present in Emacs at
that time? When we went through this copyright update process the
first time, sometimes it was added and sometimes it was not. Or is it
not important?
I get these warnings during compilation on x86_64-unknown-linux-gnu with
Debian testing with gcc (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)
I identified the reason for the first one and posted it on emacs-devel,
where I am going to follow up the answer I got. I plan to consider the
other
hi folks,
i'm including a new version of `egpg' (was `dired-gpg'), the
emacs-dired frontend to gpg.
feel free to have a look at it, send comments, or discard it, if you
wish!
best regards, mirko.
___
Telefonate ohne
Hi everybody!
On Mon, 4 Dec 2006, martin rudalics wrote:
> I see this too a lot, even in plain C files. A backtrace when this
> happen looks like this:
>
> Debugger entered--Lisp error: (scan-error "Containing expression ends
> prematurely" 107612 107612)
> scan-lists(107699 -1 0)
> forwar
> Date: Mon, 04 Dec 2006 22:09:26 +0200
> From: Eli Zaretskii <[EMAIL PROTECTED]>
> Cc: emacs-pretest-bug@gnu.org
>
> > ./ack.texi:520: Unknown command `/orgensen'.
>
> This is a bug; I will fix it shortly.
Done.
___
emacs-pretest-bug mailing list
em
> From: Michael Albinus <[EMAIL PROTECTED]>
> Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
> Date: Mon, 04 Dec 2006 21:09:39 +0100
>
> Anyway, I'm not a regular w32 user, so I would appreciate all
> recommendations.
Thanks for the explanation. I will investigate and get
martin rudalics skrev:
>> I see this too a lot, even in plain C files. A backtrace when this
>> happen looks like this:
>>
>> Debugger entered--Lisp error: (scan-error "Containing expression ends
>> prematurely" 107612 107612)
>> scan-lists(107699 -1 0)
>> forward-list(-1)
>> backward-list(1
> From: "Marshall, Simon" <[EMAIL PROTECTED]>
> Date: Mon, 4 Dec 2006 10:00:51 -
>
> My system has makeinfo version 4.2
This is too old; please upgrade.
> (cd man; make info)
> cd /rvcarma/marshals/software/emacs/man; makeinfo --force emacs.texi
> ./display.texi:170: Unknown command `tie'.
Eli Zaretskii <[EMAIL PROTECTED]> writes:
> What is the issue here, and how does one see it in tramp.el? (I
> didn't follow this thread, sorry.)
When using 'scp' instead of 'ssh' for tramp transfers, you are
prompted for your password when you connect, each time you visit a
file, and each time y
Eli Zaretskii <[EMAIL PROTECTED]> writes:
Hi Eli,
>> Under w32, it still might be desirable to go back to plink as default
>> method. Here I would like to get a recommendation from w32 users.
>
> What is the issue here, and how does one see it in tramp.el? (I
> didn't follow this thread, sorry.)
> From: Michael Albinus <[EMAIL PROTECTED]>
> Date: Mon, 04 Dec 2006 08:05:23 +0100
> Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
>
> Under w32, it still might be desirable to go back to plink as default
> method. Here I would like to get a recommendation from w32 users.
W
Reiner Steib <[EMAIL PROTECTED]> writes:
> I'd suggest the following patch on top of the previous. Which size
> was sufficient for you?
I used 2000 instead of 200. Can the array be made to grow as needed,
rather than having a hard limit to the maximum thread depth?
> Another workaround would b
Richard Stallman wrote:
Normally upon trying to open a large file, we get a warning like "file
is bigger than XX MB, proceed?". However, the same file, if
compressed, won't cause the warning upon attempts to open/view it.
That is because Emacs has no way of telling how big it is
unti
Reiner Steib <[EMAIL PROTECTED]> writes:
> I searched the archives and I only found one more report about this
> problem, so it seems to be a *very rare* situation. I'm not sure if
> such a change should be made now (in the stable series).
>
> What about providing an option and keep the current r
On Mon, Dec 04 2006, Chris Moore wrote:
> OK, so the 'loop' version of the sort function does seem to work, but
> fixing that has shown up a new problem.
>
[ gnus-make-thread-indent-array ]
> The '200' and '201' in this function limit the thread depth.
I'd suggest the following patch on top of th
Yes; it fixes the problem.
Kevin Gallagher
FCS SOSCOE Configuration & Control
The Boeing Company
281-226-6888
-Original Message-
From: Richard Stallman [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 02, 2006 11:57 AM
To: [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Subject: Re:
Chris Moore <[EMAIL PROTECTED]> writes:
> Chris Moore <[EMAIL PROTECTED]> writes:
>
>> One thing I noticed it that the new sort funcction changes the length
>> of the list of threads:
>>
>> *** Welcome to IELM *** Type (describe-mode) for help.
>> ELISP> (length before-sorting)
>> 106
>>
Richard Stallman wrote:
Should `M-x insert-file' also check the file size and ask for
confirmation?
That seems like a good idea.
Note that insert-file-1 is called by both insert-file and
insert-file-literally:
2006-12-01 Kevin Rodgers <[EMAIL PROTECTED]>
* files.el (insert-
Richard Stallman wrote:
This change is a good idea, but it should use the active voice.
This more closely matches the description of `M-x find-file-literally'
i.e. "Visit a file with no conversion of the contents."
*** files.texi.orig 2006-09-12 20:19:29 -
--- files.texi 2006-12-04 10
Kim F. Storm wrote:
Tim Van Holder <[EMAIL PROTECTED]> writes:
My original report received no replies and it's been over 3 months,
hence this ping.
Originally reported for GNU Emacs 22.0.50.1 of 2006-08-01.
Still present in GNU Emacs 22.0.91.1 of 2006-12-04.
Given a directory structure of the
Chris Moore <[EMAIL PROTECTED]> writes:
> One thing I noticed it that the new sort funcction changes the length
> of the list of threads:
>
> *** Welcome to IELM *** Type (describe-mode) for help.
> ELISP> (length before-sorting)
> 106
> ELISP> (length after-sorting)
> 258
That seems t
Richard Stallman <[EMAIL PROTECTED]> writes:
> That change is needed, and not too big.
> If it works, please install it.
I don't think it does work quite right.
I've tried opening the mailbox with the long thread and it still
doesn't work. I get a different error now though:
Debugger entered
Very occasionally I see my backup files are created in the wrong
place, but I've been unable to reproduce this behaviour.
I have this setting:
backup-directory-alist is a variable defined in `files.el'.
Its value is (("." . "Backup"))
The idea is that backup files are created in a subdirecto
On Sun, Dec 03 2006, Chong Yidong wrote:
> Chris Moore <[EMAIL PROTECTED]> writes:
>
>> I just tried opening a mail folder using nnimap in gnus.
>>
>> One of the threads in the folder is 834 messages long, and each
>> message in the thread is a reply to the previous one which results in
>> the thr
That change is needed, and not too big.
If it works, please install it.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Tim Van Holder <[EMAIL PROTECTED]> writes:
> My original report received no replies and it's been over 3 months,
> hence this ping.
>
> Originally reported for GNU Emacs 22.0.50.1 of 2006-08-01.
> Still present in GNU Emacs 22.0.91.1 of 2006-12-04.
>
> Given a directory structure of the form:
>
>
> I see this too a lot, even in plain C files. A backtrace when this
> happen looks like this:
>
> Debugger entered--Lisp error: (scan-error "Containing expression ends
> prematurely" 107612 107612)
> scan-lists(107699 -1 0)
> forward-list(-1)
> backward-list(1)
> beginning-of-defun-raw(n
Tim Van Holder skrev:
For a few weeks now, I've had intermittent issues editing C++ code in
Emacs; I was hoping to find some minimal reproducible case, but have
been unable to do so.
The symptoms are that while editing a C++ source file (typically
happens when killing or yanking, but I think I
CVS as of Dec 4 builds and runs ok on:
In GNU Emacs 22.0.91.6 (sparc-sun-solaris2.8, X toolkit)
of 2006-12-04 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure 'CFLAGS=-g''
And
In GNU Emacs 22.0.91.6 (sparc-sun-solaris2.8, Motif Version 2.1.0)
of
For a few weeks now, I've had intermittent issues editing C++ code in
Emacs; I was hoping to find some minimal reproducible case, but have
been unable to do so.
The symptoms are that while editing a C++ source file (typically
happens when killing or yanking, but I think I've seen it happen
with re
Richard Stallman <[EMAIL PROTECTED]> writes:
> recover-file
> recover-session-finish recover-this-file revert-buffer
>
> Those should not query. When you ask to revert a buffer, you are
> unlikely to want to stick with the old version just because the n
Stefan Monnier <[EMAIL PROTECTED]> writes:
> All in all I suggest the patch below, which does seem to remove the
> O(N^2) behavior.
That patch fixes the problem for me, works a lot faster than my nasty
\\{,64\\} hack, and has the added benefit of not limiting the length
of names which will be col
45 matches
Mail list logo
