> But /home//:~//info will *not* be treated like /:~//info.
> Whether it's a bug or feature, I don't know, but I find it surprising.
> I agree it would be more natural to change this.
> Just because /: suppresses special treatment of following text
> does not mean previous text must suppre
Richard Stallman <[EMAIL PROTECTED]> writes:
> But actually, I think my proposal about a C level interface into
> substitute-in-file-name would be most efficient, robust and
> unproblematic in the long run, and possibly useful for other
> applications as well.
>
> I don't want to d
But actually, I think my proposal about a C level interface into
substitute-in-file-name would be most efficient, robust and
unproblematic in the long run, and possibly useful for other
applications as well.
I don't want to do this, because it puts too much complexity in a
place wh
not.
>
> At least here with 8K users in our YP database, my code causes
> file-name-shadow-mode to take around 0.5-1s to refresh the screen
> after each key stroke if there's a ~user in the file name I'm
> editing.
You have seen Richard's proposal of going backwards l
e-in-file-name can take a non-negligible amount
of time to execute when there's a "~user" in the file name, because it calls
getpwnam to figure out whether "user" actually exists or not.
At least here with 8K users in our YP database, my code causes
file-name-shadow-mo
But /home//:~//info will *not* be treated like /:~//info.
Whether it's a bug or feature, I don't know, but I find it surprising.
I agree it would be more natural to change this.
Just because /: suppresses special treatment of following text
does not mean previous text must suppress special
Cute. It makes the assumption, however, that there is a unique point
where that equivalence occurs. I don't think that this is correct:
whenever you split in the middle of an environment variable name,
you'll get a nonmatch that can turn into a match if you happen to look
furt
The use of fset makes this rather ugly.
If the idea is to put a function onto minibuffer-setup-hook just to
execute once, I see no reason to bind anything. Just add the function
and design it to remove itself when run. For safety's sake,
use an unwind-protect to remove the function from the list
Stefan Monnier wrote:
> I think there is nothing to be done about this. It would be hard to
> fix and it probably isn't worth the trouble.
How 'bout the untested patch below?
Seems to work.
Sincerely,
Luc.
___
Emacs-devel mailing list
Ema
Stefan Monnier wrote:
How 'bout the patch below which makes no assumption (that I know of) about
substitute-in-file-name, and will thus correctly even with weird
magic file name handlers.
Seems to work very well.
But given the fact that icomplete.el has been usable for a long time
>BTW, while testing my code, I was actually surprised (although it makes
>perfect sense) by the fact that "C-x C-f /:~//info" doesn't behave as
>explained above. You need to do "C-x C-f C-a C-k /:~//info".
> The "/:" needs to be at the very beginning of the minibuffer contents
> to wo
Stefan Monnier wrote:
BTW, while testing my code, I was actually surprised (although it makes
perfect sense) by the fact that "C-x C-f /:~//info" doesn't behave as
explained above. You need to do "C-x C-f C-a C-k /:~//info".
The "/:" needs to be at the very beginning of the minibuffer c
> Cute. It makes the assumption, however, that there is a unique point
> where that equivalence occurs.
Not quite, it makes the assumption that if
(substitute-in-file-name (buffer-substring N END))
== (substitute-in-file-name (buffer-substring START END))
and (< START N) then
(substit
>> How 'bout the patch below which makes no assumption (that I know of) about
>> substitute-in-file-name, and will thus correctly even with weird
>> magic file name handlers.
> Um, I should note that the original code was designed to be fast and
> not cons unnecessarily, because it runs on every k
> Do C-g to quit the current minibuffer. Then do C-x C-f.
> One now has ~/ in the minibuffer. If you type an extra "/", the "~/"
> preceding it does not get any special highlighting, as it should if
> file-name-shadow-mode is t.
> The cause o
David Kastrup <[EMAIL PROTECTED]> writes:
> Miles Bader <[EMAIL PROTECTED]> writes:
>
>> On Mon, 21 Mar 2005 08:24:38 -0500, Stefan Monnier
>> <[EMAIL PROTECTED]> wrote:
>>> How 'bout the patch below which makes no assumption (that I know of) about
>>> substitute-in-file-name, and will thus correc
Miles Bader <[EMAIL PROTECTED]> writes:
> On Mon, 21 Mar 2005 08:24:38 -0500, Stefan Monnier
> <[EMAIL PROTECTED]> wrote:
>> How 'bout the patch below which makes no assumption (that I know of) about
>> substitute-in-file-name, and will thus correctly even with weird
>> magic file name handlers.
>
On Mon, 21 Mar 2005 08:24:38 -0500, Stefan Monnier
<[EMAIL PROTECTED]> wrote:
> How 'bout the patch below which makes no assumption (that I know of) about
> substitute-in-file-name, and will thus correctly even with weird
> magic file name handlers.
Um, I should note that the original code was des
Stefan Monnier <[EMAIL PROTECTED]> writes:
> How 'bout the patch below which makes no assumption (that I know of)
> about substitute-in-file-name, and will thus correctly even with
> weird magic file name handlers.
> + (condition-case nil
> + (let ((goal (substitute-in-file-name (minibuffer
> As well as after things like /:~//info. After /:, Emacs replaces
BTW, while testing my code, I was actually surprised (although it makes
perfect sense) by the fact that "C-x C-f /:~//info" doesn't behave as
explained above. You need to do "C-x C-f C-a C-k /:~//info".
Stefan
___
, 2001, 2002 Free Software Foundation, Inc.
+;; Copyright (C) 2000, 2001, 2002, 2005 Free Software Foundation, Inc.
;;
;; Author: Miles Bader <[EMAIL PROTECTED]>
;; Keywords: convenience minibuffer
@@ -176,25 +176,25 @@
This is intended to be used as a minibuffer post-command-hook f
A flaw that might give people the false impression that `$' after /
has the same effect as / or ~ after /.
That's a problem, but not a very big one. This misunderstanding would
be minro, not fatal, and it would happen rarely. And people can still
read the manual and find out the full fac
Do C-g to quit the current minibuffer. Then do C-x C-f.
One now has ~/ in the minibuffer. If you type an extra "/", the "~/"
preceding it does not get any special highlighting, as it should if
file-name-shadow-mode is t.
The cause of this is that the minibuf
>From my previous message:
file-name-shadow-mode should also look for /: at the beginning of a
file name and leave the file name completely alone if it starts with /:
Currently, erroneous highlighting occurs after things like /:/~ and /:/$
As well as after things like /:~//info. Af
file-name-shadow-mode should also look for /: at the beginning of a
file name and leave the file name completely alone if it starts with /:
Currently, erroneous highlighting occurs after things like /:/~ and /:/$
Sincerely,
Luc.
___
Emacs-devel
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Richard Stallman wrote:
>
>[I think it's probably possible to fix this -- e.g., by generating a
>regexp of all non-absolute environment variables and glomming it onto
>the rexexp used for filenames. But my basic point is that it
Richard Stallman wrote:
[I think it's probably possible to fix this -- e.g., by generating a
regexp of all non-absolute environment variables and glomming it onto
the rexexp used for filenames. But my basic point is that it scarcely
matters.]
Could you try fixing i
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Miles Bader wrote:
>
>A flaw whose only effect is to make the prompt slightly less clear
>that it could be?
>
> A flaw that might give people the false impression that `$' after /
> has the same effect as / or ~ after /.
>
>I expect that the
The functionality of rfn-eshadow is quite useful to the vast majority
of users, and indeed is much-requested, and you want to not enable it
because you found a minor flaw? A flaw whose only effect is to make
the prompt slightly less clear that it could be?
I agree: this bug is not
Miles Bader wrote:
A flaw whose only effect is to make the prompt slightly less clear
that it could be?
A flaw that might give people the false impression that `$' after /
has the same effect as / or ~ after /.
I expect that the
traditional "double slash" behavior of Emacs filename i
SDtefan Monnier wrote:
So I think it's best to keep the :init value at nil
_Only_ if one would decide to keep the default value nil too. in which
case there is no problem. The value given in the defcustom *needs* to
be the real default value. Otherwise "Erase Customization" in Custom
produce
Richard Stallman wrote:
Worse
is that file-name-shadow-mode stays disabled in subsequent invocations
of the minibuffer, even though the variable file-name-shadow-mode is t.
I am not sure what you mean. Would you please provide precise instructions
for that part too
Stefan Monnier wrote:
This is because if the minor mode's code needs to be run to properly set the
value, you can't run it safely before the whole file is loaded (since the
minor mode's code might call functions defined further down in the file).
That is not really different from any oth
> beginning of the define-minor-mode expansion. Otherwise, setting
> :initialize to something else but `custom-initialize-default' is
> probably not going to work for minor modes defined with
> `define-minor-mode'. (It definitely does not work with the current
> code.)
I think it's OK that way.
Worse
is that file-name-shadow-mode stays disabled in subsequent invocations
of the minibuffer, even though the variable file-name-shadow-mode is t.
I am not sure what you mean. Would you please provide precise instructions
for that part too
Miles Bader <[EMAIL PROTECTED]> writes:
> On Sat, 19 Mar 2005 20:30:57 -0600 (CST), Luc Teirlinck
> <[EMAIL PROTECTED]> wrote:
>> In other words, rfn-eshadow.el assumes that the value of _every_
>> environment variable is an absolute file name and it yields very
>> confusing results when other env
On Sat, 19 Mar 2005 20:30:57 -0600 (CST), Luc Teirlinck
<[EMAIL PROTECTED]> wrote:
> In other words, rfn-eshadow.el assumes that the value of _every_
> environment variable is an absolute file name and it yields very
> confusing results when other environment variables are used in file
> names, say
I am no longer sure that enabling `file-name-shadow-mode' by default
is really a good idea. (_Not_ because it would be difficult: it could
easily be done using `custom-reevaluate-setting' in startup.el, even
without any changes to define-minor-mode.)
The problem is a comment in rfn-
.
I indeed did not look closely enough (it did not produce warnings for
file-name-shadow-mode during bootstrapping). This problem could be
easily circumvented by a compiler defvar for the mode variable at the
beginning of the define-minor-mode expansion. Otherwise, setting
:initialize to somethi
The following would appear to be a bug `file-name-shadow-mode'.
Do emacs -Q.
M-x customize-option RET file-name-shadow-mode RET
C-x C-f
Then set file-name-shadow-mode to t for the current session using the mouse.
You are still in the minibuffer. Clearly, file-name-shadow-mode does
not
> :initialize keywords, a bug.) To make things work correctly, I had to
> rearrange define-minor-mode to define the mode function before the
> defcustom.
I don't think this is a good idea.
> Apparently, this gives no compiler warnings (I checked), even though the
> function uses the mode variabl
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> The following four patches enable `file-name-shadow-mode' by default,
> preload rfn-eshadow.el and make define-minor-mode accept an
> :initialize argument. (It currently kind of accepts such an argument,
> but the result is
The following four patches enable `file-name-shadow-mode' by default,
preload rfn-eshadow.el and make define-minor-mode accept an
:initialize argument. (It currently kind of accepts such an argument,
but the result is that the macroexpanded defcustom contains two
:initialize keywords, a bug.
Assuming it's still considered a good idea to make sure that loading a file
does not have any other side effect,
This doesn't apply to preloaded files. If you reload this file,
it won't alter the option's value.
___
Emacs-devel mailing list
Em
An alternative to setting :initialize to `custom-initialize-set'
whenever :init-value is non-nil would be to fix `define-minor-mode' to
handle an explicitly passed :initialize keyword correctly.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel
Hi, if I remember correctly, we had agreed a long time ago to make
file-name-shadow-mode active by default for the release.
What I said is that I would try it myself. I have done so. It seems
useful and painless, so now I agree it should be the default.
Could you enable it
>From my previous message:
I personally very much believe it is a bad idea. _However_ it is the
_general_ default :initialize function (`custom-initialize-reset')
that has this problem and _not_ `custom-initialize-set' (note the
missing `re').
Actually, I was confused here: `cust
ther side effect, I think it's better to keep
the :init-value at nil, and simply add a call to file-name-shadow-mode
somewhere (either in startup, or loadup).
Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Stefan Monnier wrote:
Assuming it's still considered a good idea to make sure that loading a file
does not have any other side effect,
I personally very much believe it is a bad idea. _However_ it is the
_general_ default :initialize function (`custom-initialize-reset')
that has this probl
fn-eshadow.el 17 Mar 2005 21:45:48 -0600
***
*** 207,212
--- 207,214
With prefix argument ARG, turn on if positive, otherwise off.
Returns non-nil if the new state is enabled."
:global t
+ :init-val
> > Seemingly, this has not happened yet. I think the discussion petered
> > off after somebody asked how one could actually auto-enable some minor
> > mode.
>
> That was me...
>
> Does anyone have a quick answer to that question? Otherwise I suppose
> I'll try to find out (hmmm; what's
On Thu, 17 Mar 2005 10:16:37 +0100, David Kastrup <[EMAIL PROTECTED]> wrote:
> Hi, if I remember correctly, we had agreed a long time ago to make
> file-name-shadow-mode active by default for the release.
Yes
> Seemingly, this has not happened yet. I think the discussion pete
On Thu, 17 Mar 2005 12:16:23 +, Matt Hodges <[EMAIL PROTECTED]> wrote:
> I agree that it's very useful. Furthermore, in a 256-colour xterm
>
> (setq file-name-shadow-tty-properties file-name-shadow-properties)
>
> works perfectly well. I checked a 16-colour xterm, and needed to make
> t
>>>>> David Kastrup writes:
> Hi, if I remember correctly, we had agreed a long time ago to make
> file-name-shadow-mode active by default for the release.
> Seemingly, this has not happened yet. I think the discussion
> petered off after somebody asked how one
Hi, if I remember correctly, we had agreed a long time ago to make
file-name-shadow-mode active by default for the release.
Seemingly, this has not happened yet. I think the discussion petered
off after somebody asked how one could actually auto-enable some minor
mode.
I am using this all of
55 matches
Mail list logo
