* reenabling icomplete operation during read-buffer @ 2009-02-09 23:27 ken manheimer 2009-02-10 1:01 ` Drew Adams 2009-02-10 2:11 ` Stefan Monnier 0 siblings, 2 replies; 7+ messages in thread From: ken manheimer @ 2009-02-09 23:27 UTC (permalink / raw) To: emacs-devel i noticed that icomplete stopped operating during, eg, switch-to-buffer, in my CVS checkouts a good while back. i'm finally getting around to investigating, and see that read-buffer &c fail this condition in icomplete-simple-completing-p: (or t (not (functionp minibuffer-completion-table)) (eq icomplete-with-completion-tables t) (member minibuffer-completion-table icomplete-with-completion-tables)))) i believe i (or someone) put that in to weed out complicated situations where casual use of completion may be prohibitive, for instance, during file-name read operations where the filesystem could be remote or otherwise mediated. the thing is, this inhibition is not necessary for buffer-name-reading situations, but i haven't figured out a good way to recognize that situation, in order to reframe the above condition to allow for it. can anyone suggest a good way to do so? or am i heading in the wrong direction? thanks! -- ken http://myriadicity.net ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: reenabling icomplete operation during read-buffer 2009-02-09 23:27 reenabling icomplete operation during read-buffer ken manheimer @ 2009-02-10 1:01 ` Drew Adams 2009-02-10 2:11 ` Stefan Monnier 1 sibling, 0 replies; 7+ messages in thread From: Drew Adams @ 2009-02-10 1:01 UTC (permalink / raw) To: 'ken manheimer', 'emacs-devel' > i noticed that icomplete stopped operating during, eg, > switch-to-buffer, in my CVS checkouts a good while back. i'm finally > getting around to investigating, and see that read-buffer &c fail this > condition in icomplete-simple-completing-p: > > (or t (not (functionp minibuffer-completion-table)) Typo - (or (not (functionp minibuffer-completion-table)). > (eq icomplete-with-completion-tables t) > (member minibuffer-completion-table > icomplete-with-completion-tables)))) > > i believe i (or someone) put that in to weed out complicated > situations where casual use of completion may be prohibitive, for > instance, during file-name read operations where the filesystem could > be remote or otherwise mediated. the thing is, this inhibition is not > necessary for buffer-name-reading situations, but i haven't figured > out a good way to recognize that situation, in order to reframe the > above condition to allow for it. can anyone suggest a good way to do > so? or am i heading in the wrong direction? 1. Please consider doing this for `icomplete-with-completion-tables': * Make it a defcustom. * Document `t' as a possible value. The doc of `icomplete-with-completion-tables' does not mention what it means for the value to be `t', and the above code is the only place where the variable is used. I was not aware of this variable, which has apparently existed since Emacs 22. I might even try using `t' as the value - at least for a while. ;-) 2. FWIW, this code seems a bit weird, to me: (defvar icomplete-prospects-length 80) (make-obsolete-variable 'icomplete-prospects-length 'icomplete-prospects-height "23.1") (defcustom icomplete-prospects-height (+ 1 (/ (+ icomplete-prospects-length 20) (window-width))) "Maximum number of lines to use in the minibuffer." :type 'integer :group 'icomplete :version "23.1") The CURRENT-NAME for the OBSOLETE-NAME `icomplete-prospects-length' is said to be `icomplete-prospects-height' (using the terminology of the doc string of `make-obsolete-variable'). I recognize that this really means only that the compiler warning will advise you to use the latter instead of the former, but at least some users might (mis)understand this as saying that they are just different names that represent the same thing (have the same value). Better to have an explicit message that describes the relation (see below). The default value of the option seems problematic anyway, since it is based on the width of the window that happens to be current at the time the defcustom is evaluated. Does that make sense? I guess this assumes that that window is the minibuffer window, and it assumes that that particular minibuffer window is representative of other possible minibuffer windows. If something really smart and foolsafe can't be done here, perhaps just (a) have a fixed default value for the option of, say, 1 or 2, and (b) tell users at byte-compile time that `icomplete-prospects-length' can no longer be used. IOW, something like this: (defvar icomplete-prospects-length nil "Obsolete internal variable - do not use this. You can no longer control the icomplete display length directly. You can instead control the height of the displayed prospects, using option `icomplete-prospects-height'.") (make-obsolete-variable 'icomplete-prospects-length "You can no longer control the icomplete display length. You can instead control the height of the displayed prospects, using option `icomplete-prospects-height'." "23.1") (defcustom icomplete-prospects-height 2 "Maximum number of lines for icomplete to use in the minibuffer." :type 'integer :group 'icomplete :version "23.1") Or is it "not done" to just cut off an obsolete variable completely and immediately like that? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: reenabling icomplete operation during read-buffer 2009-02-09 23:27 reenabling icomplete operation during read-buffer ken manheimer 2009-02-10 1:01 ` Drew Adams @ 2009-02-10 2:11 ` Stefan Monnier 2009-02-12 0:08 ` ken manheimer 1 sibling, 1 reply; 7+ messages in thread From: Stefan Monnier @ 2009-02-10 2:11 UTC (permalink / raw) To: ken manheimer; +Cc: emacs-devel > i noticed that icomplete stopped operating during, eg, > switch-to-buffer, in my CVS checkouts a good while back. i'm finally > getting around to investigating, and see that read-buffer &c fail this > condition in icomplete-simple-completing-p: > (or t (not (functionp minibuffer-completion-table)) > (eq icomplete-with-completion-tables t) > (member minibuffer-completion-table > icomplete-with-completion-tables)))) > i believe i (or someone) put that in to weed out complicated > situations where casual use of completion may be prohibitive, for > instance, during file-name read operations where the filesystem could > be remote or otherwise mediated. the thing is, this inhibition is not > necessary for buffer-name-reading situations, but i haven't figured > out a good way to recognize that situation, in order to reframe the > above condition to allow for it. can anyone suggest a good way to do > so? or am i heading in the wrong direction? The best fix AFAIK is to set icomplete-with-completion-tables to t (i.e. to just drop this whole condition). After all, icomplete's code is now run within a while-no-input, so even access to remote filesystems shouldn't be problematic (this was new in Emacs-22, IIRC). Stefan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: reenabling icomplete operation during read-buffer 2009-02-10 2:11 ` Stefan Monnier @ 2009-02-12 0:08 ` ken manheimer 2009-02-12 2:21 ` Stefan Monnier 0 siblings, 1 reply; 7+ messages in thread From: ken manheimer @ 2009-02-12 0:08 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel On Mon, Feb 9, 2009 at 9:11 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > i noticed that icomplete stopped operating during, eg, > > switch-to-buffer, in my CVS checkouts a good while back. i'm finally > > getting around to investigating, and see that read-buffer &c fail this > > condition in icomplete-simple-completing-p: > > > (or t (not (functionp minibuffer-completion-table)) > > (eq icomplete-with-completion-tables t) > > (member minibuffer-completion-table > > icomplete-with-completion-tables)))) > > > i believe i (or someone) put that in to weed out complicated > > situations where casual use of completion may be prohibitive, for > > instance, during file-name read operations where the filesystem could > > be remote or otherwise mediated. the thing is, this inhibition is not > > necessary for buffer-name-reading situations, but i haven't figured > > out a good way to recognize that situation, in order to reframe the > > above condition to allow for it. can anyone suggest a good way to do > > so? or am i heading in the wrong direction? > > The best fix AFAIK is to set icomplete-with-completion-tables to > t (i.e. to just drop this whole condition). After all, icomplete's code > is now run within a while-no-input, so even access to remote filesystems > shouldn't be problematic (this was new in Emacs-22, IIRC). i'd love to simplify that to default icomplete-with-completion-tables to t, but it misbehaves dramatically for special tramp file visits, like /sudo:root@localhost:/etc/hosts or /ftp:... unfortunately, it looks like read-buffer-to-switch (files.el) was changed to use a manufactured lambda as the completion table, which means that icomplete can't statically match it to recognize being within that completion context. i can add a condition like: (and (boundp 'rbts-completion-table) (equal minibuffer-completion-table rbts-completion-table)) to get the behavior i want, but that is much too brittle - it depends on an internal detail of read-buffer-to-switch. offhand, i would like to have a reliable and simple way to detect that buffer name reading is happening, so icomplete can be safely enabled in that situation. i'm not sure about the more general question, which is classifying minibuffer reads as candidates for incremental completion or not.. (in the remote-file reads, there are intermediate strings which are invalid, and even many valid intermediate strings would be expensive to complete.) -- ken http://myriadicity.net ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: reenabling icomplete operation during read-buffer 2009-02-12 0:08 ` ken manheimer @ 2009-02-12 2:21 ` Stefan Monnier 2009-02-12 23:28 ` ken manheimer 0 siblings, 1 reply; 7+ messages in thread From: Stefan Monnier @ 2009-02-12 2:21 UTC (permalink / raw) To: ken manheimer; +Cc: emacs-devel > i'd love to simplify that to default icomplete-with-completion-tables > to t, but it misbehaves dramatically for special tramp file visits, > like /sudo:root@localhost:/etc/hosts or /ftp:... These need to be fixed. At some point, they worked OK. > unfortunately, it looks like read-buffer-to-switch (files.el) was > changed to use a manufactured lambda as the completion table, which > means that icomplete can't statically match it to recognize being > within that completion context. i can add a condition like: > (and (boundp 'rbts-completion-table) > (equal minibuffer-completion-table rbts-completion-table)) > to get the behavior i want, but that is much too brittle - it depends > on an internal detail of read-buffer-to-switch. I've installed a different fix. Stefan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: reenabling icomplete operation during read-buffer 2009-02-12 2:21 ` Stefan Monnier @ 2009-02-12 23:28 ` ken manheimer 2009-02-13 0:00 ` Drew Adams 0 siblings, 1 reply; 7+ messages in thread From: ken manheimer @ 2009-02-12 23:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel On Wed, Feb 11, 2009 at 9:21 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > i'd love to simplify that to default icomplete-with-completion-tables > > to t, but it misbehaves dramatically for special tramp file visits, > > like /sudo:root@localhost:/etc/hosts or /ftp:... > > These need to be fixed. At some point, they worked OK. > > > unfortunately, it looks like read-buffer-to-switch (files.el) was > > changed to use a manufactured lambda as the completion table, which > > means that icomplete can't statically match it to recognize being > > within that completion context. i can add a condition like: > > > (and (boundp 'rbts-completion-table) > > (equal minibuffer-completion-table rbts-completion-table)) > > > to get the behavior i want, but that is much too brittle - it depends > > on an internal detail of read-buffer-to-switch. > > I've installed a different fix. thanks! people wanting to use icomplete but turn it off for buffer name reading (so they can use something like iswitchb or icycles) won't be able to do so, but providing for that seems beyond the point of diminishing returns, to me. > Stefan -- ken http://myriadicity.net ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: reenabling icomplete operation during read-buffer 2009-02-12 23:28 ` ken manheimer @ 2009-02-13 0:00 ` Drew Adams 0 siblings, 0 replies; 7+ messages in thread From: Drew Adams @ 2009-02-13 0:00 UTC (permalink / raw) To: 'ken manheimer', 'Stefan Monnier'; +Cc: 'emacs-devel' > people wanting to use icomplete but turn it off for buffer name > reading (so they can use something like iswitchb or icycles) won't be > able to do so, but providing for that seems beyond the point of > diminishing returns, to me. FWIW, there is no problem using Icomplete with Icicles (for buffer names, file names or whatever). ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-02-13 0:00 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-02-09 23:27 reenabling icomplete operation during read-buffer ken manheimer 2009-02-10 1:01 ` Drew Adams 2009-02-10 2:11 ` Stefan Monnier 2009-02-12 0:08 ` ken manheimer 2009-02-12 2:21 ` Stefan Monnier 2009-02-12 23:28 ` ken manheimer 2009-02-13 0:00 ` Drew Adams
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.