feature request: opt out from y/n when ending up with unbalanced region
terlar opened this issue · 5 comments
Sometimes for various reasons I end up with characters that will thinks it will cause unbalanced region while it actually won't. Over time I have found it quite annoying with the y/n question when I just want to fix a miss-typed character or similar.
For example if I in an emacs-lisp buffer press \
by accident I have to type another \
to be able to kill it or select the character and then use C-w
and then answer the question y/n. This also happens when if I press ]
instead of [
(which will create a balanced []
). How do you usually handle these issue do I have especially fat fingers? I think there are other cases as well where I sometimes end up with unbalanced characters.
Now when I think about it, I guess perhaps using undo is a better solution, I just have gotten used to the magic of puni and tend to rely on editing operations to fix typos instead.
Anyways it might still be useful to have a config option to disable the unbalanced warning.
Another example is when using nix-mode
which has content like this:
{ pkgs }:
{
script = pkgs.writeShellScriptBin "script" ''
cd ${toString ./.}
echo hello
'';
}
If I try to kill the line with cd
it will only kill to $
so usually then I select the whole line and kills it which will result in a balanced expression. But it will complain about unbalanced expression due to how nix-mode defines it's syntax. Inside the ${}
it is like a totally new scope. What I can do is remove the whole ${ ... }
but not only ${
for example.
How do you usually handle these issue
I use puni-force-delete
(I bind it to C-h
).
It's meaningful to support deleting a "broken part", but maybe it'll be very hard. Let me think about this.
About the problem in nix-mode, I'll try it myself later.
I think this kind of option is very convenient. Especially when I mark a region to delete and get the prompt. Puni is deliberately disobeying the user.
Now puni-backward/forward-delete-char
handles "dangling delimiters". A "dangling delimiter" is a single char opening/closing delimiter that doesn't have a matched delimiter. So when you accidentally typed \
or )
, you can just press DEL
;)
I do have some thoughts about extending this for multiple chars (e.g. when deleting a selected region, or for other deleting commands) but that seems somewhat difficult.
For the other two items:
- The problem in
nix-mode
- An option for don't prompt the user when deleting an active region (by @QiangF)
Please allow for some more time.
A user option puni-confirm-when-delete-unbalanced-active-region
is added.
@terlar I tried your example in nix-mode
and I'm not sure if it should be fixed... Here's the result of my experiment. I use forward-sexp
and backward-sexp
(not the puni versions, but the ones defined by nix-mode
) to find out all sexps that's in the same level of cd
. Here are the boundaries of them:
It looks very weird to me:
- This list begins from
"
but ends at'
- The
"
afterscript
doesn't act as a closing delimiter, but forms a sexp together with the following'
(what??) ${toString ./.}\n
is a sexp. The newline character is a part of it and that's why you can't delete to the line end.
There are some major modes utilizing SMIE that behaves weird. SMIE is not easy to make good use of.
Maybe Puni can be patched to fix this problem. The reason for me to do this:
- Based on my passed experience, only single line comment uses
\n
as the closing delimiter, and Puni deals with that when necessary. Maybe it's worthwhile to consider\n
as the closing delimiter for a general sexp (which is the case of this issue).
The reason for me to not do this:
- I don't have more examples.
- Seems Puni also doesn't behave well in other parts of your example. Fixing this doesn't immediately makes it usable in
nix-mode
.
Since I'm not familiar with nix I'm thinking whether you have some idea, but I guess it's hard to fix.