Re: tooltip-use-echo-area disappeared
Eli Zaretskii writes: > IMHO, we should rather implement the functionality that somehow isn't > there (although I could probably swear I've seen it in action, at > least in NTEmacs circa 21.1) which allows the user to select one of 3 > behaviors: > > (1) tooltips popping up in small windows > (2) tooltip text displayed in the echo area > (3) tooltips completely disabled > > (1) should be (and is) the default on graphical displays, (2) should > be the default on character terminals. Features like tooltips and mouse-face don't work on a character terminal because currently Emacs doesn't know where the mouse is between clicks. A daemon program like X is needed. GPM could possibly do this on a Linux console. I don't find help text in the echo area very distracting and I'm not sure if anyone would find a need to turn it off (option 3), but if someone wants to implement it then tooltip-use-echo-area would have more logic. Nick ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: info.texi
> From: Richard Stallman <[EMAIL PROTECTED]> > Date: Fri, 17 Jun 2005 14:47:13 -0400 > > Would someone please take on the task of updating info.texi? Could you tell what needs updating there, or point to a discussion or a document that says that? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: tooltip-use-echo-area disappeared
Richard Stallman writes: > > I must be confused. If that feature exists, doesn't > tooltip-use-echo-area > > control whether to enable it? > > That is one way, but not the only one. > > What is the interface you recommend, to control this? To display help tooltips in the echo area turn `tooltip-mode' off. To display GUD tooltips in the echo area turn `gud-tooltip-mode' on and set `gud-tooltip-echo-area' to t. This sounds more complicated, but displaying help text in the echo area shouldn't require tooltips. It a text property like mouse-face. Using tooltip-use-echo-area invokes tooltip-show with its delays etc unnecessarily. In contrast displaying GUD tooltip text in the echo area does require the gud-tooltip machinery (like track-mouse) because text properties aren't involved. Nick ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: [Emacs-diffs] Changes to emacs/nt/INSTALL
> Date: Tue, 14 Jun 2005 00:52:06 +0200 > From: Juanma Barranquero <[EMAIL PROTECTED]> > Cc: emacs-devel@gnu.org > > On 6/12/05, Eli Zaretskii <[EMAIL PROTECTED]> wrote: > > > Anyway, I'm still confused. Assuming that I checkout a file with -kb, > > and that file is not recorded as binary in the repository, would > > commands such as "cvs diff", "cvs annotate", etc. work exactly as when > > no -kb was ever used on that file? > > cvs diff, annotate, etc. do work as if the files weren't checked out with -kb. Thanks for the footwork. I've now removed the warning from nt/INSTALL. > > Finally, if "co -kb" indeed has only a local effect, and none of the > > other commands, like ci, diff, up -j, etc. are affected, it sounds > > like Windows users should be told to checkout the whole tree with -kb, > > right? > > Not sure if they should be told to, but at least there is no problem > if they do: I just checked out a -kb tree and built it with MSVC with > no problem whatsoever. I did that as well (but with MinGW). I will run with this setup for a while and see if I encounter any problems. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: [PATCH] [Peter Dyballa] --enable-locallisppath=PATH does not work when PATH contains space
Hi,
Is anyone interested in applying this patch?
Regards,
Jérôme Marant <[EMAIL PROTECTED]> writes:
> Hi,
>
> The following patch seems to fix the problem.
> Please confirm.
>
> Regards,
>
> diff -u -r emacs.orig/ChangeLog emacs/ChangeLog
> --- emacs.orig/ChangeLog 2005-06-07 22:07:31.466158056 +0200
> +++ emacs/ChangeLog 2005-06-07 22:26:48.707230672 +0200
> @@ -1,3 +1,8 @@
> +2005-06-07 Jérôme Marant <[EMAIL PROTECTED]>
> +
> + * Makefile.in (epaths-force): Protect both lisppath
> + and buildlisppath from whitespaces.
> +
> 2005-06-06 Jan Djärv <[EMAIL PROTECTED]>
>
> * configure.in (HAVE_CANCELMENUTRACKING): New test.
> diff -u -r emacs.orig/Makefile.in emacs/Makefile.in
> --- emacs.orig/Makefile.in2004-12-23 22:40:31.0 +0100
> +++ emacs/Makefile.in 2005-06-07 22:19:39.384497648 +0200
> @@ -260,8 +260,8 @@
> x_default_search_path=`echo ${x_default_search_path}`; \
> gamedir=`echo ${gamedir}`; \
> sed < ${srcdir}/src/epaths.in > epaths.h. \
> - -e 's;\(#.*PATH_LOADSEARCH\).*$$;\1 "'$${lisppath}'";'\
> - -e 's;\(#.*PATH_DUMPLOADSEARCH\).*$$;\1 "'$${buildlisppath}'";' \
> + -e 's;\(#.*PATH_LOADSEARCH\).*$$;\1 "'"$${lisppath}"'";' \
> + -e 's;\(#.*PATH_DUMPLOADSEARCH\).*$$;\1 "'"$${buildlisppath}"'";' \
> -e 's;\(#.*PATH_EXEC\).*$$;\1 "${archlibdir}";' \
> -e 's;\(#.*PATH_INFO\).*$$;\1 "${infodir}";' \
> -e 's;\(#.*PATH_DATA\).*$$;\1 "${etcdir}";' \
>
>
> --
> Jérôme Marant
>
>
> ___
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
--
Jérôme Marant
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: tooltip-use-echo-area disappeared
> From: Nick Roberts <[EMAIL PROTECTED]> > Date: Sat, 18 Jun 2005 20:29:45 +1200 > Cc: emacs-devel@gnu.org, [EMAIL PROTECTED] > > Eli Zaretskii writes: > > IMHO, we should rather implement the functionality that somehow isn't > > there (although I could probably swear I've seen it in action, at > > least in NTEmacs circa 21.1) which allows the user to select one of 3 > > behaviors: > > > > (1) tooltips popping up in small windows > > (2) tooltip text displayed in the echo area > > (3) tooltips completely disabled > > > > (1) should be (and is) the default on graphical displays, (2) should > > be the default on character terminals. > > Features like tooltips and mouse-face don't work on a character terminal > because currently Emacs doesn't know where the mouse is between clicks. True for Unix tty's (the MS-DOS port uses a character terminal, and does support tooltips and mouse-face). But I hope that we will have this implemented in the future. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
we love u !
You're looking for unbeatable wireless solutions for your family or office; powerful, family-safe cleaning products for your home; or complete liquid multivitamins and other wellness solutions, chances are, you'll find it?along with GREAT prices?here at the Veriuni Store. PLUS...you can rest easy knowing that you're shopping from a secure Website designed to keep your personal information safe. https://www.moreinfo247.com/9011935/SIM <- FREE!!! https://www.moreinfo247.com/9011935/Department.vstore?id=32 \ $$$ https://www.moreinfo247.com/9011935/Item.vstore?id=23 ---JUST $$$BUY$$$ / $$$ https://www.moreinfo247.com/9011935.123/Item.vstore?id=23 !!and get presents!! SFI? Best regards, Tautvydas Venckus ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: browse-url,el for firefox?
> From: Richard Stallman <[EMAIL PROTECTED]> > Date: Fri, 17 Jun 2005 22:21:09 -0400 > Cc: [EMAIL PROTECTED], emacs-devel@gnu.org > > March 9, Simon Josefsson posted a patch by Steve Youngs which added > firefox support to browse-url.el. Does anyone know the status of this > patch? > > I asked Eli to install it. And Eli just did. Thanks, Steve! ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
debug-on-entry question
Is there an existing function which performs the following? (defun debug-on-entry-at-point () "Perform \\[debug-on-entry] on the function at point." (let ((fn (function-called-at-point))) (if fn (debug-on-entry fn) (message "No function at point" -- "Cut your own wood and it will warm you twice" Regards, Yoni Rabkin Katzenell ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: debug-on-entry question
Yoni Rabkin Katzenell <[EMAIL PROTECTED]> writes: > Is there an existing function which performs the following? > > (defun debug-on-entry-at-point () > "Perform \\[debug-on-entry] on the function at point." > (let ((fn (function-called-at-point))) > (if fn > (debug-on-entry fn) > (message "No function at point" Usually M-x edebug-defun RET is much more useful. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: mouse-1-click-follows-link
... the highlight extends out past the filename and line number ... I've seen partial line ... Today's GNU Emacs CVS snapshot, Sat, 2005 Jun 18 10:02 UTC GNU Emacs 22.0.50.25 (i686-pc-linux-gnu, GTK+ Version 2.6.4) built with `make bootfast' started with emacs/src/emacs -Q -D This is a test case. Visit the emacs/lisp directory and run grep for 'forward-line' *.el -*- mode: grep; default-directory: "/usr/local/src/emacs/lisp/" -*- grep -nH -e forward-line *.el abbrev.el:178: (forward-line 1) abbrev.el:179: (while (progn (forward-line 1) add-log.el:547: (forward-line 1) ... On the first line, the `abbrev.el:178' line, the mouse-face highlighting extends to and including the last `e' of `forward-line'. When activated by putting the mouse cursor over any of the characters for which the the mouse-face highlighting occurs, the darkseagreen2 mouse-face highlighting overrides the tan font-lock-face match. (The mouse-face highlighting is the same as a `highlight' face.) On the first line, when I place point over the `w' of `forward-line' and press mouse-1, that line and buffer appear in another window. On the second line, the `abbrev.el:179' line, the mouse-face highlighting extends only two spaces after the second colon, the colon that follows the line number. On the second line, when I place point over the `v' of `abbrev.el' and press mouse-1, that line and buffer appear in another window. Nothing happens when I place point over the `w' of `forward-line' and press mouse-1. On the third line, the 'add-log.el:547' line, the darkseagreen2 mouse-face highlighting extends to and including the last `e' of `forward-line' when activiated. The line and buffer appear in another window when I place point over the `w' of `forward-line' and press mouse-1. This does not occur when I place point over the `1' of the argument and press mouse-1. -- Robert J. Chassell [EMAIL PROTECTED] GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: debug-on-entry question
Excellent, thank you. -- "Cut your own wood and it will warm you twice" Regards, Yoni Rabkin Katzenell ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]
Stefan Monnier <[EMAIL PROTECTED]> writes:
I've been recently in touch with Ilya Zakharevich (CPerl-mode author)
about Cperl-mode bugs I found in current version from Emacs CVS
trunk (version 5).
>>>
>>> Please post them here.
>
>> I will do. Last time I reported one, you told me perl-mode did not
>> have such a bug :-P
>
> But either you didn't mention or I didn't notice that the bug is also absent
> from the original cperl-mode.el. I'm not really interested in fixing
> cperl-mode bugs, but I do find it important that our local changes to
> cperl-mode don't add new bugs.
Hi,
I'm sorry for being very late on this issue.
After trying to reproduce all cperl-mode bugs from the Debian BTS,
it seems that most of them have been fixed in the CVS trunk, but
one which is a regression from the original CPerl-mode from
Ilya.
Could you please take care of this?
Thanks in advance.
Here is the bug report:
-
The following bug report seems to be fixed in 4.32 but I could
reproduce it with 5.0 from the Emacs CVS.
> From [EMAIL PROTECTED] Fri Nov 23 12:41:46 2001
Received: (at submit) by bugs.debian.org; 23 Nov 2001 18:41:46 +
Return-path: <[EMAIL PROTECTED]>
Received: from salmon.pepperfish.org [195.149.39.195]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 167LGi-0006Fb-00; Fri, 23 Nov 2001 12:41:44 -0600
Received: from localhost ([127.0.0.1])
by salmon.pepperfish.org with esmtp (Exim 3.32 #1 (Debian))
id 167LGY-0001aw-00
for <[EMAIL PROTECTED]>; Fri, 23 Nov 2001 18:41:34 +
Date: Fri, 23 Nov 2001 18:41:34 + (GMT)
From: Vivek <[EMAIL PROTECTED]>
X-X-Sender: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: emacs21-el: keyword highlighting bug in cperl-mode.el
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
Package: emacs21-el
Version: 21.1-2woody
Severity: normal
subroutine names which contain built in keywords/function-names
delimited by _ characters get highlighted incorrectly:
For example, in emacs20-el:
sub foo_print_desc ()
{
}
'foo_print_desc' gets highlighted in font-lock-function-name-face
whereas under emacs21-el the 'print' part gets highlighted in
cperl-nonoverridable-face and the foo_ and _desc parts don't get
any highlighting at all. (This may be a bug in emacs21, of course)
The emacs package is one I compiled from source on woody, but I didn't
make any changes to the source - the sid system here is down at the moment,
but it should be easy to check that the bug exists there too...
-
--
Jérôme Marant
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: [Emacs-diffs] Changes to emacs/nt/INSTALL
> Date: Sat, 18 Jun 2005 12:55:04 +0200 > From: Eli Zaretskii <[EMAIL PROTECTED]> > Cc: emacs-devel@gnu.org > > > > Finally, if "co -kb" indeed has only a local effect, and none of the > > > other commands, like ci, diff, up -j, etc. are affected, it sounds > > > like Windows users should be told to checkout the whole tree with -kb, > > > right? > > > > Not sure if they should be told to, but at least there is no problem > > if they do: I just checked out a -kb tree and built it with MSVC with > > no problem whatsoever. > > I did that as well (but with MinGW). I will run with this setup for a > while and see if I encounter any problems. Found one already: "cvs up" never uses patches with this setup, it always sends the entire new version of the files downstream. That is, if the Emacs tree is checked out with -kb, you will never again see messages like this: P lisp/ChangeLog but always U lisp/ChangeLog This might be a problem with slow connections, but otherwise it's harmless, I guess. A more serious problem is that automatic merges are probably not supported either (although I didn't try). ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: mouse-1-click-follows-link
> ... the highlight extends out past the filename and line number > ... I've seen partial line ... > > Today's GNU Emacs CVS snapshot, Sat, 2005 Jun 18 10:02 UTC > GNU Emacs 22.0.50.25 (i686-pc-linux-gnu, GTK+ Version 2.6.4) > built with `make bootfast' > started with > > emacs/src/emacs -Q -D > > This is a test case. > > Visit the emacs/lisp directory and run grep for 'forward-line' *.el > > On the first line, > [...] > > On the second line, > [...] > > On the third line, > [...] I've fixed three problems in grep.el. The first problem occurred without grep markers and exhibited itself by including the first space or tab of the source line into mouse-over area. The highlighted area was reduced to the separator between line number and the source line. The second problem of highlighting too wide area including the first match was solved by limiting the mouse-over area to file name and line number just like in case of compilation buffers. In the third problem lines on font-lock fontification boundaries were highlighted improperly, because font-lock tried to refontify the previous line where grep markers were already removed. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: TTY Vertical divider face?
> There is something wrong with handling faces in display tables on > character terminals. Putting a character with an added face to the > display table slot results in a different face displayed. > Some faces even cause Emacs to crash. > > I think I have fixed this. I will check it in a day or two from now. Yes, now it works. > Defaulting to mode-line-inactive seems better than defaulting > mode-line, but if it is implemented this way, there should be a > comment to explain that this code doesn't do what you might have > expected it to do. > > However, on principle it seems wrong to use mode-line-inactive > directly. There ought to be a separate named face to control this. > It could default to mode-line-inactive. How about adding this face now? -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Diff mode faces
> The "^#.*" pattern is meant to match "comment lines". These are > part of an extension of the diff format. It has nothing to do with > the -D option which I do not consider as outputting a diff format > and diff-mode does not support this output format in any way. Since it is meant to match comments then maybe we should leave the face for "^#.*" hard-coded in font-lock keywords, but change it to font-lock-comment-face. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: link appearance and soft face properties
> That way, a single (possibly user) definition of the :link > attribute would automatically affect any faces that have that > property. And it would also be easy (including for users) to > selectively apply the :link property to face or mouse-face > or both. > > I think this can be done by making these faces inherit > from a face named `link'. This is an interesting idea, but then for consistency this should be applied to every mouse-over attribute with follow-link property, i.e. not only in compilation and grep buffers, but also in info, dired, gnus... -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Diff mode faces
>> The default diff face used to highlight changed lines on tty >> (magenta/yellow bold italic) makes an indigestible fruit salad. > > In your opinion, perhaps. These faces are there since 5 years ago, > and I don't recall anyone complaining. Maybe people prefer to quietly customize faces in .emacs instead of spending energy arguing? ;-) >> OTOH, the same face has no highlighting under X. This makes >> sense, because changed lines are the primary text in diff files >> that doesn't need special highlighting. > > They need highlighting to stand out against the unchanged lines. > Since most tty's don't have too many colors, they cannot make use of > the technique similar to what we do on X, which is to dim the > context lines by using light-grey colors for them. Yellow foreground works well for context lines. >> I propose instead of highlighting whole lines on tty to use at least >> the same approach as introduced recently for comments on tty to highlight >> only comment delimiters in new face font-lock-comment-delimiter-face. >> Similarly, only diff indicators (the first character of the line) could >> be highlighted in diff buffers on tty. > > I don't think this is a good idea to make such a change. Certainly > not now, before a release. It is face fixing time now. > Haven't we already seen enough trouble from this comment-delimiter > face innovation? Comment-delimiter face was the global change, diff faces are localized to diff mode. > Anyway, the results look IMHO ugly. Partial highlighting of lines > generally looks ugly, and this case is no exception. Do you object against partial highlighting of comments on tty with comment-delimiter too? I tried to be consistent with comments highlighting on tty. > (I could never understand the urge to modify the default colors. If > you dislike the defaults, customize the faces and be done with them.) I have 40 faces customized in .emacs and never wanted to suggest them to anyone. What I want is to propose fixes for badly chosen faces according to more or less objective criteria such as that unimportant faces should not stand out too much, important faces should be easily readable, fg/bg colors should contrast well, etc. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: mouse-1-click-follows-link
> I'm aware that currently there are too large areas for mouse-1 clicking > in grep buffers. > > Would you explain what you mean, and give a test case? > When I try it, mouse-1 only follows the link when I click > on a file name or line number. And the mouse-face only appears > on that part, too. Perhaps this means that you have grep matches highlighting turned off (either your grep doesn't support grep markers or `grep-highlight-matches' is nil). -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Diff mode faces
> I don't find the current Diff mode setup hard to use on a tty. > That is perhaps because the font used for the changed lines > is not hard to read. Then could you explain the reasons for removing comments highlighting on tty with leaving only comment delimiters highlighted. I see no big difference between comments displayed in red and diff lines displayed in bold italic magenta (the latter looks even worse). I don't insist on changing the default diff face on tty, but trying to achieve consistency. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: info.texi
>> Would someone please take on the task of updating info.texi? > > Could you tell what needs updating there, or point to a discussion > or a document that says that? Look at http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00805.html where I hinted at taking care of updating Info manual after finishing all changes? -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Fundamental mode.
I have some questions. Richard Stallman <[EMAIL PROTECTED]> writes: > Lute Kamstra wrote: >> Modes derived from fundamental mode run after-change-major-mode-hook >> twice because fundamental mode runs it unconditionally. I don't understand this. As define-derived-mode is currently defined modes derived from fundamental-mode do not automatically call the fundamental-mode function. [define-derived-mode] (when (eq parent 'fundamental-mode) (setq parent nil)) [...] (,(or parent 'kill-all-local-variables)) > Fundamental mode does not run a mode hook because what it means is "put > settings in their default values". But it needs to run > after-change-major-mode-hook, since the minor modes that should apply to > all buffers apply to these buffers too. Which are "these buffers" that this refers to? A buffer that defaults to fundamental-mode (as created through C-x C-f on some unknown file type or through C-x b) does not run the `fundamental-mode' lisp function. Currently set-buffer-major-mode does not call the major-mode function when the default mode is fundamental-mode. [Fset_buffer_major_mode] if (NILP (function) || EQ (function, Qfundamental_mode)) return Qnil; [...] call0 (function); -- Johan Bockgård ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Diff mode faces
> "Juri" == Juri Linkov <[EMAIL PROTECTED]> writes: Juri> Yellow foreground works well for context lines. Except when you normally read black on white. Is there no way to switch automatically to a proper set of darker colors when the main text is black instead of white? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Diff mode faces
> Cc: Eli Zaretskii <[EMAIL PROTECTED]>, emacs-devel@gnu.org > From: merlyn@stonehenge.com (Randal L. Schwartz) > Date: 18 Jun 2005 08:27:12 -0700 > > Is there no way to switch automatically to a proper set of darker > colors when the main text is black instead of white? Yes, it's called background-mode. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Why aren't paragraph-s\(tart\|eparate\) buffer local by default?
Hi, Emacs! Why aren't paragraph-s\(tart\|eparate\) buffer local? There doesn't seem to be any call for having global values for them since so many major modes (amongst them C Mode, Lisp mode, Texinfo mode) give these variables mode specific values. The reason I ask is that a CC Mode user erroneously called (c-set-style) in a buffer that wasn't a CC Mode buffer. This set these two paragraph variables to style values. Unfortunately, the CC Mode initialisation hadn't been done for the buffer. In particular, the the two paragraph variables hadn't been made buffer local. So the global values got overwritten. May I suggest that paragraph-s\(tart\|eparate\) be made buffer local by default? -- Alan Mackenzie (Munich, Germany) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
lists.texi
I recommend the following changes to lists.texi and can install if
desired. In as far as spelling issues are concerned, `vs' seems to be
the standard abbreviation of `versus' and `indices' seems to be the plural
form of `index' consistently used in the Elisp manual.
In as far as the return value of `ring-insert-at-beginning' is
concerned, it definitely is _not_ OBJECT as currently documented in
the Elips manual. The return value is the _new_ length of the ring,
but this seems to be by accident, rather than by design. We could
either document the actual return value, change
`ring-insert-at-beginning' to really return OBJECT (does not seem
terribly useful to me) or say that the return value is not
significant. The patch below does the latter.
===File ~/lists.texi-diff===
*** lists.texi 17 Jun 2005 09:08:29 -0500 1.52
--- lists.texi 18 Jun 2005 16:58:45 -0500
***
*** 715,721
primitives @code{setcar} and @code{setcdr}. We call these ``destructive''
operations because they change existing list structure.
! @cindex CL [EMAIL PROTECTED] vrs @code{setcar}
@quotation
@findex rplaca
@findex rplacd
--- 715,721
primitives @code{setcar} and @code{setcdr}. We call these ``destructive''
operations because they change existing list structure.
! @cindex CL [EMAIL PROTECTED] vs @code{setcar}
@quotation
@findex rplaca
@findex rplacd
***
*** 1691,1697
@end defun
@defun ring-p object
! This returns @code{t} if @var{object} is a ring.
@end defun
@defun ring-size ring
--- 1691,1697
@end defun
@defun ring-p object
! This returns @code{t} if @var{object} is a ring, @code{nil} otherwise.
@end defun
@defun ring-size ring
***
*** 1705,1725
@defun ring-elements ring
This returns a list of the objects in @var{ring}, in no particular
! order.
@end defun
@defun ring-copy ring
This returns a new ring which is a copy of @var{ring}.
! The new ring contains the same objects as @var{ring}.
@end defun
@defun ring-empty-p ring
! This returns @code{t} if @var{ring} is empty.
@end defun
! The newest element in the ring always has index 0. Higher indexes
! correspond to older elements. Index @minus{}1 corresponds to the
! oldest element, @minus{}2 to the next-oldest, and so forth.
@defun ring-ref ring index
This returns the object in @var{ring} found at index @var{index}.
--- 1705,1728
@defun ring-elements ring
This returns a list of the objects in @var{ring}, in no particular
! order. The length of that list is always the ring size. If the ring
! length is less than the ring size, the entries of the list that do not
! correspond to ring elements are @code{nil}.
@end defun
@defun ring-copy ring
This returns a new ring which is a copy of @var{ring}.
! The new ring contains the same (@code{eq}) objects as @var{ring}.
@end defun
@defun ring-empty-p ring
! This returns @code{t} if @var{ring} is empty, @code{nil} otherwise.
@end defun
! The newest element in the ring always has index 0. Higher indices
! correspond to older elements. Indices are computed modulo the ring
! length. Index @minus{}1 corresponds to the oldest element, @minus{}2
! to the next-oldest, and so forth.
@defun ring-ref ring index
This returns the object in @var{ring} found at index @var{index}.
***
*** 1744,1750
@defun ring-insert-at-beginning ring object
This inserts @var{object} into @var{ring}, treating it as the oldest
! element, and returns @var{object}.
If the ring is full, this function removes the newest element to make
room for the inserted element.
--- 1747,1753
@defun ring-insert-at-beginning ring object
This inserts @var{object} into @var{ring}, treating it as the oldest
! element. The return value is not significant.
If the ring is full, this function removes the newest element to make
room for the inserted element.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
How is highlighting done in show-paren-mode?
This concerns the one remaining problem with the ClearType patch I'm trying to clean up and submit. I hope I don't seem too insistent, but I've been trying to get a hint for about a week. David Abrahams <[EMAIL PROTECTED]> writes: > David Abrahams <[EMAIL PROTECTED]> writes: > >> David Abrahams <[EMAIL PROTECTED]> writes: >> >>> I am seeing some minor artifacts that I don't know what to do about. >>> For example, when I backspace over these parens starting from the end >>> of the line, I end up with some small remnants of the background color >>> emacs uses to highlight matching parens for me. When all the close >>> parens are gone there's a thin vertical cyan line at the right edge of >>> each open paren. Any clues where to attack that? >>> >>> () >> >> Even some vague hints would be a big help here. This is the only >> remaining detail as far as I can tell. > > I have one more piece of information for anyone who can think about > this problem for a moment: When I do `C-s x', the first instance of x > (or whatever character) that is found gets highlighted in purple and > looks right. The next instance of x on that line gets highlighted in > cyan and looks right. The rest of the instances of x on that line get > highlighted in cyan, and the highlighting extends one pixel too far to > the left. On each line thereafter, the first instance of x is > highlighted in cyan and looks right, and the rest of the instances on > that line are highlighted in cyan and look wrong (i.e. the > highlighting extends one pixel too far to the left). Can someone please give me some hint as to which entry points to breakpoint in order to observe these calculations and/or drawing in action? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: lists.texi
The following patch to ring.el is equivalent to the one I sent earlier, but probably slightly better: ===File ~/ring.el-diff-b *** ring.el 02 Sep 2003 07:41:57 -0500 1.18 --- ring.el 18 Jun 2005 18:53:24 -0500 *** *** 155,162 (aref vec (ring-index index hd ln (length vec)) (defun ring-elements (ring) ! "Return a list of the elements of RING." ! (mapcar #'identity (cddr ring))) ;;; provide ourself: --- 155,163 (aref vec (ring-index index hd ln (length vec)) (defun ring-elements (ring) ! "Return a list of the elements of RING, in no particular order." ! (let ((lst (delq nil (mapcar #'identity (cddr ring) ! (nconc lst (make-list (- (ring-length ring) (length lst)) nil ;;; provide ourself: ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: lists.texi
>From my previous message:
@defun ring-elements ring
This returns a list of the objects in @var{ring}, in no particular
! order. The length of that list is always the ring size. If the ring
! length is less than the ring size, the entries of the list that do not
! correspond to ring elements are @code{nil}.
@end defun
Maybe I am trying to document a bug here. Maybe it is better not to
add these two sentences and instead make `ring-elements' do what the
first sentence above, and its docstring, say it does. `ring-elements'
is not used in the Emacs sources, so the change is not going to break
anything and all it does is make the function work as documented.
I can install if desired.
===File ~/ring.el-diff==
*** ring.el 02 Sep 2003 07:41:57 -0500 1.18
--- ring.el 18 Jun 2005 18:45:44 -0500
***
*** 155,162
(aref vec (ring-index index hd ln (length vec))
(defun ring-elements (ring)
! "Return a list of the elements of RING."
! (mapcar #'identity (cddr ring)))
;;; provide ourself:
--- 155,164
(aref vec (ring-index index hd ln (length vec))
(defun ring-elements (ring)
! "Return a list of the elements of RING, in no particular order."
! (let (lst)
! (setq lst (delq nil (mapcar #'identity (cddr ring
! (nconc lst (make-list (- (ring-length ring) (length lst)) nil
;;; provide ourself:
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Fundamental mode.
[EMAIL PROTECTED] (Johan Bockgård) writes: >>> Modes derived from fundamental mode run after-change-major-mode-hook >>> twice because fundamental mode runs it unconditionally. > > I don't understand this. As define-derived-mode is currently defined modes > derived from fundamental-mode do not automatically call the fundamental-mode > function. > > [define-derived-mode] > > (when (eq parent 'fundamental-mode) (setq parent nil)) > [...] > (,(or parent 'kill-all-local-variables)) True. But it's possible to define a derived mode manually, without using the define-derived-mode macro. Lute. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: lists.texi
Actually, if we have to do all of that to get the correct return value, we could quite as well use the following function, which does get the order correct: (defun ring-elements (ring) "Return a list of the elements of RING in order, newest first." (let (lst) (dotimes (var (ring-length ring)) (push (ring-ref ring var) lst)) (nreverse lst))) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: tooltip-use-echo-area disappeared
To display help tooltips in the echo area turn `tooltip-mode' off. To display GUD tooltips in the echo area turn `gud-tooltip-mode' on and set `gud-tooltip-echo-area' to t. This sounds more complicated, Yes, it is not clean. but displaying help text in the echo area shouldn't require tooltips. Maybe it should not, but that's a different question. Just because two underlying mechanisms are involved is no reason why it needs to have two different variables to control it. Let's stick with the simple variable that puts all tooltips in the echo area. If you want only non-GUD tooltips (and those in the echo area), then set tooltip-use-echo-area to t, and don't enable GUD tooltips. What could be cleaner than that? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: link appearance and soft face properties
> I think this can be done by making these faces inherit > from a face named `link'. This is an interesting idea, but then for consistency this should be applied to every mouse-over attribute with follow-link property, i.e. not only in compilation and grep buffers, but also in info, dired, gnus... Yes, if we make such a face, it ought to be used wherever appropriate. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: mouse-1-click-follows-link
Perhaps this means that you have grep matches highlighting turned off (either your grep doesn't support grep markers or `grep-highlight-matches' is nil). It is nil for me. So that explains why I don't see the problem. It also gives a guide for how to deal with this issue: change grep mode to do what's intended. Did your latest changes do that? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: info.texi
> Would someone please take on the task of updating info.texi? Could you tell what needs updating there, or point to a discussion or a document that says that? Figuring out what, if anything, needs updating is part of this job. I do not know. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Diff mode faces
Then could you explain the reasons for removing comments highlighting on tty with leaving only comment delimiters highlighted. I explained them a few weeks ago. I see no big difference between comments displayed in red and diff lines displayed in bold italic magenta (the latter looks even worse). I don't think the issues are similar. I don't insist on changing the default diff face on tty, but trying to achieve consistency. Consistency doesn't apply for two issues that are quite different. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: TTY Vertical divider face?
> However, on principle it seems wrong to use mode-line-inactive > directly. There ought to be a separate named face to control this. > It could default to mode-line-inactive. How about adding this face now? Please do. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Matches for multiline regexps
I will take a look at it, but first a decision has to be made on how we treat overlapping matches. When not displaying context, it should display each line that contains any part of one or more matches. It should not display any line more than once. When context lines are specified, it is less clear. One idea is to display each group of lines that contains a match, plus context around it. When there are multiple matches within one line, that line should only appear once. However, if a line is partly matched by more than one multiline match, it is not clear what the right thing is, do I'd say don't spend much time on it. I propose to have occur treat overlapping matches the same as the other Emacs search functions do, which is also the way occur behaved before Emacs 22. That would be a step backwards. Please do not make that change. `M-x occur RET 11 C-q C-j 11 RET' will find two matches, one on line 1 and one on line 3. Those are the only matches that `C-M-s 11 C-q C-j 11 RET C-s C-s C-s...' at beginning of buffer is going to find. These commands do different jobs; the right thing for one is not the right thing for the other. Consistency is not the right goal here. To be consistent with the way it currently treats multiline overlapping matches, occur should show the line enough times to highlight all overlapping matches without overlap in their highlighting. For example, with a buffer containing only "111", with the current occur, after `M-x occur RET 11 RET", the highlighting only finds a match at position 1, not at position 2. Ideally it should show the line once, but highlight all matches in that line. I am starting to wonder whether the change from the Emacs 21 behavior in the multiline case was really intentional. The code appears to be designed for uniline matches. However, the Emacs 21 behavior you described is not desirable behavior. It was merely how things happened to be. Returning to that should not be the goal. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
emacs-devel: Turning off line wrapping
Those of you who use the web archive for emacs-devel, what would you think of turning off line-wrapping on the web archive? This would avoid confusion when an example includes a long line; however, line wrapping might be convenient some of the time. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: tooltip-use-echo-area disappeared
> Let's stick with the simple variable that puts all tooltips > in the echo area. OK. I've installed a change so that its no longer obsolete. > If you want only non-GUD tooltips (and those in the echo area), then > set tooltip-use-echo-area to t, and don't enable GUD tooltips. > What could be cleaner than that? I've tried to say but clearly not communicated it. I think I've done what people have asked for. Lets leave it at that. Nick ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
