mouse-4/mouse-5 loses click modifiers

2007-07-15 Thread Juri Linkov
A recipe to reproduce this bug:

1. Run emacs -Q

2. M-: (get 'S-mouse-5 'event-symbol-elements) RET
(mouse-5 shift click)

3. Press the Shift key, and scroll the mouse wheel up/down.

4. M-: (get 'S-mouse-5 'event-symbol-elements) RET
(mouse-5 shift)

A list of modifiers now misses the `click' element that was here
initially.  As a result, mouse-avoidance-ignore-p fails to ignore
mouse wheel's scrolling events because it checks event-modifiers
for the `click' modifier.  The same bug applies to other modifiers
defined in `mouse-wheel-scroll-amount'.

GNU Emacs 22.1.50 (i686-pc-linux-gnu, GTK+ Version 2.10.12)

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: M-%, in query-replace, offers less-than-ideal default replacement text

2007-06-19 Thread Juri Linkov
 I don't think it makes sense to see foo here, since foo was never
 used as replacement text.

It seems what you want is a separate history for each of from/to prompts.
You can do this by the following settings:

(defvar query-replace-from-history nil)
(defvar query-replace-to-history nil)
(setq query-replace-from-history-variable 'query-replace-from-history)
(setq query-replace-to-history-variable 'query-replace-to-history)

`query-replace-from-history-variable' and `query-replace-to-history-variable'
are both defcustoms, but using Customize to set them doesn't make much sense,
because anyway you have to put code in .emacs declaring new history variables
with defvar.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: clipboard integration hangs pasting text from emacs

2007-06-15 Thread Juri Linkov
 Perhaps we should give the next release a name.

Emaczilla.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Saving markup formats (was: warnings before opening very big directories)

2007-06-15 Thread Juri Linkov
 Please tell what things are more important.

 Implementing horizontal position computation using variabled-width
 fonts is an important feature.

 Saving with markup in additional formats is an important feature.

What are the most preferable formats to save markup?  One variant is
Enriched text.  It was designed for using in e-mail, but actually nobody
uses it nowadays.  Most people prefer HTML in e-mail as a replacement of
plain text.

Another variant is RTF, but this format is quite obsolete now too
(not to mention that it is a proprietary format).

Most modern word processors use XML for saving formatted text.
I think Emacs should do the same.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: warnings before opening very big directories

2007-06-14 Thread Juri Linkov
 Then what about using a Help key to display the additional information?

 It sounds like more trouble than it is worth.

 Many questions Emacs asks can be disabled or made less frequent by
 setting options.  I do not want to start making all of them display
 info about those options.  That would be a lot of work, and not worth
 the trouble.

We don't need to add help to all questions at once.  We could progress
adding them one by one only for non-trivial cases (like questions asked
by options that set some limits) after a good user interface for getting
help for y-or-n-p and yes-or-no-p is implemented.

 (And we have more important things to do.)

Please tell what things are more important.  Since the feature freeze
seems to be over, I could contribute to the development of new features,
but I see no clear plan and priorities for further Emacs development.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: warnings before opening very big directories

2007-06-13 Thread Juri Linkov
 I just verified that this option is easy to find using customize-browse.

 BTW, every time I need to increase the default value of the variable
 controlling the maximum size of file above which a confirmation is 
 requested,
 I can't remember its name.

 The name is `large-file-warning-threshold'.  Perhaps the name
 `file-size-warning-threshold' would be more coherent with
 usual Emacs conventions, thus easier to remember or guess.
 Do you think so?

I don't think any other name would make it easier to find this user option.
What is missing is a direct explicit link to the option name.

 This is not user-friendly.  This warning misses a link to the user option
 where the user can change its value.  Maybe, the y-or-n prompt should 
 contain
 a line pointing to this user option?

 I do not want to start putting option names into messages.

Then what about using a Help key to display the additional information?

When seeing this yes-no question the user might wonder *why* this question
is asked, and this key will display the Help buffer with explanations
and a link to the corresponding user option.

For instance, query-replace already provides Help keys C-h, f1, ?
for displaying the Help buffer with the information about available keys,
and it adds the hint (? for help) for the end of the query-replace prompt.
y-or-n-p could do the same with e.g.

File is large (11MB), really open? (y or n) (? for help)

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: warnings before opening very big directories

2007-06-12 Thread Juri Linkov
 Emacs provides warnings before opening very big files, perhaps it
 should do the same before opening very big directories, if it doesn't
 already.

BTW, every time I need to increase the default value of the variable
controlling the maximum size of file above which a confirmation is requested,
I can't remember its name.  I try finding it in the list of variables, and
picking different keywords in the Info index of the Emacs manual. Usually,
I end up grepping the Emacs source tree for the text displayed in the
warning (File is large, really open?).

This is not user-friendly.  This warning misses a link to the user option
where the user can change its value.  Maybe, the y-or-n prompt should contain
a line pointing to this user option?

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: BUG in scroll-lock-mode?

2007-06-08 Thread Juri Linkov
 As far as I understand the Scroll Lock key was originally supposed to
 toggle scroll lock globally, i.e. for the desktop as a whole, just like
 Caps Lock or Num Lock.  There are even keyboards which provide an LED
 for indicating if scroll lock is active.

IIRC the Scroll Lock key was supposed to toggle scroll lock separately in
every window.  So when you turn the scroll on in one window (this activates
the LED indication), in all other windows Scroll mode is not active, and
switching to another window will deactivate the LED indication.

 I'm not sure if it is actually possible to configure an X server like
 that.  (Some research on the interweb did not really reveal useful
 results.)  But if this is the case, the behavior I'd expect would be
 that Emacs recognizes a globally activated scroll lock (even when not
 having focus) and activates Scroll Lock mode for all buffers.

I don't know how to recognize the globally activated scroll lock, but to
activate Scroll Lock mode for all buffers in Emacs requires a global
scroll-lock mode.  So we can't avoid creating it.

Is there any harm in binding the scroll lock key to the global-scroll-lock
mode?  Systems that handle the scroll lock key won't pass it to Emacs, so
there will be no conflict with them.  However, this key will be useful on
systems that pass this key to Emacs.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: BUG in scroll-lock-mode?

2007-06-07 Thread Juri Linkov
 I put (scroll-lock-mode t) in ~/.emacs, but it is still disabled after
 restart emacs. Is this a bug in scroll-lock-mode?

 Scroll Lock mode is a buffer-local minor mode, so your command will not
 enable it globally.  You can enable it via a hook.  For example, if you
 wanted the mode to be activated when browsing info files, you could do
 this with something like (add-hook 'Info-mode-hook 'scroll-lock-mode).

Why scroll-lock-mode is not bound to scroll or Scroll_Lock key?
This would be much more useful than making a global mode.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: BUG in scroll-lock-mode?

2007-06-07 Thread Juri Linkov
 Why scroll-lock-mode is not bound to scroll or Scroll_Lock key?
 This would be much more useful than making a global mode.

 ,[ http://mid.gmane.org/E1Dnaf1-0007am-Cg%40neutrino.iwi.uni-sb.de ]
 | An open issue is the key binding for toggling the mode.  If the minor
 | mode should be able to be activated in some major modes but not in
 | others, it doesn't make much sense to bind this to the Scroll Lock key
 | which in my understanding means to enable or disable it globally (not
 | just for Emacs but for other applications aware of it as well).
 `

 Personally I have the following in my init file:

 (let ((key (if (eq window-system 'w32) scroll Scroll_Lock)))
   (unless (lookup-key (current-global-map) (read-kbd-macro key))
 (define-key (current-global-map) (read-kbd-macro key) 'scroll-lock-mode)))

I see that Scroll_Lock does nothing special on X so it's safe to bind it
to this key.  For other systems where scroll is application-modal we could
create a new global mode and bind scroll to it.  So activating scroll-lock
will affect only Emacs, and not other applications.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: can't customize compare-windows to have previous behaviour

2007-03-25 Thread Juri Linkov
 Thanks.  Would someone please install this?

Done.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: can't customize compare-windows to have previous behaviour

2007-03-24 Thread Juri Linkov
 Yet when I go to customise compare-windows-sync, I don't see any
 option to set it to nil; all I seem to be able to chose is to set it
 to a function or a regexp.

The following patch adds an option `nil' which disables the syncing
behavior.  It also renames the old cryptic group name `compare-w' to the
full name `compare-windows' which is the real name of this Emacs feature.

Index: lisp/compare-w.el
===
RCS file: /sources/emacs/emacs/lisp/compare-w.el,v
retrieving revision 1.38
diff -u -r1.38 compare-w.el
--- lisp/compare-w.el   21 Jan 2007 03:53:12 -  1.38
+++ lisp/compare-w.el   24 Mar 2007 08:31:36 -
@@ -32,7 +32,7 @@
 
 ;;; Code:
 
-(defgroup compare-w nil
+(defgroup compare-windows nil
   Compare text between windows.
   :prefix compare-
   :group 'tools)
@@ -52,18 +52,18 @@
 If the function returns the same value for both windows, then the
 whitespace is considered to match, and is skipped.
   :type '(choice regexp function)
-  :group 'compare-w)
+  :group 'compare-windows)
 
 (defcustom compare-ignore-whitespace nil
   *Non-nil means `compare-windows' ignores whitespace.
   :type 'boolean
-  :group 'compare-w
+  :group 'compare-windows
   :version 22.1)
 
 (defcustom compare-ignore-case nil
   *Non-nil means `compare-windows' ignores case differences.
   :type 'boolean
-  :group 'compare-w)
+  :group 'compare-windows)
 
 (defcustom compare-windows-sync 'compare-windows-sync-default-function
   *Function or regexp that is used to synchronize points in two
@@ -87,10 +87,11 @@
 the nature of the difference units separator.  The variable can
 be made buffer-local.
 
-If the value of this variable is `nil', then function `ding' is
-called to beep or flash the screen when points are mismatched.
-  :type '(choice regexp function)
-  :group 'compare-w
+If the value of this variable is `nil' (option \No sync\), then
+no synchronization is performed and the function `ding' is called
+to beep or flash the screen when points are mismatched.
+  :type '(choice function regexp (const :tag No sync nil))
+  :group 'compare-windows
   :version 22.1)
 
 (defcustom compare-windows-sync-string-size 32
@@ -102,7 +103,7 @@
 
 The default value 32 is good for the most cases.
   :type 'integer
-  :group 'compare-w
+  :group 'compare-windows
   :version 22.1)
 
 (defcustom compare-windows-recenter nil
@@ -113,7 +114,7 @@
 The value `(-1 0)' is useful if windows are split vertically,
 and the value `((4) (4))' for horizontally split windows.
   :type '(list sexp sexp)
-  :group 'compare-w
+  :group 'compare-windows
   :version 22.1)
 
 (defcustom compare-windows-highlight t
@@ -125,13 +126,13 @@
   :type '(choice (const :tag No highlighting nil)
 (const :tag Persistent highlighting persistent)
 (other :tag Highlight until next command t))
-  :group 'compare-w
+  :group 'compare-windows
   :version 22.1)
 
 (defface compare-windows
   '((t :inherit lazy-highlight))
   Face for highlighting of compare-windows difference regions.
-  :group 'compare-w
+  :group 'compare-windows
   :version 22.1)
 
 (defvar compare-windows-overlay1 nil)

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


face-set-after-frame-default overrides face customization

2007-03-24 Thread Juri Linkov
The 2007-03-11 change in faces.el::face-set-after-frame-default broke
.emacs face customizations in such a way that it overrides the face
modifications made in .emacs by Lisp functions like `set-face-attribute'
after face customization is completed by `custom-set-faces'.

The cause of this change in the default Emacs behavior is the
following code:

;; If the user has customized the face, don't let X
;; resources override the customizations.
(if (get face 'theme-face)
(custom-theme-recalc-face face)))

I think this change should be reverted, and to achieve what it tries
to do is possible by adding the same condition `(get face 'theme-face)'
with `unless' just around the call to `make-face-x-resource-internal'
a few lines above in the same function like:

(unless (get face 'theme-face)
(make-face-x-resource-internal face frame))
...

Could someone confirm that this will fix the problem with X resources
the latest change was attempted to fix?

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Unsafe variable in a saved *compilation* buffer

2007-03-11 Thread Juri Linkov
 When I try to open a previously saved *compilation* buffer, GNU Emacs
 complains about an unsafe variable, default-directory. Is this needed?

   The local variables list in Kompilation-doc
   contains values that may not be safe (*).

   Do you want to apply it?  You can type
   y  -- to apply the local variables list.
   n  -- to ignore the local variables list.
   !  -- to apply the local variables list, and permanently mark these
 values (*) as safe (in the future, they will be
 set  automatically.)

 * default-directory : ~/Quellen/X11R7.1/

Yes, indeed, this is very annoying.  There are many other local variables
(including numbers!) for which Emacs asks this question.  Look, for example,
at this section:

## Local_Variables:
## perl-indent-level: 2
## perl-continued-statement-offset: 2
## perl-continued-brace-offset: 0
## perl-brace-offset: 0
## perl-brace-imaginary-offset: 0
## perl-label-offset: -2
## cperl-indent-level: 2
## cperl-brace-offset: 0
## cperl-continued-brace-offset: 0
## cperl-label-offset: -2
## cperl-extra-newline-before-brace: t
## cperl-merge-trailing-else: nil
## cperl-continued-statement-offset: 2

It seems all these variables are safe, isn't?

Perhaps Emacs shouldn't be released without marking all safe variables in
packages distributed with Emacs.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Manual: indexes are missing links

2007-01-09 Thread Juri Linkov
  Simply turning this on has an undesirable consequence that node names
  are now hidden in the index node, but it is very useful to see them!
  This is because index entries are not like normal links where nodes name
  are not very essential.  I propose the following patch that doesn't hide
  node names of the index entries while keeping index entries displayed
  as links (blue and underlined).

 Good idea.

 Would someone please install that patch?

Done.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Manual: indexes are missing links

2007-01-07 Thread Juri Linkov
 From: Juri Linkov [EMAIL PROTECTED]
 Date: Sun, 07 Jan 2007 02:09:52 +0200

 Simply turning this on has an undesirable consequence that node names
 are now hidden in the index node, but it is very useful to see them!

 You see them when the mouse pointer hovers above the link.

No, thanks, it is very inconvenient to hover the mouse pointer
on every index entry to see their corresponding node name.

 Why do you think it's more important to see the node names in the
 index than it is in any other menu?

Menu item names in any other menu are often just a modified version
of the node name, so it makes sense to hide node names as e.g. in:

* Format: Outline Format.  What the text of an outline looks like.
* Motion: Outline Motion.  Special commands for moving through outlines.
* Visibility: Outline Visibility.  Commands to control what is visible.
* Views: Outline Views.Outlines and multiple views.

Unlike this, index entry names contain no information about node names
to which they belong, and it is helpful to see them, e.g.:

* face-background:   Attribute Functions.
* face-bold-p:   Attribute Functions.
* face-differs-from-default-p:   Face Functions.
* face-documentation 1:Face Functions.
* face-documentation:Accessing Documentation.

It is especially important to see node names with the same index names
like in the two last lines above.

There is enough horizontal space in the index menus to leave node
names displayed where they were displayed for many years so far
without complaints from users.

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Manual: indexes are missing links

2007-01-06 Thread Juri Linkov
 As Jury corrected me, the problem is not with supporting the new
 format, the problem was that menus in the indices were not decorated
 as normal menus since long ago.

 I agree that we should consider revising this decision now, that the
 machines are so much faster.

 OK; I turned it on.

Simply turning this on has an undesirable consequence that node names
are now hidden in the index node, but it is very useful to see them!
This is because index entries are not like normal links where nodes name
are not very essential.  I propose the following patch that doesn't hide
node names of the index entries while keeping index entries displayed
as links (blue and underlined).

Index: lisp/info.el
===
RCS file: /sources/emacs/emacs/lisp/info.el,v
retrieving revision 1.493
diff -c -r1.493 info.el
*** lisp/info.el22 Dec 2006 19:49:08 -  1.493
--- lisp/info.el7 Jan 2007 00:08:32 -
***
*** 3996,4002 
(setq res (car hl) hl nil)
  (setq hl (cdr hl
res))) 'info-xref-visited 'info-xref)))
! (when (and not-fontified-p (memq Info-hide-note-references '(t 
hide)))
(put-text-property (match-beginning 2) (1- (match-end 6))
   'invisible t)
;; Unhide the file name in parens
--- 3996,4004 
(setq res (car hl) hl nil)
  (setq hl (cdr hl
res))) 'info-xref-visited 'info-xref)))
! (when (and not-fontified-p
!(memq Info-hide-note-references '(t hide))
!(not (Info-index-node)))
(put-text-property (match-beginning 2) (1- (match-end 6))
   'invisible t)
;; Unhide the file name in parens

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Manual: indexes are missing links

2006-12-19 Thread Juri Linkov
 I think it's a bug: it looks like Emacs doesn't support the new format
 of Index menus introduced with the latest versions of Texinfo.

 Let me rephrase: Emacs doesn't _fully_ support the new format.
 Specifically, `m', `f', TAB, and RET work, but the link face, mouse
 highlight and related features don't.

This has nothing to do with the new format, which actually is
fully supported.  Not highlighting index menu is an old feature.
I guess the reason for it was to reduce the time of preparing
usually very large index nodes.  (Look for the relevant line
`(not (Info-index-node))' in `Info-fontify-node' and the user
option `Info-fontify-maximum-menu-size'.)

-- 
Juri Linkov
http://www.jurta.org/emacs/


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Useless Local Variable in etc/grep.txt

2006-10-08 Thread Juri Linkov
 Users may have code in .emacs that removes read-onlyness from the grep
 output buffers.  This local variable overwrites this to remind that
 editing etc/grep.txt will lose escape sequences.  With your latest change
 in files.el, the local variable buffer-read-only will cause no trouble.

 Interesting: so we decided to remove those escape chars for the sake of
 copypaste, but we'd want to keep them for savereload.

I believe not many people would want to save the grep output to a file
with escape sequences.  etc/grep.txt is a special case for the demonstration
purpose.  When someone wants to save the grep output to a file, this is
possible with redirecting the output to the file on the command line of
`M-x grep', and visiting this file in read-only mode afterwards.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


cperl-after-expr-p

2006-09-25 Thread Juri Linkov
The shortest test case - put the following lines in the cperl mode:

print EOF;
$a
EOF

and type `{' when the cursor is just after `$a'.  This signals the error:

Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  goto-char(nil)
  (progn (goto-char (previous-single-property-change ... ...)) 
(beginning-of-line 0))
  (if (get-text-property (point) (quote here-doc-group)) (progn (goto-char ...) 
(beginning-of-line 0)))
  (while (and (not stop) ( ... lim)) (skip-chars-backward \n\f lim) 
(setq p (point)) (beginning-of-line) (if (get-text-property ... ...) (progn ... 
...)) (if (get-text-property ... ...) (progn ... ...)) (if (looking-at ^[   
]*\\(#\\|$\\)) nil (cperl-to-comment-or-eol) (skip-chars-backward ) (if 
... ...) (setq p ...) (if ... ... ... ...)))
  (save-excursion (while (and ... ...) (skip-chars-backward\n\f lim) 
(setq p ...) (beginning-of-line) (if ... ...) (if ... ...) (if ... nil ... ... 
... ... ...)) (or (bobp) (eq ... lim) (looking-at [  ]*__\\(END\\|DATA\\)__) 
(progn ...)))
  (let ((lim ...) stop p pr) (cperl-update-syntaxification (point) (point)) 
(save-excursion (while ... ... ... ... ... ... ...) (or ... ... ... ...)))
  cperl-after-expr-p(nil {;))
  cperl-electric-lbrace(nil)
  call-interactively(cperl-electric-lbrace)

I believe the following patch fixes this with keeping the function's
intended behavior:

Index: lisp/progmodes/cperl-mode.el
===
RCS file: /sources/emacs/emacs/lisp/progmodes/cperl-mode.el,v
retrieving revision 1.78
diff -c -r1.78 cperl-mode.el
*** lisp/progmodes/cperl-mode.el10 Jun 2006 09:05:31 -  1.78
--- lisp/progmodes/cperl-mode.el25 Sep 2006 22:34:12 -
***
*** 3914,3925 
(if (get-text-property (point) 'here-doc-group)
(progn
  (goto-char
!  (previous-single-property-change (point) 'here-doc-group))
  (beginning-of-line 0)))
(if (get-text-property (point) 'in-pod)
(progn
  (goto-char
!  (previous-single-property-change (point) 'in-pod))
  (beginning-of-line 0)))
(if (looking-at ^[ \t]*\\(#\\|$\\)) nil ; Only comment, skip
  ;; Else: last iteration, or a label
--- 3914,3927 
(if (get-text-property (point) 'here-doc-group)
(progn
  (goto-char
!  (or (previous-single-property-change (point) 'here-doc-group)
!  (point)))
  (beginning-of-line 0)))
(if (get-text-property (point) 'in-pod)
(progn
  (goto-char
!  (or (previous-single-property-change (point) 'in-pod)
!  (point)))
  (beginning-of-line 0)))
(if (looking-at ^[ \t]*\\(#\\|$\\)) nil ; Only comment, skip
  ;; Else: last iteration, or a label

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Default value of next-error-highlight is too small

2006-09-17 Thread Juri Linkov
 If the default highlighting is imperceptible, then users will not know
 about it to increase the period length (to actually use the
 highlighting feature!).

 I agree, but let's first establish how many users have the same
 problem as you do.  I'd imagine at least the person who introduced the
 default value for this variable did see the highlighting.

IIRC, the initial old hard-coded delay was 0.5 sec, but during
introducing new defcustoms due to some problems in its implementation
this value was shortened to 0.1.  Later these problems were solved,
and now I agree that 0.5 is a better default.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Bootstrapping CVS Emacs fails

2006-09-03 Thread Juri Linkov
 In toplevel form:
 quail/czech.el:42:1:Error: Invalid Quail key `[kp-1]'
 make[1]: *** [/var/local/cc/news/emacs/leim/quail/czech.elc] Fehler 1
 make[1]: Leaving directory `/var/local/cc/news/emacs/leim'
 make: *** [leim] Fehler 2

Earlier I installed an obvious fix for the error-checking rule in
quail-defrule-internal, and now it started revealing errors in
quail files.

It issues this error if a key is not a string, but perhaps should also
take into account if the key is a vector.

Handa-san, could you confirm this is the right fix?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Cannot interrupt async shell command

2006-09-01 Thread Juri Linkov
 One way to fix this bug is to replace the following line in
 `shell-filter-ctrl-a-ctrl-b':
   (goto-char (or comint-last-output-start (point-min)))
 with
   (goto-char (or (and (marker-position comint-last-output-start)
   comint-last-output-start)
  (point-min)))
 i.e. to check if there is a buffer position recorded in
 comint-last-output-start instead of checking the marker
 (always created in `comint-mode') for nil.
 That sounds like a good thing to do in any case.  Could you install this
 change?

 Shouldn't that be:

   (goto-char (or (and comint-last-output-start
 (marker-position comint-last-output-start))
(point-min)))

This will fail when `comint-last-output-start' is not a marker.

Actually, `comint-last-output-start' is never nil and always a
marker in the comint buffer, so both versions will work.

But if we want to be extra safe, then that should be:

  (goto-char (or (and (markerp comint-last-output-start)
  (marker-position comint-last-output-start))
 (point-min)))

i.e. to check if `comint-last-output-start' is a marker and has
a position, and to use this position in `goto-char'.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Cannot interrupt async shell command

2006-08-30 Thread Juri Linkov
 * Start an async shell command: M-! sleep 100  RET
 * Switch to the buffer *Async Shell Command*
 * Type C-c C-c

 I got the error: Marker does not point anywhere

 Backtrace looks as follows:

 Debugger entered--Lisp error: (error Marker does not point anywhere)
   shell-filter-ctrl-a-ctrl-b()
   run-hook-with-args(shell-filter-ctrl-a-ctrl-b )
   comint-send-input(t t)
   comint-skip-input()
   comint-interrupt-subjob()
   call-interactively(comint-interrupt-subjob)

Another commands unusable in *Async Shell Command* are `comint-quit-subjob',
`comint-stop-subjob' and `comint-kill-subjob'.  All they don't work here
due to the call to `comint-skip-input' and `shell-filter-ctrl-a-ctrl-b'
which fails in *Async Shell Command* because the marker
`comint-last-output-start' has no position.

One way to fix this bug is to replace the following line in
`shell-filter-ctrl-a-ctrl-b':

  (goto-char (or comint-last-output-start (point-min)))

with

  (goto-char (or (and (marker-position comint-last-output-start)
  comint-last-output-start)
 (point-min)))

i.e. to check if there is a buffer position recorded in
comint-last-output-start instead of checking the marker
(always created in `comint-mode') for nil.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Visiting an image file fails on tty

2006-08-28 Thread Juri Linkov
In GNU Emacs 22.0.50 (i686-pc-linux-gnu) of 2006-08-28
after visiting an image file in tty-only built Emacs (i.e. no X),
it signals the following error:

Debugger entered--Lisp error: (void-function clear-image-cache)
  clear-image-cache()
  image-toggle-display()
  image-mode()
  set-auto-mode-0(image-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(...)
  find-file-noselect(...)
  find-file(...)
  dired-advertised-find-file()
  call-interactively(dired-advertised-find-file)

But in the X no-toolkit version started in a tty with `-nw' option
the error is different:

Debugger entered--Lisp error: (error Non-X frame used)
  clear-image-cache()
  image-toggle-display()
  image-mode()
  set-auto-mode-0(image-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(...)
  find-file-noselect(...)
  find-file(...)
  dired-advertised-find-file()
  call-interactively(dired-advertised-find-file)

I think even if Emacs doesn't display images on a tty, it still makes
sense to open the content of an image file as text in the Emacs buffer
without an error.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Hello in Hungarian

2006-06-28 Thread Juri Linkov
 thanks for the quick answer. Now I see :-((

 I understand that all people want to see their native
 language listed in that file, but...

I think there is no reason to decline proposals to add a few more
language samples to the HELLO file.  Each takes only one line,
but makes Emacs newbies more happy to see their language
is supported by Emacs (especially non-ASCII characters).

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


pcomplete and partial-completion-mode

2006-06-13 Thread Juri Linkov
There is one problem in using pcomplete with partial-completion-mode
enabled.  partial-completion-mode forces pcomplete to move point to the
end of the original buffer (non-minibuffer).

Test case:

M-x partial-completion-mode RET

;;; Fill buffer with some text and set point to the beginning.
M-: (progn (insert abc\ndef\n) (goto-char (point-min)))

M-x pcomplete RET

;;; Select a file name completion from the *Completions* buffer.
C-x o C-n C-n C-n C-n C-n ... RET

;;; Observe how a selected file name is inserted to the end of the
;;; original buffer, not to the beginning where point initially was.

A small patch below fixes this bug.  I could install it, if it is right
also for other cases where the affected code was intended for.  (IIUC from
the comment above this code in complete.el, it was intended for the
minibuffer usage).

Index: lisp/complete.el
===
RCS file: /sources/emacs/emacs/lisp/complete.el,v
retrieving revision 1.53
diff -c -r1.53 complete.el
*** lisp/complete.el22 May 2006 18:09:40 -  1.53
--- lisp/complete.el13 Jun 2006 12:27:35 -
***
*** 234,240 
(funcall
 (if partial-completion-mode 'add-hook 'remove-hook)
 'choose-completion-string-functions
!(lambda (rest x) (goto-char (point-max)) nil))
;; Build the env-completion and mapping table.
(when (and partial-completion-mode (null PC-env-vars-alist))
  (setq PC-env-vars-alist
--- 234,242 
(funcall
 (if partial-completion-mode 'add-hook 'remove-hook)
 'choose-completion-string-functions
!(lambda (choice buffer mini-p base-size)
!  (if mini-p (goto-char (point-max)))
!  nil))
;; Build the env-completion and mapping table.
(when (and partial-completion-mode (null PC-env-vars-alist))
  (setq PC-env-vars-alist

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Info-try-follow-nearest-node: FORK arg is not described

2006-06-13 Thread Juri Linkov
 Info-try-follow-nearest-node: FORK arg is not described.

Isn't the FORK argument obsoleted by M-n?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Comparing 2 (or 3) directories: problems with file selector dialog (Carbon port)

2006-06-13 Thread Juri Linkov
 This is from a user. He selects Compare directories by mouse (in  the
 ediff menu), which causes a file selection dialog to appear in  the Carbon
 port (since the last input was a non-keyboard event).
 Unfortunately, it looks like directory selection is not enabled for
 this dialog.

 I verified this with a recent version.

Is this Mac-specific?  I can't reproduce this on GNU/Linux with GTK.
Dired-compare-directories uses read-directory-name, so perhaps
read-directory-name doesn't work on Mac.

 Begin forwarded message:

 From: Olivier Marti [EMAIL PROTECTED]
 Date: 23 May 2006 16:56:39 BDT
 To: [EMAIL PROTECTED]
 Subject: [Aquamacs-bugs] Comparing 2 (or 3) directory is impossible.

 Enter your bug report here.

 I've tried to compare two directories. Aquamacs open the dialog  window
 of the Finder to open a file. It is possible to select a  file, but not
 a directory ! The workaround is to select a file in  each
 directory. Which is not a very elegant method ..

 Best regards (and bravo for Aquamacs !!)

 Olivier

 In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
  of 2006-04-10 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution  0.9.9c
 X server distributor `Apple Computers', version 10.3.9
 configured using `configure '--without-x' '--prefix=/usr/local''

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: query-replace-regexp

2006-06-08 Thread Juri Linkov
 ~/emacs/src/emacs --debug-init 

 With

 M-x  `query-replace-regexp'

 I get an error:

 query-replace-read-from: Wrong number of arguments: #subr
 read-from-minibuffer, 8

Please recompile C source files.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: bug in dired-do-query-replace-regexp (fix included)

2006-06-01 Thread Juri Linkov
 Please describe exactly what actions triggered the bug
 and the precise symptoms of the bug:

 'Q' in dired doesn't work.

Could you describe exactly what a problem do you have.  I don't see any.

 It seems like the culprit is that `query-replace-read-args' is called
 with too many args.

After removing the arg `noerror' from `query-replace-read-args'
typing `Q' in dired immediately fails with the error
Buffer is read-only.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: .gcov fontification in compile.el

2006-05-28 Thread Juri Linkov
 There are a few issues with that, all the lines in the qcov use the
 `underline' face. This is kind of distracting and it does not help in
 any way.

This unnecessary fontification can be removed by deleting
.+$ from the end of gcov-never-called-line and gcov-called-line.

 The fontification of lines that use the full length of the counter
 field is incorrect.
 Example:

 116305350: 1328:  for (i = 0; i  nodes; i++) {

(gcov-called-line
  ^ +[-0-9]+: +\\([1-9]\\|[0-9]\\{2,\\}\\):.*$ nil 1 nil 0)

Shouldn't ? be used instead of + here?

Maybe this space was added to avoid false matches with other outputs?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: suggestion in query-replace is messed up after cancelation

2006-05-28 Thread Juri Linkov
 Neither one is very good.  However, to do any better
 we would need to maintain a separate history of pairs to suggest.
 This would be disconnected from the history list of strings.

 This patch should implement this behavior.

 + (defvar query-replace-defaults nil
 +   Default values of FROM-STRING and TO-STRING for `query-replace'.
 + This is a cons cell (FROM-STRING . TO-STRING), or nil if there is
 + no default value.)

What about having a list of cons cells (FROM-STRING . TO-STRING)
of all previous replacements and using new keys (e.g. M-P and M-N)
to access previous/next replacements pairs from the replacement pair
history?

 !   (if (and (zerop (length from)) query-replace-defaults)
 (progn
   (set query-replace-from-history-variable
(cdr (symbol-value query-replace-from-history-variable)))

We don't need this `set' anymore.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: suggestion in query-replace is messed up after cancelation

2006-05-25 Thread Juri Linkov
 1) $ emacs -Q
 2) type football and C-a
 3) M-% foo RET bar RET y (this replaces the only occurence of foo)
 4) M-% (suggests foo - bar) baz RET C-g
 5) M-% (suggests bar - baz, while it should suggest foo - bar)

 I think this can be fixed with the following patch to
 query-replace-read-to.  I can install it if people don't object.

Removing from-element from the history list is not a good solution.
Most often I type C-g in the to-element prompt, when instead
of typing a long to-element I need to switch to another buffer
and copy to-element from that buffer (to yank it later from the kill ring
to the to-element prompt).  After that I type M-% again, and definitely
don't want to re-type the from-element.  I need to get the previous
already entered from-element from the history by M-p in the
from-element's prompt.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


msb.el is broken

2006-05-25 Thread Juri Linkov
I noticed that msb.el is now broken: it doesn't accept down events
anymore, like the normal buffer selection menu does.  This is caused
by the recent change.

And there is also another bug in msb.el: after selecting a sub-menu
it fails with:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  x-popup-menu(((346 172) #window 3 on *scratch*) (Most recently used (1) 
(*Messages* *  *Messages* (nil) . menu-bar-select-buffer)))
  mouse-select-buffer((C-down-mouse-1 (#window 3 on *scratch* 1 (346 . 172) 
12486921 nil 1 (57 . 0) nil (346 . 172) (6 . 10
  mouse-select-buffer((C-down-mouse-1 (#window 3 on *scratch* 1 (346 . 172) 
12486921 nil 1 (57 . 0) nil (346 . 172) (6 . 10
  msb((C-down-mouse-1 (#window 3 on *scratch* 1 (346 . 172) 12486921 nil 1 
(57 . 0) nil (346 . 172) (6 . 10
  call-interactively(msb)

Perhaps this depends on the toolkit used.  I use no toolkit on GNU/Linux.

As I see this bug is possibly caused by some changes in the menu
specifications: it fails with nil element in the certain position of the
menu specification.  In Emacs 21.4 there is nil in the same position, but
it doesn't fail.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Crash in image-mode

2006-05-25 Thread Juri Linkov
Emacs crashes while visiting remote image files.

Program received signal SIGSEGV, Segmentation fault.
0xb7c03e07 in fclose () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7c03e07 in fclose () from /lib/tls/i686/cmov/libc.so.6
#1  0x081142fd in png_load (f=0x8669530, img=0x8738060) at image.c:6107
#2  0x0810f6a0 in lookup_image (f=0x8669530, spec=143472109) at image.c:1865
#3  0x0806bea2 in handle_single_display_spec (it=0xbf92e030, spec=143472109, 
object=144230780, position=0xbf92e0d0, display_replaced_before_p=0) at 
xdisp.c:4191
#4  0x0806af30 in handle_display_prop (it=0xbf92e030) at xdisp.c:3800
#5  0x080694f3 in handle_stop (it=0xbf92e030) at xdisp.c:3010
#6  0x0806e076 in reseat (it=0xbf92e030, pos={charpos = 1, bytepos = 1}, 
force_p=1) at xdisp.c:5196
#7  0x08068c8c in init_iterator (it=0xbf92e030, w=0x866c448, charpos=1, 
bytepos=1, row=0x87c91f0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:2677
#8  0x08068dbd in start_display (it=0xbf92e030, w=0x866c448, pos={charpos = 1, 
bytepos = 1}) at xdisp.c:2696
#9  0x0807eb4c in try_window (window=140952652, pos={charpos = 1, bytepos = 1}, 
check_margins=1) at xdisp.c:13326
#10 0x0807d9a0 in redisplay_window (window=140952652, just_this_one_p=0) at 
xdisp.c:12959
#11 0x08079ddb in redisplay_window_0 (window=140952652) at xdisp.c:11586
#12 0x0819de6c in internal_condition_case_1 (bfun=0x8079da8 
redisplay_window_0, arg=140952652, handlers=137942245, hfun=0x8079d87 
redisplay_window_error)
at eval.c:1522
#13 0x08079d6e in redisplay_windows (window=140952652) at xdisp.c:11565
#14 0x08079d1b in redisplay_windows (window=140858996) at xdisp.c:11557
#15 0x080791b2 in redisplay_internal (preserve_echo_area=0) at xdisp.c:11125
#16 0x08077546 in redisplay () at xdisp.c:10355
#17 0x0811df90 in read_char (commandflag=1, nmaps=2, maps=0xbf92ee00, 
prev_event=137955529, used_mouse_menu=0xbf92ef34) at keyboard.c:2549
#18 0x081282b8 in read_key_sequence (keybuf=0xbf92f110, bufsize=30, 
prompt=137955529, dont_downcase_last=0, can_return_switch_frame=1, 
fix_current_buffer=1)
at keyboard.c:8864
#19 0x0811b6f9 in command_loop_1 () at keyboard.c:1536
#20 0x0819dd40 in internal_condition_case (bfun=0x811b3d6 command_loop_1, 
handlers=138000169, hfun=0x811af04 cmd_error) at eval.c:1474
#21 0x0811b24d in command_loop_2 () at keyboard.c:1328
#22 0x0819d7dc in internal_catch (tag=137996401, func=0x811b22a 
command_loop_2, arg=137955529) at eval.c:1212
#23 0x0811b203 in command_loop () at keyboard.c:1307
#24 0x0811ac70 in recursive_edit_1 () at keyboard.c:1000
#25 0x0811adc4 in Frecursive_edit () at keyboard.c:1061
#26 0x081196b5 in main (argc=2, argv=0xbf92f8d4) at emacs.c:1789

It seems that the png library can't handle remote files, so the
following change fixes this:

Index: lisp/image-mode.el
===
RCS file: /sources/emacs/emacs/lisp/image-mode.el,v
retrieving revision 1.11
diff -u -r1.11 image-mode.el
--- lisp/image-mode.el  18 Apr 2006 21:21:08 -  1.11
+++ lisp/image-mode.el  25 May 2006 22:41:30 -
@@ -140,6 +140,8 @@
 (let* ((image
(if (and (buffer-file-name)
 (not (buffer-modified-p))
+(not (file-remote-p (buffer-file-name)))
 (not (and (boundp 'archive-superior-buffer)
   archive-superior-buffer))
 (not (and (boundp 'tar-superior-buffer)

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Info headings not streamlined properly, and missing entries

2006-03-11 Thread Juri Linkov
 Info directory headers are not merged properly.  Please see the
 attached file cap-dir.tiff.  In particular, note that World Wide Web
 is not fontified correctly and that the entry for URL is missing.
 Furthermore, if I understand correctly, Word Wide Web should get
 streamlined to Net Utilities but this doesn't happen.

 To reproduce it on my Carbon Emacs (CVS checkout today), create two
 directories ~/info-1 and ~/info-2.  Place dir-1 (attached) in ~/info-1
 and make sure it's named ~/info-1/dir.  Put dir-2 (also attached) in
 ~/info-2 and make sure it's similarly named.  On my system, I start
 Emacs like this:

 $ /Applications/Emacs.app/Contents/MacOS/Emacs -q

 and evaluate

 (setq Info-directory-list '(~/info-1 ~/info-2))

 in the *scratch* buffer.  Now do `C-h i', scroll down a bit, and you
 can see the problem.

I think I fixed this bug and also another bug I discovered while fixing.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: autoload and auto-compression-mode

2006-02-24 Thread Juri Linkov
 There are three lists, one of Elisp suffixes, one of file representation
 suffixes and one which is a computed combination of both.

I think `file representation suffix' is an unclear term.  There are such
file representations are text, image, unibyte, literal, hex dump, etc.
And using this term in the context of `load' is very confusing.
The purpose of this variable can be mistakenly interpreted as specifying
what file representation `load' uses.

Maybe in the same way as `image-file-name-extensions' is used to specify
image file name suffixes, the name of a new variable should be
`load-file-name-suffixes'?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: autoload and auto-compression-mode

2006-02-19 Thread Juri Linkov
 I can install the patches if desired.  Once they are installed, I would
 also update various docstrings and loading.texi.

 The doc strings of load-suffixes and load-file-rep-suffixes left me
 confused as to what each of the two lists does.

I want to note also that the name `load-file-rep-suffixes' is confusing too.
The meaning of the infix `-rep-' is not evident.  What does it mean?
`REPeat'?  (i.e. repeating applying suffixes from a different suffix list.)
`REPlace'? (i.e replacing suffixes.)  Replacing doesn't seem correct,
because suffixes from the second list get added to the file name.
Maybe, then `load-file-add-suffixes' is a better name?  Or maybe,
`load-same-file-suffixes'?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: space in regexp-search

2006-02-18 Thread Juri Linkov
 The right way to do what you want is to set search-whitespace-regexp
 to nil.  I will make this change in the doc string and custom type to
 make it clearer.

BTW, it seems the following fix is necessary for isearch on Info manuals,
because currently it uses Info-search-whitespace-regexp even for non-regexp
Info isearch, and it is not possible to use `C-q SPC' to search for
a literal space.  I think everyone wanting to take the advantage of
Info-search-whitespace-regexp to use SPC for a sequence of whitespace chars,
can start isearch with M-C-s instead of C-s.

Index: lisp/info.el
===
RCS file: /sources/emacs/emacs/lisp/info.el,v
retrieving revision 1.479
diff -c -r1.479 info.el
*** lisp/info.el17 Feb 2006 21:55:10 -  1.479
--- lisp/info.el17 Feb 2006 21:57:34 -
***
*** 1642,1648 
  (and (search-backward \^_ nil t)
   (looking-at
\^_\n\\(Tag Table\\|Local 
Variables\\)))
!   (let ((search-spaces-regexp Info-search-whitespace-regexp))
  (if (if backward
  (re-search-backward regexp bound t)
(re-search-forward regexp bound t))
--- 1642,1650 
  (and (search-backward \^_ nil t)
   (looking-at
\^_\n\\(Tag Table\\|Local 
Variables\\)))
!   (let ((search-spaces-regexp
!  (if (or (not isearch-mode) isearch-regexp)
!  Info-search-whitespace-regexp)))
  (if (if backward
  (re-search-backward regexp bound t)
(re-search-forward regexp bound t))
***
*** 1660,1666 
;; If no subfiles, give error now.
(if give-up
  (if (null Info-current-subfile)
! (let ((search-spaces-regexp Info-search-whitespace-regexp))
(if backward
(re-search-backward regexp)
  (re-search-forward regexp)))
--- 1662,1670 
;; If no subfiles, give error now.
(if give-up
  (if (null Info-current-subfile)
! (let ((search-spaces-regexp
!(if (or (not isearch-mode) isearch-regexp)
!Info-search-whitespace-regexp)))
(if backward
(re-search-backward regexp)
  (re-search-forward regexp)))
***
*** 1731,1737 
(and (search-backward \^_ nil t)
 (looking-at
  \^_\n\\(Tag Table\\|Local 
Variables\\)))
! (let ((search-spaces-regexp Info-search-whitespace-regexp))
(if (if backward
(re-search-backward regexp nil t)
  (re-search-forward regexp nil t))
--- 1735,1743 
(and (search-backward \^_ nil t)
 (looking-at
  \^_\n\\(Tag Table\\|Local 
Variables\\)))
! (let ((search-spaces-regexp
!(if (or (not isearch-mode) isearch-regexp)
!Info-search-whitespace-regexp)))
(if (if backward
(re-search-backward regexp nil t)
  (re-search-forward regexp nil t))

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Info fails to find history.info

2006-02-09 Thread Juri Linkov
  Do users ever enter them?

 I can't imagine a situation where users might want to enter them.

 In that case, there is no reason to keep them.

 Since `toc' pertains to the Current Info file, it makes no sense
 for that to be treated like a file of any kind.  If anything,
 it is more like a virtual node.  It could have a node name
 such as :toc: which can't really appear in an Info file.

Supporting virtual nodes looks like a new feature.  Are you sure this is
necessary for the next release?

 A phony node nane is not logically ideal for the history,
 but maybe it would work.

Do you mean a history node with references to nodes visited only in the
current manual?  As a user, I certainly wouldn't like this.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: ffap highlighting persists

2006-02-09 Thread Juri Linkov
 In case this is considered to be a feature, here are some arguments against
 it:

 1. Such mouse-face highlighting suggests a link or button - that is, it
 suggests that you can click mouse-2 to follow the link. This is of course
 not the case.

We could bind [mouse-2] on highlighted URLs to follow a link exactly like
lisp/net/goto-addr.el does.

 2. It is not needed - if you can use ffap the first time without such
 highlighting, you can continue to do so without it. If you can get to all
 such choices in a menu, you don't need them highlighted in the buffer.

 3. It is distracting, and interferes with other highlighting.

 At the very least, such persistent highlighting should be optional.

I agree.  A new option would be useful.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: ffap highlighting persists

2006-02-09 Thread Juri Linkov
Below is a patch that allows the user to turn off ffap highlighting.
Actually, it was possible to do this without this patch because
ffap.el checks for the face `ffap' with (facep 'ffap), but this
possibility is hidden from users.  A standard way to customize this
is to define faces with `defface':

Index: lisp/ffap.el
===
RCS file: /sources/emacs/emacs/lisp/ffap.el,v
retrieving revision 1.54
diff -c -r1.54 ffap.el
*** lisp/ffap.el6 Feb 2006 14:33:33 -   1.54
--- lisp/ffap.el9 Feb 2006 17:33:38 -
***
*** 1321,1326 
--- 1323,1334 
  (defvar ffap-highlight t
If non-nil, ffap highlights the current buffer substring.)
  
+ (defface ffap
+   '((t :inherit highlight))
+   Face used to highlight the current buffer substring.
+   :group 'ffap
+   :version 22.1)
+ 
  (defvar ffap-highlight-overlay nil
Overlay used by `ffap-highlight'.)
  
***
*** 1344,1351 
 (t
  (setq ffap-highlight-overlay
  (apply 'make-overlay ffap-string-at-point-region))
! (overlay-put ffap-highlight-overlay 'face
! (if (facep 'ffap) 'ffap 'highlight)
  
  
  ;;; Main Entrance (`find-file-at-point' == `ffap'):
--- 1352,1358 
 (t
  (setq ffap-highlight-overlay
  (apply 'make-overlay ffap-string-at-point-region))
! (overlay-put ffap-highlight-overlay 'face 'ffap
  
  
  ;;; Main Entrance (`find-file-at-point' == `ffap'):

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: strange behaviour of // in open file names

2006-02-09 Thread Juri Linkov
[followup to emacs-pretest-bug@gnu.org from [EMAIL PROTECTED]
 When I open a file with C-x C-f I have to enter its name in the minibuffer.  
 If
 its name contains double slashs //, everything before them is printed in 
 grey
 (my global standard colour is orange).  Additionally, a C-a doesn't go to the
 first character in the file path but to the most recent double slash (if the
 cursor was behind it).

I use ffap and since file-name-shadow-mode was enabled it bothered me that
the protocol part of URLs is shadowed and C-a doesn't go to the beginning
of the minibuffer.  In all other respects I like file-name-shadow-mode.

I think there should be a way to tell file-name-shadow-mode not to shadow
certain minibuffer strings with a patch like below:

Index: lisp/rfn-eshadow.el
===
RCS file: /sources/emacs/emacs/lisp/rfn-eshadow.el,v
retrieving revision 1.22
diff -u -w -b -r1.22 rfn-eshadow.el
--- lisp/rfn-eshadow.el 6 Feb 2006 14:33:35 -   1.22
+++ lisp/rfn-eshadow.el 9 Feb 2006 19:16:11 -
@@ -130,6 +130,10 @@
 (defvar rfn-eshadow-overlay)
 (make-variable-buffer-local 'rfn-eshadow-overlay)
 
+(defvar rfn-eshadow-update-overlay-p nil
+  Function to disable shadow depending on the minibuffer contents.
+Its return value nil removes shadow from the minibuffer.)
+
 
 ;;; Hook functions
 
@@ -168,6 +172,10 @@
 This is intended to be used as a minibuffer `post-command-hook' for
 `file-name-shadow-mode'; the minibuffer should have already
 been set up by `rfn-eshadow-setup-minibuffer'.
+  (if (and (functionp rfn-eshadow-update-overlay-p)
+  (null (funcall rfn-eshadow-update-overlay-p)))
+  (move-overlay rfn-eshadow-overlay
+   (minibuffer-prompt-end) (minibuffer-prompt-end))
   (condition-case nil
   (let ((goal (substitute-in-file-name (minibuffer-contents)))
 (mid (overlay-end rfn-eshadow-overlay))
@@ -195,7 +203,7 @@
   (setq end mid)))
   (move-overlay rfn-eshadow-overlay (minibuffer-prompt-end) start)))
 ;; `substitute-in-file-name' can fail on partial input.
-(error nil)))
+  (error nil
 
 (define-minor-mode file-name-shadow-mode
   Toggle File-Name Shadow mode.

Index: lisp/ffap.el
===
RCS file: /sources/emacs/emacs/lisp/ffap.el,v
retrieving revision 1.53
diff -c -r1.53 ffap.el
*** lisp/ffap.el19 Nov 2005 12:18:07 -  1.53
--- lisp/ffap.el9 Feb 2006 19:16:12 -
***
*** 1255,1261 
(abbreviate-file-name (expand-file-name guess))
))
  (setq dir (file-name-directory guess
! (let ((minibuffer-completing-file-name t))
(setq guess
(completing-read
 prompt
--- 1255,1263 
(abbreviate-file-name (expand-file-name guess))
))
  (setq dir (file-name-directory guess
! (let ((minibuffer-completing-file-name t)
! (rfn-eshadow-update-overlay-p
!  (lambda () (not (ffap-url-p (minibuffer-contents))
(setq guess
(completing-read
 prompt

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: shell-command-on-region fooled by long lines

2006-02-09 Thread Juri Linkov
[followup to emacs-pretest-bug@gnu.org from [EMAIL PROTECTED]
 shell-command-on-region on this:
   perl -le 'for(1..6){print $_ x 111}'
 mistakenly thinks it is showing all the output in the minibuffer, so
 it doesn't create new a new buffer for the output, when in fact it
 gets fooled by the wrapped lines.

This bothered me for a long time too until I realized that the decision
whether to display the output in the echo area or in a separate window
has nothing to do with the amount of lines in the output.

Sometimes I need to display the output in a separate window
even with 1 line to switch to this window later and to do some operation
on it (e.g. save a part of the output to the kill ring).  In all
other cases displaying the output in the echo area is more preferable
to not change the current window configuration.

But with the current code it is not possible to do this without
modifying the function `shell-command-on-region'.  I propose the
following patch that changes this function to call `display-message-or-buffer'
conditionally depending on the value of a new variable
`shell-command-display-message'.  This is not a new feature, but rather is
a fix for a misfeature.

With this variable, users can either set it permanently to nil
to always display the output in a separate window, or let-bind
it depending on the key used to exit the command-reading minibuffer:

(defadvice shell-command (around my-shell-command act)
  (let* ((shell-command-display-message
  (unless (eq last-input-char 'S-return)
shell-command-display-message)))
ad-do-it))

This displays the output in the echo area when the minibuffer is exited
with RET, and displays the output in a separate window when the minibuffer
is exited with S-RET.

Index: lisp/simple.el
===
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.790
diff -c -r1.790 simple.el
*** lisp/simple.el  4 Feb 2006 21:48:20 -   1.790
--- lisp/simple.el  9 Feb 2006 19:16:09 -
***
*** 1961,1966 
--- 1967,1976 
   (car (cdr (cdr (process-command process
   (substring signal 0 -1
  
+ (defvar shell-command-display-message t
+   If nil, display the output in a pop-up buffer.
+ If non-nil, display the output in the echo area if the output
+ is not too long.  See `display-message-or-buffer'.)
+ 
  (defun shell-command-on-region (start end command
  optional output-buffer replace
  error-buffer display-error-buffer)
***
*** 1987,1993 
  \(determined by the variable `max-mini-window-height' if
  `resize-mini-windows' is non-nil), it is shown there.  Otherwise
  it is displayed in the buffer `*Shell Command Output*'.  The output
! is available in that buffer in both cases.
  
  If there is output and an error, a message about the error
  appears at the end of the output.
--- 1997,2005 
  \(determined by the variable `max-mini-window-height' if
  `resize-mini-windows' is non-nil), it is shown there.  Otherwise
  it is displayed in the buffer `*Shell Command Output*'.  The output
! is available in that buffer in both cases.  If the variable
! `shell-command-display-message' is nil, it displays the output
! in a pop-up buffer.
  
  If there is output and an error, a message about the error
  appears at the end of the output.
***
*** 2104,2110 
 (format  - Exit [%d] exit-status)
  (if (with-current-buffer buffer ( (point-max) (point-min)))
  ;; There's some output, display it
! (display-message-or-buffer buffer)
;; No output; error?
(let ((output
   (if (and error-file
--- 2116,2126 
 (format  - Exit [%d] exit-status)
  (if (with-current-buffer buffer ( (point-max) (point-min)))
  ;; There's some output, display it
! (if shell-command-display-message
! (display-message-or-buffer buffer)
!   (with-current-buffer buffer
! (goto-char (point-min))
! (display-buffer (current-buffer
;; No output; error?
(let ((output
   (if (and error-file

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: strange behaviour of // in open file names

2006-02-09 Thread Juri Linkov
 I use ffap and since file-name-shadow-mode was enabled it bothered me that
 the protocol part of URLs is shadowed and C-a doesn't go to the beginning
 of the minibuffer.

 Try M-x url-handler-mode RET

Great.  It takes care of handling file-name-shadow-mode in ffap
prompts correctly.  Does this mean that ffap.el should enable it
by default?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Info fails to find history.info

2006-02-07 Thread Juri Linkov
-file Info-current-node)))
 
 (defun Info-restore-desktop-buffer (desktop-buffer-file-name

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Info fails to find history.info

2006-02-06 Thread Juri Linkov
 The readline 5.1 package comes with a file named history.info which
 documents the GNU history library.  The Info subsystem of Emacs fails
 to find history.info because it treats the file name history as
 special.  In particular, (Info-find-file history) always returns the
 symbol history instead of a path to a file.  This makes it somewhat
 hard to read the manual for the GNU history library.

The same problem exists for other possible Info file names: apropos and
toc whose virtual file names were reserved recently.  I see at least
two solutions:

1. Use symbols for the file name argument of `Info-find-node'
   for virtual Info files:
   e.g. use   (Info-find-node 'apropos Index)
   instead of (Info-find-node apropos Index)

2. Reserve less likely file names for virtual Info files,
   e.g. info-apropos, info-history, info-toc.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: log-view-minor-wrap

2006-01-25 Thread Juri Linkov
 With the latest change in log-view.el, typing `=' on a revision in the
 *cvs-info* shows the reverse diff.  That's because the first argument of
 cvs-diff functions should be the revision at the next older revision,
 and the second argument should be the revision at point.

 But without this latest change, cvs-mode-edit-log is broken, and so is
 cvs-mode-find-file and a few more.

If argument order depends on the function name, then perhaps the
wrapper function should have an additional argument `-cvs-mode!-fun'?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: In info: Wrong type argument: stringp, nil

2006-01-06 Thread Juri Linkov
 I fixed this bug.

I don't understand the purpose of the following fix:

@@ -568,7 +568,9 @@
(if (and (stringp file-or-node) (string-match (.*) file-or-node))
file-or-node
  (concat ( file-or-node 
-(if (zerop (buffer-size))
+(if (and (zerop (buffer-size))
+(null Info-history))
+   ;; If we just created the Info buffer, go to the directory.
 (Info-directory
 
A new condition `(null Info-history)' doesn't fix a bug, but with some
user configuration it creates an empty Info buffer.

 Does that patch from Nov 25 have any other problem?

I can't produce any problem now, so we could either wait for more bug
reports or at least restore the following change:

@@ -726,8 +729,7 @@
(pline(count-lines (point-min) (line-beginning-position)))
(wline(count-lines (point-min) (window-start)))
(old-history  Info-history)
-   (new-history (and Info-current-file
- (list Info-current-file Info-current-node (point)
+   (new-history  (list Info-current-file Info-current-node (point
 (kill-buffer (current-buffer))
 (Info-find-node filename nodename)
 (setq Info-history old-history)

This change most likely can produce a bug because a condition below in
the same function tests the value of `new-history' as:

  ;; only add to the history when coming from a different file+node
  (if new-history
  (setq Info-history (cons new-history Info-history))

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: vc-annotate tries to load vc-nil

2006-01-06 Thread Juri Linkov
 BTW, now that I think about it, the reason why I had the old behavior is
 that the current revision (the not-yet-committed state of the file) can't
 be obtained otherwise.
 So with the old behavior I could do a diff between the current file and
 revision N whereas with your patch it seems there's no way to do that
 any more.  I'm not sure who important it is in practice.

This is still possible by putting the mark or point in the *cvs-info*
buffer before the first revision line.  This produces a diff between
the current revision and revision N at the end of the region.

This behavior could be documented in the Emacs manual and docstrings.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: vc-annotate tries to load vc-nil

2006-01-03 Thread Juri Linkov
 Thanks, now I see.  I'm so accustomed to the logic of `log-view-diff'
 that uses the previous revision if there is no mark.  Perhaps `C-x c ='
 should use exactly the same logic.

 I don't have an opinion, so feel free to change it (it's probably in
 log-view-minor-wrap).

Thanks for the hint.  The patch below changes log-view-minor-wrap to use
the same logic as log-view-diff.

Index: lisp/log-view.el
===
RCS file: /sources/emacs/emacs/lisp/log-view.el,v
retrieving revision 1.27
diff -c -r1.27 log-view.el
*** lisp/log-view.el23 Dec 2005 21:49:32 -  1.27
--- lisp/log-view.el4 Jan 2006 06:28:48 -
***
*** 200,213 
  
  (defun log-view-minor-wrap (buf f)
(let ((data (with-current-buffer buf
!   (cons
!(cons (log-view-current-file)
!  (log-view-current-tag))
!(when mark-active
!  (save-excursion
!(goto-char (mark))
!(cons (log-view-current-file)
!  (log-view-current-tag
  (let ((cvs-branch-prefix (cdar data))
  (cvs-secondary-branch-prefix (and (cdar data) (cddr data)))
  (cvs-minor-current-files
--- 200,217 
  
  (defun log-view-minor-wrap (buf f)
(let ((data (with-current-buffer buf
!   (let* ((beg (if mark-active (region-beginning) (point)))
!  (end (if mark-active (region-end) (point)))
!  (fr (log-view-current-tag beg))
!  (to (log-view-current-tag end)))
! (when (string-equal fr to)
!   (save-excursion
! (goto-char end)
! (log-view-msg-next)
! (setq to (log-view-current-tag
! (cons
!  (cons (log-view-current-file) to)
!  (cons (log-view-current-file) fr))
  (let ((cvs-branch-prefix (cdar data))
  (cvs-secondary-branch-prefix (and (cdar data) (cddr data)))
  (cvs-minor-current-files

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: TAB TAB completion fails after loading AUCTeX

2006-01-03 Thread Juri Linkov
 Here's a bug report that I submitted earlier today to the AUCTeX
 buglist.  Ralf Angeli helpfully suggested that this could be a
 (Mac-specific) emacs bug that's triggered by AUCTeX, so I'm posting it
 here.  Please let me know if I can answer any further questions.

Thanks for the bug report.  I can't reproduce it on GNU/Linux.
So perhaps it is really Mac-specific.  Could you put a breakpoint
on `completion-setup-function' and find out on which variable it fails?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Function w32_abort not defined

2005-12-30 Thread Juri Linkov
 We could add this command to .gdbinit to reassure anyone who might
 get worried:

 output  If you see messages immediately following about functions not being 
 defined,\n don't worry about them.  Nothing is wrong.\n

 Done.

Since I raised this question, I want to make clear that I was worried
not by the meaning of these error messages, but by the clutter they
produce in the gdb window.  And now a new 4-line explanation just added
more clutter :-)

A proper analogy for the reaction to gdb error messages are -Wno-pointer-sign
compiler warnings.  Nobody worries about them, but everyone wants to get rid.

If it would be possible to generate .gdbinit depending on the values specified
for `configure'...

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: vc-annotate tries to load vc-nil

2005-12-29 Thread Juri Linkov
 1. start PCL-CVS;
 2. insert an old file removed from the CVS repository, e.g.
`I emacs/lisp/webjump.el' (note that it was moved from
emacs/lisp/webjump.el to emacs/lisp/net/webjump.el);
 3. type `l';
 4. in the *cvs-info* buffer type `n';
 5. type `d' or `f'  =  vc-nil error

 That's an old bug.
 Instead of `d' (which uses VC) why don't you use
 `C-x c =' (which uses PCL-CVS)?

`C-x c =' is not equivalent to `d'.  Unlike `d', it doesn't compare the
revision at point with its previous revision.  It compares the revision at
point with the current revision.  Perhaps this is another bug, I don't know.

To show the difference below are diff headers produced after typing
`d' on the revision 1.6 in the *cvs-info* buffer in log-view mode:

Index: lisp/net/webjump.el
===
RCS file: /sources/emacs/emacs/lisp/net/webjump.el,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6

And typing `C-x c =' or `=' on the same revision 1.6:

Index: lisp/net/webjump.el
===
RCS file: /sources/emacs/emacs/lisp/net/webjump.el,v
retrieving revision 1.6
diff -u -r1.6 webjump.el

The latter diff is useless.

When using `C-x c =' or `=' on a file removed from the CVS repository,
the diff is more useless: it compares the revision at point with
/dev/null:

Index: lisp/webjump.el
===
RCS file: lisp/webjump.el
diff -N lisp/webjump.el
--- lisp/webjump.el 27 May 1997 16:20:16 -  1.4
+++ /dev/null   1 Jan 1970 00:00:00 -

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: customize-group completions

2005-12-29 Thread Juri Linkov
 However, it is possible that there is a group in cus-load.el with the
 same name as autoload option in loaddefs.el.  In this case, this name
 won't get into the completion list.  Maybe a better solution is to put
 `custom-group' property explicitly on every group symbol in cus-load.el?

 Would you like to implement that fix?

I've already installed a fix in cus-edit.el on 2005-12-04.  It works
correctly for all cases except only one case where the group name
`latin1-display' is the same as the variable name `latin1-display'.
The fact that after starting Emacs with `emacs -Q' there is no completion
for `latin1-display' in the completion list of `customize-group' is not
a problem, because it exists in the completion list of `customize-option'.
And after loading `latin1-disp.el' it arrives also to the completion list
of `customize-group'.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: vc-annotate tries to load vc-nil

2005-12-29 Thread Juri Linkov
 `C-x c =' is not equivalent to `d'.  Unlike `d', it doesn't compare the
 revision at point with its previous revision.  It compares the revision at
 point with the current revision.  Perhaps this is another bug, I don't know.

 No it's not a bug.  It's just a difference.  Use point and mark to select
 the two revisions you care about.

Thanks, now I see.  I'm so accustomed to the logic of `log-view-diff'
that uses the previous revision if there is no mark.  Perhaps `C-x c ='
should use exactly the same logic.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Strange behaviour of the undo function

2005-12-28 Thread Juri Linkov
 In the *scratch* buffer type part of a symbol and type M-TAB.
 In the *Completions* buffer click mouse-1 on a completion string.

 I think I fixed this.  Does it work now?

Not quite.  Now it works very strangely.

When the first mouse click in a new Emacs instance is mouse-2, then all
subsequent mouse-1 clicks in the same Emacs instance work correctly.

Test case that works correctly:

emacs -q
d e f M-TAB
mouse-2 on a completion in the *Completions* buffer
C-x u
M-TAB
mouse-1 on a completion in the *Completions* buffer

But if the first click is mouse-1, this causes an error.
Test case that fails:

emacs -q
d e f M-TAB
mouse-1 on a completion in the *Completions* buffer

displays the error message:

insert-for-yank: Buffer is read-only: #buffer *Completions*

After the second click mouse-1 on the same completion it inserts the
completion string to the *scratch* buffer, but leaves point in the same
window where the *Completions* buffer was.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: font-lock-add-keywords in hi-lock.el

2005-12-28 Thread Juri Linkov
 font-lock-keywords in the affected Gnus buffers is (t nil).

 [...]

 Is that enough information to find the culprit, or is there a watch I
 can put on the global value of font-lock-keywords which will print a
 stacktrace or enter the debugger when it is changed?

I think this information is enough to find the culprit.  The function
`font-lock-fontify-keywords-region' is the only remaining function in
font-lock.el that compiles font-lock-keywords without calling
`(font-lock-set-defaults)' first.

Before fixing it, it would be useful to know how it gets called.
In the buffer list you sent earlier there is the *Occur* buffer.
Do you remember on what buffer you called `occur'?  Very likely
`occur' forced fontification on a non-font-lock buffer.

However, I can't reproduce this bug with `emacs -Q'.  Do you have a
special font-lock configuration in .emacs, like calling
`(font-lock-turn-on-thing-lock)' directly on non-font-lock buffers
or something like that?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: vc-annotate tries to load vc-nil

2005-12-28 Thread Juri Linkov
 the following change breaks `M-x vc-annotate RET' for me:
 [...]

 Should be fixed now,

I don't know is it a new bug or not, but I get a similar error message:

  vc-find-backend-function: Cannot open load file: vc-nil

after using `log-view-find-version' or `log-view-diff' on a file removed
from the CVS repository.  Test case:

1. start PCL-CVS;
2. insert an old file removed from the CVS repository, e.g.
   `I emacs/lisp/webjump.el' (note that it was moved from
   emacs/lisp/webjump.el to emacs/lisp/net/webjump.el);
3. type `l';
4. in the *cvs-info* buffer type `n';
5. type `d' or `f'  =  vc-nil error

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


lisp/net/webjump.el is out-of-date

2005-12-28 Thread Juri Linkov
;
!   ftp://ftp://rm.mirror.garr.it/mirrors/gnuftp;
!   ftp://ftp.nluug.nl/pub/gnu/;
!   ftp://ftp.mirror.nl/pub/mirror/gnu/;
!   ftp://ftp.nl.uu.net/pub/gnu/;
!   ftp://mirror.widexs.nl/pub/gnu/;
!   ftp://ftp.easynet.nl/mirror/GNU/;
ftp://ftp.win.tue.nl/pub/gnu;
!   ftp://gnu.mirror.vuurwerk.net/pub/GNU/;
!   ftp://gnu.kookel.org/pub/ftp.gnu.org/;
!   ftp://ftp.uninett.no/pub/gnu/;
!   ftp://ftp.task.gda.pl/pub/gnu/;
!   ftp://sunsite.icm.edu.pl/pub/gnu/;
!   ftp://ftp.man.poznan.pl/pub/gnu;
!   ftp://ftp.ist.utl.pt/pub/GNU/gnu/;
!   ftp://ftp.telepac.pt/pub/gnu/;
!   ftp://ftp.timisoara.roedu.net/mirrors/ftp.gnu.org/pub/gnu;
!   ftp://ftp.chg.ru/pub/gnu/;
!   ftp://gnuftp.axitel.ru/;
!   ftp://ftp.arnes.si/software/gnu/;
!   ftp://ftp.etsimo.uniovi.es/pub/gnu/;
!   ftp://ftp.rediris.es/pub/gnu/;
!   ftp://ftp.chl.chalmers.se/pub/gnu/;
!   ftp://ftp.isy.liu.se/pub/gnu/;
!   ftp://ftp.luth.se/pub/unix/gnu/;
!   ftp://ftp.stacken.kth.se/pub/gnu/;
!   ftp://ftp.sunet.se/pub/gnu/;
!   ftp://sunsite.cnlab-switch.ch/mirror/gnu/;
!   ftp://ftp.ulak.net.tr/gnu/;
!   ftp://ftp.gnu.org.ua;
!   ftp://ftp.mcc.ac.uk/pub/gnu/;
!   ftp://ftp.mirror.ac.uk/sites/ftp.gnu.org/gnu/;
!   ftp://ftp.warwick.ac.uk/pub/gnu/;
!   ftp://ftp.hands.com/ftp.gnu.org/;
!   ftp://gnu.teleglobe.net/ftp.gnu.org/;])
  (GNU Project Home Page . www.gnu.org)
  
  ;; Emacs.
! (Emacs Home Page .
!  www.gnu.org/software/emacs/emacs.html)
! (Savannah Emacs page .
!  savannah.gnu.org/projects/emacs)
! (Emacs Lisp List .
!  www.damtp.cam.ac.uk/user/eglen/emacs/ell.html)
! (Emacs Wiki .
!  [simple-query www.emacswiki.org
!  www.emacswiki.org/cgi-bin/wiki/ ])
  
  ;; Internet search engines.
! (Google .
!  [simple-query www.google.com
!  www.google.com/search?q= ])
! (Google Groups .
!  [simple-query groups.google.com
!  groups.google.com/groups?q= ])
  (Yahoo .
!  [simple-query www.yahoo.com search.yahoo.com/search?p= ])
! (Yahoo: Reference . www.yahoo.com/Reference/)
  
  ;; Misc. general interest.
  (Interactive Weather Information Network . webjump-to-iwin)
  (Usenet FAQs .
!  www.faqs.org/faqs/)
  (RTFM Usenet FAQs by Group .
   ftp://rtfm.mit.edu/pub/usenet-by-group/;)
  (RTFM Usenet FAQs by Hierachy .
   ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/;)
  (X Consortium Archive . ftp.x.org)
  
  ;; Computer social issues, privacy, professionalism.
  (Association for Computing Machinery . www.acm.org)
! (Computer Professionals for Social Responsibility . www.cpsr.org)
  (Electronic Frontier Foundation . www.eff.org)
  (IEEE Computer Society . www.computer.org)
  (Risks Digest . webjump-to-risks)
  
! ;; More.
! (Supplemental Web site list for webjump .
!  www.neilvandyke.org/webjump/)
  
  )
Sample hotlist for WebJump.  See the documentation for the `webjump'

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: query-replace-regexp and read-only text properties

2005-12-28 Thread Juri Linkov
 Have you noticed that read-only matches are highlighted by lazy-highlight
 even though perform-replace skips them?  This is very misleading.
 Do you think this should be fixed?

 It is worth a try.

 A patch I proposed a few months ago could fix this easily by using a new
 predicate variable to allow lazy highlighting to skip read-only matches.

 What did I say about it then?

You said it is a good feature for after the release.

However, now this feature can fix a bug - wrong highlighting of read-only
areas in query-replace-regexp.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: describe-char

2005-12-27 Thread Juri Linkov
   Now I see a new argument `buf' was added to `describe-char' in CVS.
   This doesn't work even for normal uses of the help buffer.  Clicking
   on any link in the help buffer created by `describe-char' and going
   back produces nonsense, because it tries to restore the old contents
   based on the old position in the new contents of the help buffer.

 I made two commits within a couple of hours. Have you picked up the latest
 version of descr-text.el (1.48)?

Yes, I tested the latest version.  Try to use `describe-char' on any
character in the help buffer.

   OTOH, I've tested that saving the whole old contents as a string
   works flawlessly in the help buffer for all links.  Are there reasons

 Yes, it certainly seemed to work when I tested it too.  However, I can see
 Stefan's point that it would be more consistent to make describe-char work
 like the other cases.  If my latest patch is still buggy, then I think we
 should fix that.

It makes no sense to make `describe-char' consistently buggy with
other cases.

Very few other cases are so sensitive to context.  So we could fix
`describe-char' first and fix other cases later if necessary.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: describe-char

2005-12-27 Thread Juri Linkov
 I can see a point to your proposition to save the whole buffer content, tho
 I'd do it generically in help-setup-xref:
 [...]
 and then update all uses of help-xref-stack-item.

I think this would be a good generic solution.

 But I also like the current behavior which recomputed the contents, because
 I use it specifically for this purpose: to update the help based on the
 new state (I typically use this for describe-variable).

 But maybe the two should be separated: provide a refresh command (which
 could be used in revert-buffer-function as well) which uses the
 help-xref-stack-item info, while the help-xref-go-back would reproduce the
 original buffer contents.

One standard key to revert the buffer contents is `g'.  Since the help buffer
is in view mode, it is currently bound in the help buffer to `View-goto-line'.
But we already have a key sequence exactly for this: `M-g M-g'.  So we
could bind `M-g M-g' to `View-goto-line' in view mode, and bind `g' in
help mode to a refresh command.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: describe-char

2005-12-27 Thread Juri Linkov
 OK, I can see it will never work in the help buffer.  I've installed your
 fix (almost):  help-insert-string just sets help-xref-stack-item rather than
 call help-setup-xref.

Thanks.  I just installed more minor fixes.

 If it still doesn't work, then please fix it as you see fit.  Although
 appropriate here, I think this approach is inappropriate in many cases
 e.g `C-h v' could re-create a Help buffer with an out-of-date value which
 could be very confusing and generally not what is wanted.  So I'm not sure
 I agree with Stafan's idea of a general approach.  Currently this seems to
 be a special case.

I think sometimes it is desirable to get old information when going back,
and to refresh it only when requested with a special key like `g'.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: query-replace-regexp and read-only text properties

2005-12-27 Thread Juri Linkov
 I fixed this last night, I think.  Does it work now?

Thanks, it works now.

Have you noticed that read-only matches are highlighted by lazy-highlight
even though perform-replace skips them?  This is very misleading.
Do you think this should be fixed?

A patch I proposed a few months ago could fix this easily by using a new
predicate variable to allow lazy highlighting to skip read-only matches.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


cursor-in-echo-area ignores the default cursor type

2005-12-26 Thread Juri Linkov
After setting the default cursor type to something other than the default
block cursor:

  (setq default-cursor-type 'bar)

and using a function that internally sets the variable `cursor-in-echo-area'
to non-nil, e.g.:

  (y-or-n-p prompt: )

or

  `C-h k'

the specified cursor type is ignored and the minibuffer in all these cases
displays the block cursor.

This is not a critical bug, but it would be nice to fix this if possible.

Also the prompt of key-reading commands (like `C-h k') is not highlighted
using the `minibuffer-prompt' face.  This could be fixed as well.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: describe-char

2005-12-26 Thread Juri Linkov
 This is not reliable way to restore the old output of `describe-char'
 since the original buffer might be killed or the character at the old
 position might be deleted,

 The same holds for most/all other uses of help-setup-xref.

So it makes sense to preserve the original contents of the help buffer
in other uses too.

Now I see a new argument `buf' was added to `describe-char' in CVS.
This doesn't work even for normal uses of the help buffer.  Clicking
on any link in the help buffer created by `describe-char' and going
back produces nonsense, because it tries to restore the old contents
based on the old position in the new contents of the help buffer.

OTOH, I've tested that saving the whole old contents as a string
works flawlessly in the help buffer for all links.  Are there reasons
not to use this solution?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: font-lock-add-keywords in hi-lock.el

2005-12-26 Thread Juri Linkov
 Do you use Hi-Lock (either by putting global-hi-lock-mode in .emacs
 or by using highlight-regexp or other hi-lock functions)?

 Not explicitly. Here are my buffers and their modes. I just fired up
 Gnus with this set and the highlighting was off. Do you know if any of
 the modes listed below might be triggering the bug?

I see nothing to suspect in the buffer list.

Could you look at the value of `font-lock-keywords' in the Gnus buffer
where highlighting is off.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: query-replace-regexp and read-only text properties

2005-12-26 Thread Juri Linkov
  When I try it, it replaces both instances of `foo '.
  Are you using the development Emacs?

 Yes:  emacs-version 22.0.50.2.  A few days old from HEAD.

 Strange.  Can you debug what's happening inside the loop?

It's strange that you can't reproduce it.  Perhaps when you type C-M-% on a
tty, it is interpreted as M-%.  But this bug happens only for regexp replace.

The cause of this bug are lines:

(and (or match-again
 ;; MATCH-AGAIN non-nil means we
 ;; accept an adjacent match.  If
 ;; we don't, move one char to the
 ;; right.  This takes us a
 ;; character too far at the end,
 ;; but this is undone after the
 ;; while-loop.
 (progn
   (forward-char 1)

that don't take into account the case when a read-only area is
adjacent to the next match, and skips it by (forward-char 1).

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: font-lock-add-keywords in hi-lock.el

2005-12-24 Thread Juri Linkov
 I just did another update this morning and now the highlighting goes
 away in Gnus buffers even faster than before (or I just got lucky with
 what I was doing). I managed to reproduce it twice already this morning.
 When this happens, I also notice that the highlighting is also broken in
 *Help* buffers.

 I think it was last week where I didn't observe this behavior at all.
 Hard to say if I got lucky, or whether there was a good change a week
 before that and a bad change this week. But it's what I observed.

 Sorry, this is so sporadic that I haven't been able to generate a recipe
 to reproduce it yet.

Do you use Hi-Lock (either by putting global-hi-lock-mode in .emacs
or by using highlight-regexp or other hi-lock functions)?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Function w32_abort not defined

2005-12-24 Thread Juri Linkov
 What is the purpose of the error message:

   Function w32_abort not defined.

 printed when Emacs is started under GDB on GNU/Linux?

 There's no _purpose_ to it, it's a _consequence_ of GDB trying to set
 a breakpoint on a function that doesn't exist in the GNU/Linux binary.
 Don't you see a similar message for x_error_quitter if you configure
 and build Emacs --without-x?

Usually I don't configure Emacs with --without-x, so I don't see a similar
message.  So a new error message about w32_abort is slightly distracting.
It would be good to somehow suppress this message (by using some GDB option?).

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: describe-char

2005-12-24 Thread Juri Linkov
 It is called before the old contents of the help buffer is replaced with
 the output of `describe-char'.  This is necessary to record the previous
 position of point.  But since at this moment the help buffer doesn't contain
 the new output of `describe-char', we should use nil for the first
 argument `item' of the function `help-setup-xref' here, and should set
 `help-xref-stack-item' explicitly later when the help buffer is ready.

 AFAICT it's the exact same situation as in all other cases, except that you
 use (buffer-string).

All other cases call `help-setup-xref' with the same function name and its
arguments just before calling `(with-output-to-temp-buffer (help-buffer) ...)'
and replacing old contents of the help buffer with the new contents.
But this is not possible when the new contents should be stored in the
help xref stack.

 Instead of using (help-insert-string (buffer-string)) I'd use
 (describe-char pos buf), which admittedly forces you to add a `buf'
 optional argument.

This is not reliable way to restore the old output of `describe-char'
since the original buffer might be killed or the character at the old
position might be deleted, and also this won't work when `describe-char'
was called on a character in the help buffer itself.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: describe-char

2005-12-23 Thread Juri Linkov
)
(print-help-return-message)

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Function w32_abort not defined

2005-12-23 Thread Juri Linkov
What is the purpose of the error message:

  Function w32_abort not defined.

printed when Emacs is started under GDB on GNU/Linux?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: describe-char

2005-12-23 Thread Juri Linkov
 +(setq help-xref-stack-item (list 'help-insert-string (buffer-string)))

 This is wrong.  There are functions like help-setup-xref to do this job.

The function help-setup-xref is already used in describe-char as

(help-setup-xref nil (interactive-p))

It is called before the old contents of the help buffer is replaced with
the output of `describe-char'.  This is necessary to record the previous
position of point.  But since at this moment the help buffer doesn't contain
the new output of `describe-char', we should use nil for the first
argument `item' of the function `help-setup-xref' here, and should set
`help-xref-stack-item' explicitly later when the help buffer is ready.

 Don't access help-xref-stack-item directly unless you really have to, in
 which case you should justify it with a clear comment describing
 the problem.

Unless you propose a better solution, I will add a comment.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: font-lock-add-keywords in hi-lock.el

2005-12-22 Thread Juri Linkov
 Was this patch expected to fix the broken Gnus highlighting me and
 others have reported?

 No, we fixed this one on November 24th.

 This bug (Gnus losing its highlighting) reared its ugly head again a
 couple of times in the past two days for me.

I believe this is now fixed by Stefan's font-lock patch.  With this patch,
when hi-lock is turned off on a non-font-lock buffer, highlighting in all
other non-font-lock buffers don't get broken.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


font-lock-fontify-buffer removes highlighting in non font-lock buffers

2005-12-20 Thread Juri Linkov
font-lock-fontify-buffer is an interactive command and when it is invoked
as a buffer not intended for font-lock fontification, this breaks
highlighting in all other non font-lock buffers.

A simple way to reproduce:

C-h i M-x font-lock-fontify-buffer RET

and after this to see that highlighting is broken in all other buffers:

M-x list-colors-display RET
M-x list-faces-display RET
...

That's because font-lock-default-fontify-buffer doesn't make the variable
font-lock-keywords buffer-local, and its global value gets compiled to
`(t nil)'.

After creating new buffers, font-lock-default-function checks
font-lock-keywords for nil, and since its global value is now
`(t nil)', it calls font-lock-mode-internal which removes all
highlighting from every non font-lock buffer.

This bug was responsible for removing highlighting from Gnus buffers,
and now it is avoided but not calling font-lock-fontify-buffer
from hi-lock mode.  But I think it should be fixed no matter
if it called from hi-lock or not.

I see at least three solutions:

* check font-lock-keywords in font-lock-default-function for the compiled
  empty value `(t nil)' and don't call font-lock-mode-internal for this
  value;

* make the variable font-lock-keywords automatically buffer-local;

* in font-lock-default-fontify-buffer call font-lock-set-defaults
  regardless of the value of font-lock-mode, or depending on some other
  condition, e.g. if (local-variable-p 'font-lock-keywords).

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: font-lock-add-keywords in hi-lock.el

2005-12-16 Thread Juri Linkov
 When discussing what to do in hi-lock, could you please
 include David M. Koppelman, [EMAIL PROTECTED]

Yes, I know.  I already CC'd him on two my messages with patches.
Somehow he was removed from the CC list on replies.  Anyway, due to
CC in my first messages, he follows the proposed changes and confirmed
off-list that he has no objections.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: describe-char

2005-12-15 Thread Juri Linkov
 If you do `C-u C-x =' on a link in Info, you get:

 ...
 There are text properties here:
   font-lock-face   [info-xref]
   help-echomouse-2: go to (efaq)
   mouse-face   [highlight]

 but you can no longer click on info-xref or highlight to examine that face.

That's because overlays of these button don't get copied from the
temporary buffer.  Is there a function that can copy them to another
buffer?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: isearch-query-replace: empty search

2005-12-14 Thread Juri Linkov
 Typing `C-s M-%' or `C-s C-M-%' gives the error:

   isearch-query-replace: Wrong type argument: number-or-marker-p, nil

 Here's a patch:

Thanks.  Installed.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: hi-lock-buffer-mode and hi-lock-mode do not follow normal convention

2005-12-14 Thread Juri Linkov
 I have a local fix that displays Hi in the mode line only when the
 list of regexps to highlight is not empty in the current buffer.
 This means it is displayed only when hi-lock has something to highlight.
 Do you think it would be useful to use this logic by default in
 hi-lock.el?

 As a user, I would love that!  There's no reason for hi-lock-mode to
 not be enabled, as all it does is add a menu entry to the already
 small edit menu.  Only displaying the H when hi-lock mode is doing
 something would be perfect!

Below is a patch that implements this:

Index: lisp/hi-lock.el
===
RCS file: /sources/emacs/emacs/lisp/hi-lock.el,v
retrieving revision 1.35
diff -c -r1.35 hi-lock.el
*** lisp/hi-lock.el 10 Dec 2005 11:47:28 -  1.35
--- lisp/hi-lock.el 14 Dec 2005 17:07:28 -
***
*** 293,299 
   Hi-lock: end
  is found. A mode is excluded if it's in the list `hi-lock-exclude-modes'.
:group 'hi-lock
!   :lighter  H
:global nil
:keymap hi-lock-map
(when (and (equal (buffer-name) *scratch*)
--- 305,314 
   Hi-lock: end
  is found. A mode is excluded if it's in the list `hi-lock-exclude-modes'.
:group 'hi-lock
!   :lighter (:eval (if (or hi-lock-interactive-patterns
! hi-lock-file-patterns)
!  Hi ))
:global nil
:keymap hi-lock-map
(when (and (equal (buffer-name) *scratch*)

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


font-lock-add-keywords in hi-lock.el

2005-12-14 Thread Juri Linkov
hi-lock-mode breaks existing highlighting when its regexps cover
areas highlighted by standard font-lock keywords (non-syntactic).
This is especially undesirable on large highlighted areas like
outline headings etc.

A good solution for this problem is to append new hi-lock keywords
at the end of the current highlighting list instead of adding them
at the beginning.  Thus hi-lock regexps always will be placed over
standard highlighted keywords.

A patch below sets the 3rd arg `HOW' (former `APPEND') of
`font-lock-add-keywords' to t.  (The parameter `OVERRIDE' of the
MATCH-HIGHLIGHT form is already t on every hi-lock keyword, so this
will work correctly.)

Index: lisp/hi-lock.el
===
RCS file: /sources/emacs/emacs/lisp/hi-lock.el,v
retrieving revision 1.35
diff -c -r1.35 hi-lock.el
*** lisp/hi-lock.el 10 Dec 2005 11:47:28 -  1.35
--- lisp/hi-lock.el 14 Dec 2005 17:07:29 -
***
*** 526,532 
Highlight REGEXP with face FACE.
(let ((pattern (list regexp (list 0 (list 'quote face) t
  (unless (member pattern hi-lock-interactive-patterns)
!   (font-lock-add-keywords nil (list pattern))
(push pattern hi-lock-interactive-patterns)
(let ((buffer-undo-list t)
(inhibit-read-only t)
--- 543,549 
Highlight REGEXP with face FACE.
(let ((pattern (list regexp (list 0 (list 'quote face) t
  (unless (member pattern hi-lock-interactive-patterns)
!   (font-lock-add-keywords nil (list pattern) t)
(push pattern hi-lock-interactive-patterns)
(let ((buffer-undo-list t)
(inhibit-read-only t)
***
*** 544,550 
(when (or hi-lock-file-patterns patterns)
  (font-lock-remove-keywords nil hi-lock-file-patterns)
  (setq hi-lock-file-patterns patterns)
! (font-lock-add-keywords nil hi-lock-file-patterns)
  (font-lock-fontify-buffer)))
  
  (defun hi-lock-find-patterns ()
--- 561,567 
(when (or hi-lock-file-patterns patterns)
  (font-lock-remove-keywords nil hi-lock-file-patterns)
  (setq hi-lock-file-patterns patterns)
! (font-lock-add-keywords nil hi-lock-file-patterns t)
  (font-lock-fontify-buffer)))
  
  (defun hi-lock-find-patterns ()
***
*** 573,580 
  (defun hi-lock-font-lock-hook ()
Add hi lock patterns to font-lock's.
(if font-lock-mode
!   (progn (font-lock-add-keywords nil hi-lock-file-patterns)
!(font-lock-add-keywords nil hi-lock-interactive-patterns))
  (hi-lock-mode -1)))
  
  (provide 'hi-lock)
--- 590,598 
  (defun hi-lock-font-lock-hook ()
Add hi lock patterns to font-lock's.
(if font-lock-mode
!   (progn
!   (font-lock-add-keywords nil hi-lock-file-patterns t)
!   (font-lock-add-keywords nil hi-lock-interactive-patterns t))
  (hi-lock-mode -1)))
  
  (provide 'hi-lock)

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Interactive specs

2005-12-11 Thread Juri Linkov
While looking for more places with similar problems in interactive specs
I found that four commands in diff-mode.el have the following spec:

  (interactive (if current-prefix-arg
   (list (mark) (point))
 (list (point-min) (point-max

It doesn't keep its arguments in the command history, but this is ok
according to the current rule that doesn't put the command in the
history if it doesn't read arguments in the minibuffer.

But (mark) and (point) should be replaced with region-beginning/region-end.
I am not sure how exactly to do this.  One variant I propose is:

  (interactive
   (list
(if (or current-prefix-arg (and transient-mark-mode mark-active))
(region-beginning) (point-min))
(if (or current-prefix-arg (and transient-mark-mode mark-active))
(region-end) (point-max

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Interactive specs, align.el

2005-12-11 Thread Juri Linkov
 I think using `region-beginning' and `region-end' is cleaner than
 `(max (point) (mark))', but for `repeat-complex-command' this change
 makes no difference.

 It does make a difference for one of them. Yes, I overlooked the
 `append' in the other one. Yes, it's still an improvement.

I looked only at the first command, but it is true that the second is ok.

As for fixing the first command, I looked at the code that keeps
some command arguments unevaluated in the command history, and see
that the whole function `fix_command' is a hairy hack, so it's better
not to change it radically now.  Rather below is a patch for align.el
that satisfies the current logic of keeping region-beginning/region-end
in the command history.

Index: lisp/align.el
===
RCS file: /cvsroot/emacs/emacs/lisp/align.el,v
retrieving revision 1.20
diff -c -r1.20 align.el
*** lisp/align.el   10 Dec 2005 12:35:04 -  1.20
--- lisp/align.el   11 Dec 2005 10:45:02 -
***
*** 930,950 
  using a REGEXP like \(\. All you would have to do is to mark the
  region, call `align-regexp' and type in that regular expression.
(interactive
!(append
! (list (region-beginning) (region-end))
  (if current-prefix-arg
!   (list (read-string Complex align using regexp: 
!  \\(\\s-*\\))
! (string-to-number
!  (read-string
!   Parenthesis group to modify (justify if negative):  1))
! (string-to-number
!  (read-string Amount of spacing (or column if negative): 
!   (number-to-string align-default-spacing)))
! (y-or-n-p Repeat throughout line? ))
!   (list (concat \\(\\s-*\\)
!   (read-string Align regexp: ))
!   1 align-default-spacing nil
(let ((rule
 (list (list nil (cons 'regexp regexp)
 (cons 'group (abs group))
--- 930,953 
  using a REGEXP like \(\. All you would have to do is to mark the
  region, call `align-regexp' and type in that regular expression.
(interactive
!(list
! (region-beginning)
! (region-end)
  (if current-prefix-arg
!   (read-string Complex align using regexp:  \\(\\s-*\\))
!   (concat \\(\\s-*\\) (read-string Align regexp: )))
! (if current-prefix-arg
!   (string-to-number
!(read-string
! Parenthesis group to modify (justify if negative):  1))
!   1)
! (if current-prefix-arg
!   (string-to-number
!(read-string Amount of spacing (or column if negative): 
! (number-to-string align-default-spacing)))
!   align-default-spacing)
! (if current-prefix-arg
!   (y-or-n-p Repeat throughout line? 
(let ((rule
 (list (list nil (cons 'regexp regexp)
 (cons 'group (abs group))

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Interactive specs

2005-12-11 Thread Juri Linkov
I also looked at other places with similar interactive specs and found
that the whole family of `set-justification...' commands uses the
following spec:

  (interactive (list (if mark-active (region-beginning) (point))
 (if mark-active (region-end) (point

and it doesn't keep region-beginning expression in the history,
because the `if' form is ignored if it contains else-forms.
These commands would look too cumbersome after changing all them
to use `if' without else-forms.

I think a simpler and better change is to relax this restriction in
`fix_command' to allow `if' with else-forms, and keep region-beginning
in the history only if it is presented in then-form.

Index: src/callint.c
===
RCS file: /cvsroot/emacs/emacs/src/callint.c,v
retrieving revision 1.140
diff -c -r1.140 callint.c
*** src/callint.c   7 Aug 2005 12:33:16 -   1.140
--- src/callint.c   11 Dec 2005 10:49:52 -
***
*** 219,227 
{
  Lisp_Object presflag, carelt;
  carelt = Fcar (elt);
! /* If it is (if X Y), look at Y.  */
! if (EQ (carelt, Qif)
!  EQ (Fnthcdr (make_number (3), elt), Qnil))
elt = Fnth (make_number (2), elt);
  /* If it is (when ... Y), look at Y.  */
  else if (EQ (carelt, Qwhen))
--- 219,226 
{
  Lisp_Object presflag, carelt;
  carelt = Fcar (elt);
! /* If it is (if X Y [Z]), look at Y.  */
! if (EQ (carelt, Qif))
elt = Fnth (make_number (2), elt);
  /* If it is (when ... Y), look at Y.  */
  else if (EQ (carelt, Qwhen))

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: cursor custom group: bad labels and help text

2005-12-10 Thread Juri Linkov
 M-x customize-group cursor

 1. Delay in seconds. is a poor tag for `blink-cursor-delay' - it
says nothing about cursor or blink, and gives no indication of
which Lisp option is involved. I thought that the friendly was
supposed to sytematically reflect the Lisp name (that is, be the
same, modulo capitalization). Finally, there should be no period in
the name.

I completely agree.  It is confusing when e.g. the documentation
suggests to customize an option, but really in the Customization group
buffer there is no option with the same name.  A customization tag
rather obscures the option name than makes it more clear.
All documentation strings are displayed in the Customization buffer
just next to every option anyway, so users always can see the
documentation of every customization option no matter what names
they have.

Using :tag makes sense to fix grammar (e.g. without :tag Cursor
In Non-Selected Windows it would be without hyphen Cursor
In Non Selected Windows), or to remove a redundant package prefix
like the Tooltip groups does (it uses e.g. :tag Hide Delay for
tooltip-hide-delay).  In this case the variable name can be easily
deduced from the tag name.

 2. Blink interval in seconds. - similarly to Delay in seconds.

 3. Hourglass pointer - The help doesn't say when (under what
circumstances) the pointer is changed to an hourglass. At least in
Windows, I haven't yet seen the hourglass, after turning this on.

On GNU/Linux the hourglass pointer can be seen, for instance, after
evaluating `(dotimes (i 1000))'.  I don't know about Windows.
If the hourglass pointer is not displayed on Windows, then probably
it is a bug.

I clarified the documentation string of hourglass-related
options, removed customization tags and capitalized the tag
of `cursor-in-non-selected-windows':

Index: lisp/frame.el
===
RCS file: /cvsroot/emacs/emacs/lisp/frame.el,v
retrieving revision 1.231
diff -c -r1.231 frame.el
*** lisp/frame.el   6 Dec 2005 12:43:47 -   1.231
--- lisp/frame.el   10 Dec 2005 10:17:18 -
***
*** 1203,1209 
  (defcustom show-trailing-whitespace nil
*Non-nil means highlight trailing whitespace.
  This is done in the face `trailing-whitespace'.
-   :tag Highlight trailing whitespace.
:type 'boolean
:group 'whitespace-faces)
  
--- 1214,1219 
***
*** 1235,1247 
  
  (defcustom blink-cursor-delay 0.5
*Seconds of idle time after which cursor starts to blink.
-   :tag Delay in seconds.
:type 'number
:group 'cursor)
  
  (defcustom blink-cursor-interval 0.5
*Length of cursor blink interval in seconds.
-   :tag Blink interval in seconds.
:type 'number
:group 'cursor)
  
--- 1245,1255 
***
*** 1317,1330 
  ;; Hourglass pointer
  
  (defcustom display-hourglass t
!   *Non-nil means show an hourglass pointer when running under a window 
system.
!   :tag Hourglass pointer
:type 'boolean
:group 'cursor)
  
  (defcustom hourglass-delay 1
!   *Seconds to wait before displaying an hourglass pointer.
!   :tag Hourglass delay
:type 'number
:group 'cursor)
  
--- 1325,1336 
  ;; Hourglass pointer
  
  (defcustom display-hourglass t
!   *Non-nil to show an hourglass pointer when Emacs is busy on a window 
system.
:type 'boolean
:group 'cursor)
  
  (defcustom hourglass-delay 1
!   *Seconds to wait before displaying an hourglass pointer when Emacs is 
busy.
:type 'number
:group 'cursor)
  
***
*** 1333,1339 
*Non-nil means show a hollow box cursor in non-selected windows.
  If nil, don't show a cursor except in the selected window.
  Use Custom to set this variable to get the display updated.
!   :tag Cursor in non-selected windows
:type 'boolean
:group 'cursor
:set #'(lambda (symbol value)
--- 1339,1345 
*Non-nil means show a hollow box cursor in non-selected windows.
  If nil, don't show a cursor except in the selected window.
  Use Custom to set this variable to get the display updated.
!   :tag Cursor In Non-Selected Windows
:type 'boolean
:group 'cursor
:set #'(lambda (symbol value)

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


tooltip custom group: duplicate labels

2005-12-10 Thread Juri Linkov
M-x customize-group RET tooltip RET
C-s Use echo area C-s C-s

The tag Use echo area is used twice in the same customization buffer.

Its first occurrence comes from emacs/lisp/tooltip.el:

(defcustom tooltip-use-echo-area nil
  Use the echo area instead of tooltip frames for help and GUD tooltips.
  :type 'boolean
  :tag Use Echo Area
  :group 'tooltip)

and the second occurrence comes from emacs/lisp/progmodes/gud.el:

(defcustom gud-tooltip-echo-area nil
  Use the echo area instead of frames for GUD tooltips.
  :type 'boolean
  :tag Use echo area
  :group 'tooltip)

I propose to remove :tag from all GUD tooltip options to reveal their
true identities to the users of Customize.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: tooltip custom group: duplicate labels

2005-12-10 Thread Juri Linkov
   The tag Use echo area is used twice in the same customization buffer.
  
   Its first occurrence comes from emacs/lisp/tooltip.el:
...
   and the second occurrence comes from emacs/lisp/progmodes/gud.el:
...
   I propose to remove :tag from all GUD tooltip options to reveal their
   true identities to the users of Customize.

 I don't see the need to remove them both, so I've just removed the tag for
 gud-tooltip-echo-area.  I've also added the gud groupname for the customize
 variables for GUD tooltips

Now after adding the group name `gud' to the GUD tooltips customize
variables, the group `gud' contains the following misleading labels:

GUD modes: Show Value

GUD buffers predicate: Show Value

Among other GUD-related options they don't indicate that really they
are used for tooltips.

I suggest removing their tags to show unambiguous labels that have the
word tooltip.

 and moved tooltip-mode and gud-tooltip-mode forward so that they
 appear first in their part of the customize buffers.  I think the
 first question to ask is Do you want the mode on or off.

I think you are right.  The first option in a customization group
should turn the whole mode on/off.  But the same problem exists in
many other mode customization groups.  Moving `define-minor-mode' to be
before all `defcustom' definitions in these modes would be a lot of work.

Perhaps there should be some generic solution, e.g. using a heuristic
to place an option with the substring -mode before other options in
the customization buffer or something like this.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Interactive specs, align.el

2005-12-09 Thread Juri Linkov
 This change makes repetition of these commands (with
 `repeat-complex-command') recompute the bounds of the region rather
 than use the old values of point and mark.

I think using `region-beginning' and `region-end' is cleaner than
`(max (point) (mark))', but for `repeat-complex-command' this change
makes no difference.  Neither region-beginning/region-end, nor min/max
expression with mark/point is recorded unevaluated in command-history.
Perhaps `call-interactively' should be fixed to support `append' to
quote region-beginning/region-end inside it, or align.el should be changed
to use `list' on its interactive specification.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: SPC no longer completes when minibuffer-completing-file-name is t

2005-12-09 Thread Juri Linkov
 Emacs now inserts a space when trying to complete an MH-E folder (for
 example, when visiting a folder or refiling a message).

 Could this change be responsible?

   2005-12-06  Stefan Monnier  [EMAIL PROTECTED]

 * minibuf.c (keys_of_minibuf): Just unbind SPC in
 Vminibuffer_local_filename_completion_map rather than forcing it
 explicitly to the same binding as the global map.

BTW, shouldn't exactly the same change be made also for
`Vminibuffer_local_must_match_filename_map'?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: completion in find-file

2005-12-09 Thread Juri Linkov
 I thought that the node (info (elisp)Reading File Names)
 is more suitable place to document filename completion maps
 than (info (elisp)Completion Commands).

 Yes, that does seem better.  Would you please move those @defvars?

I now think your original change was better because the node
Completion Commands is the place for all completion-related
variables.  What is missing is a xref from Reading File Names to
Completion Commands pointing to filename completion maps active when
reading filenames.  The patch below adds references that are similar how
normal keymaps are referenced from the documentation of completing-read.

Index: lispref/minibuf.texi
===
RCS file: /cvsroot/emacs/emacs/lispref/minibuf.texi,v
retrieving revision 1.69
diff -c -r1.69 minibuf.texi
*** lispref/minibuf.texi9 Dec 2005 04:38:40 -   1.69
--- lispref/minibuf.texi10 Dec 2005 01:04:36 -
***
*** 1023,1034 
  
  @defvar minibuffer-local-filename-completion-map
  This is like @code{minibuffer-local-completion-map}
! except that it does not bind @key{SPC}.
  @end defvar
  
  @defvar minibuffer-local-must-match-filename-map
  This is like @code{minibuffer-local-must-match-map}
! except that it does not bind @key{SPC}.
  @end defvar
  
  @node High-Level Completion
--- 1023,1036 
  
  @defvar minibuffer-local-filename-completion-map
  This is like @code{minibuffer-local-completion-map}
! except that it does not bind @key{SPC}.  This keymap is used by the
! function @code{read-file-name}.
  @end defvar
  
  @defvar minibuffer-local-must-match-filename-map
  This is like @code{minibuffer-local-must-match-map}
! except that it does not bind @key{SPC}.  This keymap is used by the
! function @code{read-file-name}.
  @end defvar
  
  @node High-Level Completion
***
*** 1212,1217 
--- 1214,1225 
  @var{existing} is @code{nil}, then the name of a nonexistent file is
  acceptable.
  
+ The function @code{read-file-name} uses
+ @code{minibuffer-local-filename-completion-map} as the keymap if
+ @var{existing} is @code{nil}, and uses
+ @code{minibuffer-local-must-match-filename-map} if @var{existing} is
+ [EMAIL PROTECTED]  @xref{Completion Commands}.
+ 
  The argument @var{directory} specifies the directory to use for
  completion of relative file names.  It should be an absolute directory
  name.  If @code{insert-default-directory} is [EMAIL PROTECTED],

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Menu item for delete-selection-mode (was: DEL key doesn't kill mouse-dragged region)

2005-12-09 Thread Juri Linkov
 Why not just turn on delete-selection-mode and transient-mark-mode, by
 default?

transient-mark-mode is currently disabled by default, and has a menu
item to easily enable it.  delete-selection-mode is disabled too, but
has no menu item to enable it.  What about adding it to the Option
menu?  delete-selection-mode is no less useful than transient-mark-mode,
especially for beginners.

The menu item for transient-mark-mode is named Active Region Highlighting.
What would be a good menu name for delete-selection-mode?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: hi-lock-buffer-mode and hi-lock-mode do not follow normal convention

2005-12-05 Thread Juri Linkov
 It seems that much of Emacs follows a convention for naming global
 minor modes vs buffer local minor modes that hi-lock-mode does not
 follow. The convention is for buffer local minor modes to be named
 minor-mode-name and for global minor modes to be named
 global-minor-mode-name.

 I realize that previously hi-lock-mode was the global mode, and you
 want to keep backward compatibility, but it is confusing to have
 multiple conventions for the same thing.

It is bad that now hi-lock does not follow a convention for naming
minor modes.  This makes it harder to understand how to use hi-lock mode.

 Please change the function named hi-lock-mode to global-hi-lock-mode,
 hi-lock-buffer-mode to hi-lock-mode.

I'm not sure how the users having (hi-lock-mode 1) in .emacs will
react to this change.

 This bit me because I don't like having the H for hi-lock-mode
 displayed in the mode line, so I added

 (setf (second (assoc 'hi-lock-mode minor-mode-alist)) nil)

 to my init file.  This just broke.

I don't like having the H displayed in the mode line for no reason too.
I have a local fix that displays Hi in the mode line only when the
list of regexps to highlight is not empty in the current buffer.
This means it is displayed only when hi-lock has something to highlight.

Do you think it would be useful to use this logic by default in hi-lock.el?

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Strange behaviour of the undo function

2005-12-05 Thread Juri Linkov
 The following seems to be a bug:

 Suppose the frame is splitted in say subwindow A and subwindow
 B. Select some text in A, yank it with mouse-2 somewhere in B, and
 then choose undo from the toolbar. The undo is done, but the point in
 B jumps to the position where the selection was made.

 Emacs-implementation used: Aquamacs Emacs for OSX, but with the -Q
 option so that all Aquamacs specific customizations don't apply.

While looking at this bug report, I found another bug.  The menu and
toolbar item undo doesn't become disabled when the pending undo
list is empty.  The following patch fixes this:

Index: lisp/menu-bar.el
===
RCS file: /cvsroot/emacs/emacs/lisp/menu-bar.el,v
retrieving revision 1.282
diff -c -r1.282 menu-bar.el
*** lisp/menu-bar.el19 Nov 2005 11:23:04 -  1.282
--- lisp/menu-bar.el6 Dec 2005 03:36:08 -
***
*** 481,487 
  :enable (and (not buffer-read-only)
   (not (eq t buffer-undo-list))
   (if (eq last-command 'undo)
!  pending-undo-list
 (consp buffer-undo-list)))
  :help Undo last operation))
  
--- 481,487 
  :enable (and (not buffer-read-only)
   (not (eq t buffer-undo-list))
   (if (eq last-command 'undo)
!  (listp pending-undo-list)
 (consp buffer-undo-list)))
  :help Undo last operation))

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: Strange behaviour of the undo function

2005-12-05 Thread Juri Linkov
 The following seems to be a bug:

 Suppose the frame is splitted in say subwindow A and subwindow
 B. Select some text in A, yank it with mouse-2 somewhere in B, and
 then choose undo from the toolbar. The undo is done, but the point in
 B jumps to the position where the selection was made.

 Emacs-implementation used: Aquamacs Emacs for OSX, but with the -Q
 option so that all Aquamacs specific customizations don't apply.

I tried to reproduce this, but failed.  Maybe it is OS-specific,
since I use GNU/Linux.  Or maybe there is a misunderstanding.
When I undo in B, then point jumps to the position of undone text.
Since the selection was made in A, the point doesn't jump to the
position where the selection was made in A.  Everything looks correct
to me.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: log-view-diff

2005-12-04 Thread Juri Linkov
 get the diff between the revision at point and the next revision

 Wouldn't it be more natural to compare with the previous revision?
 That would show you the changes installed _in_ the revision
 that you're pointing at.

Actually it already compares with the previous revision.  I used the
phrase the next revision because the previous revision is accessed
by using the `n' key (`log-view-msg-next') which is the next to the
revision at point in the log buffer.  I realize that the correct term
is not the next revision, but the previous revision.  Below is
a new docstring:

Index: lisp/log-view.el
===
RCS file: /cvsroot/emacs/emacs/lisp/log-view.el,v
retrieving revision 1.24
diff -c -r1.24 log-view.el
*** lisp/log-view.el2 Dec 2005 07:59:56 -   1.24
--- lisp/log-view.el4 Dec 2005 21:44:45 -
***
*** 195,204 
  ;;
  
  (defun log-view-diff (beg end)
!   Get the diff for several revisions.
! If the point is the same as the mark or the mark is not active,
! get the diff for this revision.  Otherwise, get the diff between
! the revisions where the region starts and ends.
(interactive
 (list (if mark-active (region-beginning) (point))
   (if mark-active (region-end) (point
--- 195,205 
  ;;
  
  (defun log-view-diff (beg end)
!   Get the diff between two revisions.
! If the mark is not active or the mark is on the revision at point,
! get the diff between the revision at point and its previous revision.
! Otherwise, get the diff between the revisions where the region starts
! and ends.
(interactive
 (list (if mark-active (region-beginning) (point))
   (if mark-active (region-end) (point

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: log-view-diff

2005-12-02 Thread Juri Linkov
Why require mark to be active to diff between two specified revisions?
   
   Because it's very convenient to be able to do a diff between rev N and
   current (rather between rev N1 and N2) without having to set the
   mark locally.

 OK, I see now.  I've installed Juri's doc string patch.

You missed one change in my patch which replaces

get the diff for this revision

with

get the diff between the revision at point and the next revision

I think this clarification is essential.  The phrase this revision
is not clear.  Maybe it should be even more clarified to say that
it works only when there exist the mark in non-transient-mark-mode
or if the region is active in transient-mark-mode.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: log-view-diff

2005-12-01 Thread Juri Linkov
I just noticed there was a typo in the original docstring.  Should be
not were the region starts and ends, but where the region starts and ends.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: log-view-diff

2005-12-01 Thread Juri Linkov
 The doc for log-view-diff says:

   Get the diff for several revisions.
 If the point is the same as the mark, get the diff for this revision.
 Otherwise, get the diff between the revisions
 were the region starts and ends.

 but the implementation requires that mark is active:

   (interactive
(list (if mark-active (region-beginning) (point))
  (if mark-active (region-end) (point

What about the following docstring?  It should correctly document what
this function does.

Index: lisp/log-view.el
===
RCS file: /cvsroot/emacs/emacs/lisp/log-view.el,v
retrieving revision 1.23
diff -c -r1.23 log-view.el
*** lisp/log-view.el31 Aug 2005 13:50:48 -  1.23
--- lisp/log-view.el2 Dec 2005 00:33:33 -
***
*** 196,204 
  
  (defun log-view-diff (beg end)
Get the diff for several revisions.
! If the point is the same as the mark, get the diff for this revision.
! Otherwise, get the diff between the revisions
! were the region starts and ends.
(interactive
 (list (if mark-active (region-beginning) (point))
   (if mark-active (region-end) (point
--- 196,204 
  
  (defun log-view-diff (beg end)
Get the diff for several revisions.
! If point is the same as the mark or the mark is not active, get the
! diff between the revision at point and the next revision.  Otherwise,
! get the diff between the revisions were the region starts and ends.
(interactive
 (list (if mark-active (region-beginning) (point))
   (if mark-active (region-end) (point

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


  1   2   >