Re: Customizing faces with `defcustom'
However, the associated tags are not assgined a face like `custom-variable-tag'. I don't understand that sentence at all, sorry. Consider, for example, the customization buffer for `matching': (1) `match' stands out in `custom-face-tag-face', by default scaled by 1.2 and bold. (2) `list-matching-lines-default-context-lines' is highlighted in `custom-variable-tag-face', by default scaled by 1.2 and bold. Then come the options (3) `list-matching-lines-face' and `list-matching-lines-buffer-name-face' both in default face. This makes it more difficult to spot the latter and makes you believe that these options are part of the text explaining `list-matching-lines-default-context-lines'. Shouldn't it be possible to give _all_ tags of custom - variables (including face-valued ones), faces, groups - a similar appearance with respect to height, pitch, and the like. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: jit-lock doesn't honor font-lock-lines-before
(2) Modify `jit-lock-after-change' appropriately by, for example, inserting (forward-line (- font-lock-lines-before)) before (setq start (line-beginning-position)) That seems like the right fix. Why do you think it isn't? Because this means that every time I insert one character, redisplay would refontify `font-lock-lines-before' in addition to the current line. I suppose that the impact of this variable has not been noticed so far because jit-lock doesn't consider it. On the other hand, jit-lock wouldn't be able to handle this variable in the same way as font-lock does: font-lock refontifies immediately in the after-change hook. jit-lock's after-change hook would only reset the fontified property to nil. Whether and when these lines are refontified would be _also_ decided by the redisplay engine. And the latter doesn't know about `font-lock-lines-before'. For example, editing the first line in a window would not include the line before in refontification. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
Emilio Lopes [EMAIL PROTECTED] writes: I think something like isearch's C-w and friends extended to other commands which read from the minibuffer would be useful. I would like that. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Beginingless paragraphs
Hi, Emacs!
What is a paragraph in Emacs? I can't find a @dfn{paragraph} anywhere
in the Emacs/Elisp manuals. I don't have the full CVS of Lispref, but
grepping in the released version didn't produce any hits.
There are definitions of the two paragraph regexps in the Elisp Manual:
- Variable: paragraph-separate
This is the regular expression for recognizing the beginning of a
line that separates paragraphs. (If you change this, you may have
to change `paragraph-start' also.) The default value is
`[ \t\f]*$', which matches a line that consists entirely of
spaces, tabs, and form feeds (after its left margin).
- Variable: paragraph-start
This is the regular expression for recognizing the beginning of a
line that starts _or_ separates paragraphs. The default value is
`[ \t\n\f]', which matches a line starting with a space, tab,
newline, or form feed (after its left margin).
. Then there is this evasive definition of paragraph in the Emacs
manual (taken from text.texi V1.57):
The precise definition of a paragraph boundary is controlled by the
variables `paragraph-separate' and `paragraph-start'. The
value of `paragraph-start' is a regexp that should match any line
that either starts or separates paragraphs. The value of
`paragraph-separate' is another regexp that should match only lines
that separate paragraphs without being part of any paragraph (for
example, blank lines). Lines that start a new paragraph and are
contained in it must match only `paragraph-start', not
`paragraph-separate'. Each regular expression must match at the
left margin. For example, in Fundamental mode, `paragraph-start'
is `\f\\|[ \t]*$', and `paragraph-separate' is
`[ \t\f]*$'.
I don't really want to know what _controls_ the definition of a paragraph
boundary. I want that definition itself without having to resort to a
kind of contorted reverse logic to get to it. And believe me, working
through that logic is hard.
Doing that gives this: A paragraph ends just before a line which matches
paragraph-start (?or at EOB). A paragraph starts at a line which matches
p-start, but _doesn't_ match p-separate (?or at BOB).
What happens if these two regexps are the same (as they are by default in
Text mode)? There cannot be any lines which start paragraphs, only lines
which separate them. Beginningless paragraphs! This is absurd.
Incidentally, what happens when a line matches p-start but not
p-separate? Shouldn't ever happen, but it surely will.
At this point, the Elisp programmer, reduced to tears, starts reading the
source code to find out what a paragraph really is. Non-programmers (and
there will be a fair number of them using Text mode) need to start
experimenting with regexps.
SURELY there should be a proper @dfn{paragraph} in the Emacs manual? I'm
too confused to write one myself at the moment.
Like a circle in a spiral,
Like a wheel within a wheel.
Never starting, only ending
On an ever-spinning reel.
As the images unwind
Like the paragraphs you find
In the buffers of your mind.
--
Alan Mackenzie (Munich, Germany)
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: texinfo-fill-workaround.el -- no break after @: when filling
I'd point out that fill-nobreak-predicate is a hook in recent versions of Emacs I notice the manual still only says nil or a function. Perhaps something like the following (new text for ease of reading, diff below), Your patch looks good. Would someone please install it? But it suggests that maybe we should also rename the variable to fill-nobreak-predicates. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: literal newlines in @result{} strings
which has the `\n' instead of a literal newline. i'd like to change the former two to resemble the latter. any objections? any reason to go in the opposite direction? I agree it is better to make it uniform. Each alternative has an advantage, so I am not sure which is best. It would be bad to have a long discussion about which, since the question isn't worth spending so much time. So I guess you can go ahead and change it. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: announcing defaults when reading from minibuffer
Can you please clarify the location of the colon? Your update to the manual says this: + Enter value (default 42): However, C-x b (switch-to-buffer) for example shows this: Switch to buffer: (default foo) You are right. Thanks. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: grep-use-null-device
`compilation-start' needs to check if the process is running before calling `process-send-eof': Please install your patch--and thanks. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Beginingless paragraphs
Hi Alan, Alan Mackenzie writes: What is a paragraph in Emacs? The info node that you quoted is (info (emacs)Paragraphs) I think? It has this text (this is a rather old CVS version, so it may be different by now): [...] Blank lines and text-formatter command lines separate paragraphs and are not considered part of any paragraph. [...] [...] In major modes for programs, paragraphs begin and end only at blank lines. This makes the paragraph commands continue to be useful even though there are no paragraphs per se. [...] Technically the term paragraph is defined not by some global definition but by the individual modes via the variables that you have cited. So every mode can have it's own idea of what a paragraph is. E.g. the buffer that I'm currently writing in to compose this message, is in GNUS' Message mode. It tries to accomodate the marker that separates the headers from the message body and also attribution lines like the above Alan Mackenzie writes:. benny ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: jit-lock doesn't honor font-lock-lines-before
Stefan Monnier wrote: The customizable variable `font-lock-lines-before' is not honored by jit-lock mode. I know what that means in therms of what the code does, but I'm wondering in which circumstance it makes a visible difference to the end user. Do you have a test case? Suppose not: Wouldn't that mean `font-lock-lines-before' is useless? It's not very difficult to contrive test cases for this. By default `font-lock-multiline' is nil. `font-lock-fontify-anchored-keywords' won't alter it - the appropriate lines have been commented out. Write an arbitrary multiline pattern. Now font-lock won't give it the `font-lock-multiline' text property and jit-lock not necessarily reset its `fontified' text property after a change. `font-lock-after-change', on the other hand, may refontify it provided `font-lock-lines-before' is large enough. You might argue now that the user should customize `font-lock-multiline' appropriately and major modes set it as necessary. (By the way, is the value `undecided' useful - I don't see tests like `(eq font-lock-multiline t)' or `(eq font-lock-multiline 'undecided)' anywhere?) Let's therefore suppose `font-lock-multiline' is t in the following example: I display a buffer in a new window, and jump immediately to a line within a multiline pattern. More precisely, the first line of the pattern is before window-start and the last line of the pattern appears within the window. In this case, the pattern might not be fontified properly - fontification triggered by redisplay does not fontify text before window-start. Modifying the first line of the window will cause redisplay to consider only that line (and possibly subsequent ones). The pattern will not be fontified properly unless I scroll to its beginning. Plain font-lock, on the other hand, could handle this case when `font-lock-lines-before' is set appropriately. However, I believe that `font-lock-lines-before' is a brute force approach to handle such cases and could remarkably slow down editing if it were honored by jit-lock mode. Multiline patterns are too delicate and should be treated in a completely different way. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
Emilio Lopes [EMAIL PROTECTED] writes: But the problem remains: too often I have to first mark a word or symbol, copy the region, start a command (`grep', `occur', `query-replace', whatever), paste it, press enter. That's three keystrokes too many. How about making the thing at point be accessible via M-n? Kai ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: literal newlines in @result{} strings
for `thing-at-point' i see:
@result{} Gentlemen may cry ``Peace! Peace!,''\n
which has the `\n' instead of a literal newline. i'd like to change the
former two to resemble the latter. any objections? any reason to go in
the opposite direction?
Neither of these functions returns `\n'. And `\n' is not an
alternative for a literal newline. For differences, please see
examples of newlines in the documentation of `print-escape-newlines'
in (info (elisp)Output Variables). It demonstrates that the
difference whether a function returns or prints a literal newline or
`\n' is preserved in the Emacs Lisp Reference Manual.
Since `thing-at-point' actually returns a literal newline instead of
`\n', it would be more correct to replace `\n' with a literal newline
in its example.
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
should doc on case-fold-search mention that there are other such vars also?
What about mentioning, in the Emacs manual section on `case-fold-search', that there are also other, similar options that control case sensitivity in different contexts. We could suggest, for instance, that the user do `apropos-variable' on case-fold-search to find them all. A recent question on help-gnu-emacs brought this to mind. The user was unaware of `tags-case-fold-search', and couldn't figure out how to use `case-fold-search' to make tags search case-sensitive. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: question about GDB mode in emacs
[I've moved this thread to emacs-devel as it concerns Emacs in CVS] Hi all: I am using the gdb-mode in emacs and feel it is terrific nice compared with visual studio from microsoft. But I have one question about the gud-ui frame. To be more specificly, the problem is the locals of xxx window(name of the debugged program). When my debugger is in the main program, this mini-window can display all of the local variables of the main program correctly. However, if I step into other function or other class, it cannot display the local variables of that function or class(the window displays no locals). Is there anyway to ask this window dynamicly display all of the local variables(if it can only display the local variables of main program, it will be bad)? Thanks a lot for your response. The locals buffer should work for all procedures/functions. The only reason that I can think of for it displaying No locals. is that your particular function has no locals! If thats not the case, can you please post a simple example where it fails to emacs-devel@gnu.org Nick ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: jit-lock doesn't honor font-lock-lines-before
Because this means that every time I insert one character, redisplay would refontify `font-lock-lines-before' in addition to the current line. Would that be bad? Whether and when these lines are refontified would be _also_ decided by the redisplay engine. And the latter doesn't know about `font-lock-lines-before'. For example, editing the first line in a window would not include the line before in refontification. This is a good point. However, it can probably be fixed by a change in the fontification function--when it is called, it should extend the starting point for refontification upward by the specified number of lines. (This might be the only fix needed.) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: writing an elisp interface to a c library
For the archives, src/xfaces.c is a good example to look at after reading the relevant sections of the elisp manual. I browsed through all of src; of all of the .c files, xfaces.c deals with an api most similar to what I asked about. -JimC -- James H. Cloos, Jr. [EMAIL PROTECTED] ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: patch for woman (woman-topic-at-point)
OTOH at a first glance *I* don't expect a control structures such as `when' to return any useful value when the conditional clause fails. But maybe I've been doing too much Scheme these days. (no, surely not You're just suffering from one of the many places where Scheme is too imperative. For once, Elisp is more functional in this case. one-armed `if' when the condition is false has unspecified value. that's not too imperative, just underspecified (for some tastes). see info node: (r5rs) Conditionals. Since it's unspecified, you can't rely on its value, so you end up using that form in an imperative style. I.e. too imperative. Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: jit-lock doesn't honor font-lock-lines-before
The customizable variable `font-lock-lines-before' is not honored by jit-lock mode. I know what that means in therms of what the code does, but I'm wondering in which circumstance it makes a visible difference to the end user. Do you have a test case? Suppose not: Wouldn't that mean `font-lock-lines-before' is useless? Not at all. font-lock-lines-before has not been introduced to force refontification of the previous lines but because the N previous lines are needed as context in order to properly refontify the current line. Now the code does in fact refontify the previous lines, but it is a side-effect rather than one of the original goals. It's not very difficult to contrive test cases for this. By default `font-lock-multiline' is nil. `font-lock-fontify-anchored-keywords' won't alter it - the appropriate lines have been commented out. Write an arbitrary multiline pattern. Now font-lock won't give it the `font-lock-multiline' text property and jit-lock not necessarily reset its `fontified' text property after a change. `font-lock-after-change', on the other hand, may refontify it provided `font-lock-lines-before' is large enough. Please show me a test case. However, I believe that `font-lock-lines-before' is a brute force approach to handle such cases and could remarkably slow down editing if it were honored by jit-lock mode. Multiline patterns are too delicate and should be treated in a completely different way. Indeed, but nobody has put the work needed to handle them properly. font-lock-multiline is one hack, font-lock-lines-before is another, font-lock-fontification-face-function is yet another. Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: grep-use-null-device
With this change, when grep finishes too quickly (for example, after searching in a nonexistent file), `process-send-eof' fails with the following error: Debugger entered--Lisp error: (error Process grep not running) process-send-eof(#process grep) compilation-start(grep -inH -e search file grep-mode nil nil) grep(grep -inH -e search file) call-interactively(grep) execute-extended-command(nil) call-interactively(execute-extended-command) `compilation-start' needs to check if the process is running before calling `process-send-eof': That's odd. AFAICT no blobking operation takes place between the start-process and the process-send-eof, so the process-status should still be `run' no matter how quickly the process exits (because Emacs shouldn't process the SIGCHLD it receives until later). What am I missing? Stefan Index: lisp/progmodes/compile.el === RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v retrieving revision 1.378 diff -c -r1.378 compile.el *** lisp/progmodes/compile.el 27 Aug 2005 14:38:21 - 1.378 --- lisp/progmodes/compile.el 29 Aug 2005 22:18:30 - *** *** 1032,1038 outbuf command ;; Make the buffer's mode line show process state. (setq mode-line-process '(:%s)) ! (when compilation-disable-input (process-send-eof proc)) (set-process-sentinel proc 'compilation-sentinel) (set-process-filter proc 'compilation-filter) --- 1032,1039 outbuf command ;; Make the buffer's mode line show process state. (setq mode-line-process '(:%s)) ! (when (and compilation-disable-input ! (eq (process-status proc) 'run)) (process-send-eof proc)) (set-process-sentinel proc 'compilation-sentinel) (set-process-filter proc 'compilation-filter) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
