* should `minibuffer-complete' use `abbreviate-file-name'? @ 2007-10-02 19:25 Drew Adams 2007-10-03 18:37 ` Richard Stallman 0 siblings, 1 reply; 20+ messages in thread From: Drew Adams @ 2007-10-02 19:25 UTC (permalink / raw) To: Emacs-Devel An Icicles user suggested this, so I added it. I wonder if it wouldn't also make sense for Emacs: For file-name completion, apply `abbreviate-file-name' to the user's input. This would let a user take advantage of a customized `directory-abbrev-alist' during completion. Would there be any downside to that? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-02 19:25 should `minibuffer-complete' use `abbreviate-file-name'? Drew Adams @ 2007-10-03 18:37 ` Richard Stallman 2007-10-12 19:27 ` Drew Adams 0 siblings, 1 reply; 20+ messages in thread From: Richard Stallman @ 2007-10-03 18:37 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel For file-name completion, apply `abbreviate-file-name' to the user's input. This would let a user take advantage of a customized `directory-abbrev-alist' during completion. Would there be any downside to that? I don't think Emacs should alter the names that the user enters. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-03 18:37 ` Richard Stallman @ 2007-10-12 19:27 ` Drew Adams 2007-10-12 19:42 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Drew Adams @ 2007-10-12 19:27 UTC (permalink / raw) To: rms; +Cc: emacs-devel > For file-name completion, apply `abbreviate-file-name' to the > user's input. This would let a user take advantage of a customized > `directory-abbrev-alist' during completion. > > Would there be any downside to that? > > I don't think Emacs should alter the names that the user enters. `directory-abbrev-alist' is nil by default. Users customize it. It lets them sustitute their own abbreviations for directories. Why shouldn't completion respect the user's preference for such abbreviations (e.g. symlinks)? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-12 19:27 ` Drew Adams @ 2007-10-12 19:42 ` Stefan Monnier 2007-10-12 20:34 ` Drew Adams 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2007-10-12 19:42 UTC (permalink / raw) To: Drew Adams; +Cc: rms, emacs-devel >> For file-name completion, apply `abbreviate-file-name' to the >> user's input. This would let a user take advantage of a customized >> `directory-abbrev-alist' during completion. >> >> Would there be any downside to that? >> >> I don't think Emacs should alter the names that the user enters. > `directory-abbrev-alist' is nil by default. Users customize it. It lets them > sustitute their own abbreviations for directories. > Why shouldn't completion respect the user's preference for such > abbreviations (e.g. symlinks)? I must say I do not understand what you're asking for. Can you spell out a concrete example? Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-12 19:42 ` Stefan Monnier @ 2007-10-12 20:34 ` Drew Adams 2007-10-13 3:50 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Drew Adams @ 2007-10-12 20:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: rms, emacs-devel > >> For file-name completion, apply `abbreviate-file-name' to the > >> user's input. This would let a user take advantage of a customized > >> `directory-abbrev-alist' during completion. > >> > >> Would there be any downside to that? > >> > >> I don't think Emacs should alter the names that the user enters. > > > `directory-abbrev-alist' is nil by default. Users customize it. > > It lets them substitute their own abbreviations for directories. > > > Why shouldn't completion respect the user's preference for such > > abbreviations (e.g. symlinks)? > > I must say I do not understand what you're asking for. Can you spell out > a concrete example? `directory-abbrev-alist' substitutes matches of its regexps against directory names with their corresponding directory-name "abbreviations". The doc shows only examples where the resulting directory names are shorter, but the reverse relation can be useful as well: expand instead of contract. The point is to substitute one directory name for another that is more convenient in some way. The symlink case is only one use case, IIUC. Here is the original feature request I received, describing a use case. The user requests that the cars of `directory-abbrev-alist' entries be completed to the cdrs. I've been using Icicles about over 1 year (but still i'm a sort of newbie). recently, i found i can use 'directory-abbrev-alist' not to type very long path that is hard to remember in 'find-file'. But I also found that Icicles' completion mechanism (including default Emacs' one) does not handle this abbrev consistently. for example, when i set my directory-abbrev-alist up like (("^/exe" . "/very-long-path-here/exe")) and, when i enter in minibuffer after 'find-file', "/exe", and TAB no expansion occurred. How can i utilize abbreviation to long path in Icicle ways? IOW, `find-file /exe RET' correctly expands the abbreviation. But the same is not true of `find-file /exe TAB'. The user requests that the latter feature be added. To implement this, i just call `abbreviate-file-name' on the user's current file-name input. Then, in the example above, both `C-x C-f /exe TAB' and `C-x C-f /whatever/you/might/have//exe TAB' complete to `/very-long-path-here/exe'. Seems useful to me. Again, does anyone see a downside to such behavior? The abbreviation list is under user control (customization), so I don't see the point of Richard's complaint that Emacs completion would then be altering what the user entered. That's the whole point of completion, no? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-12 20:34 ` Drew Adams @ 2007-10-13 3:50 ` Stefan Monnier 2007-10-13 6:03 ` Drew Adams 2007-10-13 9:50 ` Juanma Barranquero 0 siblings, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2007-10-13 3:50 UTC (permalink / raw) To: Drew Adams; +Cc: rms, emacs-devel > i set my directory-abbrev-alist up like > (("^/exe" . "/very-long-path-here/exe")) This is definitely not the way directory-abbrev-alist was intended to be used. `directory-abbrev-alist' should turn a valid filename into another valid filename, the difference between the two being mostly cosmetic. E.g. It should be (("^/very-long-path-here/exe" . "/exe") instead, or something like that. For shorthands, she can use any number of other things like environment variables (which *are* expanded by TAB) or bookmarks. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-13 3:50 ` Stefan Monnier @ 2007-10-13 6:03 ` Drew Adams 2007-10-13 14:14 ` Richard Stallman 2007-10-14 1:41 ` Stefan Monnier 2007-10-13 9:50 ` Juanma Barranquero 1 sibling, 2 replies; 20+ messages in thread From: Drew Adams @ 2007-10-13 6:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: rms, emacs-devel > > set my directory-abbrev-alist up like > > (("^/exe" . "/very-long-path-here/exe")) > > This is definitely not the way directory-abbrev-alist > was intended to be used. So what? Regardless of the original intention, what's important is how it actually behaves. Unless there is some reason to think that the behavior is bugged and needs to be changed to conform rigidly to the intention you assume, the assumption should be dropped in favor of reality. Anyway, who's to say that that was the only intention, back in the dawn of history when this was introduced? Are you basing that assumption only on the doc or on the actual effect? The current doc speaks of symlinks as an useful example, but the actual behavior is not limited to symlinks. The effect doesn't exclude the user's interpretation and use case at all, AFAICT. The abbreviation mechanism in fact takes no account of whether there are any symlinks - they are certainly not a requirement. > `directory-abbrev-alist' should turn a valid filename into > another valid filename, the difference between the two being > mostly cosmetic. What's a valid filename in this context? Presumably, it's a valid directory name, but what's that? Syntactic validity only, or must it also correspond to an existing directory? This is a rewrite mechanism for directory names; that's all. The effect is just to match the regexp in the car against (part of) a directory name and to replace the matched part by the cdr, another directory name. Directory name does not imply existing directory. Why impose an interpretation that the directory name matched by the car must correspond to an existing directory? It is enough, for the actual effect, that it have directory-name syntax. If a user types a directory name that is matched by the regexp in the car, then that satisfies the requirement, even if the name s?he typed does not correspond to an existing directory. Beyond the rewriting, no use is ever made of the car - it's irrelevant whether it matches the name of an existing directory. That's the whole point of the rewrite: to get beyond the car and its matched name and use the cdr instead. The same is even true for the cdr: The abbreviation mechanism itself is agnostic on whether it names an existing directory. It is the use context, not the rewrite mechanism, that determines whether the name in the cdr is OK. That context might expect the name of an existing directory or it might expect only valid directory-name syntax (e.g. to create a new directory). And even if there were a requirement that the cdr always name an existing directory, that requirement would anyway be satisfied by the user's use case: /very-long-path-here/exe names an existing directory. It is the car, ^/exe, that matches a directory name, but one that does not name an existing directory. That's fine - the name matched by the car is never used as a directory; it is used only to come up with the cdr. > E.g. It should be (("^/very-long-path-here/exe" . "/exe") C'est toi qui le dit. The abbreviation mechanism doesn't impose that. > instead, or something like that. For shorthands, she can use > any number of other things like environment variables (which > *are* expanded by TAB) or bookmarks. The fact that there exist other shorthand means is not an argument that one should not also use this directory shorthand to go from short name to long (as well as from long to short). You wouldn't argue that because we have environment variables we should forego bookmarks, would you? BTW, the user mentioned that he also uses env variables with completion. Perhaps that's in fact what gave him the idea that it would be good for completion to also support dir abbreviations. The directory abbreviation mechanism substitutes the dir name in the cdr for whatever dir name the regexp in the car matches. If that is its only effect, as it seems to be, then there is nothing wrong with putting that effect to good uses that might not have been foreseen originally. Perhaps the user misread the doc, or perhaps he read it in a new and more general way. In any case, he discovered something new for himself that works and is useful. It would be even more useful to extend its use to completion, as he requested. My question was, and is, would there be any downside to letting completion take advantage of this shorthand? If it completes env vars, why not let it also complete dir abbrevs? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-13 6:03 ` Drew Adams @ 2007-10-13 14:14 ` Richard Stallman 2007-10-13 15:06 ` Drew Adams 2007-10-14 1:41 ` Stefan Monnier 1 sibling, 1 reply; 20+ messages in thread From: Richard Stallman @ 2007-10-13 14:14 UTC (permalink / raw) To: Drew Adams; +Cc: monnier, emacs-devel > This is definitely not the way directory-abbrev-alist > was intended to be used. So what? Regardless of the original intention, what's important is how it actually behaves. If you want to know what it will do if you set variables to values that are not intended to be used, you can read the code. I made it clearer in the doc string what cases are supposed to be used. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-13 14:14 ` Richard Stallman @ 2007-10-13 15:06 ` Drew Adams 2007-10-14 16:28 ` Richard Stallman 0 siblings, 1 reply; 20+ messages in thread From: Drew Adams @ 2007-10-13 15:06 UTC (permalink / raw) To: rms; +Cc: monnier, emacs-devel > > This is definitely not the way directory-abbrev-alist > > was intended to be used. > > So what? Regardless of the original intention, what's > important is how it actually behaves. > > If you want to know what it will do if you set variables to values > that are not intended to be used, you can read the code. I did, including all of the distribution Lisp code that uses it. I see nothing in the code that contradicts what I said. There is nothing that prevents FROM from matching a valid directory name that might not in fact directly name an existing directory. The code still works fine in that case. And at least some users have been putting that behavior to good use. > I made it clearer in the doc string what cases are > supposed to be used. The only change you made, that I can see, was adding this phrase: "FROM and TO should be equivalent names, which refer to the same directory." I don't see how that contradicts what I said either. In the user's use case that I cited, FROM is ^/exe and TO is /very-long-path-here/exe. Both FROM and TO are equivalent names in terms of their effect, and both effectively refer to the same directory, /very-long-path-here/exe. Even if FROM had been ^/foo, they would be equivalent names and refer to the same directory, if what ^/foo matches is a directory name. 1. FROM: ^/foo 2. what FROM matches (e.g. typed by user): /foobar 3. replacement for the match: /very-long-path-here/exe 4. TO: /very-long-path-here/exe #3 and #4 are identical names for the same directory. #1 is an equivalent name, by the behavior of `directory-abbrev-alist', to #4. I believe that what I've described is what the code actually does. Don't you think so? That behavior might not be as limited as what you intended, but that is the current behavior AFAICT. And I don't see why the behavior should be changed to fit the more limited scenario you apparently have in mind. This is a useful mechanism. We've already had two users (not counting me) who reported using it this way: (1) the user I mentioned and (2) Juanma. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-13 15:06 ` Drew Adams @ 2007-10-14 16:28 ` Richard Stallman 2007-10-14 16:56 ` Drew Adams 0 siblings, 1 reply; 20+ messages in thread From: Richard Stallman @ 2007-10-14 16:28 UTC (permalink / raw) To: Drew Adams; +Cc: monnier, emacs-devel I don't see how that contradicts what I said either. In the user's use case that I cited, FROM is ^/exe and TO is /very-long-path-here/exe. Both FROM and TO are equivalent names in terms of their effect, and both effectively refer to the same directory, /very-long-path-here/exe. I guess I do not understand your proposed usage. I thought I did, but I can't follow this. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-14 16:28 ` Richard Stallman @ 2007-10-14 16:56 ` Drew Adams 2007-10-14 19:10 ` Stefan Monnier 2007-10-15 16:04 ` Richard Stallman 0 siblings, 2 replies; 20+ messages in thread From: Drew Adams @ 2007-10-14 16:56 UTC (permalink / raw) To: rms; +Cc: monnier, emacs-devel > I don't see how that contradicts what I said either. In the > user's use case that I cited, FROM is ^/exe and TO is > /very-long-path-here/exe. Both FROM > and TO are equivalent names in terms of their effect, and > both effectively > refer to the same directory, /very-long-path-here/exe. > > I guess I do not understand your proposed usage. > I thought I did, but I can't follow this. I didn't propose any particular usage. I described one user's use of this as an abbreviation mechanism for directory names, but unrelated to symlinks. His usage: FROM: Any easy-to-type and mnemonic regexp that matches a syntactically valid directory name, whether or not such a directory exists. Example: "^/proj1". TO: An (absolute) name of an existing directory. Example: "/a/very/long/dir/name/to/my/project". FROM and TO are equivalent, in that they have the same effect. TO is a valid directory name and FROM matches a syntactically valid directory name, even if no such directory exists. In the user's case, TO names an existing directory. So far, I've described no proposal wrt this. This already works, without problem. He uses this with `find-file': C-x C-f /proj1 RET visits the (real) directory /my/very/long/dir/name/to/a/project. This saves him time. Yes, there are other possible abbreviation mechanisms, but this one is also useful in this way. His proposal, which I relayed to the list, is this: Let completion do the same thing, so that C-x C-f /proj1 TAB completes to /my/very/long/dir/name/to/a/project. The only change needed is for TAB (`minibuffer-complete') to call `abbreviate-file-name' (for file-name completion only, of course). I don't want to belabor this. I think his idea is a good one. My question to the list was whether there would be any important downsides to such a feature. FWIW, I added this feature to Icicles, and I haven't had any complaints. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-14 16:56 ` Drew Adams @ 2007-10-14 19:10 ` Stefan Monnier 2007-10-15 16:04 ` Richard Stallman 1 sibling, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2007-10-14 19:10 UTC (permalink / raw) To: Drew Adams; +Cc: rms, emacs-devel > FROM and TO are equivalent, in that they have the same effect. TO is a valid > directory name and FROM matches a syntactically valid directory name, even > if no such directory exists. In the user's case, TO names an existing > directory. Just for the record: the directory-abbrev-alist is AFAIK only used by abbreviate-file-name which is only called occasionally rather than systematically (because its intention is to only make cosmetic changes). So using it to map non-existent filenames to real filenames is likely to lead to occasional surprises. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-14 16:56 ` Drew Adams 2007-10-14 19:10 ` Stefan Monnier @ 2007-10-15 16:04 ` Richard Stallman 2007-10-15 16:25 ` Drew Adams 1 sibling, 1 reply; 20+ messages in thread From: Richard Stallman @ 2007-10-15 16:04 UTC (permalink / raw) To: Drew Adams; +Cc: monnier, emacs-devel His usage: FROM: Any easy-to-type and mnemonic regexp that matches a syntactically valid directory name, whether or not such a directory exists. Example: "^/proj1". TO: An (absolute) name of an existing directory. Example: "/a/very/long/dir/name/to/my/project". That is definitely not what this feature is meant for. It isn't meant for expanding abbreviations. It is meant for replacing long names with equivalent short ones. If he wants a short way to enter /a/very/long/dir/name/to/my/project, he should make ~/proj1 a symlink to it. Then he can use the abbreviation ~/proj1 in EVERY program. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-15 16:04 ` Richard Stallman @ 2007-10-15 16:25 ` Drew Adams 2007-10-15 18:04 ` Stefan Monnier 2007-10-16 4:10 ` Richard Stallman 0 siblings, 2 replies; 20+ messages in thread From: Drew Adams @ 2007-10-15 16:25 UTC (permalink / raw) To: rms; +Cc: monnier, emacs-devel > His usage: > > FROM: Any easy-to-type and mnemonic regexp that matches > a syntactically valid directory name, whether or not > such a directory exists. Example: "^/proj1". > > TO: An (absolute) name of an existing directory. > Example: "/a/very/long/dir/name/to/my/project". > > That is definitely not what this feature is meant for. > It isn't meant for expanding abbreviations. > It is meant for replacing long names with equivalent short ones. It is nevertheless what this feature *does*. It is agnostic wrt name length. > If he wants a short way to enter /a/very/long/dir/name/to/my/project, > he should make ~/proj1 a symlink to it. Then he can use the > abbreviation ~/proj1 in EVERY program. For various reasons, he might not WANT such symlinks. He can also create environment variables, as Stefan suggested, but he might not WANT such env vars. He might not WANT such abbreviation/substitution/rewriting (call it what you like) in EVERY program. Anyway, I understand that you are not in favor of either (1) letting TAB completion respect `directory-abbrev-alist' or (2) documenting the existing behavior of `directory-abbrev-alist' (beyond what is the originally intended symlink use). ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-15 16:25 ` Drew Adams @ 2007-10-15 18:04 ` Stefan Monnier 2007-10-15 18:19 ` Drew Adams 2007-10-16 4:10 ` Richard Stallman 1 sibling, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2007-10-15 18:04 UTC (permalink / raw) To: Drew Adams; +Cc: rms, emacs-devel > For various reasons, he might not WANT such symlinks. He can also create > environment variables, as Stefan suggested, but he might not WANT such env > vars. He might not WANT such abbreviation/substitution/rewriting (call it > what you like) in EVERY program. Then he can do it via file-name-handler-alist ;-) Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-15 18:04 ` Stefan Monnier @ 2007-10-15 18:19 ` Drew Adams 0 siblings, 0 replies; 20+ messages in thread From: Drew Adams @ 2007-10-15 18:19 UTC (permalink / raw) To: Stefan Monnier; +Cc: rms, emacs-devel > > For various reasons, he might not WANT such symlinks. He can also create > > environment variables, as Stefan suggested, but he might not > > WANT such env vars. He might not WANT such > > abbreviation/substitution/rewriting (call it > > what you like) in EVERY program. > > Then he can do it via file-name-handler-alist ;-) ;-) indeed. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-15 16:25 ` Drew Adams 2007-10-15 18:04 ` Stefan Monnier @ 2007-10-16 4:10 ` Richard Stallman 1 sibling, 0 replies; 20+ messages in thread From: Richard Stallman @ 2007-10-16 4:10 UTC (permalink / raw) To: Drew Adams; +Cc: monnier, emacs-devel > That is definitely not what this feature is meant for. > It isn't meant for expanding abbreviations. > It is meant for replacing long names with equivalent short ones. It is nevertheless what this feature *does*. It is agnostic wrt name length. You are welcome to use the feature for something other than its intended purpose, if you like the result. However, we don't have to maintain Emacs or its manuals for the sake of such usage. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-13 6:03 ` Drew Adams 2007-10-13 14:14 ` Richard Stallman @ 2007-10-14 1:41 ` Stefan Monnier 2007-10-15 1:36 ` Richard Stallman 1 sibling, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2007-10-14 1:41 UTC (permalink / raw) To: Drew Adams; +Cc: rms, emacs-devel > So what? Regardless of the original intention, what's important is how it > actually behaves. But if you use it to a different end, you shouldn't be surprised if the behavior isn't always ideal (e.g. if TAB doesn't apply directory-abbrev-alist). This said, I have nothing against TAB calling abbreviate-file-name. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-14 1:41 ` Stefan Monnier @ 2007-10-15 1:36 ` Richard Stallman 0 siblings, 0 replies; 20+ messages in thread From: Richard Stallman @ 2007-10-15 1:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: drew.adams, emacs-devel But if you use it to a different end, you shouldn't be surprised if the behavior isn't always ideal (e.g. if TAB doesn't apply directory-abbrev-alist). This said, I have nothing against TAB calling abbreviate-file-name. I do not like the idea of making TAB perform additional alterations on the minibuffer text. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: should `minibuffer-complete' use `abbreviate-file-name'? 2007-10-13 3:50 ` Stefan Monnier 2007-10-13 6:03 ` Drew Adams @ 2007-10-13 9:50 ` Juanma Barranquero 1 sibling, 0 replies; 20+ messages in thread From: Juanma Barranquero @ 2007-10-13 9:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: rms, Drew Adams, emacs-devel On 10/13/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > This is definitely not the way directory-abbrev-alist was intended to be > used. `directory-abbrev-alist' should turn a valid filename into another > valid filename, the difference between the two being mostly cosmetic. FWIW, I use directory-abbrev-alist in my .emacs to show in the modeline aliases (which are not directories, but shorter arbitrary names) of the directory of the visited files. Juanma ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2007-10-16 4:10 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-10-02 19:25 should `minibuffer-complete' use `abbreviate-file-name'? Drew Adams 2007-10-03 18:37 ` Richard Stallman 2007-10-12 19:27 ` Drew Adams 2007-10-12 19:42 ` Stefan Monnier 2007-10-12 20:34 ` Drew Adams 2007-10-13 3:50 ` Stefan Monnier 2007-10-13 6:03 ` Drew Adams 2007-10-13 14:14 ` Richard Stallman 2007-10-13 15:06 ` Drew Adams 2007-10-14 16:28 ` Richard Stallman 2007-10-14 16:56 ` Drew Adams 2007-10-14 19:10 ` Stefan Monnier 2007-10-15 16:04 ` Richard Stallman 2007-10-15 16:25 ` Drew Adams 2007-10-15 18:04 ` Stefan Monnier 2007-10-15 18:19 ` Drew Adams 2007-10-16 4:10 ` Richard Stallman 2007-10-14 1:41 ` Stefan Monnier 2007-10-15 1:36 ` Richard Stallman 2007-10-13 9:50 ` Juanma Barranquero
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.