On Sat, Feb 17, 2024 at 8:31 PM Colin Kennedy wrote:
> Does :cc still honor the switchbuf=vsplit setting after this change?
>
> It’s nested in the PR replies currently but I think I asked whether we
> need this now in this PR and the consensus was to handle it as a horizontal
> split. If people
! if (got_int)
! {
! // Turn CTRL-C into an exception.
! got_int = FALSE;
! if (throw_exception("Vim:Interrupt", ET_INTERRUPT, NULL) !=
FAIL)
! goto failed;
! did_throw = TRUE;
! }
This was probably
> That "*" should be "s" then. I'll include that.
Yes. Sure. This is a copy-paste error where I would expect some
21st-century-AI-check to automatically kick in. ;-)
Tom M
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! T
Hi,
:menu listing sometimes contains items with an "s" in the first column.
Here is an example which can be seen after sourcing the standard menu.vim:
:menu Edit.Select\ All--- Menus ---
400 All^IggVG
n :call 11_SelectAll()
v :call 11_SelectAll()
s :call 11_SelectAll()
o
>
> + Examples: >
> + :echo maparg('Edit.Cut')
> + :echo maparg('File.Save', 'n')
> + <
> + Can also be used as a |method|: >
> + GetMenuName()->maparg('v')
>
The change to use the
On Monday, January 20, 2020 at 6:22:18 PM UTC+1, Bram Moolenaar wrote:
>
>
> > > then the Ctrl-C can mean "interrupt what is going on right now"
> >
> > Yes, where "going on right now" is from the user's perspective.
> > Because even in this state Vim is still responsive to `govim` sending
> > it
Bram Moolenaar wrote:
> Can you create a pull request, so that it triggers the CI tests?
Done. Pull Request #5215:
*GitHub* - "fix cursor column in concealed line after window scroll #5215"
https://github.com/vim/vim/pull/5215
*vim_dev* - "[vim/vim] fix cursor column in concealed line after
On Tuesday, September 10, 2019 at 9:23:45 PM UTC+2, Bram Moolenaar wrote:
>
>
> Patch 8.1.2020
> Problem:It is not easy to change the window layout.
> Solution: Add win_splitmove(). (Andy Massimino, closes #4561)
> Files:runtime/doc/eval.txt, src/evalfunc.c, src/evalwindow.c,
Hello,
I have set LANG to "en_US.UTF-8" in my environment. But when I launch gvim
and it comes to creating menus, the menu.vim script ends up executing
translations for UK English.
The reason seems to be the fact, that there is no lang/en_us.utf-8.vim
translation script shipped with Vim. So when
utput is horked
After the fix, the number of columns with features will be uniform once again.
It might even help to get rid of the hang. Though I am not sure I run vim in
the same way as toothpik as this is depends on
Tom M
--
--
You received this message from the "vim_dev" mailli
> ! #if defined(FEAT_BEVAL) || defined(FEAT_TEXT_PROP) || defined(PROT)
This was meant to check "PROTO" instead of "PROT", wasn't it?
Tom
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information,
On Sunday, June 23, 2019 at 2:40:30 AM UTC+2, Jason Franklin wrote:
> Interested to see if anyone can reproduce this:
>
> ./vim --clean --cmd 'set lz title' --cmd 'autocmd VimEnter * sleep'
>
> Summary:
>
>
> If it works for you, you may see that the title string is not
> redrawn when
> ***
> *** 1012,1027
>
> expr5 and expr6 *expr5* *expr6*
> ---
> ! expr6 + expr6 .. Number addition or |List| concatenation *expr-+*
> ! expr6 - expr6 .. Number subtraction
On Saturday, March 23, 2019 at 5:42:36 PM UTC+1, Bram Moolenaar wrote:
> Patch 8.1.1045
> Problem:E315 ml_get error when using Python and hidden buffer.
> Solution: Make sure the cursor position is valid. (Ben Jackson,
> closes #4153, closes #4154)
> Files:
On Friday, January 25, 2019 at 9:52:39 PM UTC+1, Bram Moolenaar wrote:
> Patch 8.1.0821
> Problem:Xxd "usage" output and other arguments not tested.
> Solution: Add a test to trigger the usage output in various ways. Fix
> uncovered problem.
> Files:
On Tuesday, January 22, 2019 at 11:35:50 PM UTC+1, Dominique Pelle wrote:
> Hi
>
> Attached patch contains more doc updates
> for Blobs. Behavior of :for loop, "is" and
> "isnot" were not documented for Blobs.
>
> Regards
> Dominique
Hi,
I've noticed two small typos:
> +The |:for| loop
Hi!
I see a typo and have some questions:
> ! To change a sequence of bytes the [:] notation can be used: >
> ! let blob[1:3] = 0z445566
> ! The length of the replaced bytes much be exactly the same as the value
Typo: much -> must
> ! To change part of a blob you can specify the first and last
On Tue, Jan 1, 2019 at 9:52 PM Tom M <7to...@gmail.com> wrote:
>
> for a zero-width property it's not enough to have {col} equal to "end_col
> ", "end_lnum" (if given) should be equal to {lnum} too.
>
>
I am not saying that it's coded wron
Hi Bram,
On Tuesday, January 1, 2019 at 7:50:16 PM UTC+1, Bram Moolenaar wrote:
> prop_add({lnum}, {col}, {props})
> ! Attach a text property at position {lnum}, {col}. {col} is
> ! counted in bytes, use one for the first column.
>If {lnum} is invalid an error is given. *E966*
>If
On Saturday, December 1, 2018 at 8:00:02 PM UTC+1, Yegappan Lakshmanan wrote:
> Patch to add functions to manage signs, add support for sign groups and
>
> sign priority. Also add support for allocating unique sign identifiers.
>
>
>
> You can view, comment on, or merge this pull request online
On Mon, Dec 24, 2018 at 9:36 AM Christian Brabandt wrote:
> I'll have a look.
>
> Tom, can you provide a simple test case?
It's about the issue reported by John Little and Tony Mechelynck on
Wed, Oct 24, 2018: "linebreak, showbreak, and visual block yank
problem". See:
display of characters in combination of various settings that influence
> > > the display.
> > >
> > > On Di, 27 Nov 2018, Tom M wrote:
> > >
> > > [...]
> > > > Currently (as the test case suggests), the buffer ends up with line 1
> > &
quite often tried to fix various bugs around the block editing and
> display of characters in combination of various settings that influence
> the display.
>
> On Di, 27 Nov 2018, Tom M wrote:
>
> [...]
> > Currently (as the test case suggests), the buffer ends up with l
I am wandering what is the logic behind deleting something using visual
block. In particular, the case when the cursor which denotes the lower
right-hand side corner of the block ends up on a space that got "expanded"
up to the end of the screen line due to 'linebreak' setting. I am talking
about
On Thu, Nov 15, 2018 at 7:46 AM Christian Brabandt
wrote:
>
> ...
> Thanks for contributing. Could you please also add a test for the
> changed behaviour?
>
>
I am sending some basic test for visual block yanking and deleting with
linebreak. Kind of fundamental specification of the feature. Can
On Thu, Nov 15, 2018 at 7:46 AM Christian Brabandt wrote:
>
>
> On Mi, 14 Nov 2018, Tom M wrote:
>
> > On Wednesday, November 14, 2018 at 10:23:52 PM UTC+1, Tom M wrote:
> > >
> > > Hi,
> > >
> > > I propose the following patch (please see
On Wednesday, November 14, 2018 at 10:23:52 PM UTC+1, Tom M wrote:
>
> Hi,
>
> I propose the following patch (please see the attachment) to fix issues of
> John and Tony. It ads handling of 'showbreak' and 'linebreak' in visual block
> operations.
>
> Tom
Oooops, wron
On Wednesday, October 24, 2018 at 3:42:38 PM UTC+2, Tony Mechelynck wrote:
> On Wed, Oct 24, 2018 at 1:57 PM John Little wrote:
> >
> > I noticed a problem today when editing a paragraph that was wrapped to
> > several lines on screen. To reproduce, use a file with a line with normal
> > prose
On Tue, Apr 3, 2018 at 7:14 PM, Bram Moolenaar <b...@moolenaar.net> wrote:
>
> Tom M wrote:
>
>> > On Thu, Mar 29, 2018 at 2:06 PM, Bram Moolenaar <b...@moolenaar.net>
>> > wrote:
>> >
>> >>
>> >> Tom M wrote:
>>
On Tue, Apr 3, 2018 at 7:14 PM, Bram Moolenaar <b...@moolenaar.net> wrote:
>
> Tom M wrote:
>
> > > On Thu, Mar 29, 2018 at 2:06 PM, Bram Moolenaar <b...@moolenaar.net>
> > > wrote:
> > >
> > >>
> > >> Tom M wrote:
> >
On Mon, Apr 2, 2018 at 1:33 AM, Tom M <7to...@gmail.com> wrote:
>
>
> On Thu, Mar 29, 2018 at 2:06 PM, Bram Moolenaar <b...@moolenaar.net>
> wrote:
>
>>
>> Tom M wrote:
>>
>> > First of all, thank you for VIM. Now, I'd like to share an example
On Thu, Mar 29, 2018 at 2:06 PM, Bram Moolenaar <b...@moolenaar.net> wrote:
>
> Tom M wrote:
>
> > First of all, thank you for VIM. Now, I'd like to share an example of
> > a rather confusing behaviour. It's the ':file' ex command when used in
> > combination
Hi all!
First of all, thank you for VIM. Now, I'd like to share an example of a rather
confusing behaviour. It's the ':file' ex command when used in combination with
the # register. Here is how to reproduce:
vim -N -u NONE -U NONE --noplugin somefile.txt
:file
=>
"somefile.txt"
:file #
=>
33 matches
Mail list logo
