* Re: [Emacs-diffs] Changes to emacs/lisp/ChangeLog
[not found] <E1FiEqb-0007QY-IW@savannah.gnu.org>
@ 2006-05-23 12:07 ` Michaël Cadilhac
2006-05-23 14:39 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Michaël Cadilhac @ 2006-05-23 12:07 UTC (permalink / raw)
Cc: emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 1487 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Index: emacs/lisp/ChangeLog
> diff -u emacs/lisp/ChangeLog:1.9582 emacs/lisp/ChangeLog:1.9583
> --- emacs/lisp/ChangeLog:1.9582 Mon May 22 13:19:02 2006
> +++ emacs/lisp/ChangeLog Mon May 22 18:09:40 2006
> @@ -1,7 +1,14 @@
> +2006-05-22 Stefan Monnier <monnier@iro.umontreal.ca>
> +
> + * complete.el (PC-do-completion): Undo the addition of implicit
> + wildcards if they did not lead to finding any match.
> + (read-file-name-internal): Don't add the final > if the completion is
> + not finished.
> +
When I do C-x C-f /a/b/c, with shell being /bin/sh (zsh emuled),
I still have a weird behavior:
<TAB>
read-file-name-internal: Opening directory: no such file or directory, /a*/b*/
<TAB>
read-file-name-internal: Opening directory: no such file or directory, /a**/b**/
<TAB>
read-file-name-internal: Opening directory: no such file or directory, /a***/b***/
<TAB>
read-file-name-internal: Opening directory: no such file or directory, /a****/b****/
AFAIU, this patch fixes the /c* bug (i.e. the last part of the filename
being completed) but not the whole problem.
--
| Michaël `Micha' Cadilhac | La culture c'est comme la confiture |
| Epita/LRDE Promo 2007 | c'est meilleur avec du pain. |
| http://www.lrde.org/~cadilh_m | -- MOI59 |
`-- - JID: micha@amessage.be --' - --'
[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Emacs-diffs] Changes to emacs/lisp/ChangeLog
2006-05-23 12:07 ` [Emacs-diffs] Changes to emacs/lisp/ChangeLog Michaël Cadilhac
@ 2006-05-23 14:39 ` Stefan Monnier
2006-05-23 17:14 ` Michaël Cadilhac
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2006-05-23 14:39 UTC (permalink / raw)
Cc: emacs-devel
> When I do C-x C-f /a/b/c, with shell being /bin/sh (zsh emuled),
> I still have a weird behavior:
> <TAB>
> read-file-name-internal: Opening directory: no such file or directory, /a*/b*/
> <TAB>
> read-file-name-internal: Opening directory: no such file or directory, /a**/b**/
> <TAB>
> read-file-name-internal: Opening directory: no such file or directory, /a***/b***/
> <TAB>
> read-file-name-internal: Opening directory: no such file or directory, /a****/b****/
> AFAIU, this patch fixes the /c* bug (i.e. the last part of the filename
> being completed) but not the whole problem.
Hmm... I remember working on such a bug report a few months ago.
Can't remember whether I had fixed it at the time and if so how. But in any
case, I can't reproduce the problem right now.
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Emacs-diffs] Changes to emacs/lisp/ChangeLog
2006-05-23 14:39 ` Stefan Monnier
@ 2006-05-23 17:14 ` Michaël Cadilhac
2006-05-23 20:51 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Michaël Cadilhac @ 2006-05-23 17:14 UTC (permalink / raw)
Cc: emacs-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 1142 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> When I do C-x C-f /a/b/c, with shell being /bin/sh (zsh emuled),
>> I still have a weird behavior:
>
>> <TAB>
>> read-file-name-internal: Opening directory: no such file or directory, /a*/b*/
>> <TAB>
>> read-file-name-internal: Opening directory: no such file or directory, /a**/b**/
>> <TAB>
>> read-file-name-internal: Opening directory: no such file or directory, /a***/b***/
>> <TAB>
>> read-file-name-internal: Opening directory: no such file or directory, /a****/b****/
>
>> AFAIU, this patch fixes the /c* bug (i.e. the last part of the filename
>> being completed) but not the whole problem.
>
> Hmm... I remember working on such a bug report a few months ago.
> Can't remember whether I had fixed it at the time and if so how. But in any
> case, I can't reproduce the problem right now.
My bad, I recompiled a freshly checkouted Emacs and it works almost
right.
When I do C-x C-f /a/b/c TAB, no star are added, but an _error_ is
triggered instead of a [no match].
IMHO, it's due to file_name_completion, and I'd be very tempted to
make the following:
[-- Attachment #1.1.2: direr.patch --]
[-- Type: text/x-patch, Size: 1486 bytes --]
Index: src/ChangeLog
===================================================================
RCS file: /sources/emacs/emacs/src/ChangeLog,v
retrieving revision 1.5083
diff -c -r1.5083 ChangeLog
*** src/ChangeLog 23 May 2006 08:12:13 -0000 1.5083
--- src/ChangeLog 23 May 2006 17:13:37 -0000
***************
*** 1,3 ****
--- 1,8 ----
+ 2006-05-23 Michaël Cadilhac <michael.cadilhac@lrde.org>
+
+ * dired.c (file_name_completion): Don't barf if the base directory
+ can't be opened.
+
2006-05-23 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
* macterm.c (fn_keycode_to_xkeysym_table, convert_fn_keycode): Remove.
Index: src/dired.c
===================================================================
RCS file: /sources/emacs/emacs/src/dired.c,v
retrieving revision 1.122
diff -c -r1.122 dired.c
*** src/dired.c 6 Feb 2006 15:23:20 -0000 1.122
--- src/dired.c 23 May 2006 17:13:37 -0000
***************
*** 503,509 ****
d = opendir (SDATA (Fdirectory_file_name (encoded_dir)));
if (!d)
! report_file_error ("Opening directory", Fcons (dirname, Qnil));
record_unwind_protect (directory_files_internal_unwind,
make_save_value (d, 0));
--- 503,509 ----
d = opendir (SDATA (Fdirectory_file_name (encoded_dir)));
if (!d)
! break;
record_unwind_protect (directory_files_internal_unwind,
make_save_value (d, 0));
[-- Attachment #1.1.3: Type: text/plain, Size: 422 bytes --]
It works if I do so, but I don't know if I'm not breaking another
functionality.
So ?
--
| Michaël `Micha' Cadilhac | Would someone please DTRT with this |
| Epita/LRDE Promo 2007 | then ACK? |
| http://www.lrde.org/~cadilh_m | -- Richard Stallman |
`-- - JID: micha@amessage.be --' - --'
[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Emacs-diffs] Changes to emacs/lisp/ChangeLog
2006-05-23 17:14 ` Michaël Cadilhac
@ 2006-05-23 20:51 ` Stefan Monnier
2006-05-24 8:48 ` Michaël Cadilhac
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2006-05-23 20:51 UTC (permalink / raw)
Cc: emacs-devel
> When I do C-x C-f /a/b/c TAB, no star are added, but an _error_ is
> triggered instead of a [no match].
I'm not sure it's bad, actually.
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Emacs-diffs] Changes to emacs/lisp/ChangeLog
2006-05-23 20:51 ` Stefan Monnier
@ 2006-05-24 8:48 ` Michaël Cadilhac
2006-05-26 19:15 ` PC-do-completion triggers an error (was: [Emacs-diffs] Changes to emacs/lisp/ChangeLog) Michaël Cadilhac
0 siblings, 1 reply; 7+ messages in thread
From: Michaël Cadilhac @ 2006-05-24 8:48 UTC (permalink / raw)
Cc: emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 1042 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> When I do C-x C-f /a/b/c TAB, no star are added, but an _error_ is
>> triggered instead of a [no match].
>
> I'm not sure it's bad, actually.
Well, I think it is. The behavior is not consistent with other
failed completions, and debugger should not be called on it (with
debug-on-error).
If a message such as this one has to be printed, I think it should
be, IMHO, in bracket after the text entered, like [no match]. But
sticking to short messages should be better, and [no match] is
explicit enough.
What makes you think an error is not so bad, although no other
completion system triggers one?
--
| Michaël `Micha' Cadilhac | Pour les 35-40 ans, l'humour |
| Epita/LRDE Promo 2007 | c'est une plus-value. |
| http://www.lrde.org/~cadilh_m | -- Guillaume L. |
`-- - JID: micha@amessage.be --' - --'
[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* PC-do-completion triggers an error (was: [Emacs-diffs] Changes to emacs/lisp/ChangeLog)
2006-05-24 8:48 ` Michaël Cadilhac
@ 2006-05-26 19:15 ` Michaël Cadilhac
2006-06-10 19:00 ` PC-do-completion triggers an error Michaël Cadilhac
0 siblings, 1 reply; 7+ messages in thread
From: Michaël Cadilhac @ 2006-05-26 19:15 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/plain, Size: 1209 bytes --]
michael.cadilhac@lrde.org (Michaël Cadilhac) writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> When I do C-x C-f /a/b/c TAB, no star are added, but an _error_ is
>>> triggered instead of a [no match].
>>
>> I'm not sure it's bad, actually.
>
> Well, I think it is. The behavior is not consistent with other
> failed completions, and debugger should not be called on it (with
> debug-on-error).
>
> If a message such as this one has to be printed, I think it should
> be, IMHO, in bracket after the text entered, like [no match]. But
> sticking to short messages should be better, and [no match] is
> explicit enough.
>
> What makes you think an error is not so bad, although no other
> completion system triggers one?
Anyone finding that an error should not be triggered and can review my
patch ?
--
| Michaël `Micha' Cadilhac | La culture c'est comme la confiture |
| Epita/LRDE Promo 2007 | c'est meilleur avec du pain. |
| http://www.lrde.org/~cadilh_m | -- MOI59 |
`-- - JID: micha@amessage.be --' - --'
[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PC-do-completion triggers an error
2006-05-26 19:15 ` PC-do-completion triggers an error (was: [Emacs-diffs] Changes to emacs/lisp/ChangeLog) Michaël Cadilhac
@ 2006-06-10 19:00 ` Michaël Cadilhac
0 siblings, 0 replies; 7+ messages in thread
From: Michaël Cadilhac @ 2006-06-10 19:00 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/plain, Size: 1310 bytes --]
michael.cadilhac@lrde.org (Michaël Cadilhac) writes:
> michael.cadilhac@lrde.org (Michaël Cadilhac) writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>> When I do C-x C-f /a/b/c TAB, no star are added, but an _error_ is
>>>> triggered instead of a [no match].
>>>
>>> I'm not sure it's bad, actually.
>>
>> Well, I think it is. The behavior is not consistent with other
>> failed completions, and debugger should not be called on it (with
>> debug-on-error).
>>
>> If a message such as this one has to be printed, I think it should
>> be, IMHO, in bracket after the text entered, like [no match]. But
>> sticking to short messages should be better, and [no match] is
>> explicit enough.
>>
>> What makes you think an error is not so bad, although no other
>> completion system triggers one?
>
> Anyone finding that an error should not be triggered and can review my
> patch ?
It's a no? Bah.
--
| Michaël `Micha' Cadilhac | Would someone please DTRT with this, |
| Epita/LRDE Promo 2007 | then ACK? |
| http://www.lrde.org/~cadilh_m | -- Richard Stallman |
`-- - JID: micha@amessage.be --' - --'
[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-06-10 19:00 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1FiEqb-0007QY-IW@savannah.gnu.org>
2006-05-23 12:07 ` [Emacs-diffs] Changes to emacs/lisp/ChangeLog Michaël Cadilhac
2006-05-23 14:39 ` Stefan Monnier
2006-05-23 17:14 ` Michaël Cadilhac
2006-05-23 20:51 ` Stefan Monnier
2006-05-24 8:48 ` Michaël Cadilhac
2006-05-26 19:15 ` PC-do-completion triggers an error (was: [Emacs-diffs] Changes to emacs/lisp/ChangeLog) Michaël Cadilhac
2006-06-10 19:00 ` PC-do-completion triggers an error Michaël Cadilhac
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.