Why is it setting deactivate-mark? I thought that was only set by the
sort of interactive command that shouldn't be used in hooks etc.,
which makes this problem sound more like a simple bug rather than a
design problem
Any change to the buffer sets deactivate-mark. So
Unless/until you can think of a better solution consider the following
patches as point of departure (I know, you despise yet another text
property):
The problem is not so much the use of a text-property (which I do not
despise, but that I indeed try to avoid) in this patch but the mix of
This is a bug that could take a while to fix ;-)
When in partial-completion-mode, if I try, say M-x
describe-function RET -function TAB the *Completion* buffer is
shown, but the letter in bold are not those which make a difference
for the completion.
As this is an old bug, it could have
Yes, `0' is better.
I would even prefer `t',
Maybe here it makes sense. But be super extra careful with t in
such places: it considers all frames including frames on other displays.
Stefan
___
Emacs-pretest-bug mailing list
Maybe here it makes sense. But be super extra careful with t in
such places: it considers all frames including frames on other displays.
I didn't know that. Is that behavior special for `t'? Wouldn't it logically
apply to `visible' and `0' also?
If not:
- Why is `t' an exception
When I use 'ls -lw' to display the file names in xterm, I get:
-rw-r--r--1 pete pete62 25 Mär 2005 áÛïǓà.txt
-rw-r--r--1 pete pete62 25 Mär 2005 äÖüÄöÜ.txt
-rw-r--r--1 pete pete 107 2 Dez 2004 äöüßÜÖÄ€
Doing the same in
However, this has one problem: it will correct the word only to
the first variant.
Is that because the text property keymap will go away when the word
becomes correctly spelled?
Yes, the overlay with the keymap will go away after the word is
fixed with first M-TAB.
It should be easy to
I think it makes sense: frames that are invisible are similar
to frames on other displays in the sense that no amount of
`display-buffer' (or pop-to-buffer) will be sufficient to
display them.
Just because some function (e.g. `display-buffer') treats two things
similarly
Anyway, regardless of why or whether anyone would use invisible frames, the
question here is how they should be treated.
They're not treated differently. It's the visible and iconified parts that
are treated differently because a frame that's visible/iconified but on
another display is as good
An easy fix is to turn off the boldening if partial-completion-mode is ON
and the string starts with a - (or maybe even turn it OFF altogether
whenever partial-completion-mode is ON).
A week from now, if nobody has proposed a better solution, would you
please do that?
How 'bout
p.s. Saw the following when compiling:
In end of data:
apropos.el:963:1:Warning: the function `help-buffer' is not known to be
defined.
It's harmless. The problem is that the byte-compiler doesn't think
hard enough: help-setup-xref is autoloaded from help-mode.el, so after the
call to
revision 1.2
date: 2003/07/23 00:00:13; author: gm; state: Exp; lines: +5 -1
branches: 1.2.2;
(define-derived-mode): Mention hook in doc string. Defvar the derived
hook.
Maybe someone familiar with that code can take it out...
I'll gladly take it out if nobody
AFAIK, Gerd isn't listening, so I CC'ed him.
Gerd, can you please help?
revision 1.2
date: 2003/07/23 00:00:13; author: gm; state: Exp; lines: +5 -1
I don't recognize the author gm, but I'm pretty sure it's not me :-).
Oops, sorry, you are right. It was Glenn Morris.
The example uses negative numbers to prevent impact to existing code.
Some positive number range will work, as will (symbolp (cdr (syntax-after
beg))). I've tried all these ways with success. Anything is fine for me.
I'd like to be able to finally release these modes in working condition
*** gdb-ui.el 13 Nov 2005 21:31:16 +1300 1.111
--- gdb-ui.el 14 Nov 2005 12:29:46 +1300
***
*** 2702,2708
(if (re-search-forward address nil t)
(gdb-put-breakpoint-icon (eq flag ?y) bptno
(if (not (equal
(i) In my init-file default-major-mode is set to text-mode and as a
result, since diary-list-entries only checks for fundamental-mode, my
diary file isn't automatically visited in diary-mode.
I've installed your patch for this, thank you.
(ii) In the diary display (I use fancy-diary-display)
Does this change give good results?
*** printing.el 24 Sep 2005 22:42:49 -0400 1.34
--- printing.el 15 Nov 2005 15:59:42 -0500
***
*** 1042,1050
;; To avoid compilation gripes
! (or (fboundp 'easy-menu-intern) ; hacked from
Your patch modifies the buffer which is very unclean in a function which is
only supposed to extract data from it. Does the patch below work as well?
Yes, it does the job; thanks!
Thank you, installed.
Stefan
___
emacs-pretest-bug
This code below confuses perl-mode. The comma in split /,/, ... causes
everything after it to be indented and hi-lighted wrong.
If I change the , to an X it is ok. Also if I put () around the split args
it is ok.
I recommend you put parens around the args.
I am running with the last set
An easy fix is to turn off the boldening if partial-completion-mode is ON
and the string starts with a - (or maybe even turn it OFF altogether
whenever partial-completion-mode is ON).
A week from now, if nobody has proposed a better solution, would you
please do that?
PS: guaranteed 100%
Wouldn't the patch below be preferable?
Stefan
--- printing.el 24 sep 2005 13:32:37 -0400 1.34
+++ printing.el 15 nov 2005 23:35:32 -0500
@@ -1027,6 +1027,7 @@
(require 'lpr)
(require 'ps-print)
+(eval-when-compile (require
(defconst encoded-kbd-mode-map (make-sparse-keymap)
Keymap for Encoded-kbd minor mode.)
The keymap is allocated in the pure storage if this file is preloaded,
because it is defined by `defconst' (should be `defvar'?).
That is definitely a bug. Could you change that to a
Can't we just gc the pure space too?
If the pure space gets GC'd, what's the point of the pure space?
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
If the pure space gets GC'd, what's the point of the pure space?
I don't know -- what is the point of pure space?
That you don't have to GC it ...
Yes, the point AFAIK is to reduce the size of the heap that we have to GC so
as to reduce the time spent in the GC.
Also in some older systems
This code below confuses perl-mode. The comma in split /,/, ... causes
everything after it to be indented and hi-lighted wrong.
The best I could come up with so far is the patch below. Please try it.
It's a real pain in the rear to have to do so much effort just for this one
special case.
So I just suggest the patch below instead.
Whatever way you want is fine with me.
I tried this for a while just to be sure but naturally it works just fine.
Looking forward to seeing it in CVS!
Well, I still haven't heard anybody (Richard?) confirm that I can install it.
Stefan
Steps to reproduce:
C-x 1
C-x 2
C-p
M-: (save-window-excursion (other-window 1))
Note that the point is restored to the same place the point is in the
other window.
As written in the documentation, the point of the current buffer is
not restored.
I believe Shawn's point is not
Whatever way you want is fine with me.
I tried this for a while just to be sure but naturally it works just fine.
Looking forward to seeing it in CVS!
Well, I still haven't heard anybody (Richard?) confirm that I can install
it.
I already said yes.
Sorry I missed it (or forgot it if
1) IIUC, all of the calls to macro `cmpl-statistics-block' should be removed
from this library.
The macro does nothing, and most of the args passed to it (which are
ignored) are undefined anyway.
The comment introducing the macro says that the functionality is defined in
library
I think that src/atimer.c has a bug in stop_other_atimers().
This should fix it. I also changed 0 to NULL to make it similar
to a loop in cancel_atimer().
Thanks, I installed your patch.
Stefan
--- src/atimer.c.orig 2005-11-27 16:57:35.0 +0200
+++ src/atimer.c
Drew == Drew Adams [EMAIL PROTECTED] writes:
With the most recent Emacs CVS, NOMIYA Masaru reported he cannot
delete the region that is made by dragging the mouse, using DEL
key. I also confirmed Emacs 21.4 works but 22.0.50 doesn't.
Not much many people might not know such a function,
If you could give a more precise description of the problem, we could
probably find a better fix.
E.g. show us a backtrace,
I don't have one. As I said, I was experimenting, and I must have somehow
stuck a string onto the command history (I don't remember the details). Yes,
This code below confuses perl-mode. The comma in split /,/, ... causes
everything after it to be indented and hi-lighted wrong.
The best I could come up with so far is the patch below. Please try it.
It's a real pain in the rear to have to do so much effort just for this one
special case.
- file ~/.completions does NOT exist
- emacs -q --debug-init
- M-x load-library completion
= error, completions not defined
Oops, should be fixed now,
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
I find Transient-Mark mode completely unusable as it stands.
To each his own. I find Emacs very hard to use without the visual feedback
of transient-mark-mode.
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
It's not worth continuing this thread now, but I wonder if it wouldn't be
worthwhile looking into the use patterns sometime later. It's possible that
Richard uses t-m mode differently from Stefan and I. If we looked into this
a little more (later), we might be able to either improve it (for
I have tried using Transient-Mark mode occasionally, most recently in
the past week. It screws me because I use commands that operate on a
region, in situations where normally they would work, but the mark is
not active.
Sounds like you need to set mark-even-if-inactive to t.
That's also
This was not too easy to track down.
In file skk-tut.el:
My shell find no match for **/skk-* in the Emacs sources, so you've
probably sent your email to the wrong place.
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
I wonder what do the users of transient-mark-mode with
mark-even-if-inactive=t expect in this situation?
In transient-mark-mode, the current behavior in general is that
mark-even-if-inactive is only used for commands which require a region.
For those commands whose behavior varies depending on
However, this gave me the error message
provide: Symbol's value as variable is void: ediff-dir-diffs-buffer-map
It seems to me that I get this error message because eval-after-load
is evaluated immediately after the (provide 'ediff-mult) at the
beginning of ediff-mult.el. If the (provide
* minibuf.c (keys_of_minibuf): Just unbind SPC in
Vminibuffer_local_filename_completion_map rather than forcing it
explicitly to the same binding as the global map.
BTW, shouldn't exactly the same change be made also for
`Vminibuffer_local_must_match_filename_map'?
Indeed, I missed that
In the last week, sometimes maybe 1 in 20 times, C-x C-f (find-file)
RET won't find the given file. However, the symptom is that if I'm
editing buffer foo, and run find-file to open file bar, instead of
getting two equally-sized windows containing foo and bar, I get two
foo windows, one of
After the release, I think it calls for a different approach. For
instance, we could write
(interactive
(list (recompute-arg EXPRESSION) (recompute-arg EXPRESSION) ...))
When evaluated, recompute-arg would return its arg, but when
fix_command sees it, it would save EXPRESSION as
But the above solution still has the following problem: pop-to-buffer may
create a new frame, in which case the save-window-excursion won't be enough.
Basically, we need to tell vc-do-command not to call pop-to-buffer.
I'll install a patch for it, thanks.
Thank you.
Does the patch below
The context menu created by flyspell on incorrect words works well if
you press your mouse button, select an item keeping the mouse button
pressed, and then release it.
OTOH, if you single-click on an incorrect word, the menu remains after
the button is released (which is the usual behavior
it seems that after the smerge-remove-props call, the match data
information is lost so (match-end n) returns nil, causing
delete-region to fail. Changing the definition as below seems to fix
the problem.
(defun smerge-keep-n (n)
(let ((zero-start (match-beginning 0))
Debugger entered--Lisp error: (void-function tree-widget-theme-name)
tree-widget-theme-name()
recentf-open-files((/etc/profile.d/modules.csh [file list stripped]
[...]
I tried with your .emacs and an equivalent .recentf file and can't
reproduce the bug. Can you locate-library tree-widget?
I don't know what your criteria are for installation, or what you mean
by `the release'. The encryption code works for what I needed.
However, you've installed different encryption stuff I don't
understand in allout. That wouldn't run and I don't understand why
such a facility is (just)
Given that the condition that x-backspace-delete-keys-p is quite odd,
and probably unlikely to happen, it is better in the case that we
don't have enough information (because XKB is not supported at
either run time or compile time) to return t. The result is that
[backspace] would delete
The `args' arguments to lazy-completion-table are only evaluated when we
actually compute the completion table. So they basically can only use
global variables, which is very limiting.
It's pretty clear to me that the intention was to evaluate those args
immediately, so that they are evaluated
Is this correct? It seems to work right when I try it.
Looks like it works indeed, although it breaks my code because my code
relies on lexical-let which doesn't work correctly when the lambdas are
built at run time as is the case in your code.
So maybe I'll be better off with the current
Cookies file /home/wohler/.url/cookies (see variable
`url-cookie-file') is unwritable.
I'm not using this package explicitly. Either it, or the package using
it, should be ensuring that the url environment is set up correctly
without user intervention. In this particular case, I assume
Looks like it works indeed, although it breaks my code because my code
relies on lexical-let which doesn't work correctly when the lambdas are
built at run time as is the case in your code.
So maybe I'll be better off with the current code. Hmm
I can install my fix, or
Looks like it works indeed, although it breaks my code because my code
relies on lexical-let which doesn't work correctly when the lambdas are
built at run time as is the case in your code.
So maybe I'll be better off with the current code. Hmm
I can install my fix, or I can leave it
Incidentally, ~/.url should probably be ~/.emacs.d/url instead.
It should use the latter if .emacs.d exists and ~/.url does not
exist. (That's the usual criterion.)
Would you like to fix it?
Done,
Stefan
___
emacs-pretest-bug
Could you describe more precisely? E.g. which button do you press, which
toolkit, which version of Emacs, ...?
Gtk, up-to-date version of Miles arch import. Pressing mouse-2.
Actually, I've just tested the same with Debian's emacs-snapshot, and
it doesn't seem to have the problem. A single
Thanks, but I have a write access only to Gnus (in cvs.gnus.org
which is gatewayed to Emacs CVS), I haven't worked on the paper
to Emacs. Could anyone please take it on?
Thanks, I resynchronized your patch and installed it. And by the way,
you do have papers for Emacs.
Stefan, there's a
I see at least three solutions:
* check font-lock-keywords in font-lock-default-function for the compiled
empty value `(t nil)' and don't call font-lock-mode-internal for this
value;
I'd rather intervene at an earlier stage so that it is not compiled at all.
Why not?
Stefan, there's a bug in your latest changes to this function: when a
completion has been found, the *Completions* buffer is buried but its
window remains visible. In previous versions, the window was deleted
as well.
If you do it the other way around you also have a bug in that it may
+ (setq help-xref-stack-item (list 'help-insert-string (buffer-string)))
This is wrong. There are functions like help-setup-xref to do this job.
Don't access help-xref-stack-item directly unless you really have to, in
which case you should justify it with a clear comment describing
the
+ (setq help-xref-stack-item (list 'help-insert-string (buffer-string)))
This is wrong. There are functions like help-setup-xref to do this job.
The function help-setup-xref is already used in describe-char as
(help-setup-xref nil (interactive-p))
It is called before the old
Usually I don't configure Emacs with --without-x, so I don't see a similar
message.
I see it a lot.
It would be good to somehow suppress this message (by using some GDB
option?).
I tried very hard to find a way to do that, but failed. I'm open to
suggestions.
Maybe another approach is
AFAICT it's the exact same situation as in all other cases, except that you
use (buffer-string).
All other cases call `help-setup-xref' with the same function name and its
arguments just before calling `(with-output-to-temp-buffer (help-buffer)
...)' and replacing old contents of the help
The doc string of with-temp-file should mention that the new buffer
created is killed at the end.
I tried to do this:
(unwind-protect
(with-temp-file foo (pp something (current-buffer)))
(kill-buffer foo))
You seem to also be confusing it with `with-temp-buffer'.
Stefan
This is not reliable way to restore the old output of `describe-char'
since the original buffer might be killed or the character at the old
position might be deleted,
The same holds for most/all other uses of help-setup-xref.
So it makes sense to preserve the original contents of the help
1) Keep an index with line numbers for every 5000th character in a buffer
and use the index to get a good approximate translation from
char-position to line number (or char-position to pixel height count,
i.e. lines x char-height) by using the index and counting the remaining
My point is that the doc string of `with-temp-file' says that a new buffer
is _created_, used to evaluate stuff, and then written to its file.
It says nothing about the buffer being _temporary_ (i.e., being deleted
after being saved).
Indeed it doesn't ay so. I don't find it indispensable to
Although appropriate here, I think this approach is inappropriate in many
cases e.g `C-h v' could re-create a Help buffer with an out-of-date value
which
No, only help-xref-go-back would re-create a potentially out-of-date text.
C-h v would still create a brand new text of course.
the following change breaks `M-x vc-annotate RET' for me:
2005-12-22 Stefan Monnier [EMAIL PROTECTED]
* vc.el: [...]
(vc-annotate-buffers): Remove var.
(vc-annotate-backend): Make it buffer-local.
(vc-annotate): Move the interaction to the interactive spec
I just went a couple of days without reproducing, but it happened pretty
quickly just now (after reading some mail with MH-E--h).
It's gonna be hard to fix until we have a reproducible testcase.
Local in buffer *Apropos*; global value is (t nil)
This global value is the indirect
the following change breaks `M-x vc-annotate RET' for me:
[...]
Should be fixed now,
I don't know is it a new bug or not, but I get a similar error message:
vc-find-backend-function: Cannot open load file: vc-nil
after using `log-view-find-version' or `log-view-diff' on a file removed
`C-x c =' is not equivalent to `d'. Unlike `d', it doesn't compare the
revision at point with its previous revision. It compares the revision at
point with the current revision. Perhaps this is another bug, I don't know.
No it's not a bug. It's just a difference. Use point and mark to
1. start PCL-CVS;
2. insert an old file removed from the CVS repository, e.g.
`I emacs/lisp/webjump.el' (note that it was moved from
emacs/lisp/webjump.el to emacs/lisp/net/webjump.el);
3. type `l';
4. in the *cvs-info* buffer type `n';
5. type `d' or `f' = vc-nil error
That's an
Is that enough information to find the culprit, or is there a watch I
can put on the global value of font-lock-keywords which will print a
stacktrace or enter the debugger when it is changed?
...
Before fixing it, it would be useful to know how it gets called.
In the buffer list you sent
Thanks, now I see. I'm so accustomed to the logic of `log-view-diff'
that uses the previous revision if there is no mark. Perhaps `C-x c ='
should use exactly the same logic.
I don't have an opinion, so feel free to change it (it's probably in
log-view-minor-wrap).
Stefan
Is that enough information to find the culprit, or is there a watch I
can put on the global value of font-lock-keywords which will print a
stacktrace or enter the debugger when it is changed?
...
Before fixing it, it would be useful to know how it gets called.
In the buffer list you sent
signal(error (Font-lock trying to use keywords before setting them up))
error(Font-lock trying to use keywords before setting them up)
font-lock-compile-keywords(nil t)
font-lock-fontify-keywords-region(1 81 nil)
font-lock-default-fontify-region(1 80 nil)
Thanks, now I see. I'm so accustomed to the logic of `log-view-diff'
that uses the previous revision if there is no mark. Perhaps `C-x c ='
should use exactly the same logic.
I don't have an opinion, so feel free to change it (it's probably in
log-view-minor-wrap).
Thanks for the hint.
I haven't gotten any replies to this message.
Sorry I didn't reply, but I did install a patch that does something similar
to what you suggest.
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
- transient exposure of hidden search hits during incremental search, so
they are reconcealed if the search continues past, or properly exposed if
the search concludes there
IIUC this has been supported by outline (and hs-minor-mode) since at least
Emacs-20.3.
I don't know how people use
url-retrieve-synchronously becomes asynchronous when HTTP redirects are
involved. When it encounters a redirect, url-http-parse-headers calls
url-retrieve instead of url-retrieve-synchronously. Naively switching to
the latter doesn't solve the problem and I haven't been able to find a fix..
one thing i wonder is whether the delays might depend on the number of
overlays?
Yes, it does. Most overlay manipulation operations are O(n) where n is the
number of overlays in the buffer.
Stefan
___
emacs-pretest-bug mailing list
url-retrieve-synchronously becomes asynchronous when HTTP redirects
are involved. When it encounters a redirect, url-http-parse-headers
calls url-retrieve instead of url-retrieve-synchronously.
Naively switching to the latter doesn't solve the problem and
I haven't been able to find a fix..
several people have mentioned this. i'm trying to figure out what
best to do - but do note that the standard outline-mode uses \C-c
bindings, also.
Please check the elisp manual where it explains what it reserved for what.
C-c is usually for major modes, but C-c punctuation is for minor modes
- Older versions of CVS emacs (built a couple of months ago) do not
try to load ~/bar/foo.gz (even if ~/foo/foo.el doesn't exist at
all).
Yes, we fixed a bug. The bug was that when auto-compression-mode was
enabled, (load foo) would find foo.el.gz but (load foo.el) wouldn't.
- Even my
- If ~/bar is in the load-path before ~/foo and we have files
~/bar/foo and ~/foo/foo.el, then emacs loads ~/foo/foo.el.
Really?
I've just tried it here with:
% echo '(message foo1)' ~/tmp/foo1/foo
% echo '(message foo2)' ~/tmp/foo2/foo.el
M-: (let ((load-path (list* ~/tmp/foo1
You are right -- but it seems we have indeed one more inconsistency.
Modify your example as follows:
% echo '(defun foo () (message foo1))' ~/tmp/foo1/foo
% echo '(defun foo () (message foo2))' ~/tmp/foo2/foo.el
M-: (let ((load-path (append '(~/tmp/foo1 ~/tmp/foo2) load-path)))
It might not be elegant but the attached patch works for me. If
url-retrieve sees :redirect in cbargs, it calls url-retrieve-synchronously
and then calls the callback with cbargs.
That wasn't what the attached patch did, but in any case that'd be
a workaround, not a fix.
Stefan
1. It's not clear to me what is meant by the event and its binding.
Aren't we talking here about a key sequence and its binding in KEYMAP?
The event is a key (not a key sequence: just one key).
Its binding is either a command or another map (if the key is a prefix
key).
Stefan
With CVS Emacs, url-retrieve triggers an error when it gets an HTTP status
of 304 *and* the requested page is not in the cache. To reproduce, try
this:
(setq url-request-extra-headers
'((If-Modified-Since . Sun, 18 Sep 2005 17:34:28 GMT)
(If-None-Match .
1. It's not clear to me what is meant by the event and its
binding. Aren't we talking here about a key sequence and
its binding in KEYMAP?
The event is a key (not a key sequence: just one key).
Its binding is either a command or another map (if the key is a prefix
key).
1. I'm
With CVS Emacs, url-retrieve triggers an error when it gets an HTTP status
of 304 *and* the requested page is not in the cache. To reproduce, try
this:
(setq url-request-extra-headers
'((If-Modified-Since . Sun, 18 Sep 2005 17:34:28 GMT)
(If-None-Match .
If key sequence `C-x 4 f' is bound to command `find-file-other-window',
then, IIUC, the events or keys here are `C-x', `4', and `k'. Is that what
you mean?
Yes.
I guess that the bindings for these events correspond to the
keymap that is the value of `ctl-x-map', the keymap that is the
The five patches below do that. They export `default_suffixes' to
Lisp and have jka-compr-* use it.
I can install if desired. If the patches look OK, I will also update
lispref/loading.texi.
It looks good except for the fact that `default-suffixes' is too general
a name for this variable
The docstring of load-suffixes starts with a `*'. According to what
we decided, we should either get rid of that `*' or make a defcustom
out of it. Given the way that Auto Compression mode plays around with
load-suffixes, it is not easy for ordinary users to customize it
reliably (with or
The unquoted variable in this form from table.el:
(make-variable-buffer-local table-mode-indicator)
leads to a Symbol nil may not be buffer-local error on loading.
Sorry, typo. It's fixed now,
Stefan
___
emacs-pretest-bug mailing
It might not be elegant but the attached patch works for me. If
url-retrieve sees :redirect in cbargs, it calls url-retrieve-synchronously
and then calls the callback with cbargs.
That wasn't what the attached patch did, but in any case that'd be
a workaround, not a fix.
The more I think
In a table cell, C-h m leads to the following error:
Debugger entered--Lisp error: (void-function help-print-return-message)
help-print-return-message()
*table--cell-describe-mode()
call-interactively(*table--cell-describe-mode)
C-h b leads to a similar error. The
Chris == Chris Moore [EMAIL PROTECTED] writes:
This seems to fix it:
--- Backup/wdired.el.~1~ 2006-02-07 05:10:38.0 +0100
+++ wdired.el 2006-02-07 05:10:48.0 +0100
@@ -323,8 +323,8 @@
(if old
(setq file (get-text-property beg 'old-name))
(setq
I use ffap and since file-name-shadow-mode was enabled it bothered me that
the protocol part of URLs is shadowed and C-a doesn't go to the beginning
of the minibuffer.
Try M-x url-handler-mode RET
Stefan
___
emacs-pretest-bug mailing list
201 - 300 of 725 matches
Mail list logo
