It works correctly, provided the characters in that string can be
expressed in the unibyte buffer.
But which characters can be expressed is poorly specified. E.g. Tell me
which chars can be expressed in a unibyte buffer in a BIG5 locale?
Mentioning the locale is somewhat of a
If one uses the default multibyte session, using unibyte strings is
prone to subtle problems as described in this thread.
I was not following the thread. Could you explain the problem
that was encountered?
___
emacs-pretest-bug mailing list
Hmm, shouldn't configure just be using AC_CHECK_SIZEOF(long) instead of
defining such things in the m/ files?
It would be cleaner, but that is not how we have traditionally handled
it, and this is not the best time to change that mechanism.
So I wonder what is going on with the amdx86-64
Code which implicitly converts text from multibyte to unibyte (and vice
versa), using nonascii-*, will presumably be used in all kinds of locales,
including BIG5 ones. So knowing what happens in this case is
still relevant.
It is not hard to know what happens--that is documented
C-y/M-y uses `insert' somewhere internally. My suggestion is to make
`insert' signal an error when faced with the need to insert a multibyte
string in a unibyte buffer. This doesn't mean that C-y/M-y should propagate
this error.
That might work. We could try it, after the
S-down-mouse-1 is bound to ruler-mode-mouse-set-left-margin.
S-mouse-1 is not defined, so the message is accurate.
Does this result in good behavior?
*** ruler-mode.el 07 Feb 2006 18:16:15 -0500 1.26
--- ruler-mode.el 25 Oct 2006 09:34:38 -0400
***
*** 527,532
I suggest you debug the next such crash by studying the structure
of byte_stack_list and what it points to. Try to identify the
specific object that is clobbered, and how it is wrong.
(gdb) p *stack
$6 = {pc = 0x8375629 , top = 0x6610, bottom = 0xbff3c988,
byte_string = 135894490,
I am not surprised that there are problems in Arabic support,
since we have not yet installed support for right-to-left.
Therefore, I think we don't need to fix other bugs in Arabic
support for this release.
If they are easy to fix, then let's fix them. Otherwise we
can disregard them.
Gnus stored a name of a news group in encoded form.
There is a big difference between unibyte strings and encoded unibyte
strings. The latter indeed requires a lot of special care.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
After some trial and error, I propose the following patch. I have
verified that it makes the reported bug go away. Does anyone disagree
with it?
Yes, though I'm not interested in that fork.
We cannot switch to a different version now, before the release.
We need to fix the
So I wonder what is going on with the amdx86-64 configuration:
why someone else expected it to have 64-bit longs, while Stefan's
machine uses 32-bit longs.
I think because he's using a 64-bit kernel, but 32-bit libraries etc (so
programs like Emacs use a 32-bit ABI) -- and
There is a big difference between unibyte strings and encoded unibyte
strings.
What is that difference?
You can represent one of Emacs' supported Latin alphabets in
(unencoded) unibyte strings, and Emacs will automatically convert to
and from multibyte.
However, if you store
However, if you store encoded text in unibyte strings, you are
responsible for decoding and encoding when necessary. You have to
keep track, everywhere, of whether the data is encoded or not.
It's pretty easy to keep track of it: unibyte == encoded, multibyte
== decoded.
You can represent one of Emacs' supported Latin alphabets in
(unencoded) unibyte strings, and Emacs will automatically convert to
and from multibyte.
AFAIK, Latin-N unibyte strings and iso-8859-N text encoded in Latin-N
use the same numerical codes for the same characters,
Right. I've just installed the attached fix. Or, should we
change insert-file-contents?
It seems more natural to do this in revert-buffer,
because insert-file-contents is in general used with buffers
that are not empty.
___
emacs-pretest-bug
Yes, OK. I sent these info only for your information. (Unfortunately I
don't work on opensorce sw officially,
Please don't think of GNU Emacs as open source.
GNU is part of the free software movement; we developed
GNU Emacs for the sake of users' freedom.
See
So if you could find the reason of this strange difference related to
(point), then there would be no performace problem with whitespace.
I suspect this has to do with the way overlays are stored -- in two lists,
those before the center and those after the center.
(The center can be any
1) emacs -f server-start with server-use-tcp set to off throws an error
(cannot bind to socket: address already in use). If server-use-tcp is
enabled, the error disappears - so old-style local socket use is
currently broken.
Does this mean that the emacs server is now
I can't tell you a formula for debugging these problems
because they are very hard. I think it will be necessary
for you to learn more about the internal data structures;
then if you're very clever you might find the cause of these crashes.
___
Could *please* someone document the function `overlay-recenter' in the
Elisp manual.
I will do so.
Would someone please install Martin's patch?
It appears that nothing in Emacs normally calls overlay-recenter.
Shouldn't we set up some occasional calls (overlay-recenter (point))?
Would
Do you get correct results with this change?
Index: dired-aux.el
===
RCS file: /cvsroot/emacs/emacs/lisp/dired-aux.el,v
retrieving revision 1.148
retrieving revision 1.149
diff -c -c -r1.148 -r1.149
*** dired-aux.el18 Oct
Scoring of the messages closer to the beginning of the buffer is fast,
but as we move to higher-numbered messages, that are closer to the end
of such big files/buffers, gnus will only score 2-3 messages per
minute, and that's what kills performance.
Does Gnus make lots of
If you've found a slowness in remove-overlays, could you aim to make
that function faster, rather than making its caller faster by not using
remove-overlays?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
tzdata¹, used by glibc and others, does exactly this. And most of the
linux and bsd -based dists have unbundled it from the libc packages to
make it easier to keep up to date. (As an example, in Gentoo it is
called sys-libs/timezone-data.)
That sounds like exactly the right
We changed the value of the EMACS envvar so as to fix a bug. That bug
was real and needed to be fixed, but the fix causes another problem.
Making that fix an option is not a solution, since it just means
people choose between one bug or another bug.
If people want to reopen this issue, the way
This patch implements this (modulo the requisite documentation
changes).
Please do not go ahead with this solution. Adding an option
to choose between two broken behaviors is not a good solution.
___
emacs-pretest-bug mailing list
It's clearly one or the other. Personally, I think we should revert
the changes, and get whichever projects use EMACS in their build
scripts to use some other variable name instead.
I don't like that approach because it conflicts with a general
convention for makefiles. I think that
So we should simply tell whichever programs look for EMACS=t to change?
I think that is the right thing to do.
Another possibility is to switch to a different envvar name, but I
think that would make an even bigger transient.
___
It works in that it does speed up entering in new folders.
However, it breaks mail splitting in that, at the time buffers are to
be saved, vc-before-save ends up trying to require vc-RCS, so
newly-split e-mail is not saved, remaining in open modified buffers
until I override
OK. I'll email the SWI Prolog people to get them to make that change,
and remove this item from FOR-RELEASE.
Could you please add an item about this in etc/PROBLEMS?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Another possibility is to switch to a different envvar name, but I
think that would make an even bigger transient.
I don't think it'll be much bigger. And it has the benefit of being
cleaner.
Let's set another envvar now, and suggest that other programs switch
to it gradually.
I wrote code to (1) eliminate the peculiar upcasing dotless-i to I,
and downcasing I-with-dot to i in the default case, and (2) make the
Turkish language environment fully set up Turkish case conversion for
all four characters.
I will install it soon.
So, in the meantime, Emacs will set *two* envvars, EMACS and
INSIDE_EMACS? That's really ugly.
It's not ugly. That's the way to do a transition.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
I noticed the same thing and did it today.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I do not like the idea of making it hang.
It would be nice to detect the lack of file name arguments
and output some sort of error message, but I am not sure
how to detect that condition reliably.
___
emacs-pretest-bug mailing list
Can you send a single precise test case for this problem?
Please read the Bugs section in the Emacs manual, which provides
guidelines on how to write a bug report to give us the
necessary information so we can fix the bug.
___
emacs-pretest-bug mailing
It's very easy if done at the right place: inside GNU grep (rather than
inside Emacs). And it sure should complain: the user specified a search in
0 files, so there's obviously something odd.
It would fit naturally there, but there's a POSIX spec for grep, and I
think this change
This should be fixed in the current sources. Is it?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
To align ido-find-alternate-file more closely with
find-alternate-file, perhaps the current file name should be offered
as a default. This would be particularly useful when using
ido-edit-input. Suggested patch attached.
I've been thinking that perhaps find-alternate-file should
IIUC, the problem that triggered the change from EMACS=t to
EMACS=/where/is/emacs was that some configure scripts (unrelated
to Emacs) assumed that the environment variable EMACS -- if set --
contains the full directory file name of the Emacs executable.
I think that these
It's there --- under Random quotation. I think we should remove it
from the menu bar, since Yow has been pretty much gutted due to legal
reasons.
We may as well. Meanwhile, let's add one quotation to the file
which says Please send your funny quotation suggestions to
[EMAIL
What about the EMACS variable in term mode (the one invoked by M-x
term RET)? Currently, the variable is set to the emacs version, like
$ echo $EMACS
22.0.90.1 (term:0.96)
term should set INSIDE_EMACS as well.
The idea of using the Emacs version as the value is a good
Now, I tried in vain to figure out where the lazy-lock-mode is
possibly set in *my own library files. and/or impoted from emacs archive*.
You can debug that by means of debug-on-entry; call it at the start
of your .emacs file and you should find out what enables lazy-lock.
I would not
Does this change give good behavior?
*** files.el13 Nov 2006 15:19:14 -0500 1.865
--- files.el21 Nov 2006 21:30:29 -0500
***
*** 4081,4086
--- 4081,4091
File %s no longer exists!
Cannot revert
Well, it's simple enough for Emacs to generate, but if it's a constant
strings, it's easier for the other process to recognize it.
It is easy to recognize (comint.
Please don't exaggerate these minor problems.
___
emacs-pretest-bug mailing
| ** The key ESC has been rebound, but you can use instead [More
information] **
`
I fail to understand what but you can use instead means.
Is that because the value is nil? I think that case needs to be
handled specially. It can say just The key ESC has been rebound,
so you
Is this in fact the case, for the default case table of Emacs unicode
2 branch, when the change I made for dotless i is installed there?
Your change is not yet propagated to emacs-unicode-2 branch.
is there any reason not to propagate it there?
If it will be propagated, that will
But from the lusers's point of view, it would be nice to
have a guideline of how to move over to newer and more powerful
libraries/packages such as jit-lock from lazy-lock.
(Info doesn't seem to have been updated...
Would you please be more specific?
Please show the text that
It would be even easier for a shell script to recongize without the
parentheses
I don't see their purpose (except making the value look like Lisp), so let's
leave them out.
Ok.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
I think summarizing the problematic keys _at the very beginning_ of
the tutorial or in a splash screen at it's startup would be much
better than interrupting the tutorial text several times in the middle
of a sentence.
I think that reminders right at the spot will be helpful.
I am a moderator of a NetNews list, which I control with emacs. With
emacs-22 (beta) I can only accept one message; the second one says
Denied posting -- multiple copies but it is not a multiple copy.
If I restart emacs I can send one more message.
This is not a precise report,
font-lock-support-mode has a doc string because it's a variable
and has a slot for one, but we have not documented it in the manual
because it doesn't seem important enough to mention.
Now that there is just one recommended support mode, it is even
less important than it used to be. So I don't
I took care of this. Thanks.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs -Q
C-h i, choose Elisp manual
i :type gives message Info-index: No `:type' in index
Alas, index entries cannot have colons in them.
Perhaps `i' should discard colon at the start, so that this
case will work. What do you think?
Perhaps `i' should discard colon at the start, so that this
case will work. What do you think?
Could work. But I'd suggest to postpone this till after the release.
I think it should be almost trivial -- please give it a try and see.
I note message-mode makes
Subject: =?utf-8?B?5Y+w5Lit5biC6Ieq55Sx6Lev6YKj6bq85aSn?=
whereas mail-mode just puts the raw utf-8 there. Isn't that improper
or something?
Maybe it depends on whose standard you are following.
I find that encoding a super pain in the neck.
However, there is probably a flaw in undump here that is likely
to cause other problems. It appears that state is being preserved
across undump that should not be.
We have to depend on AIX users to debug this.
Can you describe the symptoms?
Meanwhile, I am sure it is possible to
Perhaps `i' should discard colon at the start, so that this
case will work. What do you think?
Could work. But I'd suggest to postpone this till after the release.
I think it should be almost trivial -- please give it a try and see.
It doesn't
I believe the standard X term is visible.
If it is, Emacs should stick with it. But if X uses a different term,
Emacs could switch to that. Can someone check?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
I don't think so. Any windowing system that supports overlapping windows
can have visible windows that cannot be seen by the user due to being
obscured behind other windows.
Then should not the doc string say so?
We don't generally try to make doc strings explain so
Does this fix your problem?
(set-fontset-font
(frame-parameter nil 'font)
'latin
'(tahoma . unicode-bmp))
Yes it does, thanks!
Handa san, should we document this somewhere?
___
emacs-pretest-bug mailing list
I'm seeing a strange problem with 22.0.91.1 on an x86-64 Fedora rawhide
system (22.0.90 had it too). Almost everything works great, but any
attempt to resize an emacs frame using the window manager locks things
up. Essentially, metacity grabs the mouse then stops, waiting for
Should things of the form 1992-2003 be expanded to every member
year?
That is an interesting question. I don't think CC mode was part
of Emacs during all those years. When did it become part of Emacs?
And what copyright years did it have then?
According to the manual, password cashing works if password.el is
included in Emacs.
Why does the situation with caching vary between ssh and scp?
Why can't the scp method do whatever the ssh method does
for passwords?
What about if you use ssh-agent? Does that solve the problem?
My preceding email to Jon was not sent to this list, but the patch in
question was the _NET_ACTIVE_WINDOW hack discussed in the raise-frame
doesn't work in Fedora Core 4 thread on emacs-devel. Apparently, the
hack has bad side-effects.
If this causes serious problems on some
The local minor modes are buffer local variables (and more) and are
already
toggled from the mode line. You don't say why you think this is a bad
user
interface.
Yes I do. From an accessibility point of view it is not good at all.
Why so?
2 - the performance of scp is good for large files, but not for small files.
The performance of ssh is just the opposite. The advantage of ssh here
is that it doesn't surprise nearly as much: nobody is surprised that
editing a large file remotely is slow.
scp gives
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
until after uncompressing it.
No, it shouldn't: it's not uncommon for a system to have several DIR
files along INFOPATH with identical entries pointing to the same
manuals. It would be a nuisance to see all those identical entries
line up in my face.
Well, it could check whether the entries are identical
and
I investigated this. The commands that toggle default values, such as
toggle-case-fold-search, fail to make this clear in their doc strings.
Would someone please fix those doc strings?
There is already a menu item Truncate Long Lines in this Buffer. (Its
doc string doesn't make clear that it
I also see there that the Copyright years 1992-1998 were all listed
explicitly at one point, then in 1999 got changed to the compact
form. So it seems pretty clear they should be put back.
Yes, please do.
___
emacs-pretest-bug mailing list
A few other files have odd Copyright notices, eg
leim/MISC-DIC/CTLau.html
leim/quail/CTLau.el
lisp/international/titdic-cnv.el
lisp/language/thai-word.el
Eg who owns the copyright for thai-word.el in 2006? Who has owned
titdic-cnv.el since 2002?
Handa, can you
I think this means don't delete years, not don't reformat the way
years appear.
I guess it also means list the copyright owners at the time.
No, definitely not.
If someone has assigned copyright to the FSF, then the copyright notices
for his work should say Free Software
What about if you use ssh-agent? Does that solve the problem?
ssh-agent solves the problem.
So does using these 2 lines:
ControlMaster auto
ControlPath /tmp/[EMAIL PROTECTED]:%p
in ~/.ssh/config, and having an existing ssh connection to the remote
host. Then
The immediate problem can be worked around by building emacs
as a user who has no access to /dev/kmem (normal users do not).
This causes getloadavg to fail before emacs undumps, leaving
state initialized properly for operation after the undump.
Let's implement code to prevent
Except when the remote host needs your password to read your
.ssh/authorize_keys, as is the case when this authorize_keys file is on an
NFSv4 partition mounted using Kerberos authentication.
This is an unusual case, and it's not hard to choose ssh if this
case applies to you.
Is undump really supposed to be
saving ALL of bss? I am a bit
suspicious that this should NOT be the case, since getloadavg is one of
the files linked in after the marker
symbols in lastfile.c.
I don't know why this is; perhaps the linker reorders things.
One easy solution
The solution is that the menu items should have different names, e.g.
* Emacs: (emacs-21/emacs). The extensible self-documenting text
editor.
* Emacs 22: (emacs-snapshot/emacs). The extensible self-documenting text
editor.
I think you are right. I think such
This change is a good idea, but it should use the active voice.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Should `M-x insert-file' also check the file size and ask for
confirmation?
That seems like a good idea.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
There is already a menu item Truncate Long Lines in this Buffer. (Its
doc string doesn't make clear that it applies only to the current
buffer.) We could have a couple more such options -- but not too
many!
It sounds like you are suggesting more items for the menu
Does this give good results?
*** dired.el06 Nov 2006 10:51:18 -0500 1.353
--- dired.el02 Dec 2006 12:54:18 -0500
***
*** 1045,1053
;; treat top level dir extra (it may contain wildcards)
(dired-uncache
(if (consp dired-directory) (car
OK, I didn't appreciate that. Now I fail to see why the original question
was
`interesting' at all, or why you wished to know when CC mode became part of
Emacs, as it seems to have a striaghtforward answer.
It has to do with which years it was released in. For the time it was
I see the .el file is now is lisp/obsolete where it does not get installed
by default,
It does get installed. And it is autoloaded.
Actually, I think it isn't. This is because of the change we made
a couple of months ago not to scan the `obsolete' directory for
autoloads.
It's
-(defconst sgml-namespace-re [_[:alpha:]][-_.[:alnum:]]*)
-(defconst sgml-name-re [_:[:alpha:]][-_.:[:alnum:]]*)
+(defconst sgml-namespace-re [_[:alpha:]][-_.[:alnum:]]\\{,64\\})
+(defconst sgml-name-re [_:[:alpha:]][-_.:[:alnum:]]\\{,64\\})
(defconst sgml-tag-name-re (concat
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
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
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
You need to upgrade Makeinfo.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
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
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
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 from the
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.
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's
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
I wouldn't
feel comfortable to change such an important function so shortly
before the Emacs release without providing a simple way back in case
of problem with the loop implementation.
This is a simple, localized bug fix, and I'd rather fix the bug than
have it in the release.
This change seems reasonable. Would you please install it?
But we still face the question of whether to make another change in
the way C mode finds defuns, for efficiency.
That is an important question, I think.
___
emacs-pretest-bug mailing list
Perhaps there is a compelling reason to provide this new capability to
the left mouse button, such as an attempt to accommodate those with a
2-button mouse.
The compelling reason is compatibility with lots of other applications.
For that reason, the changes you've proposed simply
6. In any case, the new behavior should be documented since it applies
whenever `open-paren-in-column-0-is-defun-start' is set to nil.
Where are documentation changes are needed for this?
___
emacs-pretest-bug mailing list
It does not fail for me.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
601 - 700 of 1131 matches
Mail list logo
