Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

E340: Internal Error when using visual select and copy #14420

Open
oernohazy opened this issue Apr 5, 2024 · 9 comments
Open

E340: Internal Error when using visual select and copy #14420

oernohazy opened this issue Apr 5, 2024 · 9 comments
Labels

Comments

@oernohazy
Copy link

Steps to reproduce

Using GVIM open a file and with the mouse select a region of code, and right click and select "Copy"

Expected behaviour

The region is expected to yank into the buffer

Version of Vim

  1. 1-265

Environment

Linux aarch64 xterm-256color

Logs and stack traces

E340: Internal error..
@oernohazy oernohazy added the bug label Apr 5, 2024
@chrisbra
Copy link
Member

chrisbra commented Apr 5, 2024

can you bisect this please? And please show the full error message

@oernohazy
Copy link
Author

oernohazy commented Apr 5, 2024

I went all the way back to v8.1 and see the same issue. 7.x doesn't seem to tun on my linux aarch64.
I am ssh'ed -Y -C from a MAC into an Ubuntu 20.04 LTS host running on an ARM 64. Even the GVIM shipped with Ubuntu as the issue. I compiled the latest master from scratch and it has the problem.
My Intel based hosts have the same issue, so It doesnt seem to be arm related.

image

@oernohazy
Copy link
Author

oernohazy commented Apr 5, 2024

I made a "hack" that seems to help, at least I can cut a paste after my changes, but I'm not sure this is 100% correct. But At least I'm able to use gvim with my patch

git diff src/register.c
diff --git a/src/register.c b/src/register.c
index 47ed21846..340139b1c 100644
--- a/src/register.c
+++ b/src/register.c
@@ -1136,8 +1136,16 @@ free_yank_all(void)
  *
  * Return FAIL for failure, OK otherwise.
  */
+int _op_yank(oparg_T *oap, int deleting, int mess);
+
+    int
+op_yank(oparg_T *oap, int deleting, int mess) {
+    _op_yank(oap, deleting, mess);   // Oscar   do this twice
+    return _op_yank(oap, deleting, mess);
+}
+
     int
-op_yank(oparg_T *oap, int deleting, int mess)
+_op_yank(oparg_T *oap, int deleting, int mess)
 {
     long               y_idx;          // index in y_array[]
     yankreg_T          *curr;          // copy of y_current
@@ -1148,11 +1156,21 @@ op_yank(oparg_T *oap, int deleting, int mess)
     int                        yanktype = oap->motion_type;
     long               yanklines = oap->line_count;
     linenr_T           yankendlnum = oap->end.lnum;
+    char_u             *p;
     char_u             *pnew;
     struct block_def   bd;
 #if defined(FEAT_CLIPBOARD) && defined(FEAT_X11)
     int                        did_star = FALSE;
 #endif
+#if 0
+    if (clip_star.available)
+       clip_own_selection(&clip_star); // Oscar
+#endif
+
+#if 1
+    if(clip_plus.available)
+       clip_own_selection(&clip_plus); // Oscar
+#endif
 
                                    // check for read-only register
     if (oap->regname != 0 && !valid_yank_reg(oap->regname, TRUE))
@@ -1373,6 +1391,13 @@ op_yank(oparg_T *oap, int deleting, int mess)
            copy_yank_reg(&(y_regs[PLUS_REGISTER]));
 
        clip_own_selection(&clip_plus);
+
+#if 1
+       if(!y_current->y_size){
+           return op_yank(oap, deleting, mess);  // Retry -Oscar
+       }
+#endif
+
        clip_gen_set_selection(&clip_plus);
        if (!clip_isautosel_star()
                && !clip_isautosel_plus()

@chrisbra
Copy link
Member

chrisbra commented Apr 5, 2024

(fixing your markdown patch).

That is strange, that this is such an old issue and nobody noticed it. So it seems this happens because you seem to have :set clipboard=unnamedplus? Is that true? Does it then also happen with gvim --clean --cmd ':set clipboard=unnamedplus'?

@oernohazy
Copy link
Author

oernohazy commented Apr 5, 2024

When I use gvim --clean --cmd ':set clipboard=unnamedplus'
if I highlight and copy no matter how, using menu copy or 10yy etc, it shows 10 lines naked,
the paste of either 'p' or menu paste says nothing in register +

When I run gvim --clean --cmd ':set clipboard=unnamed' then I notice if I use the visual highlight and the menu "copy" it says 15 lines yanked into "+ and then menu paste says E353: Nothing in register +

if I highlight using Visual and use 'yy' and 'p' that seems to work.

What I now see is that the menu "copy" seems to copy into the external register, and I can paste outside of Gvim,
but paste using 'p' or menu paste says nothing in register +

Mainly I need to be able to copy from my host (source of SSH) computer and paste into the vim, and to be able to copy something in VIM and be able to paste it into other apps, either on the SSH'ed machine, or the host.

In my vimrc i use set clipboard=unnamed

But, no I don't see the error then.

@chrisbra
Copy link
Member

chrisbra commented Apr 9, 2024

so, can you reproduce using gvim --clean? I find it a bit hard to follow how to reproduce this issue.

@oernohazy
Copy link
Author

with --clean I cannot reproduce it. But then I don't have any of the features that I use the graphical vim, like selecting visual and popup mouse etc. for me it is very simple to reproduce. I just highlight a block of text, and right click, (pop up mouse). and select copy. ,out of the time it will give that internal error. If it doesnt give that error, sometimes when I go to paste, it tells me "Notihng in buffer".
The "hack" i patched the code with seems to make it work. basically internally I copy the buffer twice. It seems the second time the alloc works, and things are ok. So, with the attached patch above, I am able to use gvim now. I'm just surprised nobody else see this issue. I have seen this problem across all my hosts using gvim 8.x and 9.x. I do have some plugins like the vim-go that perform syntax checking and other gopls features.

@chrisbra
Copy link
Member

Well, then it must come from your vimrc file. Can you bisect the configuration settings that cause this behaviour?

The "hack" i patched the code with seems to make it work. basically internally I copy the buffer twice. It seems the second time the alloc works, and things are ok. So, with the attached patch above, I am able to use gvim now. I'm just surprised nobody else see this issue. I have seen this problem across all my hosts using gvim 8.x and 9.x. I do have some plugins like the vim-go that perform syntax checking and other gopls features.

Well, honestly, this sounds like there is something strange going on with your X11/Wayland system. Not sure if Vim is to blame. Did you say whether you used Wayland or X11?

@oernohazy
Copy link
Author

It's X11 but I only see issues in Gvim. When I select text visually and do YY it either shows the alloc error, or the paste ends up saying "nothing in buffer" . With my hack that cuts twice, things seem to work. Thats fine, if this is an isolated issue to my system(s) then I can live with the patch I added. I guess if nobody is complaining, it must not be something other people see. It may be the combination of the systems I use. I'm always ssh'ed in -Y -C from a MAC and connected to an Ubuntu system running X11 back through the ssh. The issue happens across all my Mac hosts, and ubuntu machines, so must be something in the combination. I have several plugins installed for code development, but the issue seems to happen when I turn on set clipboard=unnamed and set mousemodel=popup

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants