Hello,
Assuming that 'sessionoptions' contains localoptions, would the
SessionLoadPost event be a safe bet to detect whether a local option was
(explicitly) set by loading a session file?
That is, are all local options always (re)set in a session file?
Thank you for your help
Enno
Le lundi 14 mai 2018 16:43:18 UTC-3, Andy Wokula a écrit :
> Am 14.05.2018 um 19:17 schrieb Christian Brabandt:
> > On Mo, 14 Mai 2018, 'Andy Wokula' via vim_dev wrote:
> >
> >> Am 14.05.2018 um 17:00 schrieb Enno (Vim Github Repository):
> >&
d work is done.
If a shell script, for example in $VIMRUNTIME/macros, to work around the error
appearing for manpages that contain capital letters on systems that do not set
MAN_PN, can be made a stable replacement for the current Vim script, then this
is the correct approach. The manpager.
Mysteriously, the $MANPATH was empty when vim was called as manpager and caused
the
issue of this thread. Setting
export MANPAGER="env MANPATH=${MANPATH} vim -RM +MANPAGER -"
worked around it.
Also,
export MANPAGER="env LANGUAGE=${LANG} $vim -RM +MANPAGER -"
ensures that the manpages are
Le vendredi 20 mai 2016 14:08:12 UTC+2, Christian Brabandt a écrit :
> Hi,
> as some of you may know, I am maintaining a little unicode plugin
> https://github.com/chrisbra/unicode.vim
>
> Now I got an issue, that asks if it would be possible to distribute this
> plugin with Vim, so I am asking
command, turning
Vim into an info reader.
Enno
--
--
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, visit http://www.vim.org/maillist.php
---
You received this message b
Ok, got it. The documentation should now reflect this. Now on FreeBSD (and
perhaps Amiga OS, BeOS, ...), another
approach is needed to start :Man. Your suggestion, `MANPAGER = env MAN_PN=1 vim
+...` is an elegant work around.
Instead of $MAN_PN, the manpage and section seems, by a superficial
This would be very useful. For example, when using `cgn` and the dot operator
to repeat changes on all matches. This breaks down whenever the changed text
contains delimiters such as (,[,{, ... (and using an automatic
delimiter-completion plugin such as DelimitMate).
--
--
You received this
Hitting a non-keyword character, cr or esc in insert mode with the cursor
behind an abbreviation (:help abbreviation) expands the abbreviation. However,
a mapping to that character no longer expands the abbreviation in the same way.
Is this a bug or on purpose?
The remedy by prepending C-] to
; in my view this behavior goes against the
user's expectations. Practically your remark solves all of my problems,
subordinate :inoremap'ed SIDIntermediateMappings are the way to go.
Enno
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text
Le lundi 9 février 2015 21:45:42 UTC+1, Bram Moolenaar a écrit :
The Summer of Code is here again this year. If we want Vim to
participate we need a few mentors and someone to organise the
application.
To be realistic, I won't have much time for this. I can help out where
needed, but the
Le jeudi 5 février 2015 15:46:01 UTC+1, h_east a écrit :
Hi Enno,
2015/2/5(Thu) 18:25:49 UTC+9 Enno:
Le jeudi 5 février 2015 05:12:19 UTC+1, h_east a écrit :
Hi Enno,
2015/2/4(Wed) 20:42:57 UTC+9 Enno:
How about
let b:isLoc = len(getloclist(0)) 0 ? 1 : 0
Le jeudi 5 février 2015 05:12:19 UTC+1, h_east a écrit :
Hi Enno,
2015/2/4(Wed) 20:42:57 UTC+9 Enno:
How about
let b:isLoc = len(getloclist(0)) 0 ? 1 : 0
inside of a qf filetype window. See :h getloclist() that explains
For a location list window, the displayed location list
Le samedi 23 octobre 2010 22:56:28 UTC+2, PabloHot a écrit :
Hi All,
I'm trying something like :map C-- ... but just cannot get this to work. I
have tried using Ctrl-K to enter the '-' key, using {minus}, but the mapping
does nothing when I type it. If I map map '-'
on its own it
How about
let b:isLoc = len(getloclist(0)) 0 ? 1 : 0
inside of a qf filetype window. See :h getloclist() that explains
For a location list window, the displayed location list is returned.
All credit to romainl at
Le lundi 12 janvier 2015 22:57:56 UTC+1, Marcin Szamotulski a écrit :
On 22:26 Mon 12 Jan , Bram Moolenaar wrote:
Enno Nagel wrote:
Le lundi 12 janvier 2015 14:41:00 UTC+1, Bram Moolenaar a écrit :
Enno Nagel wrote:
The command
0wincmd w
throws
The command
0wincmd w
throws an error in the latest Vim version:
E16: Invalid range: 0wincmd w
Before, it simply stayed in the same window.
Is this a new feature or a bug?
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are
Le lundi 12 janvier 2015 14:41:00 UTC+1, Bram Moolenaar a écrit :
Enno Nagel wrote:
The command
0wincmd w
throws an error in the latest Vim version:
E16: Invalid range: 0wincmd w
Before, it simply stayed in the same window.
Is this a new feature or a bug
Le lundi 12 janvier 2015 17:23:37 UTC+1, David Fishburn a écrit :
On Mon, Jan 12, 2015 at 9:52 AM, Enno enno@gmail.com wrote:
Le lundi 12 janvier 2015 14:41:00 UTC+1, Bram Moolenaar a écrit :
Enno Nagel wrote:
The command
0wincmd w
throws an error
Le samedi 13 décembre 2014 20:23:22 UTC+1, Enno a écrit :
To use Vim under powershell in MS Windows, set shell=powershell and
shellcmdflag=-c.
However, if shell=powershell and shellcmdflag=-c, then tempname() returns a
file name with forward slashes because 'powershell' contains 'sh
To use Vim under powershell in MS Windows, set shell=powershell and
shellcmdflag=-c.
However, if shell=powershell and shellcmdflag=-c, then tempname() returns a
file name with forward slashes because 'powershell' contains 'sh' and '-c'
starts with '-'.
Then again, if instead shellcmdflag=\
Thank you Yasuhiro,
This was lacking ever since.
--
--
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, visit http://www.vim.org/maillist.php
---
You received this message because you are
Ok, in this case, where to file issues about plugins coming with Vim?
--
--
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, visit http://www.vim.org/maillist.php
---
You received this message
Le lundi 1 décembre 2014 20:42:50 UTC+1, v...@googlecode.com a écrit :
Comment #3 on issue 290 by chrisbr...@googlemail.com: gVim does not jump to
given linennumber if already at end of file
https://code.google.com/p/vim/issues/detail?id=290
Vim 7.4 works correctly with +[number] here (if
Le mardi 2 décembre 2014 10:06:59 UTC+1, Enno a écrit :
Le lundi 1 décembre 2014 20:42:50 UTC+1, v...@googlecode.com a écrit :
Comment #3 on issue 290 by chrisbr...@googlemail.com: gVim does not jump to
given linennumber if already at end of file
https://code.google.com/p/vim/issues
Le mardi 2 décembre 2014 10:09:36 UTC+1, Enno a écrit :
Le mardi 2 décembre 2014 10:06:59 UTC+1, Enno a écrit :
Le lundi 1 décembre 2014 20:42:50 UTC+1, v...@googlecode.com a écrit :
Comment #3 on issue 290 by chrisbr...@googlemail.com: gVim does not jump
to
given linennumber
Le mardi 2 décembre 2014 10:44:13 UTC+1, jott...@googlemail.com a écrit :
Hi,
Enno schrieb am 02.12.2014 um 10:06:
Le lundi 1 décembre 2014 20:42:50 UTC+1, v...@googlecode.com a écrit :
Comment #3 on issue 290 by chrisbr...@googlemail.com: gVim does not jump
to
given linennumber
Le mardi 2 décembre 2014 11:38:10 UTC+1, Enno a écrit :
Le mardi 2 décembre 2014 10:44:13 UTC+1, jott...@googlemail.com a écrit :
Hi,
Enno schrieb am 02.12.2014 um 10:06:
Le lundi 1 décembre 2014 20:42:50 UTC+1, v...@googlecode.com a écrit :
Comment #3 on issue 290 by chrisbr
Le mardi 2 décembre 2014 12:00:30 UTC+1, jott...@googlemail.com a écrit :
Hi
Enno schrieb am 02.12.2014 um 11:39:
Le mardi 2 décembre 2014 11:38:10 UTC+1, Enno a écrit :
Le mardi 2 décembre 2014 10:44:13 UTC+1, jott...@googlemail.com a écrit :
Hi,
Enno schrieb am 02.12.2014 um 10:06
Le lundi 1 décembre 2014 12:39:10 UTC+1, v...@googlecode.com a écrit :
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 290 by enno.na...@gmail.com: gVim does not jump to given
linennumber if already at end of file
https://code.google.com/p/vim/issues/detail?id=290
Le mardi 2 décembre 2014 15:34:09 UTC+1, Enno a écrit :
Le lundi 1 décembre 2014 12:39:10 UTC+1, v...@googlecode.com a écrit :
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 290 by enno.na...@gmail.com: gVim does not jump to given
linennumber if already
In editexisting.vim from 2013 Feb 24, can the splits occurring at line number
106 and below be made optional ? That is, use either edit or split by setting a
global variable.
The concerned code is:
if winnr 0
exe winnr . wincmd w
elseif exists('*fnameescape')
exe split .
Le vendredi 28 novembre 2014 14:33:25 UTC+1, LCD 47 a écrit :
On 28 November 2014, itchyny neknekneknek.ky...@gmail.com wrote:
Bram, the line1 is always 1 (probably after this patch).
:command! Test echo line1
try :Test and it always echoes 1.
I don't think this is a relevant
In the Vim documentation, diff.txt says
==
In your .vimrc file you could do something special when Vim was started in
diff mode. You could use a construct like this:
if diff
setup for diff mode
else
setup for non-diff mode
endif
While already in
If a large buffer with enabled syntax folding and conceal mode is edited then
the continuous computation of all folds leaves Vim less responsive.
Instead, how about an event that triggers when the user wants to close or open
a fold, and only then compute all folds? I made a plugin, FastFold,
Dear Vim developers,
The autocmd
autocmd FocusLost * wall
triggers the autocmd event BufWritePre, but not BufWritePost.
Is this expected ? To ensure that both are triggered,
is autocmd FocusLost * wall | doautocmd BufWritePost necessary?
Enno
--
--
You received this message from
Le lundi 21 juillet 2014 09:37:43 UTC+2, Enno a écrit :
When using mkview and loadview autocmds such as
au BufWinLeave *.vim mkview
au BufWinEnter *.vim silent loadview
then jumping to a yet not displayed *.vim file from a quickfix window, for
example a match found
When using mkview and loadview autocmds such as
au BufWinLeave *.vim mkview
au BufWinEnter *.vim silent loadview
then jumping to a yet not displayed *.vim file from a quickfix window, for
example a match found by the plugin ack.vim, then
':echo winnr()==winnr('#')CR'
shows
Am Montag, 21. Juli 2014 19:48:53 UTC+2 schrieb Christian Brabandt:
Hi Enno!
On Mo, 21 Jul 2014, Enno wrote:
When using mkview and loadview autocmds such as
au BufWinLeave *.vim mkview
au BufWinEnter *.vim silent loadview
then jumping to a yet
Le lundi 30 juin 2014 15:35:25 UTC+2, Charles Campbell a écrit :
Enno wrote:
Le mardi 24 juin 2014 19:16:44 UTC+2, DrChip a écrit :
Enno wrote:
Le vendredi 13 juin 2014 18:53:06 UTC+2, Charles Campbell a écrit :
Enno wrote:
Ok, I understand that spell checking is only
, Enno enno.na...@gmail.com wrote:
Is this a feature or a bug? This occurs under a Vanilla gVim 7.4.326
under Windows 7 x64, or a Vanilla Vim 7.4.326 under CygWin.
To reproduce:
Start vim. Type 'x', then type
:inoremap ; /CR
then type
r;
Expected
Is this a feature or a bug? This occurs under a Vanilla gVim 7.4.326 under
Windows 7 x64, or a Vanilla Vim 7.4.326 under CygWin.
To reproduce:
Start vim. Type 'x', then type
:inoremap ; /CR
then type
r;
Expected: The buffer contains the single character '/'.
What we got: The buffer contains
Le dimanche 29 juin 2014 13:26:37 UTC+2, Enno a écrit :
Is this a feature or a bug? This occurs under a Vanilla gVim 7.4.326 under
Windows 7 x64, or a Vanilla Vim 7.4.326 under CygWin.
To reproduce:
Start vim. Type 'x', then type
:inoremap ; /CR
then type
r;
Expected
Le vendredi 23 mai 2014 10:42:55 UTC+2, Enno a écrit :
Can one configure netrw so that when opening a file in netrw the just left
netrw buffer is automatically deleted?
For example type :e ., navigate to a file, hit CR. Then there is the netrw
buffer, created by :e . that we just left
Le vendredi 13 juin 2014 18:53:06 UTC+2, Charles Campbell a écrit :
Enno wrote:
Ok, I understand that spell checking is only activated after a
keyword, such as the \section{..} command. But why is it that
\begin{document} does not belong to these keywords? This disables
spell
Am Freitag, 16. Mai 2014 23:01:27 UTC+2 schrieb Charles Campbell:
Enno wrote:
This inconsistency is also discussed in the comments of the thread opener on
http://tex.stackexchange.com/questions/135337/how-to-set-up-spell-checking-with-vim
If set filetype=plaintex, then spell
Am Freitag, 23. Mai 2014 10:42:55 UTC+2 schrieb Enno:
Can one configure netrw so that when opening a file in netrw the just left
netrw buffer is automatically deleted?
For example type :e ., navigate to a file, hit CR. Then there is the netrw
buffer, created by :e . that we just left
Am Freitag, 23. Mai 2014 10:42:55 UTC+2 schrieb Enno:
Can one configure netrw so that when opening a file in netrw the just left
netrw buffer is automatically deleted?
For example type :e ., navigate to a file, hit CR. Then there is the netrw
buffer, created by :e . that we just left
Can one configure netrw so that when opening a file in netrw the just left
netrw buffer is automatically deleted?
For example type :e ., navigate to a file, hit CR. Then there is the netrw
buffer, created by :e . that we just left, and has done its service. Is there
an autocmd to delete it?
Le vendredi 23 mai 2014 10:42:55 UTC+2, Enno a écrit :
Can one configure netrw so that when opening a file in netrw the just left
netrw buffer is automatically deleted?
For example type :e ., navigate to a file, hit CR. Then there is the netrw
buffer, created by :e . that we just left
Le vendredi 23 mai 2014 10:42:55 UTC+2, Enno a écrit :
Can one configure netrw so that when opening a file in netrw the just left
netrw buffer is automatically deleted?
For example type :e ., navigate to a file, hit CR. Then there is the netrw
buffer, created by :e . that we just left
This inconsistency is also discussed in the comments of the thread opener on
http://tex.stackexchange.com/questions/135337/how-to-set-up-spell-checking-with-vim
If set filetype=plaintex, then spell checking in a tex file checks the text in
the whole document for spelling errors. (This is,
How about Unmap and Unabbrev accepting the same two arguments as map and abbrev?
In this way, if a script set certain maps and abbreviations, it can ensure not
to unset maps and abbreviations set by the user.
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type
Am Freitag, 4. April 2014 23:00:22 UTC+2 schrieb Enno:
Am Freitag, 4. April 2014 16:50:37 UTC+2 schrieb Bram Moolenaar:
Enno Nagel wrote:
Le vendredi 28 mars 2014 23:31:51 UTC+1, Enno a écrit :
When restoring a session with spelllang=de, encoding = utf-8
Le samedi 29 mars 2014 18:42:35 UTC+1, Enno a écrit :
Under Windows, the undo-, backup- and swapdir-settings accept back- or
forward-slashes, but viminfo only the backslash variant.
Ok, I had Viewoptions+=slash set. Other than that Set shellslash yields
Noshellslash, as is the default
Am Freitag, 4. April 2014 16:50:37 UTC+2 schrieb Bram Moolenaar:
Enno Nagel wrote:
Le vendredi 28 mars 2014 23:31:51 UTC+1, Enno a écrit :
When restoring a session with spelllang=de, encoding = utf-8 and a
nonempty german spellfile de.utf-8.add , the de.utf-8.spl is not read
Le mardi 12 novembre 2013 20:22:59 UTC+1, v...@googlecode.com a écrit :
Updates:
Status: Accepted
Owner: drc...@campbellfamily.biz
Comment #1 on issue 151 by drc...@campbellfamily.biz: file management
(copy/move) is broken on windows (netrw)
Le jeudi 3 avril 2014 18:57:12 UTC+2, Enno a écrit :
Le mardi 12 novembre 2013 20:22:59 UTC+1, v...@googlecode.com a écrit :
Updates:
Status: Accepted
Owner: drc...@campbellfamily.biz
Comment #1 on issue 151 by drc...@campbellfamily.biz: file
Am Samstag, 29. März 2014 18:42:35 UTC+1 schrieb Enno:
Under Windows, the undo-, backup- and swapdir-settings accept back- or
forward-slashes, but viminfo only the backslash variant.
It was
let s:tmpdir=$HOME.'/.vim/tmp/'
and
let viminfo=!,\'10,\100,:20,h,n.s:tmpdir.'.viminfo'
This did
Under Windows, the undo-, backup- and swapdir-settings accept back- or
forward-slashes, but viminfo only the backslash variant.
--
--
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, visit
Am Freitag, 28. März 2014 23:31:51 UTC+1 schrieb enno@gmail.com:
When restoring a session with spelllang=de, encoding = utf-8 and a nonempty
german spellfile de.utf-8.add , the de.utf-8.spl is not read.
This problem does not occur when
- set spell spelllang=de is invoked manually
When restoring a session with spelllang=de, encoding = utf-8 and a nonempty
german spellfile de.utf-8.add , the de.utf-8.spl is not read.
This problem does not occur when
- set spell spelllang=de is invoked manually,
- for other languages. Tested for English and Portuguese.
--
--
You
I have to correct: This problem occurs for any non-English spell check.
--
--
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, visit http://www.vim.org/maillist.php
---
You received this message
Once hitting a printable character x in selection mode, the currently
selected text is expected to be replaced by x.
Under this maxim, it would be consistent to assign xmode instead of
vmode mappings to the movement mappings in vim.vim and matchit.vim.
--
--
You received this message from
64 matches
Mail list logo
