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? It would slow down editing long lines. jit-lock is supposed to make editing faster. 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.) In `font-lock-default-fontify-region', immediately before the comment ;; check to see if we should expand the beg/end area for ;; proper multiline matches insert either (setq beg (line-beginning-position (1- font-lock-lines-before))) or - but this would have to be mentioned in the doc-string of `font-lock-lines-before' - (when font-lock-multiline (setq beg (line-beginning-position (1- font-lock-lines-before remove the corresponding line from `font-lock-after-change-function' and wait what happens? I'm still sceptical, though ... fontifications would always overlap by `font-lock-lines-before' lines. ___ 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
Suppose not: Wouldn't that mean `font-lock-lines-before' is useless? Not at all. Then you mean that `font-lock-lines-before' is useless with jit-lock? ... 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. When the N previous lines have not been fontified yet because they are before `window-start' you do have to fontify them anyway. Otherwise any - syntactical, for example - context infomation needed to fontify the current line correctly might be invalid. 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. Try (defun foobar (bound) (while (re-search-forward \\foo\\ bound 'bound) (save-excursion (when (re-search-forward \\bar\\ (line-end-position 2) 'lep) (font-lock-prepend-text-property (match-beginning 0) (match-end 0) 'face 'font-lock-warning-face) (defun foobar-add () (interactive) (font-lock-add-keywords nil '(foobar . nil) t)) In some buffer do `foobar-add', write foo on one line and bar on the next. Plain font-lock will handle it, jit-lock won't. 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. I don't know about font-lock-fontification-face-function. `font-lock-multiline' is not a hack, at least not a priori. It simply has not been developed yet. `font-lock-lines-before' is a brute hack. However, until `font-lock-multiline' is implemented correctly, it might be better than nothing. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: literal newlines in @result{} strings
Juri Linkov [EMAIL PROTECTED] writes:
I meant that these functions return only a literal newline, not `\n'.
It might be confusing for readers of the reference manual when they
will try out an example and see that its real output is different from
the documented output in regard to newlines. They might start to
search for an (AFAIK, nonexistent) option that toggles a literal newline
or `\n' in return values, or even to fill a bug report.
to document a literal newline, we can
(a) include a literal newline between double quotes
(b) include a representation of such, between double quotes
(c) use a literal newline after @print{}, for output
(c) is not applicable for the three functions under discussion, so i
explain my rationale for choosing (b) or (a) in this case (similar
thinking might be useful generally, but i haven't thought about it
generally).
some observations: the strings in question share some characteristics:
are result values, short, end with a newline (and only one). `\n' as a
representation for literal newline is used not just for documentation
but also in emacs lisp strings (see node Character Type). this is a
programmer's manual for which the audience tends to be less easily
confused by seeing such a representation (although programmers can
become confused over anything, with enough concentration, it is often
true :-).
here are some cases where i think (a) would be more indicated than (b):
if there is more than one newline in the result, if the newline is not
at the end of the string.
thi
___
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
1. word at point - (current-word t) 2. tag at point - (funcall (or find-tag-default-function (get major-mode 'find-tag-default-function) 'find-tag-default)) These are pretty much the same. More specifically the tag should include the current-word as a substring, so I'd drop the number 1 and just keep number 2. 3. active region - (and transient-mark-mode mark-active (buffer-substring-no-properties (region-beginning) (region-end))) You could have done M-w before the current operation. Much simpler/quicker than doing M-n M-n M-n searching for it. 4. last isearch regexp - (car regexp-search-ring) This one makes sense. Maybe we could simply use the same ring for occur as for regexp-search so that it is available as M-p. 5. last kill from the kill ring - (current-kill 0) C-y brings it more quickl;y and reliably than M-n M-n M-n M-n. I.e. there are really only 2 different useful values and we could make one of the two available via M-p. 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
Suppose not: Wouldn't that mean `font-lock-lines-before' is useless? Not at all. Then you mean that `font-lock-lines-before' is useless with jit-lock? fumbling about... Hmm now I see what you mean. I simply assumed that the code for font-lock-lines-before had been added at the same place as the code for font-lock-multiline, so it would work just as well for jit-lock as for lazy-lock or anything else. As it currently stands, it indeed is broken. Sorry for being so stubborn. I suggest the patch below, which also sets the default value to 0: except for some special modes which rely on font-lock-lines-before (and which should thus set it explicitly to an appropriate value), setting it to something more than 0 will just waste CPU. I don't know about font-lock-fontification-face-function. `font-lock-multiline' is not a hack, at least not a priori. It simply has not been developed yet. `font-lock-lines-before' is a brute hack. However, until `font-lock-multiline' is implemented correctly, it might be better than nothing. I designed and implemented font-lock-multiline. It's a hack. It can't be fixed. If you want reliable and efficient multiline keywords, you have to specify them differently (read: change/extend the format of font-lock-keywords). Although you are right that you could get it to work more or less right for the special case of anchored keywords. Stefan --- font-lock.el22 aoû 2005 10:22:15 -0400 1.271 +++ font-lock.el01 sep 2005 09:43:30 -0400 @@ -293,7 +282,7 @@ (integer :tag size)) :group 'font-lock) -(defcustom font-lock-lines-before 1 +(defcustom font-lock-lines-before 0 *Number of lines before the changed text to include in refontification. :type 'integer :group 'font-lock @@ -1049,6 +1038,8 @@ ;; Use the fontification syntax table, if any. (when font-lock-syntax-table (set-syntax-table font-lock-syntax-table)) + (goto-char beg) + (setq beg (line-beginning-position (- 1 font-lock-lines-before))) ;; check to see if we should expand the beg/end area for ;; proper multiline matches (when (and font-lock-multiline @@ -1105,8 +1096,7 @@ (save-match-data ;; Rescan between start of lines enclosing the region. (font-lock-fontify-region -(progn (goto-char beg) - (forward-line (- font-lock-lines-before)) (point)) +(progn (goto-char beg) (forward-line 0) (point)) (progn (goto-char end) (forward-line 1) (point))) (defun font-lock-fontify-block (optional arg) ___ 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
In `font-lock-default-fontify-region', immediately before the comment ;; check to see if we should expand the beg/end area for ;; proper multiline matches insert either (setq beg (line-beginning-position (1- font-lock-lines-before))) Oh, I see we violently agree. I've committed the change. or - but this would have to be mentioned in the doc-string of `font-lock-lines-before' - (when font-lock-multiline (setq beg (line-beginning-position (1- font-lock-lines-before I'd rather not force people to use font-lock-multiline at the same time as font-lock-lines-before since they interact in non-trivial ways. I'd actually rather recommend to avoid using the two together. remove the corresponding line from `font-lock-after-change-function' and wait what happens? I'm still sceptical, though ... fontifications would always overlap by `font-lock-lines-before' lines. The default setting of font-lock-lines-before makes it a nop (as it should). Major modes which rely on it should set it to the appropriate value. Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
[PATCH] intro.texi
Since one of the Release goals is proofing the manuals, I'm sending this here,
rather than the bug-lisp-manual. I've attached a patch to intro.texi and the
Changelog, but I'm going to inline the intro.texi part and make some comments,
so that a commiter can decide which parts to apply.
I tried to avoid simply stylistic issues. The only repeated change I made was adding
notation, index entries for each of the notation types, so that they will be listed
together in the index in the 'n' section.
Thanks,
Josh
*** intro.texi 10 Aug 2005 14:29:00 - 1.30
--- intro.texi 1 Sep 2005 13:32:32 -
***
*** 175,181
@cindex boolean
@cindex false
! In Lisp, the symbol @code{nil} has three separate meanings: it
is a symbol with the name @samp{nil}; it is the logical truth value
@var{false}; and it is the empty list---the list of zero elements.
When used as a variable, @code{nil} always has the value @code{nil}.
--- 175,181
@cindex boolean
@cindex false
! In Lisp, the symbol @[EMAIL PROTECTED] has three separate meanings: it
is a symbol with the name @samp{nil}; it is the logical truth value
@var{false}; and it is the empty list---the list of zero elements.
When used as a variable, @code{nil} always has the value @code{nil}.
== nil is defined here, but there was no dfn.
***
*** 197,203
(not
nil)
; @r{Emphasize the truth value @var{false}}
@end example
! @cindex @code{t} and truth
@cindex true
In contexts where a truth value is expected, any [EMAIL PROTECTED] value
is considered to be @var{true}. However, @code{t} is the preferred way
--- 197,203
(not
nil)
; @r{Emphasize the truth value @var{false}}
@end example
! @cindex @code{t}, uses of
@cindex true
In contexts where a truth value is expected, any [EMAIL PROTECTED] value
is considered to be @var{true}. However, @code{t} is the preferred way
== Make this index entry consistent with nil entry
***
*** 209,222
In Emacs Lisp, @code{nil} and @code{t} are special symbols that always
evaluate to themselves. This is so that you do not need to quote them
to use them as constants in a program. An attempt to change their
! values results in a @code{setting-constant} error. The same is true of
! any symbol whose name starts with a colon (@samp{:}). @xref{Constant
Variables}.
@node Evaluation Notation
@subsection Evaluation Notation
@cindex evaluation notation
@cindex documentation notation
A Lisp _expression_ that you can evaluate is called a @dfn{form}.
Evaluating a form always produces a result, which is a Lisp object. In
--- 209,223
In Emacs Lisp, @code{nil} and @code{t} are special symbols that always
evaluate to themselves. This is so that you do not need to quote them
to use them as constants in a program. An attempt to change their
! values results in a @code{setting-constant} error. @xref{Constant
Variables}.
@node Evaluation Notation
@subsection Evaluation Notation
@cindex evaluation notation
@cindex documentation notation
+ @cindex notation, evaluation
+ @cindex notation, documentation
A Lisp _expression_ that you can evaluate is called a @dfn{form}.
Evaluating a form always produces a result, which is a Lisp object. In
== Remove sentence about variables starting with ':', since that is irrelevant
== to this node, and it is in the referenced node anyway.
== Added index entries so that all of the notations will be listed together
== in the index
***
*** 252,257
--- 253,259
@node Printing Notation
@subsection Printing Notation
@cindex printing notation
+ @cindex notation, printing
Many of the examples in this manual print text when they are
evaluated. If you execute example code in a Lisp Interaction buffer
== Added index entries so that all of the notations will be listed together
== in the index
***
*** 262,269
Examples in this manual indicate printed text with @[EMAIL PROTECTED],
irrespective of where that text goes. The value returned by
! evaluating the form (here @code{bar}) follows on a separate line with
! @[EMAIL PROTECTED]
@example
@group
--- 264,271
Examples in this manual indicate printed text with @[EMAIL PROTECTED],
irrespective of where that text goes. The value returned by
! evaluating the form (in the example below: @code{bar}) follows on a
! separate line with @[EMAIL PROTECTED]
@example
@group
== The first time I read this I thought the form was (here @code{bar}), so I
== reworded to make it more apparent that 'here' was not a made up function
== name for the example.
***
*** 277,282
--- 279,285
@node Error Messages
@subsection Error Messages
@cindex error message notation
+ @cindex notation, error message
Some examples signal errors. This normally displays an error message
in the echo area. We show the error message on a line starting with
== Added index entries so that all of the notations will be listed together
== in the index
ispell/aspell problem
I have the following backtrace when I try to change the dictionary. The error comes from the fact that Emacs runs ispell dicts rather than aspell dicts. The same kind of problem appears in ispell-get-aspell-config-value where we also run ispell-program-name which may be ispell rather than aspell. Stefan Debugger entered--Lisp error: (file-error Opening input file aucun fichier ou répertoire de ce type /u/monnier/src/emacs/trunk/lisp/Error:/Error.dat) insert-file-contents(Error:/Error.dat) ispell-aspell-find-dictionary(Error:) mapcar(ispell-aspell-find-dictionary (Error: Could not open the file \dicts\ for reading.)) ispell-find-aspell-dictionaries() ispell-valid-dictionary-list() (mapcar (function list) (ispell-valid-dictionary-list)) (and (fboundp (quote ispell-valid-dictionary-list)) (mapcar (function list) (ispell-valid-dictionary-list))) (completing-read Use new dictionary (RET for current, SPC to complete): (and (fboundp ...) (mapcar ... ...)) nil t) (list (completing-read Use new dictionary (RET for current, SPC to complete): (and ... ...) nil t) current-prefix-arg) call-interactively(ispell-change-dictionary t nil) execute-extended-command(nil) call-interactively(execute-extended-command nil nil) ___ 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': 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? The process exits during execution of create_process. The gdb log below with a breakpoint on sigchld_handler demonstrates what really happens: Breakpoint 4, sigchld_handler (signo=17) at process.c:6249 6249 XSETINT (p-raw_status_low, u.i 0x); (gdb) n 6250 XSETINT (p-raw_status_high, u.i 16); (gdb) n 6253 if ((WIFSIGNALED (w) || WIFEXITED (w)) (gdb) n 6260 FD_CLR (XINT (p-infd), input_wait_mask); (gdb) n 6261 FD_CLR (XINT (p-infd), non_keyboard_wait_mask); (gdb) p w $1 = 512 -- WIFEXITED (gdb) bt #0 sigchld_handler (signo=17) at process.c:6261 #1 signal handler called #2 0x4031f784 in sigprocmask () from /lib/libc.so.6 #3 0x0817af28 in create_process (process=141365940, new_argv=0xbfffe954, current_dir=140249731) at process.c:2153 #4 0x0817a97d in Fstart_process (nargs=5, args=0xbfffea94) at process.c:1695 ... (gdb) fr 3 #3 0x0817af28 in create_process (process=141365940, new_argv=0xbfffe954, current_dir=140249731) at process.c:2153 2153 sigprocmask (SIG_SETMASK, procmask, 0); Oh, I now see that process-send-eof does: if (! NILP (XPROCESS (proc)-raw_status_low)) update_status (XPROCESS (proc)); which basically copies the asynchronously updated proc-raw_status_* to the synchronously updated proc-status. Since this process status can change asynchronously, adding your test for (eq (process-status proc) 'run) before calling process-send-eof doesn't fix the bug but just narrows the window of the race condition because the status can still change between the call to process-status and the call to process-send-eof. So I suggest the patch below instead, Stefan --- compile.el 01 sep 2005 10:04:39 -0400 1.379 +++ compile.el 01 sep 2005 10:58:22 -0400 @@ -1038,11 +1038,14 @@ 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) (set-marker (process-mark proc) (point) outbuf) + (when compilation-disable-input +(condition-case nil +(process-send-eof proc) + ;; The process may have exited already. + (error nil))) (setq compilation-in-progress (cons proc compilation-in-progress))) ;; No asynchronous processes available. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Info node (emacs)Faces
`menu' This face determines the colors and font of Emacs's menus. Setting the font of LessTif/Motif menus is currently not supported; attempts to set the font are ignored in this case. I believe this paragraph also applies to GTK. In fact, maybe under all X toolkits (the only other one is Athena). Can people report on which toolkits this applies to? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: font-lock bug in fundamental mode
With emacs 22.0.50.1 under Mac OS X 10.4.2 (installed via darwinports), I have the following problem. Consider the following emacs-test file: (add-to-list 'load-path /opt/local/share/emacs/site-lisp) (require 'font-lock) (global-font-lock-mode t) (setq font-lock-maximum-decoration t) (add-hook 'font-lock-mode-hook 'turn-on-lazy-lock) I open it with: emacs -no-site-file -q -l emacs-test emacs-test At this time, nothing has been colorized yet (this is OK). But if I add something like a blank line at the beginning of the file ([Enter] key), then the string /opt/local/share/emacs/site-lisp gets colorized. This shouldn't happen in fundamental mode. I cannot reproduce it on GNU/Linux. ___ 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
M-n and M-p are for the history list. M-n already pulls the default value into the minibuffer and adds it (possibly edited) to the history list. This is enough connection between the two. In this case, you seem to want the default value to be the _previous_ history value (so that empty input searches the same thing again). Yes, that's what the default is now. This means that M-n, M-p, and empty input will all do more or less the same thing: use the last (i.e. previous) history value. Each of them follows a convention. In this case, all three conventions converge. However, you might consider giving access to a list of default values (more than just 1 or 2) via _different_ keys from M-n and M-p - the arrow keys, for instance. Finding other keys would be difficult. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Beginingless paragraphs
Do we need one? Certainly in the Emacs Lisp manual we don't. It is a high-level concept used in just a few user-level commands. I disagree most strongly here. Hackers need to know how to set up paragraph-s\(tart\|eparate\) so that they can make the canonical paragraph commands behave the way they want them to. This is precisely what the Emacs Manual documents now. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: (message (format File %s file))
I plan to go through the entire source code, and only in cases I am sure, fix these bugs (which mostly involves adding a %s% after `message', or getting rid of the unnecessary format call following (message). Thank you for taking the initiative. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: literal newlines in @result{} strings
I meant that these functions return only a literal newline, not `\n'. They return strings which contain newlines. You can write a newline in a string either with a newline, or with `\n'. So it is meaningless to argue about which one they return. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: grep-use-null-device
Stefan Monnier [EMAIL PROTECTED] writes: `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? The process exits during execution of create_process. The gdb log below with a breakpoint on sigchld_handler demonstrates what really happens: Breakpoint 4, sigchld_handler (signo=17) at process.c:6249 [...] Oh, I now see that process-send-eof does: if (! NILP (XPROCESS (proc)-raw_status_low)) update_status (XPROCESS (proc)); which basically copies the asynchronously updated proc-raw_status_* to the synchronously updated proc-status. Since this process status can change asynchronously, adding your test for (eq (process-status proc) 'run) before calling process-send-eof doesn't fix the bug but just narrows the window of the race condition because the status can still change between the call to process-status and the call to process-send-eof. So I suggest the patch below instead, [...] + (when compilation-disable-input +(condition-case nil +(process-send-eof proc) + ;; The process may have exited already. + (error nil))) (setq compilation-in-progress (cons proc compilation-in-progress))) ;; No asynchronous processes available. I think it is the wrong fix to just ignore an error which should not occur in the first place. Rather process-send-eof should be fixed not to throw an error as long as the process is not considered dead from Emacs' point of view. That there is nobody to actually look at the eof can't be considered a problem in asynchronous operations: the consuming process can close down without waiting for an explicit eof. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ 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
However, you might consider giving access to a list of default values (more than just 1 or 2) via _different_ keys from M-n and M-p - the arrow keys, for instance. Finding other keys would be difficult. Why? There is currently a good deal of redundancy in the bindings for `next-history-element' and `previous-history-element'. These minibuffer history-list commands are bound to *FOUR PAIRS* of keys: (1) arrows [up] / [down], (2) C-n / C-p, (3) M-n / M-p, and (4) [next] / [prior]. (Well, actually, [prior] is then rebound to `switch-to-completions'.) [Not to mention M-r, and M-s, which also provide access to previous minibuffer input (and ESC ESC C-x, which provides access to previously executed commands).] Could none of those history-list bindings be sacrificed for accessing default values (such as those Juri Stefan have mentioned, and/or the values in `minibuffer-completion-table')? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: grep-use-null-device
+ (when compilation-disable-input +(condition-case nil +(process-send-eof proc) + ;; The process may have exited already. + (error nil))) (setq compilation-in-progress (cons proc compilation-in-progress))) ;; No asynchronous processes available. I think it is the wrong fix to just ignore an error which should not occur in the first place. Rather process-send-eof should be fixed not to throw an error as long as the process is not considered dead from Emacs' point of view. That there is nobody to actually look at the eof can't be considered a problem in asynchronous operations: the consuming process can close down without waiting for an explicit eof. I agree it'd be the better thing to do. But I have no patch to do that, so unless someone else can provide a patch for it, my suggestion is a good temporary workaround. Stefan ___ 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
1. word at point - (current-word t) 2. tag at point - (funcall (or find-tag-default-function (get major-mode 'find-tag-default-function) 'find-tag-default)) These are pretty much the same. More specifically the tag should include the current-word as a substring, so I'd drop the number 1 and just keep number 2. I agree. 3. active region - (and transient-mark-mode mark-active (buffer-substring-no-properties (region-beginning) (region-end))) You could have done M-w before the current operation. Much simpler/quicker than doing M-n M-n M-n searching for it. 5. last kill from the kill ring - (current-kill 0) C-y brings it more quickl;y and reliably than M-n M-n M-n M-n. Doing M-w/C-y is simpler only for strings that don't contain special regexp characters. But in regexps they need to be quoted. `M-n M-n ...' could provide a default value with quoted special regexp characters. 4. last isearch regexp - (car regexp-search-ring) This one makes sense. Maybe we could simply use the same ring for occur as for regexp-search so that it is available as M-p. There is also another command that reads a regexp and that could share the same regexp ring - `query-replace'. It has a special variable `query-replace-from-history-variable' that defines the history list to use. So `occur' and `isearch' could have similar variables to allow occur/multi-occur/keep-lines/flush-lines/how-many and isearch-regexp to use the same ring with either: (setq regexp-history-variable 'regexp-history) (setq regexp-search-ring-variable 'regexp-history) or: (setq regexp-history-variable 'regexp-search-ring) (setq regexp-search-ring-variable 'regexp-search-ring) -- Juri Linkov http://www.jurta.org/emacs/ ___ 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
Could none of those history-list bindings be sacrificed for accessing default values (such as those Juri Stefan have mentioned, and/or the values in `minibuffer-completion-table')? There are two different issues here: accessing the completion values, and accessing the default values supplied explicitly via the `default' argument of the minibuffer reading functions. So please make this distinction when discussing them. These are two different sets of values (though, one is a subset of another). 1. a list of all possible completions. There are many packages that provide key bindings for accessing next/previous completion items. AFAIK, most popular key pairs are [left]/[right], C-s/C-r, TAB/M-TAB. You seem to be advocating for unified key bindings for these packages. 2. a list of default values. The most natural key to access a list of default values is M-n. It could work like M-p for a list of history values, but in the opposite direction. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Beginingless paragraphs
Hi, Emacs! On Thu, 1 Sep 2005, Richard M. Stallman wrote: Do we need one? Certainly in the Emacs Lisp manual we don't. It is a high-level concept used in just a few user-level commands. I disagree most strongly here. Hackers need to know how to set up paragraph-s\(tart\|eparate\) so that they can make the canonical paragraph commands behave the way they want them to. This is precisely what the Emacs Manual documents now. I think precisely is an overstatement. I'd find it helpful here if other people would step in and say how they find the existing documentation of paragraphs, paragraph-start and paragraph-separate. If others also find it confusing and obscure, then it should be improved, and I'm willing to do the improving. If, on the other hand, others can read and understand it without too much difficulty, then it's my personal problem which I'll have to deal with myself in private. -- Alan Mackenzie (Munich, Germany) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
-3% sur tout le catalogue + ...
Title: News MP Si vous ne visualisez pas ce message, cliquez-ici Illustrations et textes non contractuels - Prix valables la date de parution de cette publicit et modifiables sans pravis par la suite Si vous ne souhaitez plus recevoir d'offres de Multe-pass cliquez ici ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: literal newlines in @result{} strings
They return strings which contain newlines. You can write a newline in a string either with a newline, or with `\n'. So it is meaningless to argue about which one they return. What I mean is that printed representation of the result of evaluation (which is displayed in the echo area, or inserted into the buffer) contains a literal newline instead of `\n'. So after evaluating examples from the manual users will see different results when examples of output contain `\n' in the manual, and the real displayed output contains literal newlines. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Failing filename completion in large NFS-mounted directories
I Google'd and came across Stefan Monnier's email:
http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00643.html
including this patch to dired.c:
Somehow I failed to install that patch. Huh!
Seeing how mobody else reacted, I suggest the patch below, which also fixes
an ugly bug on 64bit systems.
-- Stefan
* dired.c (directory_files_internal_unwind): Use a proper pointer
rather than a pair of 16bit integers to store the DIR*.
(directory_files_internal, file_name_completion): Update use.
Handle EAGAIN and EINTR consistently, and check QUIT.
--- dired.c 22 aoû 2005 10:24:18 -0400 1.117
+++ dired.c 01 sep 2005 16:53:06 -0400
@@ -131,7 +131,7 @@
directory_files_internal_unwind (dh)
Lisp_Object dh;
{
- DIR *d = (DIR *) ((XINT (XCAR (dh)) 16) + XINT (XCDR (dh)));
+ DIR *d = (DIR *) XSAVE_VALUE (dh)-pointer;
closedir (d);
return Qnil;
}
@@ -155,7 +155,6 @@
int count = SPECPDL_INDEX ();
struct gcpro gcpro1, gcpro2, gcpro3, gcpro4, gcpro5;
DIRENTRY *dp;
- int retry_p;
/* Because of file name handlers, these functions might call
Ffuncall, and cause a GC. */
@@ -189,12 +188,6 @@
/* Now *bufp is the compiled form of MATCH; don't call anything
which might compile a new regexp until we're done with the loop! */
- /* Do this opendir after anything which might signal an error; if
- an error is signaled while the directory stream is open, we
- have to make sure it gets closed, and setting up an
- unwind_protect to do so would be a pain. */
- retry:
-
d = opendir (SDATA (dirfilename));
if (d == NULL)
report_file_error (Opening directory, Fcons (directory, Qnil));
@@ -203,8 +196,7 @@
file-attributes on filenames, both of which can throw, so we must
do a proper unwind-protect. */
record_unwind_protect (directory_files_internal_unwind,
-Fcons (make_number (((unsigned long) d) 16),
- make_number (((unsigned long) d) 0x)));
+make_save_value (d, 0));
directory_nbytes = SBYTES (directory);
re_match_object = Qt;
@@ -222,10 +214,15 @@
errno = 0;
dp = readdir (d);
+ if (dp == NULL (0
#ifdef EAGAIN
- if (dp == NULL errno == EAGAIN)
- continue;
+|| errno == EAGAIN
+#endif
+#ifdef EINTR
+|| errno == EINTR
#endif
+))
+ { QUIT; continue; }
if (dp == NULL)
break;
@@ -316,22 +313,11 @@
}
}
- retry_p = 0;
-#ifdef EINTR
- retry_p |= errno == EINTR;
-#endif
-
closedir (d);
/* Discard the unwind protect. */
specpdl_ptr = specpdl + count;
- if (retry_p)
-{
- list = Qnil;
- goto retry;
-}
-
if (NILP (nosort))
list = Fsort (Fnreverse (list),
attrs ? Qfile_attributes_lessp : Qstring_lessp);
@@ -519,8 +505,7 @@
report_file_error (Opening directory, Fcons (dirname, Qnil));
record_unwind_protect (directory_files_internal_unwind,
- Fcons (make_number (((unsigned long) d) 16),
-make_number (((unsigned long) d)
0x)));
+ make_save_value (d, 0));
/* Loop reading blocks */
/* (att3b compiler bug requires do a null comparison this way) */
@@ -532,8 +517,19 @@
#ifdef VMS
dp = (*readfunc) (d);
#else
+ errno = 0;
dp = readdir (d);
+ if (dp == NULL (0
+# ifdef EAGAIN
+|| errno == EAGAIN
+# endif
+# ifdef EINTR
+|| errno == EINTR
+# endif
+))
+ { QUIT; continue; }
#endif
+
if (!dp) break;
len = NAMLEN (dp);
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
recentf.el - digit shortcuts
Here is a patch that adds shortcut keys and corresponding labels to recentf-dialog-mode (the mode that `recentf-open-files' uses). The variable `recentf-dialog-show-labels-p' controls whether labels are displayed, and could default to nil. I've been using this functionality for a long time and find it indispensable. However, defadvice is brittle and I had to rewrite it every time recentf changed. I hope this feature is suitable for installing. 2005-09-01 Karl Chen [EMAIL PROTECTED] * recentf.el (recentf-dialog-choose): Open the Nth item. (recentf-dialog-show-labels-p): New variable. (recentf-dialog-mode-map): Define keys 0-9 as recentf-dialog-choose. (recentf-dialog-files, recentf--number): New variables. (recentf-open-files-item): Display label (via recentf--number) if recentf-dialog-show-labels-p. (recentf-open-files): Reflect new variables and help text. --- /usr/share/emacs/22.0.50/lisp/recentf.el2005-08-06 15:13:43.0 -0700 +++ recentf.el 2005-09-01 13:42:22.0 -0700 @@ -259,6 +259,15 @@ :group 'recentf :type '(choice (const :tag None nil) function)) + +(defcustom recentf-dialog-show-labels-p t + Whether to show ``[N]'' for the Nth item up to 10. + +If set, `recentf-open-files' will show labels for keys that +can be used as shortcuts to open the Nth file. + :group 'recentf + :type 'boolean) + ;;; Utilities ;; @@ -926,6 +935,19 @@ (set-keymap-parent km widget-keymap) (define-key km q 'recentf-cancel-dialog) (define-key km [down-mouse-1] 'widget-button-click) + +;; define in reverse order of how we want the keys to appear in help +(define-key km 0 'recentf-dialog-choose) +(define-key km 9 'recentf-dialog-choose) +(define-key km 8 'recentf-dialog-choose) +(define-key km 7 'recentf-dialog-choose) +(define-key km 6 'recentf-dialog-choose) +(define-key km 5 'recentf-dialog-choose) +(define-key km 4 'recentf-dialog-choose) +(define-key km 3 'recentf-dialog-choose) +(define-key km 2 'recentf-dialog-choose) +(define-key km 1 'recentf-dialog-choose) + km) Keymap used in recentf dialogs.) @@ -1063,6 +1085,9 @@ (kill-buffer (current-buffer)) (funcall recentf-menu-action (widget-value widget))) +;; The current item number while building recentf-open-files buffer +(defvar recentf--number nil) + (defun recentf-open-files-item (menu-element) Return a widget to display MENU-ELEMENT in a dialog buffer. (if (consp (cdr menu-element)) @@ -1076,8 +1101,12 @@ ,@(mapcar 'recentf-open-files-item (cdr menu-element))) ;; Represent a single file with a link widget +(setq recentf--number (+ 1 recentf--number)) `(link :tag ,(car menu-element) - :button-prefix + :button-prefix ,(if recentf-dialog-show-labels-p + (if (= recentf--number 10) + (format [%d] (% recentf--number 10)) ) + ) :button-suffix :button-face default :format %[%t%]\n @@ -1085,6 +1114,9 @@ :action recentf-open-files-action ,(cdr menu-element +;; Current files listed +(defvar recentf-dialog-files nil) + (defun recentf-open-files (optional files buffer-name) Show a dialog to open a recent file. If optional argument FILES is non-nil, it is a list of recently-opened @@ -1092,8 +1124,9 @@ If optional argument BUFFER-NAME is non-nil, it is a buffer name to use for the dialog. It defaults to \*`recentf-menu-title'*\. (interactive) + (or files (setq files recentf-list)) (recentf-dialog (or buffer-name (format *%s* recentf-menu-title)) -(widget-insert Click on a file to open it. +(widget-insert Click on a file or type the corresponding digit key to open it. Click on Cancel or type `q' to cancel.\n ) ;; Use a LF that looks like the recentf menu. (tree-widget-set-theme folder) @@ -1101,17 +1134,38 @@ `(group :indent 2 :format \n%v\n - ,@(mapcar 'recentf-open-files-item - (recentf-apply-menu-filter -recentf-menu-filter -(mapcar 'recentf-make-default-menu-element -(or files recentf-list)) + ,@(let ((recentf--number 0)) + (mapcar 'recentf-open-files-item + (recentf-apply-menu-filter + recentf-menu-filter + (mapcar 'recentf-make-default-menu-element files)) (widget-create 'push-button :notify 'recentf-cancel-dialog Cancel) +(set (make-local-variable 'recentf-dialog-files) files) (recentf-dialog-goto-first 'link))) +(defun recentf-dialog-choose (n) + Open the Nth file. + +When called interactively via a numeric key N,
Re: Beginingless paragraphs
Alan Mackenzie [EMAIL PROTECTED] writes: This is precisely what the Emacs Manual documents now. I think precisely is an overstatement. I'd find it helpful here if other people would step in and say how they find the existing documentation of paragraphs, paragraph-start and paragraph-separate. fwiw, i found docs w/ grep. first in lispref/*.texi, then in man/*.texi. the docs i found were adequate enough to start experimenting in an emacs session. probably if i were reading them outside of emacs (hypothetical situation :-), they would not be complete and thus, depending on my mood, i might find them adequate or not. thi ___ 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
Could none of those history-list bindings be sacrificed for accessing default values (such as those Juri Stefan have mentioned, and/or the values in `minibuffer-completion-table')? There are two different issues here: accessing the completion values, and accessing the default values supplied explicitly via the `default' argument of the minibuffer reading functions. So please make this distinction when discussing them. These are two different sets of values (though, one is a subset of another). 1. a list of all possible completions. 2. a list of default values. Yes, there is a difference. That's partly what I meant to indicate by using quotes around default and separating this from the list of completions with and/or - but the difference is clearer as you express it - thanks. You distinguish the two in terms of their meaning: default value vs a value that completes an input (i.e. works via completion). These can be different, a priori. You also distinguish them operationally: one is accessed via the default-value argument to completing-read, the other via the obarray argument (minibuffer-completion-table). These two distinctions are not the same, so let's distinguish them, too ;-). The second distinction more or less assumes what we are debating (_how_ users are to access default values). You assume that default values are to be treated as the default-value arg to completing-read. And, besides begging the question, your second distinction is a bit premature: until now, the default-value arg to completing-read has in fact been a single value, not a list of values. So, I'll concentrate on the first distinction: default values vs completions. Given the fact that default value does not necessarily imply completion, and vice versa, we can nevertheless _choose_ to consider accessing the two in the same way - that is, to equate them _operationally_ (i.e., in terms of use). They are all, in principle, reasonable input values to expect the user to choose. IOW, having gone through the exercise of distinguishing their meanings logically, we can still choose to treat default value and completion the same way (giving them the same meaning, some might argue!). Let's assume that the minibuffer-completion-table passed to completing-read etc. is intelligently tailored to be a set of values the user would likely choose. That's not always the case today (the unfocussed obarray is often passed), but there is nothing standing in the way of programmers passing a well-chosen minibuffer-completion-table that is truly helpful in some particular context. Not to mention also passing a useful minibuffer-completion-predicate. In some cases, this sequence of completions could perhaps be sorted in some special way, in terms of likelihood of use, for instance. That might provide additional help to the user. In front of these completion values we might place some even-more-intelligently-crafted choices - the kinds of choices that you and Stefan suggested, perhaps. That is, there is nothing preventing us from tacking on super-smart choices to the front of a list of less brilliant choices. This is just another way of ordering the list. This gives us a sequence of possible choices, perhaps ordered in some smart way. I suggest that there is no reason not to make each of these choices available also as a _completion_ - that is, to let users complete input to obtain it. This is the main reason for bringing together the two lists you distinguished above. Then, the list of completions and the list of possible default values would be the same: each default value would be a completion target, and each completion would be a possible default value. If we did that, then the original question would remain, _how to access_ the values in this list? Completion would be one way now, thanks to unifying the two lists. Cycling via one or two keys could be another way. I suggested reusing one of the 4 redundant pairs currently dedicated to the history lists - the up/down arrows, for instance. You mentioned that some external libraries cycle completions using left/right, C-s/C-r etc. Whatever - in any case, I don't see a _scarcity_ of such pairs, as Richard suggested. An alternative, which you suggest, is to use M-n for this cycling (though you propose it only for the default-value list, which you separate from the completions list): The most natural key to access a list of default values is M-n. It could work like M-p for a list of history values, but in the opposite direction. To me, that's less desirable/natural, as it confuses the history list (which can already be navigated in both directions) with the default-value list. I personally would prefer to keep the two critters separate, operationally. However, you're right that M-n accesses the future here (possible inputs), while M-p (and M-n, up to the last input!) accesses past inputs, so that is also a perfectly _workable_ scheme.
