Terry J. Reedy added the comment:
I am not currently seeing the problem I reported, so closing. If I type past /
and hit ^space, I sometimes get an empty listbox, but I do not yet have a
consistent failing case. Will open a new issue if/when I get one.
--
resolution: - fixed
stage:
Westley Martínez added the comment:
On Thu, Oct 11, 2012 at 3:06 PM, Terry J. Reedy rep...@bugs.python.org wrote:
Terry J. Reedy added the comment:
This patch (I suspect it is this one) disabled the use of '/' in filenames on
windows when using filename completion.
'c:\ wait, tab,
Westley Martínez added the comment:
On 3.4.0a1 on Windows it seems to come up automatically with \ or \\. A single
\ will only pop up with the tab key; I think it's good that way. Special
characters (i.e. æ) work normally. All this said, I think this issue is fixed.
--
Francisco Gracia added the comment:
In my machine with Windows XP and Python 3.3.0 both variants work, the only
difference being that
'c:/
brings up the selection box authomatically and
'c:\
requieres that it be summoned with the tab key, as indicated.
2012/10/12 Terry J. Reedy
Terry J. Reedy added the comment:
This patch (I suspect it is this one) disabled the use of '/' in filenames on
windows when using filename completion.
'c:\ wait, tab, ^space bring up box in 3.2.3 and 3.3.0
(If there is no 'r' prefix, it really should require '\\' to be safe.)
c:/ ditto
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 62030ebb2b01 by Martin v. Löwis in branch '3.2':
Issue #14937: Fix typo. Patch by Roger Serwy.
http://hg.python.org/cpython/rev/62030ebb2b01
--
___
Python tracker
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks, fixed
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14937
___
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 41e85ac2ccef by Martin v. Löwis in branch '3.2':
Issue #14937: Perform auto-completion of filenames in strings even for
non-ASCII filenames.
http://hg.python.org/cpython/rev/41e85ac2ccef
New changeset 9aa8af0761ef
Martin v. Löwis mar...@v.loewis.de added the comment:
I have now fixed it by looking for the beginning of the string, and not
checking for file name characters at all. There was a related issue that the
auto-complete window would disappear if you type a non-ascii character; I have
fixed that
Westley Martínez aniko...@gmail.com added the comment:
I think a better technique would be to expand FILENAME_CHARS to include more
characters.
--
nosy: +anikom15
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14937
Westley Martínez aniko...@gmail.com added the comment:
Also, shouldn't the space character ' ' be included?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14937
___
Westley Martínez aniko...@gmail.com added the comment:
Ahh okay, sorry for the triple post, I have an idea. On UNIX, the function
should accept any character except: \0 /, and on Windows should accept any
character except: \0 \ / : * ?| On classic Macintosh, : is invalid.
However, I do
Roger Serwy roger.se...@gmail.com added the comment:
I agree that chr(32) should be included in FILENAME_CHARS.
The algorithm for backward searching checks that each character is contained in
FILENAME_CHARS. I'm concerned about running time, as expanding FILENAME_CHARS
to include all valid
Roger Serwy roger.se...@gmail.com added the comment:
Westley, I was responding to msg162168 and didn't see msg162169 yet.
PEP11 mentions MacOS 9 support was removed in 2.4. Is : still invalid in OSX?
I'll need to think about the approach of using an INVALID_CHARS list. It
looks like it might
Francisco Gracia fgragu...@gmail.com added the comment:
Is there any necessity at all for the IDLE to test the validity of the
filenames?
I mean: the file specification is provided by the underlying operating system,
so by definition it has to be taken as valid. Testing for its validity is
Westley Martínez aniko...@gmail.com added the comment:
You're right. The code shouldn't *have* to check if the name is valid. It
should just accept that the name is already valid. This would simplify things.
Here's the problem: the code needs to find the index of where the string with
the
New submission from Francisco Gracia fgragu...@gmail.com:
I find specially nice the completion feature for filenames of IDLE when they
include long paths, something that is more mand more frequent with big disks
and infinite amounts of files.
But there is a small problem with it. If the name
Martin v. Löwis mar...@v.loewis.de added the comment:
Would you like to contribute a patch?
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14937
___
Francisco Gracia fgragu...@gmail.com added the comment:
I would be delighted, but unfortunately I am a very poor programmer and do not
have the slightest idea of how all this works.
--
___
Python tracker rep...@bugs.python.org
Roger Serwy roger.se...@gmail.com added the comment:
The open_completions method in AutoComplete.py is where the bug exists. When
mode == COMPLETE_FILES, the code searches for characters within the ASCII set,
plus a few others contained in FILENAME_CHARS.
Attached is a patch to also include
20 matches
Mail list logo
