Peter Dyballa wrote:
When I try the same in xterm or in Apple's Terminal without windows,
the truncated lines like in this example
Debugger entered--Lisp error: (void-variable -)
eval-buffer(#buffer *load* nil /Users/pete/.emacs nil t) ;
Reading at buffer position 2$
Christoph Conrad wrote:
make[1]: Entering directory `/cygdrive/c/user/cco/emacs-cvs/lisp'
Cygwin make does not work for building Emacs. That is documented in
nt/INSTALL.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Zhang Wei wrote:
process.c: In function `conv_sockaddr_to_lisp':
process.c:2307: `uint16_t' undeclared (first use in this function)
Please check if it compiles now. I checked in a Windows specific fix,
since there have never been reports of this in the past, and that code
has been there some
Zhang Wei wrote:
Input the character U+ with `M-x ucs-insert ', it won't
display, not even in a hollow box, it looks like as if that char
doesn't exist, but moving the cursor *does* stop at it.
Try a different font. It may be that the font you are using claims to
support that
Hongzheng Wang wrote:
Jason Rumney wrote:
Try a different font. It may be that the font you are using claims to
support that character, but doesn't have a glyph for it.
I'm afraid not. I can re-produce this bug with the font DejaVu Sans
Mono, which does contain the Unicode char
Lennart Borgman (gmail) wrote:
Unfortunately I do not think that is the right change. This totally
spoils the possibility to use accelerators for the menus on w32. I do
not think the minor problem it solves justifies that.
For now, it is the right change. In future when accelerators are
Peter Wisnovsky wrote:
In GNU Emacs 22.0.990.1 (i386-mingw-nt5.1.2600)
Loading semantic-edit...done
Loading semanticdb-file...done
Emacs 21.1 has been released, so please use that rather than a pretest
version.
Also, I see you are using semantic. Make sure you are using the latest
version
Miles Bader wrote:
The 19 should be 21 in the unicode branch.
I'm not sure I understand what this magic number 19/21 is. Is there a
constant for it that could be substituted?
I'm surprised that that is the only change needed. The code points
between the unicode branch and Emacs 22 should be
Drew Adams wrote:
What does Emacs mean by Emacs 23?
There are currently two branches in CVS identifying themselves as Emacs
23 AFAIK. When you are using CVS versions, it helps considerably if you
tell us details about which branch you are using, rather than relying on
version numbers. I suspect
Drew Adams wrote:
emacs -Q
(aset standard-display-table ?\014 [10 33030176 33030176 33030176
See two attached images. In Emacs 22 (all recent builds), this is
displays correctly. In Emacs 23: 1) Each character appears as an empty
rectangle.
What do you mean by Emacs 23? Thinking
Leo wrote:
In file included from term.c:418:
buffer.h:403: error: redefinition of ‘struct buffer_text’
buffer.h:461: error: redefinition of ‘struct buffer’
buffer.h is included at the top of the file, so doesn't need to be
included again, but shouldn't it be protected against double
The 22.0.990 pretest tarball contains the file
emacs-22.0.990/info/.arch-inventory.
There are many other files of that name in the repository, but they are
filtered out from the release tarballs, so I think the presence of this
one is an oversight.
Rainer Stengele [EMAIL PROTECTED] writes:
M-x dired
//server/sharename
crashes my emacs w32 repeatable. Emacs asks to attach the gdb debugger
but that doesn't really help.
When you say it doesn't help, what exactly do you mean?
Can you try running Emacs under gdb to start with? That
Richard Stallman wrote:
That would be good to install in the unicode-2 branch.
Maybe I am misunderstanding what you wrote there, but it appears that
even bug fixes cannot be installed in HEAD right now?
___
emacs-pretest-bug mailing list
Eivind Midtgård wrote:
In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600)
of 2007-01-01 on DTOP
Please try the latest pretest before reporting bugs in old unreleased
versions.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Lennart Borgman (gmail) wrote:
I just tried the latest pretest (unpatched) and indeed AFAICS Emacs
now behave as it should with a maximized window, at least on Windows XP.
That is very nice! When was that change made?
Apparently there is no such change, as Eivind can still reproduce the
Livin Stephen Sharma wrote:
output of top -o pid
please note:
Carbon Emacs cpu-usage is 81.2%.
Minor modes in effect:
semantic-idle-scheduler-mode: t
have you pulled the latest semantic-idle.el from semantic's CVS, or are
you using the released version? The released one is known to cause
Lennart Borgman (gmail) wrote:
In the attached images I have one overlay one character long that has
a red underline. In the first picture there is only this overlay at
that point and the display is correct.
In the second picture I have added another overlay, with a slightly
blue
Thanks, but I should have sent some code in addition to my
explanation. The above works for me to, but can you please test the
code below. That code gives the error. The important thing is the
newline characters.
The behaviour is the same on w32 as it is on X. What made you say it was
on
Chong Yidong wrote:
Convert filename name to absolute, and canonicalize it.
All your examples are consistent with this behavior. The important
thing is that DEFAULT-DIRECTORY is only consulted if the filename is
relative.
But shouldn't the and canonicalize it step involve replacing the
Richard Matthew Stallman wrote:
The Windows system was using ClearType. Changing that setting fixed
the problem. Thanks Eli.
Should Emacs users always turn off use of ClearType?
These problems are not apparent with most fonts. I can only see them
with some fonts if I reduce the
Juanma Barranquero wrote:
ClearType cannot be deactivated for specific apps
Yes it can.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Juanma Barranquero wrote:
On 4/12/07, Jason Rumney [EMAIL PROTECTED] wrote:
Yes it can.
Cool. How? (I searched Microsoft's docs, but they are less than clear
sometimes and I didn't find anything which seemed to imply
app-specific settings of ClearType...)
You can specify the antialiasing you
graphist wrote:
I'm using NTemacs22 and have found one small bug.
If you add the following statement in .emacs file:
(setq-default case-fold-search nil)
you can't drag and drop some files to emacs (eg: with : in its full
path).
I have tried to modify the dnd-get-local-file-name function in file
Stephan Hennig wrote:
I've done some tests with that version now (This is GNU Emacs 22.0.93.1
(i386-mingw-nt5.1.2600) of 2007-02-19 on LENNART-69DE564).
Scrolling has indeed improved. The erratic up and down movement of the
buffer while dragging the scrollbar in _one_ direction seems to has
Lennart Borgman (gmail) wrote:
But unfortunately the other bug (menu title corruption in the second
popup-menu) is still there.
This bug indeed looks a bit serious IMO. I have not been able to
reproduce it clearly before, but with the test code I sent I see it
every time.
What especially
Here is the end of x-popup-menu in w32menu.c. It looks to me like the
menu structure is freed before selection is used. Obviously you
think otherwise, Jason. Can you explain to me what is happening here?
Does perhaps w32_menu_show do more than the name suggests?
discard_menu_items frees up
Lennart Borgman (gmail) wrote:
I know one should not expect anything if there is no guarantee, but
should all doc strings be read that way?
The doc string for sit-for explicitly states both that it will not wait,
and that it will not redisplay when input is pending.
Lennart Borgman (gmail) wrote:
Thanks, but is there a global variable wv? Do you mean
current_popup_menu? Is that what is freed in w32_free_menu_strings?
That is called right after discard_menu_item.
So I still do not understand.
Indeed it is w32_free_menu_strings that is the function I was
Lennart Borgman (gmail) wrote:
Do you mean that the second menu is created before returning from the
first w32_menu_show. It does not look so to me, but I might be
misreading the code. Is not selection that is returned from the
first w32_menu_show what is used to decide to do?
Lennart Borgman (gmail) wrote:
Ah, then should not menu_kill_timer be called from within
w32_free_menu_strings (or always before that)?
I have fixed it now. I moved the freeing of strings earlier for popup
menus, so we can guarantee they are freed even when a signal is raised
instead of
martin rudalics wrote:
I have the same problem with a popup-menu and a toggle-styled entry.
Whenever I toggle the entry and line- or mouse-move to the menu title,
the latter changes to something like t, a dot, or an unprintable
character. When I toggle the entry again the original title is
Lennart Borgman (gmail) wrote:
There still seems to be some problems with refreshing buffer contents.
In the example below the buffer gets refreshed before the first popup
menu, but not before the second popup menu.
Redisplayed is blocked while popup menus are active. The user's
attention is
Lennart Borgman (gmail) wrote:
I consider this bug and I can see other bugs here that seems related.
Though I do not know if these bugs are only related to the w32 port.
I can't comment, because I don't know which bugs you are referring to.
This particular one is specific to w32, because the
The bugs I refer to here are in the display of the popup menus. The
display of the second popup menu gets garbled very often.
I also once saw that the menus did not open at all. I got an error
instead. I have no idea of why.
Probably not related directly to this, but may be caused by the
Jason Rumney wrote:
This particular one is specific to w32
Actually, I was wrong. redisplay_internal contains the following code
which makes the behaviour the same on X (I have not yet found what
prevents redisplay on Windows)...
#if defined (USE_X_TOOLKIT) || defined (USE_GTK
I wonder if this has something to do with the mime codes? I do not
know anything about it, but could it be that the web server changes
something in the output?
Web servers don't change anything (at least, no web server I've ever
seen does, and I've worked with most of them).
I don't know
Lennart Borgman (gmail) wrote:
We have previously on the developers list discussed coding systems for
*Shell* buffers on w32. I have sent some suggestions, but I do not
think any changes have been done yet. Could we please try to fix this?
There are two parts to this. One part is to set the
Lennart Borgman (gmail) wrote:
We have also discussed the tab file name completion in a cmdproxy
*Shell* buffer. This is currently broken. I sent a suggestion to fix
it, but I have got no feedback whatsoever on this.
http://lists.gnu.org/archive/html/emacs-devel/2006-12/msg01128.html
That
Lennart Borgman (gmail) wrote:
Yes, but it works. But maybe it interferes with the comint code in a
bad way?
We are looking for something that causes backslashes to be used in
completion when the shell is cmd.exe. We are not looking for a complete
replacement for the completion mechanism.
Lennart Borgman (gmail) wrote:
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
We have also discussed the tab file name completion in a cmdproxy
*Shell* buffer. This is currently broken. I sent a suggestion to
fix it, but I have got no feedback whatsoever on this.
http://lists.gnu.org
Lennart Borgman (gmail) wrote:
There is a problem with spaces in the names too in the current code.
And the output is quite confusing as it looks now.
Spaces in file names seems to be a problem for all platforms. What about
the output is confusing?
Prof. G. Venkatarathnam wrote:
The cursor is absent in my emacs in the beginning. If I delete a
character after marking it, I get the usual block cursor. How do I
make my cursor visible ? I din’t have this problem before. I’m using
the latest version of precompiled win32 version available
Paul Whitfield wrote:
In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
of 2005-12-18 on NEUTRINO
Perhaps you should update from CVS more often.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Kenichi Handa wrote:
It seems that default-process-coding-system is not setup
properly on Windows. When I run Emacs on my Windows,
default-buffer-file-coding-system is set correctly to:
japanese-shift-jis-dos
but default-process-coding-system is:
(undecided-dos . undecided-unix)
This is
Lennart Borgman (gmail) wrote:
We never made any decision on this issue. Most of the answers pointed
to that GetUserDefaultUILanguage is the correct function to use. Or am
I just misinterpreting to confirm what I said at the beginning ;-)
You are just misinterpreting to agree with what you
Eli Zaretskii wrote:
This is because DOS programs and Windows programs use different
coding-systems for their output.
I believe you mean console programs and GUI programs, not DOS
programs and Windows programs, is that right?
Right. Native Windows console programs tend to use the DOS
Lennart Borgman (gmail) wrote:
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
We never made any decision on this issue. Most of the answers
pointed to that GetUserDefaultUILanguage is the correct function to
use. Or am I just misinterpreting to confirm what I said at the
beginning
Lennart Borgman (gmail) wrote:
In *Shell* using cmdproxy.exe on w32 a character shows up as \377:
2006-12-10 16:14 6\377588\377879 emacs.exe
It is actually from a directory list where emacs.exe is shown:
2006-12-10 16:14 6 588 879 emacs.exe
It seems you have set
Lennart Borgman wrote:
It is a very good idea to document those keys. Here is a preliminary
list for w32:
- Ctrl-Tab, Ctrl-Shift-Tab
- Ctrl-C, Ctrl-X, Ctrl-V, Ctrl-Z
- Ctrl-A
- Alt-Space
- Esc
- Tab, Shift-Tab
** Also very important:
- Ctrl-arrow key
- Alt-any letter
-
Lennart Borgman (gmail) wrote:
I have never even thought about what Ctrl-Esc does in Emacs. Hope it
does not do anything I want to use.
It doesn't really make any sense, as ESC is used as a sticky Meta key,
so the Ctrl- usually follows it.
That Esc does not run some form of quit is probably
Drew Adams wrote:
1. Reminder: The bug report was about the default order of options in a
custom buffer. If it were alphabetical, users could find options there
easier.
I can't think of any other program that orders its options
alphabetically by default. Usually they are grouped by
Kenichi Handa wrote:
I couldn't compile the second program (saved as mstest.c) by
gcc in my Cygwin environment. This is the error log.
To compile a native Windows program with Cygwin gcc, you need to use
-mno-cygwin.
___
emacs-pretest-bug
Eli Zaretskii wrote:
Date: Fri, 22 Dec 2006 01:11:01 +0100
From: Lennart Borgman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Could people who have access to MS-Windows please try these two
programs and report the results? It is important to describe the full
details about your regional and
Eli Zaretskii wrote:
cmdproxy is IMO the _only_ level where this should be done
I think it is wrong to do this in cmdproxy, as cmdproxy has no knowledge
about what is a filename, and what is a literal string that must be
passed to the command untouched.
The right place to do this is when
Lennart Borgman wrote:
Regional settings:
Your local (location): Swedish
Language setting: x Western Europe and United State (default) -- enda
ikryssade
Where are you getting this information?
Windows AFAIK does not distinguish locale from language, but does have a
User locale and System
LENNART BORGMAN wrote:
Lennart Borgman wrote:
Regional settings:
Your local (location): Swedish
Language setting: x Western Europe and United State (default)
Control Panel - Regional Options - General.
Unfortunately th e Regional Options control panel changes between every
Richard Stallman wrote:
The answer is no, and I've chosen a different solution.
Please drop the subject.
If a developers mailing list cannot be used for discussing development
ideas, then I think I might as well unsubscribe.
Discussing an idea in a useful way does
Richard Stallman wrote:
The answer is no, and I've chosen a different solution.
Please drop the subject.
If a developers mailing list cannot be used for discussing development
ideas, then I think I might as well unsubscribe.
___
Richard Stallman wrote:
It would handle that one case, but it would still produce false
matches.
It would only produce false matches for cases where Emacs would have
defaulted to Fundamental mode.
Yes, and that is a mistaken outcome. There is no reason to make such
Richard Stallman wrote:
Perhaps this can be solved by first doing a case-sensitive scan through
auto-mode-alist, then if that fails to find a match do a
case-insensitive scan.
Brilliant!
It would handle that one case, but it would still produce false
matches.
It would
Miles Bader wrote:
I don't think they'd care in general, and might even approve. Like most
people, even though I never use windows, I occasionally receive files
from windows users, and there's lots of crufty old windows software that
still uses DOS-like names.
I think it's the special cases
Suraj Acharya wrote:
The GUD icons seem to
be a bit odd too - notice the wrapped go and stop icons.
A number of pbm images in the etc/images/gud directory are not marked as
binary.
I tried running cvs admin -kb go.pbm myself, but it did not work, I am
not sure whether it is because I don't
Michael Albinus wrote:
Please do. I hoped it could be determined simply via the existence of
environment variables (as it is possible with ssh-agent, environment
variables $SSH_AUTHENTICATION_*), but it doesn't seem so easy. And I
also don't know a command like 'ps' which returns running
Mathias Dahl wrote:
Richard Stallman [EMAIL PROTECTED] writes:
If .JPG/.JPEG is frequent, perhaps we should add it to
`auto-mode-alist', then. Or do this:
(push '(^\xFF\xD8\xFF\xE0\x00\x10JFIF . image-mode)
magic-mode-alist)
I am not sure which is better, but I
Chris Moore wrote:
Is there any reason not to just treat the regexps in auto-mode-alist
as case insensitive?
Is there any kind of file where the case of the extension matters?
.C is commonly used for c++ files where filenames are case-sensitive.
Lennart Borgman wrote:
I know that it is important that many users build Emacs too, but the
problem on MS Windows is that most users will not do that. That means
that there will be fewer testers when we do not supply prebuilt binaries.
The aim of a pretest has always been to get a limited
Lennart Borgman wrote:
Sounds better to me, but is this only an X-window thing?
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.
ishikawa wrote:
So I am wondering. Is there a way to print the
calling function of turn-on-lazy-lock
a la the following code snippet?
(backtrace)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
The same happens on MS Windows, it is caused by the underlying APIs
that we use to draw text being RTL aware, while Emacs is not. So when
we ask the system to draw a string of text, it is drawn correctly RTL,
but when we draw it a character at a time while moving the cursor,
Emacs does not
emacs user wrote:
From: Jason Rumney [EMAIL PROTECTED]
flyspell-auto-correct-word seems to be more appropriate for binding
to a key than flyspell-correct-word, as the latter relies not just on
the mouse, but on menus as well. I see that is already bound to C-.
yes, but the point was to have
Ralf Angeli wrote:
Perhaps somebody can tell me what the problem was which the check-in
from 2002-02-22 was supposed to solve in order for me being able to
check if this is still an issue. I could not find anything related to
it in the list archives of emacs-devel or emacs-pretest-bug (the
Peter Dyballa wrote:
The reason it *had*, is that I had in load-path four ELisp files:
So if I understand you correctly, this was a local configuration
problem, and we can remove this bug from FOR-RELEASE?
___
emacs-pretest-bug mailing list
People didn't care for that suggestion, so I will continue to test the key
itself. Perhaps I could test the key somehow with `generic-char-p' (how?),
but, as Stefan pointed out, there are also other keys that cannot be
trivially converted to chars.
How about: (char-valid-p
Richard Stallman wrote:
Shouldn't the `single-key-description of a Chinese etc. character simply be
that Chinese character in a string?
In an ideal world, that would be ok, but most people's terminals probably
can't display the Chinese character, so they will see just a box.
Such
Drew Adams wrote:
So what? Binding thousands of characters is something computers are good at.
Binding thousands of characters is a waste of memory and time.
Or are you saying that that would affect performance in an unacceptable way?
If so, what's special about `self-insert-command' -
Kenichi Handa wrote:
But, it seems that we need similay additions to the other
lang. env. Do you have any suggestions?
Here is a list from codepage.el that shows which language groups each
Windows codepage is used for and which standard charset contains the
same characters.
Where it says
Drew Adams wrote:
I'll take your word for it; I know nothing abou this. I thought Handa was
saying that an integer event indicated such an invalid key. If not, then I
guess one is reduced to parsing the `single-key-description' - that's what I
do currently.
You are confusing events with
Drew Adams wrote:
There is nothing in the documentation that suggests that it
should generate a unique value for every possible key sequence.
Maybe there is nothing about that in the doc, but doesn't it seem logical?
No. If that was its purpose, then it should be called something
Richard Stallman wrote:
It is not surprising that that change would have this effect
if a program uses the function this way.
I'm not sure what you mean by this way. I wonder if you are meaning
the explanation of a different bug I gave last week where I discovered
that the semantic-idle
Jason Rumney wrote:
Andreas Roehler [EMAIL PROTECTED] writes:
Sorry, it's not the memory, it's the CPU which is taken.
Do you use semantic? There have been a couple of reports recently
about semantic's idle timer functions taking 100% CPU on recent CVS
versions of Emacs
Andreas Roehler [EMAIL PROTECTED] writes:
Emacs consumes all the memory by time, as `top' indicates.
Sorry, it's not the memory, it's the CPU which is taken.
Do you use semantic? There have been a couple of reports recently
about semantic's idle timer functions taking 100% CPU on recent CVS
Eli Zaretskii [EMAIL PROTECTED] writes:
Okay, but I think what Emacs does now is better. Do we need to follow
bad example of Alt-TAB?
I have to disagree here. If the user is using the keyboard to switch
frames, then they probably want the pointer to stay out of the way,
not move to the frame
Dan Jacobson [EMAIL PROTECTED] writes:
Naw, need complete freedom like M-x grep...
So use M-x grep... we won't report you for it.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
YAMAMOTO Mitsuharu wrote:
Let me confirm one thing. The value doesn't affect the behavior with
respect to the mouse position on W32, either? I'm asking because I'm
thinking about setting its default to nil on Mac Carbon, because if
the value is t, C-x 5 o moves the mouse pointer to the
Andrew M. Scott [EMAIL PROTECTED] writes:
nnrss: http://www.michaelhyatt.com/: Not valid XML (error XML:
(Not Well-Formed) Invalid end tag (expecting p) at pos 49598)
and w3-parse doesn't work (void-function w3-parse-buffer)
You'd be better off asking for help on the gnus mailing lists, as
Richard Stallman wrote:
I have noticed today that while pasting from Emacs to other apps, the
other app seems to hang until some input event occurs in Emacs (normally
when I switch to it and click on the window).
I suspect that the cause is the recent changes to sit-for. I
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 mailing
list.
Please describe exactly what actions triggered the bug
and the precise symptoms of
Chong Yidong wrote:
(nor is it obvious from your description that it IS a
result of sit-for).
I suspected that, because it was changed recently, and there had been
other problems with it, including something about calling it from idle
timers, which I suspected may have been the case here.
Lennart Borgman wrote:
1) A new function quote-special-characters that will quote characters
like (); if it is a unix style shell.
If we DTRT in shell-quote-argument, then we don't need to introduce
further complication.
2) A new function w32-shell-is-unix-style that looks at
Jason Rumney wrote:
We already have w32-system-shells, which is the inverse of the
variable you propose (except it is missing cmdproxy.exe, I am not
sure if there is a good reason for that).
In fact we have a function w32-shell-dos-semantics for precisely this
purpose. So a suitable patch
Lennart Borgman wrote:
There seem to be another bug on w32 too. I just tried using CMD.EXE
for the inferior process instead. That does not seem to work at all. I
got this:
d:/ecvs/:
find . \( -type f -exec grep -q -e message {} \; \) -exec ls -ld
{} \;
find: missing argument to `-exec'
Lennart Borgman wrote:
I think there is a bug in shell-quote-argument that is used here. This
function does not care about shell-file-name. How can quoting succeed
if it does not do that?
Indeed, that is a problem, as is the blind wrapping in double quotes on
w32 when ms-dos has a much more
Lennart Borgman wrote:
In any case the command string that is built and send to CMD does not
work. Here I am using the GnuWin32 port of find, version 4.2.20. Find
complains about the first -exec:
find . \( -type f -exec grep -q -e message {} \; \) -exec ls -ld
{} \;
find: missing
Stefan Monnier wrote:
Huh? I thought we had agreed to use %USERPROFILE% instead (which is
usually closer to Unix's $HOME).
%USERPROFILE% is not defined on some versions of Windows, and it is not
one of the standard locations available through system calls. No other
Windows application writes
Eric Hanchrow wrote:
For what it's worth, this patch seems to make Emacs work as I'd
expect:
Your patch changes the default HOME directory to your personal
preference. The current default was chosen carefully based on MS
guidelines, which directories may be unwritable on a locked down
Eric Hanchrow wrote:
(setenv HOME (getenv USERPROFILE))
This will not affect how Emacs interprets ~/, since you are changing the
environment variable HOME after Emacs has already initialized.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED] wrote:
This doesn't explain why (find-file-noselect ~/) and
(find-file-noselect ~/Application Data/) return the same buffer.
Shouldn't they be differnet no matter what ~ expands to?
find-file-noselect calls (abbreviate-file-name (expand-file-name FILE)),
where
Eli Zaretskii wrote:
Date: Fri, 04 Aug 2006 22:00:02 +0100
From: Jason Rumney [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
We already have a hack in the code to keep the menu for a second,
because we know that Windows tells us these things in the wrong
order
Could you
Ralf Angeli wrote:
IIUC the next step is to look at why get_menu_item_info puts an
integer into dwItemData.
It's a pointer.
I can't reproduce the problem, and the line numbers in your stack traces
are slightly out from what I have in a clean CVS checkout. But IIUC,
what appears to be
1 - 100 of 146 matches
Mail list logo
