>> 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
Great. It takes care of handling file-name-shadow-mode in ffap
prompts correctly. Does
;; This version of ffap supports Emacs 20 only, see the ftp site
;; for a more general version. The following functions are necessary
;; "leftovers" from the more general version.
Note: There are also other references to "Emacs 20" in the file that should
perhaps b
> Regardless of whether this interface to `sort' should have been
> deleted,
What is wrong with POSIX?
That question is rather vague. The issue at hand is whether to delete
an interface that users use.
___
emacs-pretest-bug mailing list
e
> 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 li
[followup to emacs-pretest-bug@gnu.org from [EMAIL PROTECTED]
> shell-command-on-region on this:
> perl -le 'for(1..6){print $_ x 111}'
> mistakenly thinks it is showing all the output in the minibuffer, so
> it doesn't create new a new buffer for the output, when in fact it
> gets fooled by the
[followup to emacs-pretest-bug@gnu.org from [EMAIL PROTECTED]
> When I open a file with C-x C-f I have to enter its name in the minibuffer.
> If
> its name contains double slashs "//", everything before them is printed in
> grey
> (my global standard colour is orange). Additionally, a C-a doesn
Below is a patch that allows the user to turn off ffap highlighting.
Actually, it was possible to do this without this patch because
ffap.el checks for the face `ffap' with (facep 'ffap), but this
possibility is hidden from users. A standard way to customize this
is to define faces with `defface':
> In case this is considered to be a feature, here are some arguments against
> it:
>
> 1. Such mouse-face highlighting suggests a link or button - that is, it
> suggests that you can click mouse-2 to follow the link. This is of course
> not the case.
We could bind [mouse-2] on highlighted URLs to
> In case this is considered to be a feature, here are some
> arguments against it:
>
> 1. Such mouse-face highlighting suggests a link or button -
>that is, it suggests that you can click mouse-2 to follow
>the link. This is of course not the case.
We could bin
> > Do users ever enter them?
>
> I can't imagine a situation where users might want to enter them.
>
> In that case, there is no reason to keep them.
>
> Since `toc' pertains to the Current Info file, it makes no sense
> for that to be treated like a file of any kind. If anything,
> it is
Below is a patch that allows the user to turn off ffap highlighting.
Actually, it was possible to do this without this patch because
ffap.el checks for the face `ffap' with (facep 'ffap), but this
possibility is hidden from users. A standard way to customize this
is to define f
Stephen Berman wrote:
1. emacs -q (or -Q)
2. Invoke a mode that has a header line with highlightable text,
e.g. Info, Buffer Menu (list-buffers), ruler mode, also tab bar mode
from the external library tabbar.el.
3. Drag the mouse pointer over the header line until a portion of the
header line h
> On Thu, 9 Feb 2006 08:58:10 +, David Reitter <[EMAIL PROTECTED]> said:
> Works as intended. The fact that newly opened frames get the focus
> seems inconsistent, however. From a user's perspective, the same
> sequence of inputs will not lead to the same results, depending on
> whether th
On 9 Feb 2006, at 08:04, YAMAMOTO Mitsuharu wrote:
Could you try the following patch that prevents raise-frame from
giving focus to a raised frame that is already visible? Note that a
newly created or previously iconified frame still gets focus when the
frame is popped up by display-buffer, bu
With Emacs -q evaluating
(progn
(split-window-horizontally)
(let ((window-min-width 1))
(shrink-window (1- (window-width)) t)))
removes scrollbars from both emanating windows and makes the left window
inaccessible. For some strange reason `check_min_window_sizes' seems to
fail here.
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
I have written the following function. It fetches a page from the web.
In that page are links to archive pages, which should also be fetched,
and appended to the buffer. The problem: re-search-forward alway
> On Wed, 8 Feb 2006 19:59:22 +, David Reitter <[EMAIL PROTECTED]> said:
> The below issue is reproducible in a plain GNU Emacs (Carbon). Note
> that the X11 version is reported to work fine, but not Carbon Emacs.
> This might not be considered a bug by some of you (for example
> because t
17 matches
Mail list logo
