Re: Info-search-isearch
Richard Stallman <[EMAIL PROTECTED]> writes: > > Currently only regexp isearch invoked with M-C-s can use `Info-search' > > and search through multiple Info nodes. But it would be better if > > normal C-s isearch searched through multiple nodes as well. > > This would be actually great, it would match the behavior of standalone > info (which, IMO, is much better). > > Is there any reason not to check this code in? > > Does the code look clean to you? > If so, it is ok with me. I installed this code. Now C-s in Info works like in standalone info. If there are good reasons to add a "Failing isearch in node Foo: bar" message before trying other nodes, as Drew suggested, this could be added as a separate option value of the Info-isearch-search variable. But I think such delay in one C-s key press is inconvenient when the user intention is to search all nodes. When isearch goes to the next node with the user intention to search only in the current node then it is easy to get back by typing DEL without leaving isearch mode. -- 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-search-isearch
Currently multi-node isearch in Info ignores word search. It searches for a sequence of words only in the current node. But it is useful to search for words through multiple Info nodes. I think search in Info should support nonincremental and "half-incremental" word search. Word search what I call "half-incremental" is an undocumented feature that allows almost incremental search by typing `C-s M-e C-w WORDS C-s', i.e. it starts as nonincremental search, and after typing the second C-s in the minibuffer it continues as incremental search. I discovered this feature accidentally. Perhaps, it should be documented in the Emacs manual? Below is an implementation of word search for Info isearch which duplicated in Lisp the C function `wordify' used by word search. Index: lisp/info.el === RCS file: /cvsroot/emacs/emacs/lisp/info.el,v retrieving revision 1.417 diff -u -r1.417 info.el --- lisp/info.el23 Feb 2005 17:03:17 - 1.417 +++ lisp/info.el25 Feb 2005 19:55:18 - @@ -1646,10 +1646,16 @@ (Info-search regexp bound noerror count 'backward)) (defun Info-isearch-search () - (if (and Info-isearch-search (not isearch-word)) + (if Info-isearch-search (lambda (string &optional bound noerror count) (condition-case nil - (progn + (if isearch-word + (Info-search (concat "\\b" (replace-regexp-in-string + "\\W+" "W+" + (replace-regexp-in-string +"^\\W+\\|\\W+$" "" string)) "\\b") +bound noerror count +(unless isearch-forward 'backward)) (Info-search (if isearch-regexp string (regexp-quote string)) bound noerror count (unless isearch-forward 'backward)) @@ -1659,7 +1665,7 @@ (isearch-search-fun (defun Info-isearch-wrap () - (when (and Info-isearch-search (not isearch-word)) + (when Info-isearch-search (if isearch-forward (Info-top-node) (Info-final-node)) (goto-char (if isearch-forward (point-min) (point-max) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
safe-magic for image-file-handler
With auto-image-file-mode turned on, `!' (`dired-do-shell-command') called on a image file in the *Locate* buffer (created by the `M-x locate' command) doesn't work, because `dired-get-filename' puts "/:" at the beginning of the file name, and then the file name with the leading "/:" is given as an argument to the shell command. It seems the correct fix is to put safe-magic property: (put 'image-file-handler 'safe-magic t) in image-file.el. But generally, the solution of using safe-magic doesn't seem right to me. Maybe a better solution would be to eliminate safe-magic property entirely, and to let `dired-get-filename' to always add "/:", but to remove it somewhere in low-level functions (e.g. in `call-process' or `file-name-non-special') just before giving a file name to the external command. This will also allow the correct processing of commands where users put "/:" explicitly, for example: C-x C-f /:/some/dir/file.gz RET which currently doesn't work. BTW, auto-image-file-mode doesn't handle image files visited inside compressed files visited with auto-compression-mode. Are there plans to improve auto-image-file-mode to handle such situations? This is a necessary feature. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Putting blink-cursor-mode in Options menu.
Richard Stallman <[EMAIL PROTECTED]> writes: > Does anyone else agree that this option should be in the Options menu? Yes. If not directly on the top level, then at least in one of the submenus. Since Emacs has the blinking cursor enabled by default, then there should be an easy way to disable it. Also a year ago I proposed in http://lists.gnu.org/archive/html/emacs-devel/2004-02/msg00223.html to add a new command line option: --no-blinking-cursor, -nbcdisable blinking cursor In case there will be a consensus to disable the blinking cursor by default (AFAIK, XEmacs already does this), then the option should be the opposite: --blinking-cursor, -bcenable blinking cursor > What do other applications do about this? Most applications have no easy way to disable blinking cursors. So everyone who want to do it, has to spend too much time searching an appropriate option. To help people to find such an option quickly there is a page with instructions how to turn blinking cursors off in most popular applications: http://www.jurta.org/prog/noblink.en.html > My version of mozilla has no way to change whether the cursor > blinks, but it is rather old. There is no such option in Mozilla Preferences UI. However, in Mozilla there is the variable ui.caretBlinkTime which can be set to 0 through about:config or directly in user.js. In very old versions, putting *blinkRate: 0 in .Xresources should help. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
sgml-mode.el fixes for html-mode
t;/>" ">") + (funcall skeleton-transformation + (if sgml-xml-mode " checked=\"checked\"" " checked"))) + (if sgml-xml-mode " />" ">") (skeleton-read "Text: " (capitalize str)) (or v2 (setq v2 (if (y-or-n-p "Newline after text? ") (funcall skeleton-transformation -(if sgml-xml-mode "" "")) +(if sgml-xml-mode "" "")) ""))) \n)) @@ -2000,12 +2004,13 @@ "\" name=\"" (or (car v2) (setcar v2 (skeleton-read "Name: "))) "\" value=\"" str ?\" (when (and (not v1) (setq v1 (y-or-n-p "Set \"checked\" attribute? "))) - (funcall skeleton-transformation " checked")) - (if sgml-xml-mode "/>" ">") + (funcall skeleton-transformation + (if sgml-xml-mode " checked=\"checked\"" " checked"))) + (if sgml-xml-mode " />" ">") (skeleton-read "Text: " (capitalize str)) (or (cdr v2) (setcdr v2 (if (y-or-n-p "Newline after text? ") (funcall skeleton-transformation -(if sgml-xml-mode "" "")) +(if sgml-xml-mode "" "")) ""))) \n)) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Key binding M-g should really be goto-line
I see `goto-line' finally bound to M-g in CVS. Good news! After such a big change, it is time now for a few improvements. 1. Before this change, font-lock-fontify-block was bound to `M-g M-g'. Now it is bound to `M-o M-g'. I suspect that the reason to bind it to `M-g M-g' was to make it easier to run this frequent command by typing the same key twice. If this is true then now perhaps it should be rebound to `M-o M-o'. 2. goto-line is not too frequent command to deserve the sole M-g key. There are many other goto-related commands that could share the same mnemonics and have the common M-g prefix key. Since goto-line is still the most frequent among them, it could have also the most easily typed key binding `M-g M-g'. Other commands that deserve a key binding with a `M-g' prefix are: 2.1. next-error (alias goto-next-locus), previous-error The current key binding C-x ` is too hard to type on many keyboards, and it is the constant cause of complaints. The prefix key M-g will allow to add natural key bindings for these commands and to reduce complaints in future. 2.2. dired-goto-file This command is used to move point to the specified file name in dired buffers. It would be useful to run this command not only in dired buffers, but in any buffer, with a new key binding. 2.3. goto-char is much less used command than goto-line, but sometimes it's needed and could have a key binding too. 2.4. The M-g prefix key will also reserve a space for adding other goto-related commands later. Similarly to facemenu-keymap which currently displays the message after typing M-o: Set face: default, bold, italic, l = bold-italic, underline, Other... M-g could display a message: Go to: line, M-g = line, char, file, next error, prev error, Other... and have a keymap with the following key bindings: M-g M-g - goto-line M-g l - goto-line M-g c - goto-char M-g f - dired-goto-file M-g n - next-error (goto-next-locus) M-g M-n - next-error (goto-next-locus) M-g p - previous-error M-g M-p - previous-error -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Key binding M-g should really be goto-line
[EMAIL PROTECTED] (Kim F. Storm) writes: > One command I use quite often is "find-file-and-line-near-point" > which takes something like FILE:LINE "near" the cursor and jumps to > LINE in FILE. This is what `goto-line' is supposed to do. Since it was already completely modified recently with the complex logic of getting a line number from the buffer and jumping to the most recently displayed other buffer, why not modify it further to get a file name from the buffer (before colon and the line number) and to visit it before moving to the specified line number. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: isearch-forward and Info-search
Nick Roberts <[EMAIL PROTECTED]> writes: > Maybe theres been a long thread about this which I've missed, in which case > I apologise but is there a variable to change this behaviour back to the > old one? The variable is `Info-isearch-search' and when set to nil it changes the behavior to the old one. > Could it be made the default? Let's try to fix the new behavior and see if it will satisfy most people. Would you like it if isearch failed before proceeding to the next Info node? > I've also noticed that if you abort a search (C-s) before it gets to the end > of the manual the formatting of the links on the current page gets messed up. This looks like a bug, but I can't reproduce it. Could you provide a precise receipt to reproduce it? -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: isearch-forward and Info-search
Miles Bader <[EMAIL PROTECTED]> writes:
> I think it would be a lot less annoying if it at least changed the
> prompt to say what it was doing, in the manner of a wrapped isearch
> ("I-search in node ...: " ?).
>
> Maybe it could even act more like wrapped i-search, and fail once,
> before proceeding to the next info page if you hit C-s again.
It seems this is the most reasonable default behavior.
But I also think it would be too annoying to fail before
leaving every Info node. It would be better to fail only
in the first Info node where isearch was started. Of course,
this doesn't preclude creating at least four different options
for the `Info-isearch-search' variable:
- never fail (current behavior)
- fail only in the node where isearch was started (proposed default)
- fail in every node visited by isearch (somebody may like this)
- fail and wrap to the beginning of the current node (old behavior)
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Key binding M-g should really be goto-line
[EMAIL PROTECTED] (Johan Bockgård) writes: > Indeed not. It's called `dired-jump' (bound to C-x C-j when dired-x > is loaded). It is good as a global binding, but it has one limitation: it can't jump to an arbitrary file, it jumps only to buffer-file-name when called not from a dired buffer. It would be useful to move `dired-jump' to dired.el and to modify it to ask the file name with the default set to buffer-file-name (or to create a new similar function and bind it to M-g f). -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: isearch-forward and Info-search
"Drew Adams" <[EMAIL PROTECTED]> writes: > Would you like it if isearch failed before proceeding to the > next Info node? > > I would. I suggested this long ago. It should first wrap, as Richard > suggested. After the entire Info node has been searched, it should > fail. A subsequent invocation should continue through the manual. > > IOW, isearch the node completely first (wrapping), then inform the > user that there are no more occurrences in the node, then continue > on to other nodes. IMO, this behavior is too confusing. Imagine the situation where isearch was wrapped once and after overwrapping it landed again on the first matching point. Now the user sees lazy-highlighted matches below point, and when he types C-s again, isearch skips these matches and continues on to the next node. Even though these matches were visited once, the user may forget this, so it would be confusing when the user expects that C-s will go to the next lazy-highlighted match, but it goes to the next node instead. It's better is to go to the next node after the first failure without wrapping. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: isearch-forward and Info-search
earch (concat "\\b" (replace-regexp-in-string - "\\W+" "W+" - (replace-regexp-in-string -"^\\W+\\|\\W+$" "" string)) "\\b") -bound noerror count -(unless isearch-forward 'backward)) - (Info-search (if isearch-regexp string (regexp-quote string)) - bound noerror count - (unless isearch-forward 'backward)) - (point)) - (error nil))) + (if isearch-word + (Info-search (concat "\\b" (replace-regexp-in-string + "\\W+" "W+" + (replace-regexp-in-string +"^\\W+\\|\\W+$" "" string)) "\\b") +bound noerror count +(unless isearch-forward 'backward)) + (Info-search (if isearch-regexp string (regexp-quote string)) + bound noerror count + (unless isearch-forward 'backward)) + (point))) (let ((isearch-search-fun-function nil)) (isearch-search-fun (defun Info-isearch-wrap () - (when Info-isearch-search -(if isearch-forward (Info-top-node) (Info-final-node)) + (if Info-isearch-search + (if Info-isearch-first-node + (progn + (if isearch-forward (Info-top-node) (Info-final-node)) + (goto-char (if isearch-forward (point-min) (point-max + (setq Info-isearch-first-node Info-current-node) + (setq isearch-wrapped nil)) (goto-char (if isearch-forward (point-min) (point-max) (defun Info-isearch-push-state () @@ -1680,6 +1690,9 @@ (string= Info-current-node node)) (progn (Info-find-node file node) (sit-for 0 +(defvar Info-isearch-first-node nil) +(defun Info-isearch-start () + (setq Info-isearch-first-node nil)) (defun Info-extract-pointer (name &optional errorname) "Extract the value of the node-pointer named NAME. @@ -3217,6 +3230,7 @@ (setq desktop-save-buffer 'Info-desktop-buffer-misc-data) (add-hook 'clone-buffer-hook 'Info-clone-buffer-hook nil t) (add-hook 'change-major-mode-hook 'font-lock-defontify nil t) + (add-hook 'isearch-mode-hook 'Info-isearch-start nil t) (set (make-local-variable 'isearch-search-fun-function) 'Info-isearch-search) (set (make-local-variable 'isearch-wrap-function) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: isearch-forward and Info-search
ghlight-overlays nil) @@ -2369,7 +2363,7 @@ isearch-lazy-highlight-window-end ;; something important did indeed change (isearch-lazy-highlight-cleanup t) ;kill old loop & remove overlays -(when (not isearch-invalid-regexp) +(when (not isearch-error) (setq isearch-lazy-highlight-start-limit beg isearch-lazy-highlight-end-limit end) (setq isearch-lazy-highlight-window (selected-window) @@ -2391,18 +2385,20 @@ Attempt to do the search exactly the way the pending isearch would." (let ((case-fold-search isearch-case-fold-search) (search-spaces-regexp search-whitespace-regexp)) -(funcall (isearch-search-fun) - isearch-string - (if isearch-forward - (min (or isearch-lazy-highlight-end-limit (point-max)) - (if isearch-lazy-highlight-wrapped - isearch-lazy-highlight-start - (window-end))) - (max (or isearch-lazy-highlight-start-limit (point-min)) - (if isearch-lazy-highlight-wrapped - isearch-lazy-highlight-end - (window-start - t))) +(condition-case nil + (funcall (isearch-search-fun) +isearch-string +(if isearch-forward +(min (or isearch-lazy-highlight-end-limit (point-max)) + (if isearch-lazy-highlight-wrapped + isearch-lazy-highlight-start + (window-end))) + (max (or isearch-lazy-highlight-start-limit (point-min)) + (if isearch-lazy-highlight-wrapped + isearch-lazy-highlight-end + (window-start +t) + (error nil (defun isearch-lazy-highlight-update () "Update highlighting of other matches for current search." -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: "Match whole word only" "Match case"
Tak Ota <[EMAIL PROTECTED]> writes: > Do you think it is worth considering to have these search options to > be explicit choice from the Edit->Search and Edit->Replace menu? There is already "Case-Insensitive Search" option in Options menu. But putting "Word Search" option in Options menu is a possible source of confusion: users might forget about it after turning it on, and later wonder why normal search can't find a part of the word. Also note that word search and replace are not very useful. In source code they often don't work as intended. What is more useful are not \b delimiters, but \_< and \_> to match symbols instead of words. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Putting auto-image-file-mode in Options menu
There is already "Automatic File De/compression" menu item
for auto-compression-mode in the Options menu, but no menu item
for auto-image-file-mode. This looks like an unintentional omission.
Index: lisp/menu-bar.el
===
RCS file: /cvsroot/emacs/emacs/lisp/menu-bar.el,v
retrieving revision 1.254
diff -u -r1.254 menu-bar.el
--- lisp/menu-bar.el6 Mar 2005 20:18:06 - 1.254
+++ lisp/menu-bar.el12 Mar 2005 23:34:25 -
@@ -970,6 +970,13 @@
(define-key menu-bar-options-menu [cursor-separator]
'("--"))
+(define-key menu-bar-options-menu [toggle-auto-image-file]
+ '(menu-item "Automatic Image Files"
+ auto-image-file-mode
+ :help "Toggle visiting of image files as images"
+ :button (:toggle . (rassq 'image-file-handler
+ file-name-handler-alist
+
(define-key menu-bar-options-menu [toggle-auto-compression]
'(menu-item "Automatic File De/compression"
auto-compression-mode
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Putting auto-image-file-mode in Options menu
Stefan Monnier <[EMAIL PROTECTED]> writes: >> There is already "Automatic File De/compression" menu item >> for auto-compression-mode in the Options menu, but no menu item >> for auto-image-file-mode. This looks like an unintentional omission. > > I think it's omitted because it's a very rarely used feature. Indeed, auto-image-file-mode is useful only for viewing images. OTOH, editing image files as plain text in Emacs is a rare operation too. And even with auto-image-file-mode set to t, editing is possible after visiting them with find-file-literally. With all this said, I have a question: is there any reason not to turn auto-image-file-mode on by default? I would like to ask the same question for auto-compression-mode too. What is the reason not to turn it on by default? How often people visit compressed files for editing without uncompressing? -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: isearch magic space
"Chong Yidong" <[EMAIL PROTECTED]> writes: > Some time ago, I proposed providing a magic space for ordinary isearch. > The response was generally favorable, but my papers were not in order, so > the patch could not be applied. My copyright assignment is settled now; > can the patch be applied, or is it too late? I like the idea of using a space to match any whitespace in plain non-regexp isearch. However, it should be nil by default to preserve the default behavior for users who don't expect such a change. Also there should be an easy way to put a literal space into the search string. In regexp isearch this can be done with C-q SPC. One solution is to allow `search-whitespace-regexp' to be a list of regexps and a new key could rotate this list and search will use the first element. I noticed that in most cases as the whitespace regexp "\\W+" is more useful than "\\s-+". So a new key could use the default values '(nil "\\s-+" "\\W+") and switch between them. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Putting auto-image-file-mode in Options menu
Stefan Monnier <[EMAIL PROTECTED]> writes: > I admit that I've never opened a png file in Emacs, so for png it might be > OK, but in general there are several "image formats" which are quite > viewable/editable in Emacs. > > OTOH I find auto-image-file-mode of very dubious utility: you can barely > look at the image (it's a bit better now with partial-line scrolling, but > it's still much more clunky than any other image-viewing tool), and you > can't do anything more (crop/zoom/rotate/save in another format, ...). True, Emacs is not intended to be an image editor (at least, not in TODO list now :-) But editing binary image files is not useful either. And even when this is necessary, editing binary files is always safer with find-file-literally. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Putting auto-image-file-mode in Options menu
David Kastrup <[EMAIL PROTECTED]> writes: > If you are working through a slow X connection, accidentally visiting > an image file could be a very expensive mistake. In the past, > displaying an image that was overtall could really confuse Emacs. > This has become much better recently, but I don't know how the > situation is with overwide images. Emacs can horizontally scroll images wider than the window width. > Anyway, there are ASCII-based image file formats like ASCII PBM, PGM, > PPM, PAM and XBM and XPM. Much more often than not, when I open such > files with Emacs, I really don't want to see the picture, but the > source text (to see comments, assignment of colors and palette, ranges > and so on). And using find-file-literally (even if we provided it in > the menus, where it currently isn't) does not cater overly gracefully > for the line endings in those files. No big problem when the DOS line endings are displayed after using find-file-literally. > I don't know how well auto-compression-mode deals with things like > missing compression commands. If it fails gracefully, enabling it by > default should not do much harm. With missing compression commands it displays an error message in the separate window with *jka-compr-error* buffer. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Putting auto-image-file-mode in Options menu
Stefan <[EMAIL PROTECTED]> writes: > As I said, it's probably true for "binary" image formats (like PNG). > But auto-image-file-mode, as it currently stands, applies to more formats > than just those. I guess there should be a special mode `image-file-mode' to switch between textual and graphical representations of the buffer content for visited image files in ASCII-based file formats. > BTW, the file-coding-system-alist should stipulate `binary' for > files like *.png or *.gif. Yes, it would be right. -- 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 tooltip for *Menu items
"Lennart Borgman" <[EMAIL PROTECTED]> writes: > The tooltip I get for *Menu items in Info is only "mouse-1: go to ". Did I > break something or do you see the same as I see? Thanks for the report. This is fixed now to work as intended. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Putting auto-image-file-mode in Options menu
Richard Stallman <[EMAIL PROTECTED]> writes: > What do people think? Here's the code to do it. I looked at the code and have a few comments: 1. .xpm file extension is missing from the list of autoload cookies. 2. Perhaps image-mode should be minor mode for extensions like .xbm and .xpm which already have associated major mode c-mode in auto-mode-alist. 3. By default this mode should be enabled for non-ascii based image format files like .png, .jpg. This could be achieved by enabling auto-compression-mode by default and turning image-mode off by default for ascii based formats. 4. Calling `image-toggle-display' sets the modification flag, so after visiting image files only for viewing buffers become modified. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Type Ahead Find
earch-error) (setq isearch-lazy-highlight-start-limit beg isearch-lazy-highlight-end-limit end) (setq isearch-lazy-highlight-window (selected-window) @@ -2384,7 +2388,7 @@ (unless (equal isearch-string "") (setq isearch-lazy-highlight-timer (run-with-idle-timer lazy-highlight-initial-delay nil - 'isearch-lazy-highlight-update)) +'isearch-lazy-highlight-update) (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. @@ -2393,6 +2397,10 @@ (isearch-regexp isearch-lazy-highlight-regexp) (search-spaces-regexp search-whitespace-regexp)) (condition-case nil + (let ((retry t) + (success nil)) + (while retry + (setq success (funcall (isearch-search-fun) isearch-lazy-highlight-last-string (if isearch-forward @@ -2404,7 +2412,14 @@ (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-end (window-start -t) + t)) + (if (or (not success) + (if isearch-success-function + (funcall isearch-success-function) + (not (isearch-range-invisible + (match-beginning 0) (match-end 0) + (setq retry nil))) + success) (error nil (defun isearch-lazy-highlight-update () Index: lisp/info.el === RCS file: /cvsroot/emacs/emacs/lisp/info.el,v retrieving revision 1.421 diff -u -r1.421 info.el --- lisp/info.el16 Mar 2005 07:32:43 - 1.421 +++ lisp/info.el18 Mar 2005 19:33:20 - @@ -1505,9 +1505,11 @@ (while (and (not give-up) (save-match-data (or (null found) - (if backward - (isearch-range-invisible found beg-found) - (isearch-range-invisible beg-found found)) + (if isearch-success-function + (not (funcall isearch-success-function)) + (if backward + (isearch-range-invisible found beg-found) + (isearch-range-invisible beg-found found))) ;; Skip node header line (and (save-excursion (forward-line -1) (looking-at "\^_")) @@ -1593,9 +1595,11 @@ (while (and (not give-up) (save-match-data (or (null found) - (if backward - (isearch-range-invisible found beg-found) - (isearch-range-invisible beg-found found)) + (if isearch-success-function + (not (funcall isearch-success-function)) + (if backward + (isearch-range-invisible found beg-found) + (isearch-range-invisible beg-found found))) ;; Skip node header line (and (save-excursion (forward-line -1) (looking-at "\^_")) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Type Ahead Find
Stefan Monnier <[EMAIL PROTECTED]> writes: >> >> I-search: gnu [GNU Free Documentation License] > > I'm not particularly happy about this reuse of the [...] message. > It's meant to hold an error message. Reusing an error message variable is not a clean solution, indeed. Perhaps, it's better to add a new similar variable with the purpose of displaying an additional data during isearch. > Maybe it's not too serious as such, but given that the text displayed > there is (at least in your example) nothing more than the text > under point, I don't find it to be worthwhile. There is the text under point only in my first example. It would be very useful to display hidden text like when Info-hide-note-references hides the reference node names, so for example, when isearch reaches the reference `*Note Local Variables in Files: (emacs)File variables', it would display the hidden node name in square brackets: I-search: local variables [(emacs)File variables] It is also useful to display a data associated with the text under point (from text properties, or other associated sources). So in w3m buffers (where only a link text is displayed) it would display an URL (not present in the buffer) in square brackets. For example, for a link http://www.gnu.org/";>The GNU Project when isearch finds the link text `The GNU Project', the message will be: I-search: project [http://www.gnu.org/] > Actually, the first implementation of isearch-search-fun-function > (a good bit before I installed it in the CVS) was triggered by > a question on gnu.emacs.help of how to do an "incremental imenu" and > I implemented it with isearch-search-fun-function where I simply > mixed the "current search string" with the imenu-generic-expression > in order to constrain the search space, pretty much in the way > you suggest. IMO, it would be much simpler to implement this with `isearch-success-function', with a small piece of code: (set (make-local-variable 'isearch-success-function) ;; isearch only in function names (lambda () (save-match-data (let* ((re (cdr (assoc nil imenu-generic-expression (and (save-excursion (beginning-of-line) (looking-at (car re))) (>= (point) (match-beginning (cadr re))) (<= (point) (match-end (cadr re > It seems that what you're suggesting is basically implementable as: > >(setq isearch-search-fun-function > `(lambda (string &optional bound noerror) >(if (funcall isearch-success-function) >(,(isearch-search-fun) string bound noerror This won't work. There should be a while-loop to call the default search function in loop until the predicate function `isearch-success-function' reports the success. But there is already such a loop in `isearch-search'. It's better to reuse it. `isearch-success-function' has another useful property: it overrides the test with `(isearch-range-invisible)'. This will allow searching in invisible texts in a function defined in `isearch-success-function'. The new `isearch-success-function' will also simplify implementing of search in modes where both "widening" and constraining the search space is simultaneously needed, like in Info to search text only in references and menu items through multiple nodes. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RFC: a minor mode that uses GDB like CLI commands
Dan Nicolaescu <[EMAIL PROTECTED]> writes: > Comments, suggestions, etc. are welcome. It would be very good to make this mode to work like edebug (automatically making the source code buffer read-only, etc.) and to have similar keybindings: " " - step "n" - next "c" - cont "g" - go ... -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Type Ahead Find
+'isearch-lazy-highlight-update) (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. @@ -2393,9 +2404,9 @@ (isearch-regexp isearch-lazy-highlight-regexp) (search-spaces-regexp search-whitespace-regexp)) (condition-case nil - (funcall (isearch-search-fun) -isearch-lazy-highlight-last-string -(if isearch-forward + (let ((retry t) + (success nil) + (bound (if isearch-forward (min (or isearch-lazy-highlight-end-limit (point-max)) (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-start @@ -2403,8 +2414,22 @@ (max (or isearch-lazy-highlight-start-limit (point-min)) (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-end - (window-start -t) + (window-start)) + (while retry + (setq success + (funcall (isearch-search-fun) + isearch-lazy-highlight-last-string + bound t)) + (if (or (not success) + (eq (point) bound) + (if isearch-success-function + (funcall isearch-success-function +(match-beginning 0) (match-end 0)) + (text-property-any + (match-beginning 0) (match-end 0) + 'invisible nil))) + (setq retry nil))) + success) (error nil (defun isearch-lazy-highlight-update () -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Type Ahead Find
Miles Bader <[EMAIL PROTECTED]> writes:
> Something like:
>
>Global info I-search: foo
>
> [Maybe "Cross-node" would be better than "Global"?]
>
> or whatever would be even more similar to the existing "Wrapped", get
> the point across well, and address your concern about the prompt size
> bouncing around excessively.
I don't like "[initial node]" too. Your idea of using a prefix
looks better. We could have the following prefixes:
1. In the initial node:
Info I-search: foo
2. Before leaving the initial node:
Failing Info I-search: foo
3. After leaving the initial node:
Cross-node Info I-search: foo
4. When failing for the rest of the manual:
Failing Cross-node Info I-search: foo
5. After wrapping to the top node:
Wrapped Cross-node Info I-search: foo
6. Failing wrapped search:
Failing wrapped Cross-node Info I-search: foo
The prefix "Info " indicates that a special Info search is active
that will wrap to the next node instead of the top of the current node.
This can be implemented by adding a new variable `isearch-type'
holding a search type string and set in the `isearch-search-fun-function'
or the proposed `isearch-success-function'. With both these
functions defined (e.g. to search menu items, references and links
through multiple nodes in Info) the search message will look like this:
Cross-node Links Info regexp I-search: foo
In the function `isearch-message-prefix' the most suitable place for
this variable seems to be after the error prefixes ("failing", "wrapped")
and before generic search type prefixes "regexp", "word", "backward"
(shown by the arrow below):
(if isearch-success "" "failing ")
(if isearch-adjusted "pending " "")
(if (and isearch-wrapped ...) "over")
(if isearch-wrapped "wrapped ")
-> (or isearch-type "")
(if isearch-word "word " "")
(if isearch-regexp "regexp " "")
(if nonincremental "search" "I-search")
(if isearch-forward "" " backward")
(if current-input-method (concat " [" current-input-method-title "]: ")
": ")
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Type Ahead Find
Miles Bader <[EMAIL PROTECTED]> writes: >> I-search: local variables [(emacs)File variables] > >I-search (in node File Variables): local variables > > That's also more similar to other "informational messages" used by > search, e.g., "overwrapped" or whatever. > > [It seems a good idea for space reasons to omit the info-file name; > AFAIK, isearch won't cross info file boundaries.] Perhaps you misunderstood what was in square brackets in my example I-search: local variables [(emacs)File variables] `(emacs)File variables' is not the name of the current node and file. It is the name of the reference to another info file and node which is normally hidden by `Info-hide-note-references'. The purpose of text in square brackets is to show hidden reference names under the search point. This is especially useful in browser-like buffers (e.g. w3m) to show URLs of displayed link texts. Some web browsers (for example, text mode browser ELinks) already has such a feature where during typeahead search URLs are displayed in square brackets: Typeahead: gnu project [http://www.gnu.org/] In Emacs this will look similarly: I-search: gnu project [http://www.gnu.org/] -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Type Ahead Find
Juri Linkov <[EMAIL PROTECTED]> writes:
> (set (make-local-variable 'isearch-success-function)
> ;; isearch only in function names
> (lambda ()
>(save-match-data
>(let* ((re (cdr (assoc nil imenu-generic-expression
> (and (save-excursion (beginning-of-line) (looking-at (car re)))
> (>= (point) (match-beginning (cadr re)))
> (<= (point) (match-end (cadr re
I noticed that `(point)' is not a reliable indicator to find
a matching point. It seems better to give two arguments
(match-beginning 0) and (match-end 0) to `isearch-success-function'.
So a correct example would be:
(set (make-local-variable 'isearch-success-function)
;; isearch only in function names
(lambda (mb me)
(save-match-data
(let ((re (cdr (assoc nil imenu-generic-expression
(and (save-excursion (beginning-of-line) (looking-at (car re)))
(>= mb (match-beginning (cadr re)))
(<= me (match-end (cadr re
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Putting auto-image-file-mode in Options menu
Richard Stallman <[EMAIL PROTECTED]> writes: > 3. By default this mode should be enabled for non-ascii based >image format files like .png, .jpg. This could be achieved >by enabling auto-compression-mode by default and turning >image-mode off by default for ascii based formats. > > I am completely lost here. What does auto-compression-mode have > to do with image-mode? Sorry, I meant auto-image-file-mode. Currently the only one way to visit binary image files in image mode is to enable auto image mode by auto-image-file-mode. However, it doesn't distinguish between ascii based and binary image formats and enables auto image mode for ascii based image files too. But it is desirable to visit ascii based image files in text mode and binary image files in image mode. There should a separate variable with a list of extensions of binary formats (or ascii image formats) to be able after visiting an image file to display it either as an image or as text, without the explicit need to type C-c C-c. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Type Ahead Find
David Kastrup <[EMAIL PROTECTED]> writes: > Again: I don't like the left-right jump of the minibuffer caused by > that. If there really is a need for that kind of information, can't > we put this in the mode-line lighter of Isearch mode? > > Like Isearch/Wrapped, Isearch/X-Node... > > Then the information is available in case of need, but does not take > up room and concentration in the minibuffer. As I see in isearch.el there is the following line in `isearch-mode' function with the comment indicating that someone already considered this idea: (setq isearch-mode " Isearch") ;; forward? regexp? This suggests to put the search type in the mode-line. But I think its biggest drawback is that the search state might be not visible in the mode-line when the mode-line is too wide. For example, in the current buffer when I activate the search I see the text "Isearch" truncated in the mode-line: -=:** *wide reply to David Kastrup* All (32,42)(Message MML Abbrev Fill Isea Any additional information in the mode-line will not be visible at all. So the only place for this information is the minibuffer. Instead of putting it in the message prefix we could put it in the suffix in square brackets: I-search: foo [Failing] I-search: foo [Wrapped] I-search: foo [Failing wrapped] But this doesn't look good either when after wrapping the suffix [Wrapped] remains for the wrapped search. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Todays exercise of sanity (or does "see" really match "not"?)
"Lennart Borgman" <[EMAIL PROTECTED]> writes: > From: "Luc Teirlinck" <[EMAIL PROTECTED]> >> I guess that you have Info-hide-note-references enabled. The reason >> why it stops on "see" is that the actual text in the buffer is: >> (*note Character Sets::). and note matches "not". > > Thanks. I am feeling better. The text "*note " has the `display' text property with the string "see " which is displayed instead of the original text. The function `isearch-range-invisible' (which is used by Info search) doesn't pay attention to the `display' property. It processes only the `invisible' property. It works the same in all Emacs buffers with the `display' property (in `image-mode', `w3m' mode, etc.) where it finds the text not visible on the screen. How to handle this situation is not clear. Should isearch find the displayed text as a contiguous part of the search space? The simplest solution is to treat the `display' property like `invisible' property and to skip the text displayed over the original text. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Possible change to startup.el
Miles Bader <[EMAIL PROTECTED]> writes: > On Tue, 22 Mar 2005 17:15:35 +0900 (JST), Kenichi Handa <[EMAIL PROTECTED]> > wrote: >> What kind of flag do you mean? If you mean "national flag", >> I think it's a very bad idea. > > Why? There is a good article explaining why using country flags as symbols of languages is a bad idea: http://tech.irt.org/articles/js173/ (or http://www.cs.tut.fi/~jkorpela/flags.html). > How about, if there's an appropriate locale set, putting the "in > LANGUAGE" -- except writing that phrase in LANGUAGE instead of > English. That should really help it stand out visually too > (especially with non-latin fonts). There is a list of language names in etc/HELLO (also in the `sample-text' property of the language info), so I think writing that phrase in the same language as defined by locale is a good idea. In addition to the direct link to the appropriate tutorial, it will also immediately indicate that Emacs supports the language of the user. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Todays exercise of sanity (or does "see" really match "not"?)
(isearch-range-invisible beg-found found)) - ;; Skip node header line - (and (save-excursion (forward-line -1) - (looking-at "\^_")) - (forward-line (if backward -1 1))) - ;; Skip Tag Table node - (save-excursion - (and (search-backward "\^_" nil t) -(looking-at "\^_\nTag Table")) + (or (null found) + (not (if isearch-success-function +(funcall isearch-success-function beg-found found) + (Info-search-success-function beg-found found) (let ((search-spaces-regexp Info-search-whitespace-regexp)) (if (if backward (re-search-backward regexp nil t) @@ -1667,9 +1649,27 @@ nil 'Info-search-history))) (Info-search regexp bound noerror count 'backward)) +(defun Info-search-success-function (beg-found found) + (save-match-data +(let ((backward (< found beg-found))) + (not + (or + ;; Skip `*Note' + (Info-get-token (point) "\\*note[ \n\t]+" "\\(\\*note[ \n\t]+\\)") + ;; Skip node header line + (and (save-excursion (forward-line -1) +(looking-at "\^_")) +(forward-line (if backward -1 1))) + ;; Skip Tag Table node + (save-excursion + (and (search-backward "\^_" nil t) + (looking-at "\^_\nTag Table" + (defun Info-isearch-search () (if Info-isearch-search (lambda (string &optional bound noerror count) + (setq isearch-message-prefix-add + (if Info-isearch-initial-node "X-node " "")) (if isearch-word (Info-search (concat "\\b" (replace-regexp-in-string "\\W+" "W+" -- 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: Why is "note" hidden by "see"?
"Lennart Borgman" <[EMAIL PROTECTED]> writes: > Maybe this is not the time to ask, but I simply do not understand why an > overlay is used in the Info buffer to hide "note" and display "see". Why > can't the text in the buffer be changed instead? Would not that be better > for the search functions? Or does that give some new problems? Is the actual > text in Info buffer important in some way? "*note" text in Info buffer is important since Info uses it to find cross references. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Putting auto-image-file-mode in Options menu
Richard Stallman <[EMAIL PROTECTED]> writes:
> 2. Perhaps image-mode should be minor mode for extensions like
>.xbm and .xpm which already have associated major mode c-mode
>in auto-mode-alist.
>
> Someone else can do that.
I can't find a solution better than below.
With this patch `image-mode' visits an image file either in the major
mode specified by `image-auto-mode-alist' and Image minor mode, or in
the Image major mode with displaying an image file as the actual image
initially. The first works for .xbm and .xpm filename extensions, the
second for the rest of image types.
Index: lisp/files.el
===
RCS file: /cvsroot/emacs/emacs/lisp/files.el,v
retrieving revision 1.750
diff -u -r1.750 files.el
--- lisp/files.el 19 Mar 2005 19:58:34 - 1.750
+++ lisp/files.el 22 Mar 2005 19:36:00 -
@@ -1794,7 +1794,6 @@
("\\.dtd\\'" . sgml-mode)
("\\.ds\\(ss\\)?l\\'" . dsssl-mode)
("\\.js\\'" . java-mode) ; javascript-mode would be better
- ("\\.x[bp]m\\'" . c-mode)
;; .emacs or .gnus or .viper following a directory delimiter in
;; Unix, MSDOG or VMS syntax.
("[]>:/\\]\\..*\\(emacs\\|gnus\\|viper\\)\\'" . emacs-lisp-mode)
Index: lisp/image-mode.el
===
RCS file: /cvsroot/emacs/emacs/lisp/image-mode.el,v
retrieving revision 1.3
diff -u -r1.3 image-mode.el
--- lisp/image-mode.el 21 Mar 2005 17:42:36 - 1.3
+++ lisp/image-mode.el 22 Mar 2005 19:41:20 -
@@ -49,6 +49,17 @@
;;;###autoload (push '("\\.ppm\\'" . image-mode) auto-mode-alist)
;;;###autoload (push '("\\.pnm\\'" . image-mode) auto-mode-alist)
+(defvar image-auto-mode-alist
+ '(("\\.x[bp]m\\'" . c-mode))
+ "*Alist of image filename patterns vs major mode functions.
+Visiting an image file whose name matches REGEXP specifies FUNCTION
+as the major mode function to use. After calling FUNCTION,
+Image minor mode will be called on the buffer.
+
+If FUNCTION is nil, or a pattern is not specified, then Image
+major mode will be called, and an image file will be displayed
+as the actual image initially.")
+
(defvar image-mode-map
(let ((map (make-sparse-keymap)))
(define-key map "\C-c\C-c" 'image-toggle-display)
@@ -61,13 +72,33 @@
You can use [image-toggle-display]
to toggle between display as an image and display as text."
(interactive)
- (kill-all-local-variables)
- (setq mode-name "Image")
- (setq major-mode 'image-mode)
- (use-local-map image-mode-map)
- (run-mode-hooks 'image-mode-hook)
- (message (substitute-command-keys
- "Type \\[image-toggle-display] to view the image as an image.")))
+ (if (assoc-default buffer-file-name image-auto-mode-alist
+'string-match)
+ (let ((auto-mode-alist image-auto-mode-alist))
+ (set-auto-mode)
+ (image-minor-mode t))
+(kill-all-local-variables)
+(setq mode-name "Image")
+(setq major-mode 'image-mode)
+(use-local-map image-mode-map)
+(unless (get-text-property (point-min) 'display)
+ (image-toggle-display))
+(run-mode-hooks 'image-mode-hook))
+ (message (concat (substitute-command-keys
+ "Type \\[image-toggle-display] to view the image as ")
+ (if (get-text-property (point-min) 'display)
+ "text" "an image") ".")))
+
+;;;###autoload
+(define-minor-mode image-minor-mode
+ "Toggle Image minor mode.
+With arg, turn Image minor mode on if arg is positive, off otherwise.
+See the command `image-mode' for more information on this mode."
+ nil " Image" image-mode-map
+ :group 'image
+ :version "22.1"
+ (unless (or (eq major-mode 'image-mode) image-minor-mode)
+(use-local-map image-mode-map)))
(defun image-toggle-display ()
"Start or stop displaying an image file as the actual image.
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Todays exercise of sanity (or does "see" really match "not"?)
[EMAIL PROTECTED] (Kim F. Storm) writes: > Instead we can explicitly put an inivisible property together with the > display property on a priece of "hidden" text which should be ignored > by searches. That need a little work to check all uses of display > properties, but it doesn't break any old code relying on the current > behaviour. Yes, there are existing packages where finding the underlying text might be useful. For example, in w3m images are placed over the text extracted from the ALT="" image HTML attribute. Finding it with isearch seems useful. > I don't know whether it actually works to put both invisible and > display on some text (with the effect of showing the image and > ignoring the under-laying text). Would someone make some examples > to check it? The `display' property takes precedence over the `invisible' property: (progn (goto-char (point-min)) (insert "abcdefghi\n") (add-text-properties (- (point) 9) (- (point) 2) `(display ,(create-image (expand-file-name "gnu.xpm" data-directory) 'xpm) invisible t)) (goto-char (point-min)) (search-forward "def")) And the image is visible. Incremental search skips the underlying text, but low-level search functions find it. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Possible change to startup.el
Richard Stallman <[EMAIL PROTECTED]> writes:
> Having the list of languages is good, but I think we also need to
> include a message in the user's language (as derived from the current
> locale), as others have suggested.
Below is an alist of locales and tutorial titles extracted from first lines
of etc/TUTORIAL* files to put onto the link to the corresponding tutorial
depending on the current locale:
'((nil . "Emacs tutorial")
("bg". "ÐÑÐÐÐÑÐ ÐÐ Ñ")
("cn". "Emacs åéæå")
("cs". "tutoriÃl k Emacsu")
("de". "EinfÃhrung in Emacs")
("es". "tutorial de Emacs")
("fr". "Didacticiel d'Emacs")
("it". "Esercitazione di Emacs")
("ja". "Emacs åéã")
("ko". "ìëì(Emacs) ëë")
("nl". "Emacs-inleiding")
("pl". "krÃtki samouczek Emacsa")
("pt_BR" . "tutorial do Emacs")
("ro". "tutorialului de Emacs")
("ru". "ÑÑÐ Emacs")
("sk". "tÃtorial k Emacsu")
("sl". "Prvo berilo za Emacs")
("sv". "anvÃndarhandledningen till Emacs")
("th".
"à")
("zh". "Emacs åéæå"))
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Todays exercise of sanity (or does "see" really match "not"?)
Richard Stallman <[EMAIL PROTECTED]> writes: > 1. Set both `invisible' and `display' properties. It seems the >display engine ignores the `invisible' property when the `display' >property is present. But isearch still respects it. > > I agree that that way is the best--if we decide that the current > behavior when invisible and display are both present is the correct > one. Maybe it is the right behavior; I see no reason to think it > should be changed. But it would be nice to be really sure. Even though adding the `invisible' property will allow isearch to skip the text under the `display' property for Emacs packages where this is desirable, it will not solve the original problem in Info reported in the initial message of this thread. Info-search operates on plain text Info files without text properties set by Info-fontify. So it should rely on pure syntactical elements like `*Note ' tags. This is implemented in my latest patch. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Todays exercise of sanity (or does "see" really match "not"?)
Luc Teirlinck <[EMAIL PROTECTED]> writes: > Just to make sure: did you check that your patch works correctly when > Info-hide-note-references is nil, where `not' _should_ match `*Note'? > Personally, I have not had the time to follow this thread completely, > but at first view, nothing in this seem like a bug in any search > function to me. To me, it seems like an obvious bug in > Info-hide-note-references; it abuses the display property for editing > purposes. It is easy to add a test for Info-hide-note-references, but I think it would be more convenient to skip the `*Note ' tag even when it is visible. Searching for "not" is too tiresome when search stops at every cross reference. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Todays exercise of sanity (or does "see" really match "not"?)
>It is easy to add a test for Info-hide-note-references, but I think it >would be more convenient to skip the `*Note ' tag even when it is visible. >Searching for "not" is too tiresome when search stops at every cross >reference. > > A search for `not' is going to stop at many places. Searching should > be predictable. Please do not start adding tons of exceptions and > "exceptions to exceptions" to searching by trying to double guess the > user. > > A case-insensitive non-word search for `not' _should_ match `*Note'. `*Note' is a special tag, not part of the text. For instance, Web browsers don't display tags, and don't allow them to interfere while searching. Some browsers provide two search modes: search for text including link text, and separate mode to search only link text. And nobody asks for an ability to search for HTML tags like `http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Putting auto-image-file-mode in Options menu
> So I think you should leave the function `image-mode' unchanged
> and define a new function `image-mode-maybe' which does the new job.
> Then the entries in auto-mode-alist can call `image-mode-maybe'
> and `image-mode-maybe' can conditionally call `image-mode'.
>
> Want to try it that way?
I don't like this solution because it is too ad-hoc.
How about the following?
Currently the first line of the file can specify several modes:
-*- mode: MODE-NAME; mode: MINOR-MODE-NAME; ... -*-
But why can't `auto-mode-alist' allow to do the same?
If `auto-mode-alist' allowed to put a list of modes instead
of one mode then the solution would be simple:
(push '("\\.png\\'" . image-mode) auto-mode-alist)
(push '("\\.xbm\\'" (c-mode image-minor-mode)) auto-mode-alist)
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Todays exercise of sanity (or does "see" really match "not"?)
> Info-search operates on plain text Info files without text properties > set by Info-fontify. > > How does that happen? Does Info-fontify sometimes fail to be called? Info-search searches the text on plain unfontified Info files (sometimes fontification remains on parts of the Info file with visited nodes where fontification was done, but search should work for general case with unfontified Info files) and when it finds it narrows the Info file buffer to the found node and calls `Info-fontify' on that node. Fontifying the whole Info file before starting the search only for the sake of putting text properties to help Info-search to find the text that will be invisible after fontification is too costly operation. Info-search should anticipate what text will be invisible (or will be replaced by the `display' property). To do this it should use rules similar to rules used by `Info-fontify' and skip the text that `Info-fontify' will make invisible. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Todays exercise of sanity (or does "see" really match "not"?)
> `*Note' _is_ a part of the text. It occurs in the output produced by > `makeinfo --plaintext', which, since it is entirely plain text, does > not have _any_ special markers. Anyway, rather than to argue over > terminology, the important thing is: the user sees it, search has to > find it. Note that both `s' and `C-s' in standalone Info correctly > match `*Note'. If `not' would not match `*Note' in Emacs Info with > Info-hide-note-references set to t, then this would be very confusing. Did you mean "Info-hide-note-references set to nil"? > It would make people start to doubt the reliability of search in > Emacs. (What _other_ stuff does search in Emacs ignore?) It would be > an outright bug. Isearch ignores text with `invisible' text properties and hidden overlays according to `buffer-invisibility-spec'. Info-search ignores Info files headers, header lines and Tag Table nodes. > Sorry for misspelling your name once more in my previous reply. > I do not know why I keep doing this. I guess it's because you manually type a citation line every time you write a response. To insert it automatically you can use message.el and set `message-citation-line-function' to `message-insert-citation-line'. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Auto-fill-mode bug: unbreakable space lost
BTW, now Emacs highlights non-breaking space and soft hyphen only for two charsets. Perhaps support for all other charsets should be added to xdisp.c? I.e. to test for the following characters: iso8859-2: 0x920 0x92d iso8859-3: 0x9a0 0x9ad iso8859-4: 0xa20 0xa2d iso8859-5: 0xe20 0xe2d iso8859-6: 0xba0 0xbad iso8859-7: 0xb20 0xb2d iso8859-8: 0xc20 0xc2d iso8859-9: 0xea0 0xead iso8859-14: 0xfa0 0xfad iso8859-15: 0xf20 0xf2d -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Possible change to startup.el
> i empathize w/ the authors of the tutorials who may not
> wish to change their text.
>
> This is a small change in the packaging of *translations* of a part of
> Emacs, which are also meant ascontributions to Emacs. If some
> translator gets worked up about it, that is not our problem.
>
> Unless there is a practical problem with the solution I've proposed,
> that's what we will use.
Different languages have different conventions for document titles:
some require to upper-case all letters, some - to capitalize all words,
others - to capitalize only the first word ("EMACS TUTORIAL",
"Emacs Tutorial", "Emacs tutorial"), different conventions for
centering the title, etc. This can't be done without the help of
translators of the Emacs tutorial. But it makes no sense to bother
them now for such a small change. What is more useful is to provide
complete internationalization of Emacs after the next release (there
is already an entry in etc/TODO) for Emacs 23 (Unicode-2) and to ask
translation teams to translate menus, messages as well as the
splash screen.
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
auto-compression-mode (was: Putting auto-image-file-mode in Options menu)
> Can't this program just set the find-file-literally variable to t? > That will prevent auto-compression-mode from trying to compress the > contents > when you save. > > I will see if that works. What was the outcome? Can we turn `auto-compression-mode' on by default? -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: announcing thaiword.el?
> Is it ok to install a change that binds such word-oriented > commands as M-f, M-b, M-t, M-d, M-DEL to the functions > recognizing thai words when a user select Thai lang. env? BTW, there is also the variable `sentence-end-without-period' for Thai texts. Maybe it should be enabled in Thai lang.envs too. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Possible change to startup.el
The text "Emacs Tutorial" on the splash screen should not be replaced with a translation at all because it is the text of the menu item and menu items under the Help menu are not translated. The splash screen says this explicitly: Important Help menu items: === Emacs Tutorial Learn-by-doing tutorial for using Emacs efficiently == Emacs FAQFrequently asked questions and answers ... Until menu items get translated, the text of the menu item should remain the same on the splash screen. BTW, there is other incorrect menu item title on the splash screen: Useful File menu items: Exit Emacs(Or type Control-x followed by Control-c) Recover Session Recover files you were editing before a crash === There is no such menu item. The correct menu item title is "Recover Crashed Session". -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Possible change to startup.el
> there are five elements on the tutorial line: > > TITLE -- "Emacs Tutorial" translated for the current language env > EN-TITLE -- English text "Emacs Tutorial" > EN-BLURB -- English text "Learn-by-doing tutorial ... efficiently." > tab -- a tab character (0x9) > LIST-OF-AVAILABLE-TUTORIALS -- list of locale suffixes > > the pre-patch presentation format is: > > EN-TITLE tab EN-BLURB > > the patched presentation format is: > > (if data-directory is not availble) > EN-TITLE tab EN-BLURB > > (if filename resolved from consulting language env is "TUTORIAL") > EN-TITLE tab LIST-OF-AVAILABLE-TUTORIALS > > (otherwise) > TITLE tab (EN-TITLE) LIST-OF-AVAILABLE-TUTORIALS > > what do you propose for the presentation format, based on these > conditions and elements? Since the splash screen displays menu items, I think that the last case (labelled as `otherwise') should have two lines with menu items: Important Help menu items: EN-TITLE tab EN-BLURB EN-TITLE-LANG tab TITLE LIST-OF-AVAILABLE-TUTORIALS where EN-TITLE-LANG is the menu item with English text "Emacs Tutorial (choose language)..." And for the case `(if filename resolved from consulting language env is "TUTORIAL")': Important Help menu items: EN-TITLE tab EN-BLURB EN-TITLE-LANG tab LIST-OF-AVAILABLE-TUTORIALS This raises another issue: I can't imagine how a non-English speaking novice can start the tutorial? Well, if we now add the English menu item "Emacs Tutorial (choose language)..." to the splash screen then she might find it under the Help menu and select it. This creates the buffer with a list of language completion. But how she can select a language when she knows nothing about Emacs! With keyboard, cursor keys don't work because she has to switch buffers with `C-x o' to the completion buffer. And even the left mouse button doesn't work when slowly clicked on a language in the completion buffer with a delay more than 350ms! -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Possible change to startup.el
After a week of messing with tutorial files we eventually reached the point where tutorial files are no more correct: some files now miss important references to copyright conditions and not grammatically correct anymore. Many languages don't allow titles ended with a period. They should be restored to their initial correct state. There was nothing wrong with tutorial files before changes. A more correct way to implement this feature is to add tutorial titles as a new property of the language info-alist similarly to the `sample-text' property which contains a sample text in the same language. With this getting a tutorial title will be very easy: (get-language-info current-language-environment 'tutorial-title) Also currently the splash screen is misleading: Emacs Tutorial Learn how to use Emacs efficiently (TUTORIAL TITLE) It suggest users to select "Emacs Tutorial" to get the tutorial in their native languages. This is wrong menu item name. More correct text on the splash screen would be: Emacs Tutorial Learn how to use Emacs efficiently Emacs Tutorial (choose language)... TUTORIAL TITLE It would be good also to create a X menu with a list of languages after selecting "Emacs Tutorial (choose language)..." menu item to help Emacs novices to select their languages. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Possible change to startup.el
> Help->Emacs Tutorial _is_ such a menu item. Type "C-h k" followed by > selecting that menu item, and you will see this in the *Help* buffer: > >runs the command > help-with-tutorial >which is an interactive compiled Lisp function in `help-fns'. > It is bound to C-h t, t, . > (help-with-tutorial &optional ARG) > > Select the Emacs learn-by-doing tutorial. > If there is a tutorial version written in the language > of the selected language environment, that version is used. > If there's no tutorial in that language, `TUTORIAL' is selected. > With ARG, you are asked to choose which language. > > So I don't understand why Juri says that this is misleading. Juri, > can you explain? I was mislead by the "Emacs Tutorial (choose language)..." menu item. I thought that "Emacs Tutorial" always selects the English tutorial while "Emacs Tutorial (choose language)..." selects a tutorial in any language. The fact that English menu item "Emacs Tutorial" can select a non-English tutorial is misleading too. Ideally the menu item "Emacs Tutorial" should be translated into the same language whose tutorial it selects. This requires support for multi-language menus. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Possible change to startup.el
>> If the reference to copyright conditions was deleted, could you put it >> back? > > He won't be able to do this unless he speak all of the languages already > translated. I might try to do this only if respective maintainers don't take care of this. > If one would like to help, just remember that the rule is: > > "The first line of every tutorial must begin with a sentence saying > "Emacs Tutorial" in the respective language. This should be > followed by "See end for copying conditions", likewise in the > respective language." Your rules don't mention a period. Does this mean that a period is not required now. If so, I agree. There are languages even with no periods at all. It's better to put just the title on the first line without a period. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Fwd: Re: junk in *grep* buffers
> This is still not enough when there are multiple matches on the same line > close to each other. Since we delete some text during fontification > font-lock-fontify-keywords-region will skip over some of the following > text when it readjusts point. > > Is it possible to adjust the position at which > font-lock-fontify-keywords-region will set point, to compensate for > the deletion? Could the code use a marker to maintain that position? > Then it would be relocated automatically. The following hack fixes the problem, but this is an imperfect solution. It sets the local variable `pos' from `font-lock-fontify-keywords-region' to avoid changing the current position on the line: ;; Ensure forward progress. (if (< (point) pos) (goto-char pos)) Index: lisp/progmodes/grep.el === RCS file: /cvsroot/emacs/emacs/lisp/progmodes/grep.el,v retrieving revision 1.36 diff -u -r1.36 grep.el --- lisp/progmodes/grep.el 7 May 2005 16:21:12 - 1.36 +++ lisp/progmodes/grep.el 9 May 2005 22:16:22 - @@ -303,7 +303,8 @@ ;; Delete markers with `replace-match' because it updates ;; the match-data, whereas `delete-region' would render it obsolete. (replace-match "" t t nil 3) -(replace-match "" t t nil 1) +(replace-match "" t t nil 1) +(setq pos (point)) "Additional things to highlight in grep output. This gets tacked on the end of the generated expressions.") -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: read-directory-name
>Sorry, that was wrong. It should have been: > > ! (if initial (concat dir initial) dir default-directory))) > > Obviously, that was even _more_ wrong. > It should have been the following, as in Juri's original patch: > > - (if initial (concat dir initial) default-directory))) > + (or (if initial (concat dir initial)) > + dir > + default-directory))) I haven't installed this patch, because I've found that `read-directory-name' inherits its behavior from `read-file-name', so changing `read-directory-name' would make it inconsistent with `read-file-name'. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Overlay arrow in *compilation* and *grep* buffers
> Currently simple.el has: > > (put 'next-error-overlay-arrow-position 'overlay-arrow-string "=>") > > but this could be removed as it is the default now anyway (I think Juri > disappeared again before 2005-04-08). Sorry. I traveled to my friend. She lives 1000km from me. > I suggest this latter change until Juri (or maybe Stefan) comes up with a > better solution that will work with "=>". I suggest adding a new option defining how to highlight lines in compilation/grep buffers, similar to `next-error-highlight' which defines highlighting in source buffers. It will replace `compilation-context-lines': (defcustom compilation-message-highlight 0 "*Highlighting of locations in the compilation buffer. If number, display this many lines of leading context before message. If t, use persistent overlays fontified in next-error face. If nil, don't highlight the locus in the compilation buffer. If `fringe-arrow', indicate the locus by the fringe arrow." :type '(choice (number :tag "Context lines") (const :tag "Persistent overlay" t) (const :tag "No highlighting" nil) (const :tag "Fringe arrow" 'fringe-arrow)) :group 'compilation :version "22.1") Since the number of context lines and fringe arrow are mutually exclusive values, there will be no problem with an arrow overlapping a file name in the compilation buffer, because by default there will be no arrow at all. Users wishing to use arrows can set `compilation-message-highlight' to `fringe-arrow' in .emacs conditionally depending on the presence of fringes. BTW, I don't understand the reason of adding `(defvar next-error-highlight-timer)' to compile.el on 2005-04-23. There is already the same defvar in simple.el. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: flyspell bug
>> To: emacs-devel@gnu.org >> From: Magnus Henoch <[EMAIL PROTECTED]> >> Date: Wed, 27 Apr 2005 16:04:45 +0200 >> Subject: Re: flyspell bug >> >> So it seems that the variable ispell-really-aspell is moderately >> useful, as there are three situations: ispell, aspell in ispell >> compatibility mode, and "real" aspell. >> >> The following patch eliminates the middle case. The documentation of >> aspell 0.50.5 claims that it supports the "list" command, but I >> haven't tested it. >> >> - --- orig/lisp/textmodes/ispell.el >> +++ mod/lisp/textmodes/ispell.el >> @@ -301,7 +301,8 @@ >>:type 'integer >>:group 'ispell) >> >> - -(defcustom ispell-program-name "ispell" >> +(defcustom ispell-program-name (or (executable-find "aspell") >> + "ispell") >>"Program invoked by \\[ispell-word] and \\[ispell-region] commands." >>:type 'string >>:group 'ispell) > > Thanks, I installed a slightly different change (using locate-file > instead of executable-find). Now with using a non-default dictionary ispell.el fails with the error message telling that ispell can't find a dictionary in /usr/lib/aspell-0.60/. That's becuase ispell and aspell have different sets of dictionaries with different names. ispell.el shouldn't insist on using "aspell" instead of "ispell" even when aspell executable happens to be in exec-path. Perhaps the following patch will do what was intended to fix the original problem: Index: lisp/textmodes/ispell.el === RCS file: /cvsroot/emacs/emacs/lisp/textmodes/ispell.el,v retrieving revision 1.162 diff -u -r1.162 ispell.el --- lisp/textmodes/ispell.el7 May 2005 16:04:39 - 1.162 +++ lisp/textmodes/ispell.el10 May 2005 00:05:05 - @@ -302,7 +302,8 @@ :group 'ispell) (defcustom ispell-program-name - (or (locate-file "aspell" exec-path exec-suffixes 'file-executable-p) + (or (and ispell-really-aspell + (locate-file "aspell" exec-path exec-suffixes 'file-executable-p)) "ispell") "Program invoked by \\[ispell-word] and \\[ispell-region] commands." :type 'string @@ -815,7 +816,11 @@ (goto-char (point-min)) (let (case-fold-search) (setq ispell-really-aspell -(and (search-forward "(but really Aspell " nil t) t + (and (search-forward "(but really Aspell " nil t) t)) + (if ispell-really-aspell + (let ((exec (locate-file "aspell" exec-path exec-suffixes + 'file-executable-p))) + (if exec (setq ispell-program-name exec)) (kill-buffer (current-buffer))) result)) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: flyspell bug
>> Index: lisp/textmodes/ispell.el >> === >> RCS file: /cvsroot/emacs/emacs/lisp/textmodes/ispell.el,v >> retrieving revision 1.162 >> diff -u -r1.162 ispell.el >> --- lisp/textmodes/ispell.el 7 May 2005 16:04:39 - 1.162 >> +++ lisp/textmodes/ispell.el 10 May 2005 00:05:05 - >> @@ -302,7 +302,8 @@ >>:group 'ispell) >> >> (defcustom ispell-program-name >> - (or (locate-file "aspell" exec-path exec-suffixes 'file-executable-p) >> + (or (and ispell-really-aspell >> + (locate-file "aspell" exec-path exec-suffixes 'file-executable-p)) >>"ispell") > > ??? Does this really work? AFAIK, ispell-really-aspell is set when > ispell.el invokes the speller for the first time, not before that. So > this defcustom wuill never try aspell, I think. This may be needed when users set `ispell-really-aspell' explicitly in .emacs. However, after looking at ispell.el it seems that `ispell-check-version' always is called before invoking the speller for the first time. So maybe the second part of my patch makes the search for aspell in defcustom unnecessary, and its initial value should be reverted to "ispell". Note that automatic changing the value of `ispell-program-name' in `ispell-check-version' might surprise users of the aspell's implementation of ispell. Anyhow, this is the better place to change ispell program name to "aspell" than defcustom. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Fwd: Re: junk in *grep* buffers
>> Could the code in font-lock-fontify-keywords-region use a marker to >> maintain that position? Then it would be relocated automatically. > > Would the patch below do the trick? Yes, it fixes the problem of too close multiple matches. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: flyspell bug
>> Cc: emacs-devel@gnu.org, [EMAIL PROTECTED], >> [EMAIL PROTECTED], [EMAIL PROTECTED] >> From: Juri Linkov <[EMAIL PROTECTED]> >> Date: Tue, 10 May 2005 08:04:07 +0300 >> >> Note that automatic changing the value of `ispell-program-name' >> in `ispell-check-version' might surprise users of the aspell's >> implementation of ispell. Anyhow, this is the better place to >> change ispell program name to "aspell" than defcustom. > > I think the right thing to do is to modify what's currently in CVS so > that it doesn't fail with non-English dictionaries. Can you describe > how it fails in that case, and why? ispell and aspell use different dictionaries. Changing the default ispell program name from "ispell" to "aspell" is an incompatible change for users configured Emacs to use ispell dictionaries, not aspell dictionaries. `ispell-program-name' can be changed automatically to "aspell" only when `ispell-check-version' detects aspell's implemention of ispell, i.e. a program for which `ispell -v' returns: @(#) International Ispell Version 3.1.20 (but really Aspell 0.50.5) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: flyspell bug
> (1) user doesn't have aspell installed > (2) user has aspell installed, but configured it to use ispell's > dictionaries > (3) user has aspell installed and wants to use aspell's dictionaries There is also a fourth situation: (4) user has aspell installed, but uses ispell with ispell's dictionaries > I know how to detect (1) -- use locate-file or similar technique to > look for aspell. But how to distinguish between (2) and (3)? AFAIK, the situation (2) doesn't exist. There are the following situations instead: (2) user has aspell installed and uses the compatibility script `ispell' as a wrapper around aspell with aspell's dictionaries (3) user has aspell installed and uses `aspell' executable with aspell's dictionaries (2) is detected by checking the output of `ispell -v'. (3) is configured by users by changing ispell-program-name to "aspell". After the change in flyspell.el it doesn't work with the `ispell' compatibility script. Maybe ispell-really-aspell should have more values to distinguish between (2) and (3). (3) can be detected by matching ispell-program-name against the regexp "aspell$". -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: flyspell bug
> ispell.el shouldn't insist on using "aspell" instead of "ispell" > even when aspell executable happens to be in exec-path. > > Of course it should. aspell is a GNU package. > > What led you to think the contrary? I had the impression that the intention was to fix a problem of using aspell with ispell.el. However, the installed change is too radical. It affects all users of ispell having aspell in exec-path. If switching from ispell to aspell was intentional (I can't find a discussion about this on emacs-devel) then we need to document it in the NEWS file with a warning about possible problems, to inform maintainers of ispell.el and aspell about this change asking them to update documentation, web pages, and to test aspell dictionaries to confirm their compatibility with ispell.el. But perhaps switching from ispell to aspell was too hasty change. According to aspell's TODO list, ispell.el is not quite ready for using aspell. The Info node (info "(aspell)Important Items") has: Things that need to be done --- * Enhance *ispell.el* so that it will work better with GNU Aspell. _[In Progress]_. I don't know what is the current status of this TODO item. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: flyspell bug
To my surprise I just discovered that the latest development release of ispell.el at http://kdstevens.com/~stevens/ispell-page.html already supports the option to choose between ispell and aspell: (defcustom ispell-prefer-aspell nil "*Select preference between using the `ispell' or `aspell' program. `ispell' is used by default. When this variable is set, `aspell' is used if it is installed on the system." :type 'boolean :group 'ispell) (defcustom ispell-program-name (or (and (exec-installed-p "aspell") (or ispell-prefer-aspell (not (exec-installed-p "ispell"))) "aspell") "ispell") "Program invoked by \\[ispell-word] and \\[ispell-region] commands." :type 'string :group 'ispell) This seems right to me. Are there any reasons why the latest development release of ispell.el is not synced with Emacs CVS? -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Overlay arrow in *compilation* and *grep* buffers
e.el --- lisp/simple.el 8 May 2005 19:33:14 - 1.720 +++ lisp/simple.el 13 May 2005 04:55:15 - @@ -89,11 +89,11 @@ If number, highlight the locus in next-error face for given time in seconds. If t, use persistent overlays fontified in next-error face. If nil, don't highlight the locus in the source buffer. -If `fringe-arrow', indicate the locus by the fringe arrow." +If `arrow', indicate the locus by the fringe or overlay arrow." :type '(choice (number :tag "Delay") (const :tag "Persistent overlay" t) (const :tag "No highlighting" nil) - (const :tag "Fringe arrow" 'fringe-arrow)) + (const :tag "Arrow" 'arrow)) :group 'next-error :version "22.1") @@ -102,14 +102,17 @@ If number, highlight the locus in next-error face for given time in seconds. If t, use persistent overlays fontified in next-error face. If nil, don't highlight the locus in the source buffer. -If `fringe-arrow', indicate the locus by the fringe arrow." +If `arrow', indicate the locus by the fringe or overlay arrow." :type '(choice (number :tag "Delay") (const :tag "Persistent overlay" t) (const :tag "No highlighting" nil) - (const :tag "Fringe arrow" 'fringe-arrow)) + (const :tag "Arrow" 'arrow)) :group 'next-error :version "22.1") +(defvar next-error-highlight-overlay nil + "Overlay used to highlight next-error matches.") + (defvar next-error-highlight-timer nil) (defvar next-error-overlay-arrow-position 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: flyspell bug
> If you use "-d DICT" where DICT does NOT end in ".hash" or is a complete > path to an Ispell dictionary than it should work as you suggested. > > If this already works, how come the problem happens? > Why doesn't this make everything work right already? Users may have different sets of dictionaries installed for Ispell and Aspell. After replacing the default program name "ispell" by "aspell", ispell.el may fail when a configured Ispell's dictionary name doesn't match any of installed Aspell dictionary names. To avoid such failure, ispell.el could check the Aspell's exit code and in case when Aspell can't find a dictionary name among its list of available dictionaries, ispell.el could change the default program name from "aspell" to "ispell" and try to run Ispell with the same dictionary name. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: "Recent" changes to compilation-mode?
> Yeah, there's a tiny arrow there. The problem is that the diagnostics > typically span several lines and are often quite dense, and the arrow > isn't quite enough to help me distinguish the boundaries of the > diagnostic being indicated by the arrow. Would it be possible to add > some kind of highlighting to the current error, similar to what I get > when hovering the mouse over it? Recently I proposed a patch that does exactly what you want, i.e. highlights the whole current error message with a special user option. You can get the patch here: http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00561.html This patch is too good for the coming release. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: org-mode and mode hooks.
e) help.el:describe-mode (pretty-minor-mode pretty-minor-mode pretty-minor-mode pretty-minor-mode pretty-minor-mode pretty-minor-mode pretty-minor-mode) help-mode.el:help-mode (view-mode) fringe.el:fringe-mode (set-fringe-mode) fringe.el:set-fringe-mode (fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode fringe-mode) font-core.el:font-lock-change-mode (font-lock-mode) follow.el:turn-off-follow-mode (follow-mode) follow.el:turn-on-follow-mode (follow-mode) files.el:normal-mode (default-major-mode fundamental-mode set-auto-mode) faces.el:frame-set-background-mode (bg-mode frame-background-mode old-bg-mode background-mode bg-mode old-bg-mode background-mode bg-mode) emerge.el:emerge-set-merge-mode (emerge-fast-mode emerge-fast-mode emerge-edit-mode) emerge.el:emerge-edit-mode (emerge-mode emerge-fast-mode) emerge.el:emerge-fast-mode (emerge-mode emerge-edit-mode) ehelp.el:electric-describe-mode (describe-mode) ehelp.el:electric-help-mode (view-mode) ediff-merg.el:ediff-set-merge-mode (normal-mode) cus-edit.el:customize-mode (custom-group-of-mode custom-group-of-mode custom-group-of-mode) completion.el:dynamic-completion-mode (completion-setup-fortran-mode) calculator.el:calculator-radix-mode (calculator-radix-input-mode calculator-radix-output-mode) bindings.el:mode-line-auto-fill-mode (auto-fill-mode) bindings.el:mode-line-abbrev-mode (abbrev-mode) autorevert.el:turn-on-auto-revert-tail-mode (auto-revert-tail-mode) autorevert.el:turn-on-auto-revert-mode (auto-revert-mode) array.el:array-mode (overwrite-mode) arc-mode.el:archive-mode (default-major-mode auto-save-mode archive-subfile-mode archive-subfile-mode) gnus-dired.el:turn-on-gnus-dired-mode (gnus-dired-mode) gnus-dired.el:gnus-dired-mode (dired-mode gnus-add-minor-mode) mml.el:mml-mode (gnus-add-minor-mode) gnus-undo.el:gnus-undo-mode (gnus-add-minor-mode) gnus-topic.el:gnus-topic-mode (gnus-group-mode gnus-add-minor-mode) gnus-sum.el:gnus-dead-summary-mode (gnus-summary-mode gnus-add-minor-mode) gnus-sum.el:gnus-summary-mode (turn-on-gnus-mailing-list-mode summary-mode) gnus-start.el:gnus-slave-mode (gnus-add-minor-mode) gnus-salt.el:gnus-tree-mode (tree-mode) gnus-salt.el:gnus-binary-mode (gnus-summary-mode gnus-add-minor-mode) gnus-salt.el:gnus-pick-mode (gnus-summary-mode gnus-add-minor-mode) gnus-ml.el:gnus-mailing-list-mode (gnus-summary-mode gnus-add-minor-mode) gnus-ml.el:turn-on-gnus-mailing-list-mode (gnus-mailing-list-mode) gnus-group.el:gnus-group-mode (group-mode gnus-undo-mode gnus-slave-mode) gnus-gl.el:gnus-grouplens-mode (gnus-summary-mode menu-bar-mode gnus-add-minor-mode) gnus-draft.el:gnus-draft-mode (gnus-summary-mode gnus-add-minor-mode mml-mode) gnus-art.el:gnus-article-mode (article-mode) gnus-agent.el:gnus-agent-mode (gnus-group-mode) calc.el:calc-trail-mode (fundamental-mode) calc.el:calc-mode (calc-algebraic-mode) calc-mode.el:calc-units-simplify-mode (calc-set-simplify-mode) calc-mode.el:calc-ext-simplify-mode (calc-set-simplify-mode) calc-mode.el:calc-alg-simplify-mode (calc-set-simplify-mode) calc-mode.el:calc-bin-simplify-mode (calc-set-simplify-mode) calc-mode.el:calc-default-simplify-mode (calc-set-simplify-mode calc-num-simplify-mode calc-no-simplify-mode calc-bin-simplify-mode calc-alg-simplify-mode calc-ext-simplify-mode calc-units-simplify-mode) calc-mode.el:calc-num-simplify-mode (calc-set-simplify-mode) calc-mode.el:calc-no-simplify-mode (calc-set-simplify-mode) calc-mode.el:calc-set-simplify-mode (calc-change-mode calc-simplify-mode calc-simplify-mode calc-simplify-mode) calc-mode.el:calc-matrix-mode (calc-change-mode) calc-mode.el:calc-infinite-mode (calc-change-mode calc-change-mode) calc-mode.el:calc-symbolic-mode (calc-change-mode) calc-mode.el:calc-algebraic-mode (calc-change-mode calc-incomplete-algebraic-mode calc-incomplete-algebraic-mode calc-change-mode calc-incomplete-algebraic-mode calc-incomplete-algebraic-mode) calc-mode.el:calc-total-algebraic-mode (calc-algebraic-mode calc-algebraic-mode calc-change-mode calc-algebraic-mode calc-incomplete-algebraic-mode) calc-mode.el:calc-mode-record-mode (calc-change-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode calc-mode-save-mode) calc-math.el:calc-radians-mode (calc-change-mode calc-angle-mode) calc-math.el:calc-degrees-mode (calc-change-mode calc-angle-mode calc-radians-mode calc-hms-mode) calc-frac.el:calc-frac-mode (calc-change-mode) calc-forms.el:calc-hms-mode (calc-change-mode calc-angle-mode) calc-ext.el:calc-change-mode (calc-mode-save-mode calc-mode-save-mode) calc-cplx.el:calc-polar-mode (calc-complex-mode calc-change-mode calc-complex-mode calc-chan
Re: Tips to suppress compilation warnings
>>> However, if Info-goto-node is a useful thing to use from outside Info, >>> perhaps it should be defined as autoloaded in info.el rather than in mh-e. >> >> No. Elisp packages that want to invoke info this way should use the `info' >> function, which can be called just the same: (info "(mh-e)Draft Editing"). > > Info-goto-node is already autoloaded in info.el. I wonder why there is the warning in mh-customize.el if Info-goto-node currently has an autoload cookie in info.el? > (This looks recent.) autoload for Info-goto-node was added in info.el to avoid errors in packages that don't call (require info) and don't autoload Info-goto-node before calling Info-goto-node. If `info' is the preferred method instead of `Info-goto-node', autoload could be removed from info.el after replacing `Info-goto-node' with `info' in all places in Emacs source code and mentioning the preferred method in the NEWS file and Info documentation. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: trivial bug of font-lock in Change Log mode.
> For instance, emacs/src/ChangeLog has this line near the > end. > > See ChangeLog.9 for earlier changes. > > When I visit this file and turn on font-lock mode, "See > Change" (the first 10 characters) gets change-log-data-face. > > It seems that the attached change fix the problem, but, it > may fail if there are some other old style than these two: > > Wed Aug 21 03:51:42 1996 > 2005-05-16 > > Could someone verify it? This will cover most ChangeLog files, but I'd rather move your new restricted date regexp to a new special variable `change-log-date-regexp' (and using it in `change-log-font-lock-keywords'), thus allowing users to override it by file local variables in ChangeLog files with a different date format. Also it seems that the format for arbitrary text in ChangeLog files is a line beginning with two spaces. Look for example in the same file emacs/src/ChangeLog for the copyright statement. It is indented with two spaces, probably with the intention to not highlight it as a date: Copyright (C) 2001, 02, 04 Free Software Foundation, Inc. Copying and distribution of this file, with or without modification, are permitted provided the copyright notice and this notice are preserved. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: non-break-space in tutorial
> In a French locale, C-h T shows the French tutorial which includes > some NBSP chars which are rendered as "\ " as in "m\ emacs\ ". > The \ are clearly undesirable here. This could be fixed by adding `show-nonbreak-escape: nil' to tutorial's file local variables. But I think that adding escape characters before non-breaking spaces and hyphens is undesirable everywhere, even in files where some indication for non-breaking space is desirable. Interspersing the text with backslash characters sometimes makes the text almost unreadable. Also this changes relative positions of text characters and the total line lengths, thus breaking text formatting and truncating right-aligned lines when they become too long after adding \'s on display. A better indication for non-breaking spaces and hyphens is the same as for whitespace highlighting enabled with show-trailing-whitespace, i.e. displaying non-breaking spaces and hyphens in a special face with a non-default background color without adding \. -- 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-face on mode-line and header-line
> *** Mouse-face on mode-line(and header-line) is now supported. > `mode-line-highlight' is the standard face indicating mouse sensitive > elements on mode-line(and header-line) like `highlight' face on text > areas. Good improvement, but there is no reason to have two different faces with different colors for the same purpose - highlighting text areas under the mouse pointer. So there is no need in the new face `mode-line-highlight', or at least it should inherit from `highlight' 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: A few issues with thumbs.el
> Much, much easier to just use md5(). Even though I like when thumbnail file names are composed from file name parts (this allows to purge old thumbnails based on their names), this method is not reliable, because thumbnails don't get updated when image file contents changes. AFAIK, GIMP uses md5 for naming thumbnail files. It stores original file names as comments in image files. thumb.el could do the same adding comments with original file names, e.g.: /usr/bin/convert -comment "Description: Thumbnail of /home/user/images/image.jpg" -sample 100x100 "/home/user/images/image.jpg" "png:/home/user/.emacs-thumbs/b765f25b9ed0233aaefcd601e63d6c86.png" BTW, in thumbs.el the condition for comparing geometry is currently commented out: ;; This is not the right fix, but I don't understand ;; the external program or why it produces a geometry ;; unequal to the one requested -- rms. ;;; (not (equal (thumbs-file-size tn) thumbs-geometry)) The reason why the conversion program produces a different geometry is because it tries to maintain the aspect ratio of the original image. One solution is to add the geometry string to thumbnail file names, e.g. /home/user/.emacs-thumbs/100x100_b765f25b9ed0233aaefcd601e63d6c86.png or to add the original geometry string to the thumbnail file comments: /usr/bin/convert -comment "Geometry: 100x100" ... with assumption that it is possible to extract comments in Emacs from image files before comparing them with the current value of thumbs-geometry. -- 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-face on mode-line and header-line
>Good improvement, but there is no reason to have two different faces >with different colors for the same purpose - highlighting text areas >under the mouse pointer. > > I believe there is, because the mode line has a different background face. > I believe that the regular highlight face might be hard to see against > the mode line background. It is foreground/background color combination that can make text hard to read. Since both foreground and background colors are displayed with `highlight' face on the mode line, there should be no problem to see text highlighted under the mouse pointer on the mode line. Using completely different color for the same action is too confusing. If there is not enough contrast between adjacent highlighted and active/inactive mode line areas, then the color of mode-line-highlight could be adjusted to a darker color. For example, replacing "DarkSeaGreen2" used in `highlight' face with "DarkSeaGreen3" for `mode-line-highlight' face on light backgrounds looks very good and makes highlighting of the mode line very easy to notice, and at the same time preserves its visual association with usual highlighting under the mouse pointer. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: non-break-space in tutorial
> A better indication for non-breaking spaces and hyphens is the same
> as for whitespace highlighting enabled with show-trailing-whitespace,
> i.e. displaying non-breaking spaces and hyphens in a special face
> with a non-default background color without adding \.
>
> Would you like to write a patch do this, so people can try it and see
> if they like it better?
The patch below eliminates the backslash before non-breaking spaces
and hyphens. Without the backslash non-breaking spaces need to be
highlighted by background instead of foreground, so foreground colors
were changed to background colors with values not standing out too
much on the default background. The same face with backgroung color
affects also displaying control characters, for good reason, since
they share the same goal of highlighting dangerous characters.
The user option `show-nonbreak-escape' can be renamed to `show-nonbreak-space'
(by analogy with `show-trailing-whitespace') or removed at all. Users who
dislike highlighting of control characters and non-breaking space can set
the face to the void value.
Index: src/xdisp.c
===
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1014
diff -u -r1.1014 xdisp.c
--- src/xdisp.c 27 May 2005 16:59:55 - 1.1014
+++ src/xdisp.c 29 May 2005 15:18:14 -
@@ -5165,10 +5165,9 @@
if (it->c == 0x8a0 || it->c == 0x8ad
|| it->c == 0xf20 || it->c == 0xf2d)
{
- XSETINT (it->ctl_chars[0], escape_glyph);
g = it->c;
- XSETINT (it->ctl_chars[1], g);
- ctl_len = 2;
+ XSETINT (it->ctl_chars[0], g);
+ ctl_len = 1;
goto display_control;
}
Index: lisp/faces.el
===
RCS file: /cvsroot/emacs/emacs/lisp/faces.el,v
retrieving revision 1.309
diff -u -r1.309 faces.el
--- lisp/faces.el 23 May 2005 18:30:20 - 1.309
+++ lisp/faces.el 29 May 2005 15:18:55 -
@@ -2079,11 +2079,11 @@
:group 'whitespace ; like `show-trailing-whitespace'
:group 'basic-faces)
-(defface escape-glyph 'background dark)) :foreground "cyan")
+(defface escape-glyph 'background dark)) :background "rosybrown4")
;; See the comment in minibuffer-prompt for
;; the reason not to use blue on MS-DOS.
- (((type pc)) :foreground "magenta")
- (t :foreground "blue"))
+ (((type pc)) :background "magenta")
+ (t :background "rosybrown1"))
"Face for characters displayed as ^-sequences or \-sequences."
:group 'basic-faces)
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: non-break-space in tutorial
>> -(defface escape-glyph 'background dark)) :foreground "cyan") >> +(defface escape-glyph 'background dark)) :background "rosybrown4") >> ;; See the comment in minibuffer-prompt for >> ;; the reason not to use blue on MS-DOS. >> -(((type pc)) :foreground "magenta") >> -(t :foreground "blue")) >> +(((type pc)) :background "magenta") >> +(t :background "rosybrown1")) > > You've changed all the colors except the ones for (type pc). I think > it doesn't make sense to use the same color for background as we did > for foreground. I can't find a better color among other 8 values for (type pc) than magenta. Maybe this is not a bad choice. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: A few issues with thumbs.el
>> AFAIK, GIMP uses md5 for naming thumbnail files. It stores original >> file names as comments in image files. thumb.el could do the same >> adding comments with original file names, e.g.: > > I'd like that, but the most prevalent opinion has been that people > wants to have the filename directly visible in the thumbname, so > that's what I've finally implemented. Maybe just a file name without the directory part is enough for people to recognize the thumbnail file? This makes thumbnail filenames much shorter, so they fit into 80-character wide windows (currently thumbnail filenames are so long that they are truncated in dired buffers and the non-directory part is not visible without horizontal scrolling). How about the following template? (format "%s/%s-%x.jpg" thumbs-thumbsdir (file-name-nondirectory filename) (sxhash contents)) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: non-break-space in tutorial
With all opinions taken into account I installed a patch, so all people can try it. A new special face was added for highlighting non-breaking spaces. By default, it uses the underline attribute. Underline appropriately represents the meaning of non-breaking space in a similar way as underscore character is used in some programming language identifiers, and it is less annoying than an additional backslash. The color of underline is not loud but still distinguishable from the default foreground color. I believe this is a good solution. After a testing period (say, 1 week) I could remove the variable `show-non-break'. There seems to be no need for this variable since highlighting can be disabled by inheriting `no-break-space' face from the default face. PS: I also changed NBSP with space in remaining tutorial files. This shows that accidentally typed NBSP is quite a common case. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: regexp font-lock highlighting
> Note that I removed the "\\(\\?:\\)?" since I find it distracting to
> put yet another face here. If you believe that you _really_ need it
> you will have to reinsert it, but in that case you have to modify
> match-data cropping as well. (I do have to modify match-data since
> redisplay wants some valid buffer positions for highlighting.)
I fixed shy group handling in this regexp by allowing ?: to be only
before `(' instead of before any of `(', `|' or `)'. You may need to
adjust your code before submitting your final patch.
Also I tried to extend this regexp to highlight other special backslash
constructs like `\<', `\_<', `\w', `\sC', but soon discovered that
sometimes there are similar constructs in non-regexp strings that become
inappropriately highlighted. Unless it's possible to detect whether
a given string is a regexp or not, I think the regexp highlighting
code should be split into multi-level font-lock variables
font-lock-regexp-keywords-1 and font-lock-regexp-keywords-2.
The first variable would highlight only `\\(?:', `\\|' and `\\)' constructs,
but the second - all other regexp constructs. Everyone agreed to see
regexp constructs sometimes highlighted in wrong places could use
the second level variable.
> Finally, I would use three distinct font-lock faces for regexps:
>
> - One face for highlighting the "\\"s which by default should inherit
> from `font-lock-string-face' with a dimmed foreground - I'm using
> Green4 for strings and PaleGreen3 for the "\\"s. Anyone who doesn't
= =
I see everyone tends to change the default color of `font-lock-string-face'
(which is barely visible on light backgrounds) to a green color.
Currently on tty strings are fontified in green, so maybe this is one
of the reasons why people prefer green strings. This indicates that
we should change the current "RosyBrown" default to one of the shades
of green.
> like the highlighting could revert to `font-lock-string-face'.
>
> - One face for highlighting the "(", "|" and ")" in these expressions.
> I find `bold' good here but again would leave it to the user whether
> she wants to turn off highlighting this. Moreover, such a face could
> allow paren-highlighting to _never_ match a paren with that face with
> a paren with another face. Consequently, paren-matching could finally
> provide more trustable information within regular expressions.
I added two new faces: for a backslash and regexp constructs after
a backslash. The former inherits from escape-glyph to be highlighted
like a backslash in escape sequences, the latter is bold by default.
I think there is no need for a face for shy groups. It is fontified
now in the same face as other regexp constructs (bold).
> - One face for highlighting the innermost grouping. Basically,
> `underline' is not bad here but appears a bit noisy in multiline
> expressions or things like
>
> (concat "\\("
> some-string
> "\\)")
You could add this face after implementing correct highlighting of
nested groups.
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: mode-line-highlight
> I just wanted to mention that I didn't like the default RoyalBlue4/white > appearance of the mode-line-highlight. It doesn't bother me, but I just > found it loud and ugly. > > What I use instead of > > :background "RoyalBlue4" :foreground "white" > is > :box (:line-width 2 :color "grey40" :style released-button) > > It's much more subdued and sticks to the general grey appearance of > GUI elements. Also it makes those elements appear as buttons, which I find > to be a good choice for something which can be activated with a click. Yes, the current colors are too loud. I already proposed to inherit `mode-line-highlight' from `highlight'. I still think this is a good default setting. But for the 88-colors case (i.e. where the active mode line is displayed as a big button) your proposal is better. However, it looks strange to put a released button over a bigger released button. Maybe the shape of the pressed button for the mode-line-highlight is better, i.e.: :box (:line-width -1 :color "grey40" :style pressed-button) BTW, long ago I customized mode-line-inactive in .emacs to a pressed button: ((t (:inherit mode-line :box (:line-width -1 :style pressed-button It seems logical when the inactive mode line is displayed as a pressed button while the active mode line is a released button. PS: There is no distinction currently between active and inactive modelines on TTY. Should it be? PPS: I can't find mode-line-highlight documented in (info "(emacs)Faces"). -- 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?
>> How can I set the face used to display the vertical divider that >> separates side-by-side windows (I am running in a TTY). I was >> initially told that modeline-inactive face would do the trick, but I >> think my question was misunderstood. It would seems a strange >> omission if such a thing were not possible. > > I had tried googling for answers to this before I posted, but lacked > the right keywords. Kim Storm gave me some clues and I found that the > following code works: > > (set-display-table-slot standard-display-table > 'vertical-border > (let* ((face 'mode-line) > (face-offset (lsh (face-id face) 19))) > (+ face-offset ?|))) > > I'd like to also suggest that this be made a default, perhaps using a > specific vertical-border-face, to be more consistent with how the rest > of face customization works. Using inverse colors for the vertical border on a TTY (where the border is displayed as a dash line) seems like a natural default. Is it possible to set inverse colors for the vertical border by default without using the display table? -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: isearch-lazy-highlight-face
> I'd like to rename this face to just `isearch-lazy-highlight' before the > release (with a face alias for compability). Any objections? `isearch-lazy-highlight-face' was already renamed to `lazy-highlight' in January 2005. `isearch-lazy-highlight-face' can remain as an alias for indefinite time. On a related topic, I'd like to propose a slight improvement for the background color of `isearch' face. Currently background and foreground colors are both light which makes the highlighted search text hardly readable. I'm aware of the comment in the face definition saying why the background color must not be dark. Surely, "magenta4" used as a foreground color under the cursor would be too dark when the color of the cursor is black. What I propose is to make the background color only slightly darker by replacing "magenta2" with "magenta3". The character under the cursor is still well visible with "magenta3" used for its foreground color. (defface isearch 'class color) (min-colors 88) (background light)) ;; The background must not be too dark, for that means ;; the character is hard to see when the cursor is there. - (:background "magenta2" :foreground "lightskyblue1")) + (:background "magenta3" :foreground "lightskyblue1")) (((class color) (min-colors 88) (background dark)) (:background "palevioletred2" :foreground "brown4")) (((class color) (min-colors 16)) (:background "magenta4" :foreground "cyan1")) (((class color) (min-colors 8)) (:background "magenta4" :foreground "cyan1")) (t (:inverse-video t))) "Face for highlighting Isearch matches." :group 'isearch) -- 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?
> It's easy just using the same method Len used in lisp. Any objection > to the following patch? > > Should it use a different face I think yes. I'd personally set its both background and foreground colors to "white" to display the vertical border as a solid 1-character-wide white line. > (note that the actual face that ends up being used by this code is > `mode-line-inactive', even though the code says MODE_LINE_FACE_ID; > I'm not sure why this is)? I tried your patch, but instead of either `mode-line' or `mode-line-inactive' it displays the vertical border in the `fringe' face. But maybe this is good. We can reuse `fringe' face for the vertical border because fringes are not available on text-only terminals. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: non-break-space in tutorial
> 1) Faces are global, but it's extremely desirable to disable special
> treatment of NBSP (etc) on a per-buffer basis. So we can't get rid of
> `show-nonbreak-escape'.
I've already thought about the need to retain `show-nonbreak-escape'.
That is why I used the renamed variable name in my previous mail.
So with the lack of support for buffer-local faces and with changed
treatment of `show-nonbreak-escape' we should rename this variable
to something like `show-no-break-space'.
> 2) The original treatment of NBSP -- displaying it like a normal
> escape character, with backslash prefix and in the normal escape
> character face -- is IMO better than your method, so _at the least_ it
> should be user selectable, but it seems that your patch makes this
> impossible. [And I personally think it should be the default.]
I've seen various texts with a lot of non-breaking spaces.
Additional backslashes render such texts almost unreadable.
Since we can't predict in which context and modes users might
encounter non-breaking spaces, we should make their default
highlighting as least annoying as possible.
> 3) Your patch treats "soft hyphens" in the same way as NBSP, and I'm
> not sure this is desirable; it at least seems worthy of discussion.
It treats soft hyphens as NBSP only in regard of not adding a escape
character. Their faces are different: soft hyphens are displayed in
`escape-glyph', but NBSP in `no-break-space'. I think from the user's
POV this should be fine. I'm still not sure about the need for a
separate user option (e.g. `show-soft-hyphen') for configuring the
display of soft hypens.
> BTW, something funny I noticed while testing, though I'm not sure
> whether it is caused by your patch or not, is that when displaying on
> a tty with `terminal-coding-system' set to nil, both NBSP and
> soft-hyphen are show as "?". Since most fonts simply display these
> character in the same way as their non-special brothers, wouldn't be
> good for emacs to do the translation itself so that they show up ok on
> simple ascii terminals?
It is caused by the 2005-03-24 change in xdisp.c:
{
XSETINT (it->ctl_chars[0], escape_glyph);
- g = it->c == 0x8ad ? '-' : ' ';
+ g = it->c;
XSETINT (it->ctl_chars[1], g);
ctl_len = 2;
goto display_control;
which now doesn't replace the NBSP by an SPC. Maybe this line should
be restored for ascii terminals?
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: non-break-space in tutorial
> This is your _opinion_, which I disagree with. I think dIsplaying
> them with a modified background, if anything, looks worse, and is more
=
> confusing to users than making them look like an "escape character",
> which is already a familiar concept.
>
> In your post, you said you had "taken everybody's opinion into
> account", which is clearly not true. Despite the initial objections
> to your proposed changes, you simply went ahead and made them anyway.
Perhaps, you missed something. It was your opinion about
unsuitability of a modified background that I've taken into account
before I started to think about a different solution. I fully
agree with you that a modified background is a bad solution.
That's why I installed for people to try a completely different
patch which I think is much better than anything proposed so far.
A new solution puts the underline attribute on non-breaking spaces.
This appropriately reflects the purpose of non-breaking spaces
("gluing" words together) and is not as annoying as anything else.
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: isearch-lazy-highlight-face
> I'd like to rename this face to just `isearch-lazy-highlight' before the > release (with a face alias for compability). Any objections? > > Ok. Since this face was first created a few months ago, I see no need > for the alias. ChangeLog says that it was created a few _years_ ago, so the alias is needed for it. It seems all is correct already with isearch-lazy-highlight-face. Isn't it? As for removing -face suffix from face names, C-u M-x list-faces-display RET -face$ RET still displays too many unconventional face names waiting to be renamed. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: non-break-space in tutorial
>> So with the lack of support for buffer-local faces and with changed >> treatment of `show-nonbreak-escape' we should rename this variable >> to something like `show-no-break-space'. > > You might as well make it `show-non-breaking-spaces' if you're > going to rename it anyway. The current name is ugly, and I think > the name you're proposing is unnecessarily confusing. It makes > you wonder what the ``break space'' is. According to the official Unicode Character Database the name of NBSP is NO-BREAK SPACE, and its _old_ name is NON-BREAKING SPACE. IMO we should use the new Unicode character name in variable names, possibly with omitting the hyphen inside the `no-break' word. Is `show-nobreak-space' is clearer than `show-no-break-space'? >> Since we can't predict in which context and modes users might >> encounter non-breaking spaces, we should make their default >> highlighting as least annoying as possible. > > I read that as a typo for ``at least as annoying as possible.'' > :-) > But now that I think about it, ``as little annoying as possible'' > sounds slightly awkward too. What is the correct way to say it? Maybe ``as unannoying as possible'' :-) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: non-break-space in tutorial
> The strength of the old display method is that it uses a familiar > notation (backslash escape and common escape highlighting) to show > that NBSP/soft-hyphen are "funny" characters, rather than adding yet > another ad-hoc notation. The new display method uses no less familiar notation. The underlined space looks very like the underscore character used in programming languages to represent a space between inseparable words inside identifiers. > Now, you may dislike this representation, but the fact that you think > your preferred solution "is better than anything proposed so far" > doesn't make that some kind of undisputed fact. [Clearly, because I'm > here disputing it.] I never claimed it to be undisputed fact. On the contrary, in the mail I sent after installing the patch I asked all people to try the new highlighting for some time period with the intention to hear all opinions about it afterwards. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: regexp font-lock highlighting
> I tried to implement variants of that but it did not turn out well. > Highlighting backslashes only is more distracting than useful. Having > `<' or `w' stand out with bold face makes groupings much less readable. A different face could be used for `<', `w' and other constructs. -- 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. For example, Emacs started with `emacs -Q -nw' crashes on GNU/Linux with the following code: (progn (setq standard-display-table (make-display-table)) (set-display-table-slot standard-display-table 'vertical-border (+ (lsh (face-id 'isearch) 19) ? )) (split-window-horizontally)) -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: non-break-space in tutorial
> The display-table allows you to do just that, even more flexibly.
>
>> Here is a generic approach (similar to using a display table,
>> but without the overhead):
>
> What overhead? Just for the record, could all you people check the value of
> `standard-display-table' in your current Emacs session? My bet is that most
> of you have it non-nil already.
I don't know the reasons for not using the display table by default
neither what overhead it causes, but among other benefits using the
standard display table would be more user-friendly. Currently users
unaware about the new faces for NBSP and escape characters have
difficulties in finding ways to configure them. With display tables
and the patch below it will be possible to find used faces by typing
C-u C-x = directly on NBSP and escape characters. It will display
a clickable button with the face name leading to the face configuration,
e.g.:
The display table entry is displayed by these fonts (glyph codes):
: -Misc-Fixed-Medium-R-Normal--10-100-75-75-C-60-ISO8859-1 (0x20)
face: [escape-glyph]
Index: lisp/descr-text.el
===
RCS file: /cvsroot/emacs/emacs/lisp/descr-text.el,v
retrieving revision 1.35
diff -u -r1.35 descr-text.el
--- lisp/descr-text.el 26 May 2005 12:41:52 - 1.35
+++ lisp/descr-text.el 8 Jun 2005 19:16:48 -
@@ -619,7 +625,21 @@
(format "%s (0x%02X)" (cadr (aref disp-vector i))
(cddr (aref disp-vector i)))
"-- no font --")
- "\n ")))
+ "\n")
+ (when (> (car (aref disp-vector i)) #x7)
+ (let* ((face-id (lsh (car (aref disp-vector i)) -19))
+ (face (car (delq nil (mapcar (lambda (face)
+ (and (eq (face-id
face)
+ face-id)
face))
+ (face-list))
+ (when face
+ (insert (propertize " " 'display '(space :align-to 5))
+ "face: ")
+ (widget-create
+'link
+:notify `(lambda (&rest ignore) (describe-face ',face))
+(format "%S" face))
+ (insert "\n"))
(insert "these terminal codes:\n")
(dotimes (i (length disp-vector))
(insert (car (aref disp-vector i))
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: regexp font-lock highlighting
> I can't help wondering what would be the benefit of highlighting > things like \< and \w. Highlighting \( and \| and \) can make sense > since it helps doing visual paren matching \< and \w are keywords of the language of regular expressions. Like keywords of other programming languages highlighted in Emacs it makes sense to highlight keywords of regular expressions as well. > Please leave \< and \w alone, thank you. Highlighting of \< and \w should by no means be the default. Anyone willing to implement highlighting of all regexp constructs could add it as an option for those users who like fruit salad (I'm not speaking for myself, I like moderate highlighting). -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: non-break-space in tutorial
> By the way, having NBSP and soft-hyphen escaped breaks alignment in the > character table in M-x describe-input-method latin-1-prefix (and surely > some others) This is not the worst example. It breaks alignment on any formatted text using NBSP extensively. Such texts are not rare, and users may encounter them in many unexpected places. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: emacs-buffer.gdb
> +printf "%2d %c %9d %-20s %-10ss\n", \ = This looks like a tyop. BTW, emacs-buffer.gdb deserves mentioning in etc/NEWS (and maybe in etc/DEBUG as well), and a better location for this file is src/emacs-buffer.gdb (where other gdb files are located) instead of etc/emacs-buffer.gdb. -- 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 is slow in Emacs 22.0.50
n-tag-table-1 2 0.000199 9.999...e-05 Info-extract-menu-node-name 1 0.00019 0.00019 Info-set-mode-line1 0.000182 0.000182 Info-escape-percent 1 9.8e-05 9.8e-05 replace-regexp-in-string 1 6e-05 6e-05 Info-following-node-name-re 1 1.3e-05 1.3e-05 Info-node-at-bob-matching 1 9e-06 9e-06 info-initialize 2 6e-06 3e-06 With loaded .emacs and Info-fontify-maximum-menu-size = 0: Function Name Call Count Elapsed Time Average Time == Info-follow-nearest-node 1 0.060599 0.060599 Info-try-follow-nearest-node 1 0.060563 0.060563 Info-goto-node1 0.058121 0.058121 Info-find-node1 0.057991 0.057991 Info-find-node-2 1 0.046453 0.046453 info-insert-file-contents 2 0.027276 0.013638 Info-read-subfile 1 0.024617 0.024617 re-search-forward 96 0.017714 0.0001845208 Info-select-node 1 0.01770.0177 Info-fontify-node 1 0.014428 0.014428 Info-find-file1 0.011469 0.011469 info-file-exists-p145 0.008243 5.684...e-05 Info-get-token4 0.001839 0.00045975 looking-at44 0.001313 2.986...e-05 Info-index-node 3 0.001055 0.000351 put-text-property 92 0.000815 8.869...e-06 Info-display-images-node 1 0.000754 0.000754 Info-hide-cookies-node1 0.00073 0.00073 info-insert-file-contents-1 143 0.000670 4.692...e-06 Info-find-node-in-buffer 1 0.000286 0.000286 Info-find-node-in-buffer-11 0.000263 0.000263 Info-find-in-tag-table1 0.000231 0.000231 Info-find-in-tag-table-1 2 0.000202 0.000101 match-beginning 86 0.000177 2.069...e-06 Info-extract-menu-node-name 1 0.000159 0.000159 match-end 86 0.000158 1.848...e-06 Info-set-mode-line1 0.000126 0.000126 Info-escape-percent 1 0.000121 0.000121 match-string 9 6.6e-05 7.333...e-06 replace-regexp-in-string 1 4.2e-05 4.2e-05 Info-following-node-name-re 1 1.2e-05 1.2e-05 Info-node-at-bob-matching 1 1e-05 1e-05 info-initialize 2 8.000...e-06 4.000...e-06 These results indicate that the main source of the slowdown is the menu items fontification code in `Info-fontify-node', and it is caused by a large amount of Info menu items needed to be processed. -- 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 is slow in Emacs 22.0.50
> >I noticed that info in Emacs 21.2, on my 200MHz PC, is a lot more > >responsive than in Emacs 22.0.50. Am I getting anything extra for the > >longer wait? > > > > Does it help to set Info-hide-note-references to nil? > > I can't see any difference. I haven't been very scientific and it probably > wouldn't be noticeable with a more powerful computer. Do you see a difference with Info-fontify-maximum-menu-size set to 0? Could you try this on a slow computer? -- 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 is slow in Emacs 22.0.50
>> These results indicate that the main source of the slowdown is the >> menu items fontification code in `Info-fontify-node', and it is caused >> by a large amount of Info menu items needed to be processed. > > While I still don't understand where the slowdown actually comes from > (e.g. why do 1559 calls to put-text-property take 0.01s with -Q -D but then > take 5.46s with a loaded .emacs? Also more than half the elasped time is > unaccounted for in the profile of the pathological case), we can always try > and move some of Info-fontify-node into font-lock-keywords where jit-lock > should help us stay nice and responsive. Definitely worth trying. But before doing that I want to understand why in `emacs -Q -D' this is faster. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: hidden buffers for async
>> I agree that downloading a lot of files will be silly. Perhaps I will >> set up a pool of 20 or so buffers for downloads and block or error >> when the pool is exhausted. > > My guess is that the possible performance hit you'd get by using 100 or > 1000 buffers would still be insignificant. > > Stefan "whose Emacs routinely has 100 buffers" M-: (length (buffer-list)) RET 322 I rarely close visited files and use desktop.el. This way I give Emacs pretty good stress-testing. With so many buffers some Emacs packages (Dired, Info) suffer from the noticeable slowdown. However, I can't definitely attribute this to the number of buffers, because in `emacs -Q -D' after (dotimes (i 1000) (generate-new-buffer "buffer")) there is no slowdown. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: A few issues with thumbs.el
>> Have you seen the thumbnail-spec, which is apparently poised to become a >> freedesktop.org standard? It seems to allow usage of the same >> thumbnails by several programs. >> >> <http://jens.triq.net/thumbnail-spec/> > > I have now... :) > > Seems quite good although I don't like the idea of using PNG-files as > their size is much larger than using JPEG. PNG is more optimal for small images like thumbnails. > The file names are named according to the absolute URI's MD5 value, > which most in this thread seems to dislike (including myself). This specification is _already_ implemented in Gimp. Since Gimp is the primary GNU image manipulation program, this is the _de-facto_ GNU standard for creating thumbnails. Gimp users already have the directory ~/.thumbnails. Some time ago thumbs.el was added to the Emacs CVS tree which uses the ~/.emacs-thumbs directory for thumbnails. And now you've created a new package that uses yet another directory ~/.tumme. All these three directories are used for the same purpose. This is a waste of user space. The above-mentioned specification is well thought out, and the list of advantages of this approach is convincing. So the best thing for us to do now is just to follow this standard and to share the same standard thumbnail directory with other GNU programs. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: A few issues with thumbs.el
>>> - I wish there was a way to put the thumbs directly next to the original >>> image files. E.g. instead of ~/.emacs-thumbs/foo!bar!baz!toto!.jpg >>> I'd like to use ~/foo/bar/baz/.emacs-thumbs/toto_.jpg. >> What are the benefits of doing this? > > Locality. I find the concept of locality to be extremely important. > E.g. if I rename the directory "foo/bar/baz" to "off/bar/baz" it will just > keep working without any need to recreate thumbs. If I delete the > directory, the thumbs will automatically be deleted with the images, ... You can't create thumbnails when viewing images in directories with read-only permissions. >> I think it would litter the system with extra directories. > > What are the problems with that? It'll still be a negligible fraction of > the disk space and of the number of directories on the disk. > > Other advantages: the number of files in a .emacs-thumbs dir will this way > not be larger than the number of files in any other directory, so it'll > automatically avoid suffering from the all-too-common problem where some > Unix file systems don't handle large directories efficiently (things like > O(n) lookup (and worse) behavior). Theoretically this is reasonable, but from a practical POV this approach is too intrusive. I had unpleasant experiences with earlier Gimp versions: often Gimp created thumbnail subdirectories where it really shouldn't do this, (e.g. in backup directories) when simply previewing image files in the File Open dialog. Fortunately Gimp developers realized this annoyance and fixed it in Gimp 2 to put all thumbnail images in ~/.thumbnails/. -- 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
> Some like grep, seem to cover a lot of the buffer. I'm not saying > that you can't get round it, just that it requires thought. I like how it's implemented in the *Occur* buffer and wish grep to have the same. In the *Occur* buffer mouse-1 is active only on areas with `highlight' mouse-face, but mouse-2 has a wider coverage. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
