Open nonumeros opened 2 years ago
I didn't properly understand the issue.
What happens when you don't have trailing whitespace in the echo command you pasted in kakoune? What happens when you do? What is the difference in what you see in kakoune?
Try doing this on in your unix shell:
$ echo 'hello
bye' | kak -n
There is no trailing space after "bye".
What do you see? It is as per your expectations? On my machine I get:
hello¬
bye¬
¬
(Here I've depicted the newline char \n
by ¬
)
BTW you can see the whitespace in the file by typing the following command
<esc>: addhl window/ show-whitespaces<ret>
(<ret>
simply means please press the return or enter key)
(The -n
switch to kak
causes kakoune to not load any special configuration/setting/customizations that may be causing it to behave badly on your system)
Once we establish what the issue is then we can try to compare with what pico
does and perhaps argue on the merits/demerits of how kakoune does things.
lol I don't get it. The issue stands though.
@sidkshatriya allow me some time to process what you just wrote.
the echo
part for some given reason is not happening anymore. The other issue stands by pasting from the clipboard.
I too am confused at my end. Sorry!
So -- broadly speaking, what are you trying to accomplish?
Can you step by step layout what you're doing without skipping any step? What you might consider obvious at your end may be not be when I'm trying to debug the issue. At each step you should point out (a) What you expected (b) what you actually saw.
In the screenshots you shared I'm not able to understand what is the trailing whitespace that is problematic? Can you mark it on your screenshot?
In general it is not helpful to compare with Pico as I and probably many others here don't use it. Just mention what you're expecting Kakoune to show and what it is showing instead.
What I have in my bash init file is mainly something that you'd expect.
I was referring to the kakoune init and not bash init. Kakoune can run in plain vanilla mode and with some customizations. kak -n
disables them. Forget about that for now.
If you have have vim [with/without settings on the config file] and have the default bindings of a combination such as ctrl-shift-v, then it would normally paste the contents, unlike kak, which unfortunately dismisses the first characters of the system clipboard.
I am guessing it "dismisses" the characters until it encounters a character like i
or a
which puts it in insert mode. As far as I know Vim "understands" that you are pasting something through the terminal using bracketed-paste mode. There is an open issue about adding support for that to Kakoune here: https://github.com/mawww/kakoune/pull/2465
If you have have vim [with/without settings on the config file] and have the default bindings of a combination such as ctrl-shift-v, then it would normally paste the contents, unlike kak, which unfortunately dismisses the first characters of the system clipboard.
I am guessing it "dismisses" the characters until it encounters a character like
i
ora
which puts it in insert mode. As far as I know Vim "understands" that you are pasting something through the terminal using bracketed-paste mode. There is an open issue about adding support for that to Kakoune here: #2465
You're right. I had it set at one point set enable-bracketed-paste on
. Made no difference.
I am not sure where you found that option in Kakoune, or whether you mean you set it in another editor. Kakoune doesn't have such an option implemented.
I am not sure where you found that option in Kakoune, or whether you mean you set it in another editor. Kakoune doesn't have such an option implemented.
Correct. For neither one. Whether editor or terminal.
I've used vim and there has been a consistent set of functions. So I was going back and forth with bash, trying to figure out what this was about.
And now thtat you mention it, I may have read about it a while ago. And I forgot. But one things is for sure. At this rate, an emacs mode implemented in kak would be as feasible.
What was the idea behind it.
If you are trying to paste from your system clipboard into kakoune you can usually paste using ctrl+shift+v
without worrying about xsel etc.
But when you do so you need to do two things:
\
(backslash) in Normal mode (you can enter Normal mode by pressing the <esc>
key). Once you do that kakoune says [no-hooks]
in the status bari
) and then press the Ctrl+shift+v
. If you are not in insert mode then the paste would be messed up (as @caksoylar alluded to ... basically paste would not start until there was some i
or a
encountered in the text)Can you do the above small experiment and report if the paste worked properly for you? If it did not, please paste any screenshots showing what went wrong.
After reading https://github.com/mawww/kakoune/pull/2465
Optional<ScopedSetBool> m_disable_hooks_for_pasting
should be a field of InputModes::Insert, callemplace(context.hooks_disabled())
on it on paste:begin and reset on it on paste:end. The optionally contained ScopedSetBool will disable the NestedBool given to it (here context.hooks_disabled()) for its lifetime, so from emplace until either a call to reset, or the destruction of the Optional itself, which will happen when the insert mode is destructed. That should give the behaviour we want for pastes while in insert mode.But thinking more about it, it will be complex to make paste:end work nice when pasting from normal mode this way, as we need to tell the insert mode to exit on paste:end. I need to think a bit more about how to implement that nicely.
To exit on paste mode. But isn't the combination of ctrl-shift-v
and ctrl-v
share the same attributes?
the issue here is hte combination of and mainly the keys. Nothing else. Yanking is not even the issue. But pasting to.
If you are trying to paste from your system clipboard into kakoune you can usually paste using
ctrl+shift+v
without worrying about xsel etc.But when you do so you need to do two things:
- [Optional but useful when you are pasting into source code files which have auto indentation setup ] You need to disable hooks. Hooks can be disabled by pressing
\
(backslash) in Normal mode (you can enter Normal mode by pressing the<esc>
key). Once you do that kakoune says[no-hooks]
in the status bar- Enter Insert mode (by pressing
i
) and then press theCtrl+shift+v
. If you are not in insert mode then the paste would be messed up (as @caksoylar alluded to ... basically paste would not start until there was somei
ora
encountered in the text)Can you do the above small experiment and report if the paste worked properly for you? If it did not, please paste any screenshots showing what went wrong.
By @caksoylar bringing up the issue https://github.com/mawww/kakoune/pull/2465 I remember it was always an outstanding problem with the pasting operation mainly.
No bueno.
The latest unstable for example gave me an regex error parse *
message
Error: regex parse error: unexpected '*' at 'e it for notes or open a file buffer with the :edit command *<<<HERE>>>**'
and if by any chance, one happens to
Disregard the block of code. Double quotes must be used. It shouldn't have been echo ' <yanked text>
with a single quote, but rather echo "<yanked text>"
here
echo '*** this is a *scratch* buffer which won't be automatically saved ***
' | kak -n
The following happens:
*** this is a *scratch* buffer which wont be automatically saved alias_registry.cc alias_registry.hh array_view.hh assert.cc assert.hh backtrace.cc backtrace.hh buffer.cc buffer.hh buffer.inl.hh buffer_manager.cc buffer_manager.hh buffer_utils.cc buffer_utils.hh changes.cc changes.hh client.cc client.hh client_manager.cc client_manager.hh clock.hh color.cc color.hh command_manager.cc command_manager.hh commands.cc commands.hh completion.cc completion.hh constexpr_utils.hh context.cc context.hh coord.hh diff.hh display_buffer.cc display_buffer.hh enum.hh env_vars.cc env_vars.hh event_manager.cc event_manager.hh exception.cc exception.hh face.hh face_registry.cc face_registry.hh file.cc file.hh flags.hh hash.cc hash.hh hash_map.cc hash_map.hh highlighter.cc highlighter_group.cc highlighter_group.hh highlighter.hh highlighters.cc highlighters.hh hook_manager.cc hook_manager.hh input_handler.cc input_handler.hh insert_completer.cc insert_completer.hh json.cc json.hh json_ui.cc json_ui.hh kak kak.opt keymap_manager.cc keymap_manager.hh keys.cc keys.hh line_modification.cc line_modification.hh main.cc Makefile memory.cc memory.hh meta.hh normal.cc normal.hh optional.hh option.hh option_manager.cc option_manager.hh option_types.cc option_types.hh parameters_parser.cc parameters_parser.hh range.hh ranges.cc ranges.hh ranked_match.cc ranked_match.hh ref_ptr.hh regex.cc regex.hh regex_impl.cc regex_impl.hh register_manager.cc register_manager.hh remote.cc remote.hh safe_ptr.hh scope.cc scope.hh selection.cc selection.hh selectors.cc selectors.hh shared_string.cc shared_string.hh shell_manager.cc shell_manager.hh string.cc string.hh string_utils.cc string_utils.hh terminal_ui.cc terminal_ui.hh unicode.hh units.hh unit_tests.cc unit_tests.hh user_interface.hh utf8.hh utf8_iterator.hh utils.hh value.hh vector.hh window.cc window.hh word_db.cc word_db.hh
>
But with the same token, |
from within the prompt mode minibuffer, still return, the correct clipboard contents. So, it'll probably get resolved.
@caksoylar thanks for looking it up and referencing the issue. (couldn't auto complete your username, the display didn't help me when I quoted you earlier)
@sidkshatriya thanks for the extra help with steps and detailed explanation. I had encountered this problem before, but desisted by just mapping keys to xclip -select clip
and xclip -select clip -o
respectively. And forgot about this issue completely. To make matters worse, and lo and behold, further mapping keys in the configuration file, with say map global insert <whatever key here> %{key} %(key}
causes havoc really. Not good.
someone may say, «well, that's why it's recommended to read the documentation, and it'd be more viable especially with an external program, and whether it's xclip or xsel to use the prompt mode to pipe the contents with the |
key followed by ctrl-shift-v
combination»
So now, the outstanding problem with the PRIMARY CLIPBOARD gets resolved, correct? Wrong!
Why? Because mapping any key to insert mode with map global insert %<key> %<key>
, creates another unforeseen set of problems.
with vim for example, even having
inoremap ; \
inoremap \ ;
on the init file, has no effect whatsoever, with the PRIMARY CLIPBOARD, by using the ctrl-shift-v
combination. Obviously, with kak is another story. And conversely, this effect is different.
Needless to say, and my apologies for being redundant here (I think), but the reason why this incomplete feature is so unsettling, is that by having for example, map global insert %{\} %{;}
and viceversa respectively , the following simple few lines block of code, may not turn out what it seemed while yanking it out from the system clipboard:
location ~ \.php$ {
include /etc/nginx/fcgi_params; #or whatever you named it
fastcgi_pass 127.0.0.1:9000;
}
Question
I don't want to have any further clipboard settings on the init file. Although, technically speaking (I guess) kak does better than other editors in this regard with file permissions and such. The counterargument to this, is that there may be other ways around it. But this is besides the point. Kakoune definitely performs better in this regard than most editors.
But every once in a while I can't be dealing with the init file and its settings.
If I were to paste a yanked text from the primary system clipboard and then invoke on the terminal
it returns the expected output.
With kak, however, there must be a trailing whitespace added just before the last single quote, so this would be
echo '<text> '
in order to have the same output than Pico. Of course, pico crashes but it will save the buffer. Kak does the latter too, so this part is irrrelevantWhat is not relevant, is the part every single time where a trailing whitespace must be added from the primary clipobard selection
so in order to have the same under kak