Dear eBay valued member,
We recently have determined that different computers
have logged onto your eBay account, and multiple
password failures were present before the logons. We
now need you to re-confirm your account information to
us. If this is not
Nick Roberts <[EMAIL PROTECTED]> writes:
> > It would be very good to make this mode to work like edebug
> > (automatically making the source code buffer read-only, etc.)
> > and to have similar keybindings:
> >
> > " " - step
> > "n" - next
> > "c" - cont
> > "g" - go
> > ...
>
> Its se
> It would be very good to make this mode to work like edebug
> (automatically making the source code buffer read-only, etc.)
> and to have similar keybindings:
>
> " " - step
> "n" - next
> "c" - cont
> "g" - go
> ...
Its seems more natural to use the existing abbreviations for GDB, as
Hello folks,
how difficult would it be to make "--without-toolkit-scroll-bars" a
runtime instead of or in addition to being a compile-time option?
Background: for serious use, the "modern" scroll-bars (everything
Post-Athena) are deficient. You can't switch between back- and
forward motion with
>From my previous message:
Some get saved if they were set through the menu
bar _or_ through Custom. (There does not seem to be too much we can
do about that right now. Without storing more stuff in property
lists, Emacs can not distinguish.)
Even so, we might not _want_ to do an
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
> I would like a small group to organize to make a plan for what to do
> with M-g, and discuss the question outside of this list. Would those
> who want to do this please do so?
We can just postpone this discussion to after the release.
We could, but that's not quite the issue.
But the problem here are things like:
If nobody objects in the next day or so, I volunteer to install these
two changes
Yes, exactly. No one should EVER wait less than 2 days for such
responses.
___
Emacs-devel mailing list
Emacs-de
I sometimes wish that we had
appointed or elected "dictators" for specific subsystems of Emacs:
We do, for many parts. For instance, Handa is in charge of Mule
issues and mostly decides them on his own. But there are parts
that nobody wants to take special responsibility for.
David Kastrup wrote:
Well, that assessment of the situation certainly sounds like
qualifying for the "bug fixes" department even before the release, and
I don't think it can be considered adequately addressed in
release-quality merely by having the "Save Options" menu entry appear
a
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 minibuffer binds minibuffer-
In article <[EMAIL PROTECTED]>, James Cloos <[EMAIL PROTECTED]> writes:
> There are also still at least a couple of things I forgot to mention.
> Server-side unicode fonts are limited to the bmp, so one cannot edit
> scripts that use non-bmp characters w/o switching to client-side
> fonts. Client-
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Lennart Borgman wrote:
>
>3) Choose menu "Save Options".
>
>What happens on your computer? On my computer debug-on-error is
>saved as far as I can see.
>
> If I understood the code in menu-bar.el correctly (I did not try out
> anything), then
Lennart Borgman wrote:
3) Choose menu "Save Options".
What happens on your computer? On my computer debug-on-error is saved as far
as I can see.
If I understood the code in menu-bar.el correctly (I did not try out
anything), then an oversimplified description of the situation if you
cho
Stefan Monnier wrote:
I have started on Xft support, but it is really something for the release
after the next, so I don't spend much time on it yet. I can confirm your
reasoning, the Emacs font-selection machinery is indeed the most tricky
part, I have not done that fully, so I can't change font
On Mon, 21 Mar 2005 11:03:10 +1200, Nick Roberts <[EMAIL PROTECTED]> wrote:
> I don't think using breakpoint faces in text-mode quite works. On a basic
> xterm, an enabled breakpoint (letter 'B') stands out clearly in red, but
> as disabled breakpoint (letter 'b') disappears completely.
It works c
- Original Message -
From: "Jason Rumney" <[EMAIL PROTECTED]>
> I think the reason to put it above "Customize Emacs" is to avoid
> misleading users into thinking that it will save changes made inside
> customize.
I am beginning to feel dizzy. Do you mean something like this:
1) M-x cust
On Sun, 20 Mar 2005 11:49:50 -0500, James Cloos <[EMAIL PROTECTED]> wrote:
> My understanding is that when a (server-side) font is opened by the
> X server it must determine all of the glyphs' metrics, which requires
> rendering all of them.
I think this is not true -- it seems to be exactly this
I don't think using breakpoint faces in text-mode quite works. On a basic
xterm, an enabled breakpoint (letter 'B') stands out clearly in red, but
as disabled breakpoint (letter 'b') disappears completely. I don't understand
the subtleties of faces but maybe grey60 gets 'rounded' to white on an xt
> âMilesâ == Miles Bader <[EMAIL PROTECTED]> writes:
>> The other benefits are just as important. Control and installation
>> of fonts are easier for most users
Miles> Can you explain in more detail? I use debian, and Emacs
Miles> already seems able to use the same fonts as xft-using progra
On Sun, 20 Mar 2005 22:46:42 +0100, David Kastrup <[EMAIL PROTECTED]> wrote:
> > Your idea of using a prefix
> > looks better. We could have the following prefixes:
>
> Again: I don't like the left-right jump of the minibuffer caused by
> that. If there really is a need for that kind of informat
On Sun, 20 Mar 2005 17:26:02 +0100, David Kastrup <[EMAIL PROTECTED]> wrote:
> b) one of the few additions we have is the "Hide/Show" menu. It
> appears that similar functionality is available in other applications
> as a top-level menu "View". There has pretty much consent on the list
> that thi
Juri Linkov <[EMAIL PROTECTED]> writes:
> Miles Bader <[EMAIL PROTECTED]> writes:
>> Something like:
>>
>>Global info I-search: foo
>>
>> [Maybe "Cross-node" would be better than "Global"?]
>>
>> or whatever would be even more similar to the existing "Wrapped", get
>> the point across well, a
Richard Stallman <[EMAIL PROTECTED]> writes:
> 3. By default this mode should be enabled for non-ascii based
>image format files like .png, .jpg. This could be achieved
>by enabling auto-compression-mode by default and turning
>image-mode off by default for ascii based
Rajsekar <[EMAIL PROTECTED]> writes:
> Rajsekar <[EMAIL PROTECTED]> writes:
>
>> I want to setup the smileys similar to gaim.
>> So I put
>>
>> "\\(:)\\)\\W" for smile.
>> and
>> "\\(:))\\)\\W" for laugh.
>>
>> The problem is that :)) also contains a :). At the same time, i do no
Jason Rumney <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> Since I have stared now at the current menus for 21.4 and 22.x for
>> longer than probably ever previously, I would like to mention one
>> other thing that has struck me as standing out negatively, and this
>
Rajsekar <[EMAIL PROTECTED]> writes:
> I want to setup the smileys similar to gaim.
> So I put
>
> "\\(:)\\)\\W" for smile.
> and
> "\\(:))\\)\\W" for laugh.
>
> The problem is that :)) also contains a :). At the same time, i do not
> want to replace \W with something like [^)] b
>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
Juri Linkov <[EMAIL PROTECTED]> writes:
> (set (make-local-variable 'isearch-success-function)
> ;; isearch only in function names
> (lambda ()
>(save-match-data
>(let* ((re (cdr (assoc nil imenu-generic-expression
> (and (save-excursion (beginning-of-line) (l
Miles Bader <[EMAIL PROTECTED]> writes:
>> I-search: local variables [(emacs)File variables]
>
>I-search (in node File Variables): local variables
>
> That's also more similar to other "informational messages" used by
> search, e.g., "overwrapped" or whatever.
>
> [It seems a good idea for spac
"Lennart Borgman" <[EMAIL PROTECTED]> writes:
>> "global-font-lock-mode" which we now present as "Syntax
>> Highlighting".
>
> Can this go into "Appearance" too please. A shorter structured menu
> makes it easier for users.
It has been there already in Emacs-21.1, and all the other
"Hide/View/App
Miles Bader <[EMAIL PROTECTED]> writes:
> Something like:
>
>Global info I-search: foo
>
> [Maybe "Cross-node" would be better than "Global"?]
>
> or whatever would be even more similar to the existing "Wrapped", get
> the point across well, and address your concern about the prompt size
> bou
Richard Stallman <[EMAIL PROTECTED]> writes:
> But it allows to narrow the search only
> to specific text part (such as e.g. in Firefox typing a ' before the
> search string searches only links) which is currently not easily
> implementable in Emacs.
>
> Making such a feature usef
David Kastrup <[EMAIL PROTECTED]> writes:
> Since I have stared now at the current menus for 21.4 and 22.x for
> longer than probably ever previously, I would like to mention one
> other thing that has struck me as standing out negatively, and this
> _would_ be a change with regard to 21.4: I'd sw
- Original Message -
From: "David Kastrup" <[EMAIL PROTECTED]>
> It has been proposed to rather name this menu "Appearance" since
Agree.
> c) The option blink-cursor-mode has been put into the top level of the
...
> a) naming the current "Hide/Show" (which has not yet been released
>
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 <[EMAIL PROTECTED]> writes:
> --ansi may have other consequences, and I don't trust it.
> Can we avoid generating these double-slashes?
I have had a bit of experience with this stuff in the installation
procedure of preview-latex and AUCTeX where several generated
directory names
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
Richard Stallman <[EMAIL PROTECTED]> writes:
> If you used an overlay instead of text properties, there would be no
> necessity to modify the buffer.
>
> That is true. However, copying the image to another buffer would only
> get you text.
Which is what would be appropriate when copying
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
Luc Teirlinck <[EMAIL PROTECTED]> writes:
>Of course Richard fills in some of that space,
>
> Of course.
>
>but given his intermittent access and numerous other chores,
>
> But the problem here are things like:
>
>If nobody objects in the next day or so, I volunteer to install these
>
If you used an overlay instead of text properties, there would be no
necessity to modify the buffer.
That is true. However, copying the image to another buffer would only
get you text. That's why I decided to make it a text property.
___
Emac
--ansi may have other consequences, and I don't trust it.
Can we avoid generating these double-slashes?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
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
Of course Richard fills in some of that space,
Of course.
but given his intermittent access and numerous other chores,
But the problem here are things like:
If nobody objects in the next day or so, I volunteer to install these
two changes
If you were willing to wait at least two da
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
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>
>Since both of these suggestions would be a change with regard
>to 21.4, if there is any contention about them (except maybe for
>better proposals for the "All Options" menu), we should rather drop
>them instead of
David Kastrup wrote:
Since both of these suggestions would be a change with regard
to 21.4, if there is any contention about them (except maybe for
better proposals for the "All Options" menu), we should rather drop
them instead of wasting time discussing them, if the advantages are
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 <[EMAIL PROTECTED]> writes:
> I don't want to rethink the Emacs menu bar now.
> It would be a big argument. Let's not have the argument.
>
> People, when someone starts a discussion about a substantial change
> in Emacs, please don't argue about the details. If you disagree
> wi
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
At Mon, 21 Mar 2005 00:52:33 +0900,
Yoichi NAKAYAMA wrote:
>
> The change in keyswap.el:
>
> 2005-03-19 Eli Zaretskii <[EMAIL PROTECTED]>
>
> * obsolete/keyswap.el: Moved to obsolete/ from term/.
>
> broke term/bobcat. If the change implies that the function is
> replaced by normal-er
The change in keyswap.el:
2005-03-19 Eli Zaretskii <[EMAIL PROTECTED]>
* obsolete/keyswap.el: Moved to obsolete/ from term/.
broke term/bobcat. If the change implies that the function is
replaced by normal-erase-is-backspace-mode, following change
seems adequate.
--- bobcat.el 1 Sep
Richard Stallman <[EMAIL PROTECTED]> writes:
> I would rather put this aside until after the release.
I was hoping we could at least add the "candidates" from my list before
the release. New bindings for previous-error and next-error would be
immediately useful and everyone involved in the discu
> 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.
Stefan Monnier wrote:
I don't think you wasted your time, but in case you're interested, I've
appended a patch I extracted from that xft branch at some point. I had some
trouble extracting the patch, so there might be some missing bits and some
unrelated extra bits. It surely doesn't compile.
$B40A4L5NA3NDj!*!*!*(B
$B:#$^$G!"[EMAIL PROTECTED],(B
$B9%I>$K$D$-!"A49q3HBg!*!*:#$,%A%c%s%9$G$9!#(B
$B"(%3%3$KEPO?$7$F$k=w$N;R$OK\Ev$G$9!#(B
1.$B5U!{=u4uK>[EMAIL PROTECTED](B
2.$B#S#M4uK>[EMAIL PROTECTED](B
3.$B:#F|[EMAIL PROTECTED](B
4.$BITNQ4uK>[EMAIL PROTECTED](B
[EMAIL PROTECTED]|B
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?
__
Deletion in RMAIL slows after an instance of GNU Emacs has been
running for several days. The time to delete the same 50 messages,
all marked with `d', is double in the five day older instance than in
the newer instance.
You said "deletion", but do you really mean "expunging"?
It
I don't want to rethink the Emacs menu bar now.
It would be a big argument. Let's not have the argument.
People, when someone starts a discussion about a substantial change in
Emacs, please don't argue about the details. If you disagree with the
idea, please just say that this is the wrong time
Stefan Monnier wrote:
Well, my patch does not address the issue mentioned by Dave: it can only
display multilingual chars that are part of the user's locale.
Could it select the locale according to the characters to be displayed?
The locale info is embedded somewhere in the Xt widget inf
Han Boetes wrote:
- if (s-> font == NULL)
+ if (0 && s-> font == NULL)
I suppose this is a mistake.
As the font is hardcoded it should always be found. It may be that in
the case of Xft s->font is NULL always. I agree it looks strange, but I
also use this device sometimes to "comment out
64 matches
Mail list logo
