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 th
I have the problem that preactivated advice no longer gets
preactivated. However, the same problem occurs now with a current
compilation of Emacs-21.3! So I suspect that it might be
compiler-related (gcc-4.0). It worked at one point of time in the
past.
Whatever. In the search for the problem
I like to use emacs with black background. I use some png files for my
gnus smiley. The problem is that the transparent portions of the png file
are rendered white (instead of black). Is this a bug? any workarounds?
--
Rajsekar Manokaran
IIT Madras
__
David Kastrup <[EMAIL PROTECTED]> writes:
> I have the problem that preactivated advice no longer gets
> preactivated. However, the same problem occurs now with a current
> compilation of Emacs-21.3! So I suspect that it might be
> compiler-related (gcc-4.0). It worked at one point of time in t
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 [^)] because i lose the advantage of
\W (which works based
> 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
>
> "R" == Rajsekar <[EMAIL PROTECTED]> writes:
R> I like to use emacs with black background. I use some png files for my
R> gnus smiley. The problem is that the transparent portions of the png file
R> are rendered white (instead of black). Is this a bug? any workarounds?
If you use GIMP se
In any case, here is the new improved patch. This new patch should also
enable non-ASCII in Motif menus, although I haven't actually checked it.
>>
>>> I think you can have that already as long as your menu strings are in
>>> your
>>> locale. It works for me :-)
>>
>> Actually, I doub
[EMAIL PROTECTED] (Gian Uberto Lauri) writes:
>> "R" == Rajsekar <[EMAIL PROTECTED]> writes:
>
> R> I like to use emacs with black background. I use some png files for my
> R> gnus smiley. The problem is that the transparent portions of the png file
> R> are rendered white (instead of black
[EMAIL PROTECTED] (Kim F. Storm) writes:
> To fix this, I propose adding the following command to simple.el and
> binding it to C-a:
>
>
> (defun move-beginning-of-line (arg)
...
The version in the current CVS causes C-a to go to the beginning of
the *screen* line instead of the beginning of the
> This looks so wrong that I want somebody with more of a clue to take a
> look at it: ad-make-mapped-call is called in two branches of a cond,
> and the order of its first two arguments is interchanged in those two
> calls!
I think the patch below is the right one,
Stefan
--- orig/lis
Istvan Marko <[EMAIL PROTECTED]> writes:
> The version in the current CVS causes C-a to go to the beginning of
> the *screen* line instead of the beginning of the buffer line.
Thanks for noticing this. I have installed a fix.
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
__
Here is an updated patch that incorporates the feedback of Stefan and
Richard.
I also changed three other things:
I removed the (eval-when-compile (require 'cl)) as that is not
needed.
I changed define-generic-mode so that the name of the mode command
need not be quoted (while retaining
- Original Message -
From: "Drew Adams" <[EMAIL PROTECTED]>
I do not use the toolbar very often, but I think it is good to have it as
easy to understand as possible. I agree with much of your suggestions, but
there are some things I would like a bit different:
> - Magnifying glass for
Lute Kamstra <[EMAIL PROTECTED]> writes:
> I changed define-generic-mode so that the name of the mode command
> need not be quoted (while retaining backward compatibility). This
> makes define-generic-mode more like other defining forms. I updated
> the docstring of define-generic-mode t
- Original Message -
From: "Jan D." <[EMAIL PROTECTED]>
> >You can (perhaps) see another version of this problem if you slowly move
the
> >mouse over a link. The tooltip pops up and immediately disappears again.
> >
> >That I am seeing this problem may depend on both that I have a slow pc
- Original Message -
From: "Jan D." <[EMAIL PROTECTED]>
> The tool bar icons follow the Gnome stock items
> (http://www.gtk.org/api/2.6/gtk/gtk-Stock-Items.html). I think Emacs
> should follow them as close as it can, but we can of course change if
> there is a good reason.
Thanks for t
I won't belabor this, but I do have a few responses. Your reply is, in
essence, "GNMMME" (shades of Allen Ginsberg w/ "Oo"). If GNOME's
choices are not always the best, we will nevertheless live with it.
> - Folder (for "file): This is _not_ good. A folder icon is used
>ubiqui
I won't belabor this, but I do have a few responses. Your reply is, in
essence, "GNMMME" (shades of Allen Ginsberg w/ "Oo"). If
GNOME's
choices are not always the best, we will nevertheless live with it.
No,they are not always the best, far from it. But there is a point in
aligning with
Gnome stock left/right/up.
I can actually not find that on the page above. That is I can find
GTK_STOCK_GO_UP, but there is as far as I can see nothing like
GTK_STOCK_GO_PREVIOUS (or LEFT). It seems like they forgot to
distinguish
between GTK_STOCK_GO_BACK (ie a chronological move) and ...PREVIOUS
You can (perhaps) see another version of this problem if you slowly
move
the
mouse over a link. The tooltip pops up and immediately disappears
again.
That I am seeing this problem may depend on both that I have a slow
pc
and
that I am using w32. I believe it is a thread issue. Mouse movements
- Original Message -
From: "Jan D." <[EMAIL PROTECTED]>
> No, previous and next are missing.
..
> > I think this is pretty bad if you need both. On the page above they
> > have
> > actually used filled arrows for structural moves (see the top). Is that
> > consistent with their suggestion
- Original Message -
From: "Jan D." <[EMAIL PROTECTED]>
> > Thanks. Then I must say I do not understand how this works. As far as
> > I see
> > for this to work reliably tooltip.el:tooltip-start-delayed-tip must
> > record
> > the mouse position (because if the mouse has moved when the ti
They really don't say mush on the issue, the guidelines are at
http://developer.gnome.org/projects/gup/hig/2.0/. Some applications,
like gthumb, uses a filled arrow that points into a "file"-like
background, see attachement.
Funny enough this was one of the idea I had. It kind of make sense to
me
"Drew Adams" <[EMAIL PROTECTED]> writes:
[...]
> The point of stock items is that themes may change them and
> applications that uses stock items change appearence
> automatically.
>
> I think that Emacs could do better than what is there now,
I agree with that assessment, but I thin
I have seen
2005-03-16 Stefan Monnier <[EMAIL PROTECTED]>
* help.el (describe-mode): Allow a :minor-mode-function property to
specify a different minor mode toggle function than the variable.
* simple.el (auto-fill-function):
* subr.el (add-minor-mode): Use it.
> * help.el (describe-mode): Allow a :minor-mode-function property to
> specify a different minor mode toggle function than the variable.
> * simple.el (auto-fill-function):
> * subr.el (add-minor-mode): Use it.
> I have my doubts that the resulting flexibility is really in
When discussing the icons in the Emacs toolbar we discovered that the GTK
stock icon items (http://www.gtk.org/api/2.6/gtk/gtk-Stock-Items.html) does
not really distunguish between "chronological" and "structural" links.
With a chronological link we mean something like for example the left arrow
i
- Original Message -
From: "Lennart Borgman" <[EMAIL PROTECTED]>
> Yes, that is how it works on w32 too. I meant something a little bit
> different. I think the timer for the tooltip popup should be canceled (and
> maybe started again) every time the mouse is moved. Indeed I believe that
OPEN is what the action is, not FILE. Sometimes (without file dialog or
the
Motif dialog), you can actually open directories with open. So FILE
does not apply.
Yes, despite the name, `find-file-existing' can also open directories. I
still think the folder icon is misleading here.
In this case, I'd prefer to have
(defcustom generic-use-find-file-hook t
! "*If non-nil, add a hook to call `default-generic-mode'
automatically.
The main rationale is that this will give a working cross reference
link in the help window.
That is ok.
What is buffer-file-coding-system set to in that buffer?
nil. It is a unibyte buffer.
How
do you insert the compressed data into it?
With a Lisp program that copies text from another buffer and then does
base64-decode-region.
In any case, here is the new improved patch. This new patch should also
enable non-ASCII in Motif menus, although I haven't actually checked it.
I'll be happy to keep this patch for post-21.4, but if people feel like this
is important, I can install it as well.
The failure to sup
> What is buffer-file-coding-system set to in that buffer?
> nil. It is a unibyte buffer.
> How
> do you insert the compressed data into it?
> With a Lisp program that copies text from another buffer and then does
> base64-decod
C-h w ignore RET
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
> What do people think? Here's the code to do it.
> (But I wonder, was there some reason why Miles implemented
> this feature using a file name handler instead of with a major mode?)
There was an explicit reason, but I don't remember what it is anymore;
perhaps some google searching would reveal
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
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 10:33:59 -0800, Drew Adams wrote:
> I said I wouldn't belabor this, but I did run on a bit. I'll not follow up -
> do whatever you like. Oo.
Man, you start out implying you don't want to start an argument and
yet fill your message up with this sort of crap. You clearly don
> > 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 Tue, 15 Mar 2005 06:14:13 -0500 (EST), Chong Yidong
<[EMAIL PROTECTED]> wrote:
> Some time ago, I proposed providing a magic space for ordinary isearch.
> The response was generally favorable, but my papers were not in order, so
> the patch could not be applied. My copyright assignment is settl
> The failure to support non-ASCII characters in menus is a bug, in my
> opinion. If you've fixed it, and your fix works well, let's install
> it now.
Installed,
Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/ma
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
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
> 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
Would people please turn their attention to debugging the problems
listed in FOR-RELEASE?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
>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
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?
__
OPEN is what the action is, not FILE. Sometimes (without file
dialog or
the
Motif dialog), you can actually open directories with open. So
FILE
does not apply.
Yes, despite the name, `find-file-existing' can also open directories.
I
still think the folder icon is misleading here.
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
"Jan D." <[EMAIL PROTECTED]> writes:
>> OPEN is what the action is, not FILE. Sometimes (without file
>> dialog or
>> the
>> Motif dialog), you can actually open directories with open. So
>> FILE
>> does not apply.
Please, Jan, when replying to Outlook users, use the WYf command from
51 matches
Mail list logo
