cannot disable paren matching

cannot disable paren matching

[Don Woods]

I am having a problem where paren matching is not working as desired,
and I am unable either to turn it off or to make it work correctly.

The specific case where I'm having trouble is in PostScript mode,
when also in Overwrite mode.  When I type a character that acts as a
close paren -- such as > or } -- the character is inserted instead of
overwriting the current char.  Emacs briefly highlights the matching
open paren, or reports a mismatch, as the case may be, but does NOT
remove the char I was intending to overwrite.

Since I don't especially need the paren highlighting in my current
editing, most of my attempts to work around this bug have involved
trying to disable the paren-matching behavior.  I have tried such
things as

(show-paren-mode 0)     ;; no noticeable change

(show-paren-mode nil)   ;; no longer shows matching open
			;; but still does not overwrite

(modify-syntax-entry ?> "w" ps-mode-syntax-table)
			;; > now highlights the char AFTER the matching <
			;; but still does not overwrite
(modify-syntax-entry ?< "w" ps-mode-syntax-table)
			;; when combined with previous, > goes back to
			;; showing matching <, but still does not overwrite

I know I've tinkered with other paren-related vars without success,
but no longer recall everything I tried.

My only successful workaround so far is to scrap postscript-mode and
use fundamental-mode.  I'm using overwrite-mode while editing a portion
of the PostScript file that is a block of "ascii art" data, so don't
really need postscript-mode there, but it's awkward when switching
between the data and code portions of the file.

Note: emacs-version is:
"GNU Emacs 22.1.1 (mac-apple-darwin)
 of 2016-04-22 on osx143.apple.com"

Suggestions appreciated!

	-- Don Woods

Re: cannot disable paren matching

[Skip Montanaro]

Have you tried (show-paren-mode -1)? The function help (24.3 here, not
22.x) says, "enable Show Paren mode if ARG is positive, and disable it
otherwise." Not sure whether ELisp considers 0 a positive number or
not, or how it might classify nil, but maybe give that a try...

Skip

Re: cannot disable paren matching

[John Mastro]

Don Woods <don@icynic.com> wrote:
> I am having a problem where paren matching is not working as desired,
> and I am unable either to turn it off or to make it work correctly.
>
> The specific case where I'm having trouble is in PostScript mode,
> when also in Overwrite mode.  When I type a character that acts as a
> close paren -- such as > or } -- the character is inserted instead of
> overwriting the current char.  Emacs briefly highlights the matching
> open paren, or reports a mismatch, as the case may be, but does NOT
> remove the char I was intending to overwrite.
>
> Since I don't especially need the paren highlighting in my current
> editing, most of my attempts to work around this bug have involved
> trying to disable the paren-matching behavior.  I have tried such
> things as
>
> (show-paren-mode 0)     ;; no noticeable change
>
> (show-paren-mode nil)   ;; no longer shows matching open
>                         ;; but still does not overwrite
>
> (modify-syntax-entry ?> "w" ps-mode-syntax-table)
>                         ;; > now highlights the char AFTER the matching <
>                         ;; but still does not overwrite
> (modify-syntax-entry ?< "w" ps-mode-syntax-table)
>                         ;; when combined with previous, > goes back to
>                         ;; showing matching <, but still does not overwrite
>
> I know I've tinkered with other paren-related vars without success,
> but no longer recall everything I tried.
>
> My only successful workaround so far is to scrap postscript-mode and
> use fundamental-mode.  I'm using overwrite-mode while editing a portion
> of the PostScript file that is a block of "ascii art" data, so don't
> really need postscript-mode there, but it's awkward when switching
> between the data and code portions of the file.
>
> Note: emacs-version is:
> "GNU Emacs 22.1.1 (mac-apple-darwin)
>  of 2016-04-22 on osx143.apple.com"

I'm not totally sure I understand the scenario, but I tried to reproduce
this in Emacs 25 using the steps below and everything seemed to work as
intended. Specifically, at the end of the steps, the buffer contained
"a{b}c{d}".

Here are the steps I tried:
  emacs -Q
  C-x b ps RET
  M-x ps-mode RET
  M-x show-paren-mode RET
  M-x overwrite-mode RET
  foo{bar}
  C-a
  a{b}c{d}

If my recipe above would indeed trigger the problem you're describing,
perhaps using a newer version of Emacs would do the trick - Emacs 22 is
quite old (circa 2006 I believe).

If the recipe above does not capture the problem, can you provide
similar steps from "emacs -Q" that we can experiment with?

        John

Re: cannot disable paren matching

[Stefan Monnier]

> Note: emacs-version is:
> "GNU Emacs 22.1.1 (mac-apple-darwin)
>  of 2016-04-22 on osx143.apple.com"

IOW, this is Apple's brain-dead version which is only about 15 years old.
Please stay away from it, use the real thing instead.


        Stefan

Re: cannot disable paren matching

[John Mastro]

John Mastro <john.b.mastro@gmail.com> wrote:
> I'm not totally sure I understand the scenario, but I tried to reproduce
> this in Emacs 25 using the steps below and everything seemed to work as
> intended. Specifically, at the end of the steps, the buffer contained
> "a{b}c{d}".

By the way, I believe disabling show-paren-mode should be as simple as
typing `M-x show-paren-mode RET', or (show-paren-mode -1), though to be
honest Emacs 22 is from before I started using Emacs.

        John

Re: cannot disable paren matching

[Don Woods]

Thanks John and Skip for the answers so far.  I tried (show-paren-mode -1)
and it seems to be the same as (show-paren-mode 0) in that it yields nil,
whereas (show-paren-mode 1) yields t.  I've also tried M-x show-paren-mode,
which toggles the state.  Interestingly, even in fundamental-mode, turning
show-paren-mode off does NOT stop emacs from briefly moving to the matching
open when I type a close, whether or not I'm in overwrite-mode.

As to John's scenario starting with emacs -Q, I tried it on my emacs and
ended with "a{b}c{d}r}" in the buffer, i.e. with two extra chars at the end
due to the two occurrences of buggy behavior on close.  I have emacs 24.2.1
on another system (unix not Mac, not that that should matter) and it shows
the same bug.  I guess I'll have to see if I can get 25 installed on either
or both of those systems.

Perhaps someone who has Emacs 24 installed can try John's scenario and shed
further light?

	-- Don.

Re: cannot disable paren matching

[Konstantin Shakhnov]

On Tue, Dec 27, 2016 at 01:29:47PM -0700, Don Woods wrote:
> I am having a problem where paren matching is not working as desired,
> and I am unable either to turn it off or to make it work correctly.
>
> The specific case where I'm having trouble is in PostScript mode,
> when also in Overwrite mode.  When I type a character that acts as a
> close paren -- such as > or } -- the character is inserted instead of
> overwriting the current char.  Emacs briefly highlights the matching
> open paren, or reports a mismatch, as the case may be, but does NOT
> remove the char I was intending to overwrite.
>
> Since I don't especially need the paren highlighting in my current
> editing, most of my attempts to work around this bug have involved
> trying to disable the paren-matching behavior.  I have tried such
> things as
>

Similar at GNU Emacs 24.5.1.

Are you sure that the culprit is the (show-paren-mode) ?

M-x describe-mode ps-mode said

...
>		ps-mode-r-gt
]		ps-mode-r-angle
}		ps-mode-r-brace
...

(defun ps-mode-r-brace ()
  "Insert `}' and perform balance."
  (interactive)
  (insert "}")
  (ps-mode-r-balance "}"))

So it seems like you need overwrite or disable or make something other
with ps-mode-r-brace. For instance (add to .emacs):

(defun my-ps-mode-r-brace ()
  (interactive)
  (self-insert-command 1))

(add-hook 'ps-mode-hook
	  (lambda () (local-set-key (kbd "}") 'my-ps-mode-r-brace)))

Re: cannot disable paren matching

[John Mastro]

Konstantin Shakhnov <kastian@mail.ru> wrote:
> Similar at GNU Emacs 24.5.1.
>
> Are you sure that the culprit is the (show-paren-mode) ?
>
> M-x describe-mode ps-mode said
>
> ...
>>               ps-mode-r-gt
> ]               ps-mode-r-angle
> }               ps-mode-r-brace

In Emacs 25 these are all bound to `self-insert-command', so I suspect
that's the issue (and not show-paren-mode).

        John

Re: cannot disable paren matching

[Stefan Monnier]

> In Emacs 25 these are all bound to `self-insert-command', so I suspect
> that's the issue (and not show-paren-mode).

Indeed.  The issue is that the ps-mode-r-* commands just used `insert`
which does just what it says.  If they had used self-insert-command
internally (which is the function which pays attention to overwrite
mode), then it could have worked right.

These issues were part of the motivation to add post-self-insert-hook,
so that those commands can be replaced by `self-insert-command` without
any need to rebind the keys.


        Stefan

Re: cannot disable paren matching

[martin rudalics]

 > Interestingly, even in fundamental-mode, turning
 > show-paren-mode off does NOT stop emacs from briefly moving to the matching
 > open when I type a close, whether or not I'm in overwrite-mode.

 From what you write here the thing that seems to annoy you is
‘blink-matching-paren’.  Try setting it to nil.

martin

Re: cannot disable paren matching

[Don Woods]

> > Are you sure that the culprit is the (show-paren-mode) ?
> >
> > M-x describe-mode ps-mode said
> >
> > ...
> >>               ps-mode-r-gt
> > ]               ps-mode-r-angle
> > }               ps-mode-r-brace
>
> In Emacs 25 these are all bound to `self-insert-command', so I suspect
> that's the issue (and not show-paren-mode).
>
>         John

We have a winner!!  Indeed, in Emacs 22 and 24 those functions all
use (insert ">") and such, rather than self-insert-command.  I changed
them to use (self-insert-command 1) and now they behave as desired!
(I suppose the 1 might be optional.  Whatever.  It works!)

Thanks, John!  And apparently there is no lingering bug to be fixed,
since Emacs 25 already includes the correction.

	-- Don.