> 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
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 work correctly even with weird
>> magic file name handlers.
>
> Regarding performance of my code: I just bumped into a performance
> pr
> How 'bout the patch below which makes no assumption (that I know of) about
> substitute-in-file-name, and will thus work correctly even with weird
> magic file name handlers.
Regarding performance of my code: I just bumped into a performance problem.
The problem is that substitute-in-file-name c
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
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
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
___
> 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 that the
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
>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. After
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 maili
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
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.
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-eshadow.el:
Stefan Monnier wrote:
> Apparently, this gives no compiler warnings (I checked), even though the
> function uses the mode variable, which is, in the new version, not
> yet defcustomed.
I'd be surprised if it doesn't introduce spurious warnings at
various places.
I indeed did not l
> :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 that the macroexpanded defcus
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.) To
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
> I believe that the reason you have problems is that define-minor-mode
> uses `custom-initialize-default' as the Custom :initialize function.
> That is correct if you want the minor mode disabled by default, but
> not if you want it enabled by default. Then you need to use
> `custom-initialize-se
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
Miles Bader wrote:
> 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?
I believe that the reason you have problems
> > 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 petered
> off after some
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 could actually auto-enable
>
47 matches
Mail list logo
