Re: surprised by beta
On Tue, May 08, 2007 at 04:50:36PM -0500, Robert Lee wrote: The SVN Repos has conflict markers left in the file filetype.vim, Sorry for the silly question, but the answer is not clear to me from your text: is your working copy that has conflict markers or the last committed version in the repository which has been committed without removing conflict markers? -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time
plugin loading ordering
According to my reading of :help load-plugins the plugins should be loaded following the runtimepath ordering. That is: first load all the plugins in the first component of runtimepath, then all the plugins in the second component and so on. According to my experiments however this is not the case. It looks like all the plugins from all the components of the runtimepath are loaded in alphabetic order. For example, I have the following runtimepath: runtimepath=~/.vim,/var/lib/vim/addons,/usr/share/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/vim70,/usr/share/vim/vimfiles/after,/usr/share/vim/addons/after,/var/lib/vim/addons/after,~/.vim/after with matchit.vim installed (i.e. symlinked) under /usr/share/vim/addons/plugin/. If I add the following plugin to my ~/.vim: $ cat .vim/plugin/no-matchit.vim let loaded_matchit = 1 matchit is still loaded and works properly (note that no-matchit matchit in alphabetic order). However if I move it as follows: $ mv .vim/plugin/no-matchit.vim .vim/plugin/lo-matchit.vim matchit is prevented to be loaded. Is this a bug or a underspecification in the vim docs? Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time
Re: plugin loading ordering
On Wed, Jan 24, 2007 at 09:48:03AM +0100, A.J.Mechelynck wrote: That's what :scriptnames should show. If a plugin has a :finish clause near the start, it might get loaded and do nothing, but still appear in the :scriptnames listing. Thanks, I was not aware of the :scriptnames command. What you describe lets me believe that there's something in your ~/.vim/plugin (maybe ~/.vim/plugin/matchit.vim ?) which invokes (or is) some version of matchit. Gotcha, I had indeed a symlinked matchit.vim from my ~/.vim/. Sorry for the noise. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time
Re: Odp: BOF Vim 8 - Suggestions
On Thu, Jan 18, 2007 at 05:46:55PM +0100, A.J.Mechelynck wrote: Vim defaults to 'compatible' mode everywhere, except where it finds a user _vimrc or .vimrc (system vimrc doesn't count). I personally recommend to create the following as $HOME/_vimrc (or $HOME/.vimrc) immediately after first installation, and to add tweaks as one gets going: This isn't really applicable to *nix-like systems, where you have tons of users, and packages as vim are usually installed system-wide. As a sysadm, should I install .vimrc on the home of every user? Should I modify the /etc/skel/ dir so that every new user get a .vimrc upon account creation? Ok that vim is my second most used command (after ls :-)), but this is really too much to ask for just an editor. Rather, time is probably mature to ship vim with 'compatible' mode off by default, explaining ancient *nix lovers how to turn it *on*. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time
Re: Odp: BOF Vim 8 - Suggestions
On Fri, Jan 19, 2007 at 01:09:41PM +0100, Martin Stubenschrott wrote: First and most important thing would be to enable nocompatible by default when the executable name is (g)vim, compatible should still be on, when the executable name is vi. Enabling/disabling by an (non-)existing That's precisely what we do in Debian. In the past we used to have 'nocompatible' set per default, but a non-negligible amount of users asked for vim to behave more similarly to the plain old Vi when we switched from nvi to vim in the default debian installation. The solution of being compatible when invoked as 'vi' and being nocompatible when invoked in a different way made everybody happy. The (trivial) patch we are using to implement this behaviour is available at: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim/debian/tiny/vimrc.tiny.diff?op=filerev=0sc=0 FWIW we also set a lot of other default values when not invoked as 'vi'. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time
Re: Patch 7.0.139
On Tue, Oct 17, 2006 at 01:40:04PM +0200, Bram Moolenaar wrote: Patch 7.0.139 Problem:Using CTRL-PageUp or CTRL-PageDown in Insert mode to go to another tab page does not prepare for undo properly. (Stefano Zacchiroli) Solution: Call start_arrow() before switching tab page. Files:src/edit.c Thanks a lot for this fix! Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!-
better user-definition of paragraphs
Hi all,
playing with formatoptions+=a I stumbled on the 'paragraphs' option
and I must confess I feel it's quite dumb (probably due to compatibility
issue with old vi? don't know ...)
My main problem is that I want a way to define where paragraphs start,
... even if I'm not writing nroff! Two use cases that may clarify my
needs:
1) TeX
I want to tell vim that a line starting with ^\s*\\ (a TeX macro at
the beginning of a line) marks a new paragraph. This way vim with
automatic formatting wont try to change the following:
\begin{itemize}
\item foo
\item bar
\end{itemize}
in the following:
\begin{itemize} \item foo \item bar \end{itemize}
2) Mail
Similarly, I usually write mails in mutt editing headers. I want to
tell vim that a line starting with ^\u\U+: (an header name at the
beginning of a line) marks a new paragraphs. Such that the following:
From: Stefano Zacchiroli [EMAIL PROTECTED]
To: VIM Development List vim-dev@vim.org
Subject: better user-definition of paragraphs
is not changed to:
From: Stefano Zacchiroli [EMAIL PROTECTED] To: VIM Development List
vim-dev@vim.org Subject: better user-definition of paragraphs
I'm a bit puzzled that there is no support for that, maybe I am missing
something? No one else has ever wanted such a feature?
Thanks in advance,
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
Re: better recognising of tex vs plaintex filetype
On Wed, Aug 30, 2006 at 08:42:52AM -0400, Benji Fisher wrote: If you maintain a vim package (for Debian, guessing from your sig?), then you can always define g:tex_flavor in a system vimrc if you want. BTW, the documentation for this is under Yes, sure, I was proposing it to you assuming it could have been an improvement for all users. In Debian we try to push upstream changes we think are useful. Of course if you don't agree on this change it is pointless. Since you agree that LaTeX is more common, what is exactly your argument against having it as the default? Plain TeX came first, so it has priority. (Maybe LaTeX 2ε is an independent format, but I remember when LaTeX first came out that it was actually a bunch of \def's made on top of plain TeX.) This is the same logic that leads to keeping vi-compatible regular expressions, despite the persistent suggestions that vim adopt PCRE. Ok, got it, I will then decide whether to change the default in Debian depending on users willingness. Please read the thread on this list started Mar 2, 2006, with the subject RFC: filetypes for TeX, LaTeX, ConTeXT (others?) Thanks for the pointer. Beside that, I agree with the other proposal in this thread of recognizing as LaTeX files which starts with a sectioning command (after several possible blanks of course), and I'm going to implement it. Any comments on that choice? Do you mean you plan to implement it as a proposed modification to $VIMRUNTIME/filetype.vim in the standard distribution, or a change to your vim package? In Debian we usually first implement changes as patches to our packages and then try to push patches upstream, hoping to improve the life of non-Debian users. So yes to both questions: first modifying our package, than proposing the modification for the official $VIMRUNTIME/filetype.vim. I agree with the comment that plain TeX users may also define such sectioning commands. Maybe it would be safe if you check for such definitions, using an include-file search ... but of course, that is more convenient after ftplugin/plaintex.vim has been :source'd. I'm not really fond of plain TeX, but I think it is not really widespread to \input slices of plain TeX. So the idea mentioned in this thread was to implement the policy: if a document starts with a lot of blanks followed by one of the possible LaTeX sectioning commands, then it is (probably) a LaTeX source file. What do you think of this policy? Of course the comment about plain TeX coming first still applies, but maybe you like this or have a better suggestion :-) Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!-
Re: better recognising of tex vs plaintex filetype
On Sat, Aug 26, 2006 at 08:42:39AM +0200, Giuseppe Bilotta wrote:
I don't think this is correct: these commands can be defined (and
therefore appear) in plain TeX documents too (defined by the document
writer), and they are defined by other TeX formats too (eplain and
AMS-TeX, for example). Moreover, LaTeX requires these to appear before
\begin{document}: in a LaTeX document there is some possibility of
them appearing before only within a definition or somesuch, in which
case \newcommand similia will appear before.
Good point.
Still, with the current situation, working with long latex document,
likely to be split in several files which are \included from a single
on, is annoying.
The reason being that the included files do not have a preamble, and the
recognition of 'tex' vs 'plaintex' is mainly based on stuff to appear in
preamble. Note that not recognizing files as 'tex' properly will inhibit
an important plugin as the vim latex suite to be loaded automatically.
Maybe is just a matter of changing the default to 'tex' then?
I tend to believe that the vast majority of documents in some \TeX
dialect authored these day are \LaTeX ones ...
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
Re: any git developper using gvimdiff ?
On Mon, Aug 21, 2006 at 04:07:21PM +0200, Christian MICHON wrote: I'm currently trying out git (linux scm) and I have not found yet how to perform a gvimdiff on a file locally modified with the latest commit. Maybe you can adapt this to your needs: http://vim.sourceforge.net/scripts/script.php?script_id=1209 -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!-
Re: invisible bar in help tags
On Fri, Apr 14, 2006 at 08:22:14AM +0200, Georg Dahn wrote: If the cursor is sometimes invisible in the default configuration, then this is indeed a problem which has to be solved. Since I don't have Debian, I cannot try to locate the problem myself. Does this problem occur in the latest gnome-terminal only? Has it worked with the previous version? Is there a change which could affect this? No, it happens even in a plain xterm, light background, when bg='light'. According to last Bram's mail this is probably something that colorscheme maintainers should fix. I will try to collect a list of the affected colorschemes and mail the maintainers about it. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!-
Re: invisible bar in help tags
On Thu, Apr 13, 2006 at 11:26:02PM +0200, Georg Dahn wrote: What you call 'totally lost' is only a minor problem compared to that, what 'totally lost' means in reality. Are you sure that you know, what it means to be totally lost? Let's distinguish: are you nitpicking about my word choice or actually stating that there's no problem at all? If you want me to change my word choice: ok, 'totally lost' was an exaggeration, but 'lost' it is not. If looking at a screen I could not discover where my cursor is, then I feel lost. It's an annoying absence of feedback. It's my belief that the cursor should always be visible on the screen. Then feel free to change your terminal settings and/or your cursor settings such that you can see your cursor everywhere. Other people don't seem to have that problem, so it might be a problem of your configuration and not a general one. Well, I'm playing with the vim Debian package I (co-)maintain and the problem is there with the latest gnome-terminal, dark background, bg=dark, default Debian configuration. Just to sure I just made some more test and the problem is there even with xterm, light background, bg=light, default Debian configuration. You can claim our default configuration is buggy, I would be happy to discover so and fix it. But I'm quite sure the problem will affect a lot of Debian user as soon as vim7 will be released and that I will receive a bug report about this. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!-
Re: vim 7.0d segfault while opening .vimrc in cwd
On Tue, Apr 11, 2006 at 08:00:39PM +0200, Bram Moolenaar wrote: I think this patch should fix it, please verify: The patch indeed fixed the problem. Thanks. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!-
