headers
Stefan Monnier | 1 Aug 2010 02:04
Picon

bug#6616: S-TAB is mismapped in the *Help* buffer

> and binding [S-tab] to [backtab] in the `ns-alternatives-map' instead?

Actually, we might want to do that everywhere, rather than only in
x-win.el and ns-win.el.

        Stefan
Permalink | Reply | 9 comments |
headers
Stefan Monnier | 1 Aug 2010 02:28
Picon

bug#6747: Documentation: `syntax-ppss-toplevel-pos' xref typo `partial-parse-sexp' <- `parse-partial-sexp'

>>>>> "MON" == MON KEY <monkey <at> sandpframing.com> writes:

> The function `syntax-ppss-toplevel-pos' in emacs-lisp/syntax.el appears to
> have a type:

> ,---- (documentation 'syntax-ppss-toplevel-pos)
> |
> | Get the latest syntactically outermost position found in a syntactic scan.
> | PPSS is a scan state, as returned by `partial-parse-sexp' or `syntax-ppss'.
> | An "outermost position" means one that it is outside of any syntactic entity:
> | outside of any parentheses, comments, or strings encountered in the scan.
> | If no such position is recorded in PPSS (because the end of the scan was
> | itself at the outermost level), return nil.
> |
> `----

> Is the second line in error? e.g.

> "PPSS is a scan state, as returned by `partial-parse-sexp' or `syntax-ppss'."
>                                        ^^^^^^^^^^^^^^^^^^

> Shouldn't that be `parse-partial-sexp'?

> Appears with docstring current through bzr-100920

Thanks, fixed in the emacs-23 branch,

        Stefan
(Continue reading)

Permalink | Reply | 0 comments |
headers
YAMAMOTO Mitsuharu | 1 Aug 2010 08:28
Picon

bug#6765: 24.0.50; Tooltip over mode-line has strange content.

>>>>> On Fri, 30 Jul 2010 17:26:36 +0200, Jan Djärv <jan.h.d <at> swipnet.se> said:

> % emacs -q
> Move mouse to (Fundamental) in the mode-line.  A tooltip pops up:

> "mouse-1ode
> mouse-1: Display major mode menu
> mouse-2: Show help for major mode
> mouse-3: Toggle minor modes'
> "

> The first line is strange, should be "Major mode".

mouse-fixup-help-message in mouse.el seems to have clobbered it.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

=== modified file 'lisp/mouse.el'
*** lisp/mouse.el	2010-01-13 08:35:10 +0000
--- lisp/mouse.el	2010-08-01 06:11:31 +0000
***************
*** 887,893 ****
      (if (and mouse-1-click-follows-link
  	     (stringp msg)
  	     (save-match-data
! 	       (string-match "^mouse-2" msg))
  	     (setq mp (mouse-pixel-position))
  	     (consp (setq pos (cdr mp)))
  	     (car pos) (>= (car pos) 0)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Drew Adams | 1 Aug 2010 16:24
Picon
Favicon

bug#6616: S-TAB is mismapped in the *Help* buffer

> > and binding [S-tab] to [backtab] in the 
> `ns-alternatives-map' instead?
> 
> Actually, we might want to do that everywhere, rather than only in
> x-win.el and ns-win.el.

I disagree.  S-TAB has always been a free global key, and it has remained free
in most keymaps.

In Emacs there are several different behaviors that here and there are
associated with TAB.  The use of TAB for navigation in the sense of being
opposite to [backtab] (e.g. navigation in Info or *Help*) is only one of them,
and it is a fairly minor one (for Emacs).  We only recently added it to Info.
Arguably it can be said to make sense for other, similar read-only modes such as
*Help*.  Beyond that it does not necessarily make sense.

Please do not bind S-TAB in a general way to [backtab] or anything else.  Modes
that really need that can do so.  That leaves other code (e.g. other modes, user
code, 3rd-party code) free to use S-TAB for other uses, especially uses that are
related to a particular use of TAB.  TAB for navigation is only one use of TAB.

We already have potential and some real conflicts between different meanings of
TAB.  A mode needs to choose which meaning it prefers when there is a potential
conflict.  Some modes try to combine such behaviors into a DWIM behavior.  This
is enough - let's not make this more problematic by throwing S-TAB into the mix
in a predefined way.  Let the code in question decide.

Bind S-TAB to `backtab' for *Help* if you want - that's helpful.  Likewise
perhaps some view-mode contexts (maybe all of them; dunno).  But otherwise
please leave it alone.  Thx.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Steve Purcell | 1 Aug 2010 18:19
Gravatar

bug#6771: 24.0.50; Child process input isn't closed by process-send-eof; hangs indefinitely

I've been investigating an issue with magit in Emacs HEAD which isn't
present in Emacs 23.x. Specifically, the git subprocesses it starts in
order to pipe data to them do not exit as expected when magit calls
process-send-eof.

Further investigation shows that this misbehavior can be demonstrated by
executing the following simple code in *scratch*:

(let ((p (start-process "cat" (current-buffer) "cat")))
  (process-send-eof p)
  (sit-for 1)
  (process-status p))

In Emacs 23, the result is 'exit, and "Process cat finished" is written
into the buffer.

In Emacs HEAD, however, the result is 'run, and "^D" is written into the
buffer - obviously the process' input is not really being closed.

This incorrect behavior happens regardless of the value of
process-connection-type.

More discussion of this issue in the context of magit is to be found
here: http://github.com/philjackson/magit/issues/#issue/18

In GNU Emacs 24.0.50.1 (x86_64-apple-darwin10.4.0, NS apple-appkit-1038.32)
of 2010-08-01 on mandala.home
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--with-ns' '--without-dbus' 'CFLAGS=''
(Continue reading)

Permalink | Reply | 6 comments |
headers
David Maus | 1 Aug 2010 10:12
Picon

bug#6772: 23.2; Gnus' `nnimap-retrieve-headers-from-file' fails to load novcache

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

While trying to mitigate the problem with IMAP server implementations
that perform a painful slow UID SEARCH for a message-id I noted that
`nnimap-retrieve-headers-from-file' fails to load the novcache because
it inserts the content of the cache file in `nntp-seerver-buffer' that
is not empty.

I use this simple setup to access a local IMAP server:

,----[ gnus.el ]
| ;;; Experimental Gnus setup
| 
| (setq gnus-select-method '(nntp "news.gmane.org"))
| (setq gnus-secondary-select-methods
|       '((nnimap "localhost"
| 		(nnimap-address "localhost")
| 		(nnimap-server-port 993)
| 		(nnimap-stream ssl))))
|
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jan Djärv | 1 Aug 2010 10:53
Picon

bug#6765: 24.0.50; Tooltip over mode-line has strange content.

That fixes it.  Strange that it doesn't fail everytime, but only the first time.

	Jan D.

YAMAMOTO Mitsuharu skrev 2010-08-01 08.28:
>>>>>> On Fri, 30 Jul 2010 17:26:36 +0200, Jan Djärv<jan.h.d <at> swipnet.se>  said:
>
>> % emacs -q
>> Move mouse to (Fundamental) in the mode-line.  A tooltip pops up:
>
>> "mouse-1ode
>> mouse-1: Display major mode menu
>> mouse-2: Show help for major mode
>> mouse-3: Toggle minor modes'
>> "
>
>> The first line is strange, should be "Major mode".
>
> mouse-fixup-help-message in mouse.el seems to have clobbered it.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu <at> math.s.chiba-u.ac.jp
>
> === modified file 'lisp/mouse.el'
> *** lisp/mouse.el	2010-01-13 08:35:10 +0000
> --- lisp/mouse.el	2010-08-01 06:11:31 +0000
> ***************
> *** 887,893 ****
>        (if (and mouse-1-click-follows-link
>    	     (stringp msg)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juanma Barranquero | 1 Aug 2010 18:52
Picon
Gravatar

bug#6765: 24.0.50; Tooltip over mode-line has strange content.

On Sun, Aug 1, 2010 at 08:28, YAMAMOTO Mitsuharu
<mituharu <at> math.s.chiba-u.ac.jp> wrote:

> !              (string-match "\\`mouse-2" msg))

I've committed your fix with a slight change (and a ChangeLog entry).

Thanks,

    Juanma
Permalink | Reply | 0 comments |
headers
Paul Griepentrog | 1 Aug 2010 19:38
Picon

bug#6616: S-TAB is mismapped in the *Help* buffer

  On 7/31/10 5:04 PM, Stefan Monnier wrote:
> > and binding [S-tab] to [backtab] in the `ns-alternatives-map' instead?
>
>  Actually, we might want to do that everywhere, rather than only in
>  x-win.el and ns-win.el.

Thinking more about the problem, I think the confusion comes from
a perfect storm of evolution:

   - The [backtab] key does not exist on modern keyboards, but
     several modes define keybindings only for [backtab].  (See
     erc, grep, compile, ses, diff-mode and log-view.)

   - But, X and Windows translate [S-tab] into [backtab], so you
     don't even notice this unless you're working on a platform/
     terminal without this mapping, for example: Mac OS X.

   - Add to that: people treat [backtab] as logically the same as
     [S-tab], even though they are different key presses when you
     have a [backtab] key.

As a developer, I would be confused.  I need to map both for my
mode to be consistent across terminals/platforms.  Several modes
do this exactly.  (See forms, info, widget, org, and mh.)

I say, pick a solution and make it consistent across the modes
shipped with Emacs.  IMHO, [S-tab] is the 'correct' binding,
since we press those actual keys.  Update all the modes using
[backtab] to use [S-tab].  Now, anybody who has a [backtab] key
can actually use it, and the rest continue with [S-tab], like
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Engster | 1 Aug 2010 19:54
Picon

bug#6772: 23.2; Gnus' `nnimap-retrieve-headers-from-file' fails to load novcache

David Maus writes:
> While trying to mitigate the problem with IMAP server implementations
> that perform a painful slow UID SEARCH for a message-id I noted that
> `nnimap-retrieve-headers-from-file' fails to load the novcache because
> it inserts the content of the cache file in `nntp-seerver-buffer' that
> is not empty.

I don't see this as a bug. `nnimap-retrieve-headers-from-file' is an
internal nnimap function, and it just happens to depend on the caller
taking care of erasing (and maybe also restoring) the
nntp-server-buffer. If you don't want this, you could just duplicate the
three lines from the function to load the NOV file in any other (empty)
buffer of your choice.

-David
Permalink | Reply | 1 comment |

Gmane