* 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 public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).