.xht and .xhtml file extensions for xhtml filetype detection
Hi, Is this possible to add .xht and .xhtml file extensions for xhtml filetype detection? Sylvain
Re: .xht and .xhtml file extensions for xhtml filetype detection
On Sun, 25 Feb 2007, Sylvain Bertrand wrote: Hi, Is this possible to add .xht and .xhtml file extensions for xhtml filetype detection? Yes, see :help new-filetype. I think this should be added to the Vim distribution, and often wonder how it got left out of Vim7. - Christian -- White dwarf seeks red giant for binary relationship. Christian J. Robinson [EMAIL PROTECTED] http://infynity.spodzone.com/ PGP keys: 0x893B0EAF / 0xFB698360 http://infynity.spodzone.com/pgp
Re: .xht and .xhtml file extensions for xhtml filetype detection
I did add support for those extensions manually in file in filetype.vim. I wonder the same thing than you. Maybe in the next patchset if we reach the top devs. Sylvain 2007/2/25, Christian J. Robinson [EMAIL PROTECTED]: On Sun, 25 Feb 2007, Sylvain Bertrand wrote: Hi, Is this possible to add .xht and .xhtml file extensions for xhtml filetype detection? Yes, see :help new-filetype. I think this should be added to the Vim distribution, and often wonder how it got left out of Vim7. - Christian -- White dwarf seeks red giant for binary relationship. Christian J. Robinson [EMAIL PROTECTED] http://infynity.spodzone.com/ PGP keys: 0x893B0EAF / 0xFB698360 http://infynity.spodzone.com/pgp
BUG: nested syntax regions and tranparent
G'day folks,
In the following sample string:
{pre{contained}post}
the right brace after contained is not highlighted when using these
syntax commands.
syn region foo1 matchgroup=foo2 start={ end=} contains=foo3
syn region foo3 start={ end=} transparent contained
hi def link foo1 Constant
hi def link foo2 Delimiter
Vim 6 seems to exhibit the correct behaviour.
Regards,
Doug
Re: Bug? in vimgrep with g flag and long lines.
Tony Mechelynck wrote: When cycling through matches using :cnext, if there are several matches in a single long line, the line is only shortened the first time (but _not_ the 2nd, 3rd, etc.,) to avoid a Hit-Enter prompt. Reproducible: every time. Steps to reproduce: 1. :set wrap I'm not sure this is necessary 2. :vimgrep /pattern/g filename where: - filename is a file or files with a number of lines longer than 'cmdheight' times 'columns' - /pattern/ will happen more than once in some long lines 3. :cn 4. Go to step 3. Notice that the first match in any given line never produces a Hit-enter prompt. Too-long lines have part of their non-matching text replaced by Actual result: 2nd, 3rd, etc. matches in any given line produces a Hit-enter prompt; the line is displayed in full, overflowing the command-line. Expected result: No hit-enter prompts. Additional info: I've been seeing this for as long as I've used :vimgrep (i.e., since shortly after that command was introduced) and I'm still seeing it in gvim 7.0.201. I just never came around to report it. (I didn't use the quickfix commands much before :vimgrep appeared, except for :helpgrep where lines are shorter than 80 characters.) This works as intended. It's a compromise between shortening the message, to avoid the press-enter prompt, and being able to see the whole message. The idea is that after jumping to a line with :cnext you can do :cc to see the whole message. It's implemented in a way that when displaying the same line twice the second time it displays the whole line. -- hundred-and-one symptoms of being an internet addict: 191. You rate eating establishments not by the quality of the food, but by the availability of electrical outlets for your PowerBook. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
RE: Win64-related patches
Michael Wookey wrote:
Michael Wookey wrote:
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim
- register', and watch it crash while trying to display an error
message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
-if (*p_vfile != NUL)
+if (p_vfile *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p (b = *p) != NUL)
{
if (b == c)
return p;
Well, that may fix it, but the problem is that the order of
initializations is violated. Normally all option pointers are not
NULL.
I think I've found it. In src/main.c:main(), the call to gui_prepare()
needs to occur after set_init_1() for two reasons:
1. set_init_1() ends up initialising the options table - and therefore
p_vfile.
2. The win32 implementation of gui_mch_prepare() as called from
gui_prepare() calls ole_error() in an error path. ole_error() calls
through to EMSG2() which eventually uses p_vfile. However since
gui_prepare() is called before set_init_1(), p_vfile has not yet been
initialised.
The attached patch demonstrates the solution by moving gui_prepare()
after set_init_1().
Changing the order of initializations is tricky. I would rather not do
this without extensive testing.
Isn't it much simpler to change ole_error() to invoke mch_errmsg()
instead of EMSG2()?
--
hundred-and-one symptoms of being an internet addict:
194. Your business cards contain your e-mail and home page address.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Regular expression warning E54 when saving arbitrary files (backslash-issue) including FIX
Basti Grembowietz wrote:
Hi vim-developers!
I have a small bug-report with including fix.
WHAT:
On my home PC the saving of a file always raised two E54 warnings.
Yesterday this was annoying to much (having to press some key before
working on normally, so I investigated a bit. And fixed it =) Open
source is nice.
It showed up that my chosen username in Windows XP was the cause of
these warnings - it is (rax). This implies that my temporary
directory is located at C:\DOKUME~1\(rax)\LOKALE~1\Temp\. And that
was the reason for these E54 warnings.
E54 means unmatched bracket (. Usually backslashes will be
replaced by [\/] when they are allowed as means to describe paths.
WHERE IT HAPPENS IN THE SOURCE:
While saving, there are some paths added (for a purpose I do not see /
but also do not need in this context):
fileio.c!buf_write():
3238 #ifdef FEAT_WILDIGN
3239if (dobackup *p_bsk != NUL match_file_list(p_bsk, sfname,
ffname))
3240 dobackup = FALSE;
3241 #endif
p_bsk was set to
C:\DOKUME~1\(rax)\LOKALE~1\Temp\*,C:\DOKUME~1\(rax)\LOKALE~1\Temp\*
This goes then to fileio.c!match_file_list(), then to
fileio.c!file_pat_to_reg_pat() - and there is the bug.
WANTED BEHAVIOUR:
file_pat_to_reg_pat should convert
C:\DOKUME~1\(rax)\LOKALE~1\Temp\ to
^C:[\/]DOKUME\~1[\/](rax)[\/]LOKALE\~1[\/]Temp[\/]
CURRENT BEHAVIOUR:
file_pat_to_reg_pat converts
C:\DOKUME~1\(rax)\LOKALE~1\Temp\ to
^C:[\/]DOKUME\~1\(rax)[\/]LOKALE\~1[\/]Temp[\/]
THE FIX
change
fileio.cpp!file_pat_to_reg_pat()
9368 if ((vim_isfilec(p[1]) || p[1] == '*' || p[1] == '?' )
9369 p[1] != '+')
to this:
fileio.cpp!file_pat_to_reg_pat()
9368 if ((vim_isfilec(p[1]) || p[1] == '*' || p[1] == '?' || p[1] ==
'(' )
9369 p[1] != '+')
I'm glad you managed to figure out the problem and suggest a patch.
However, I think this is the wrong place to fix it. The \( in
'backupskip' must be seen as a special item in the pattern, after all it
is a list of patterns and \( is a regexp item.
We better make sure that when there are special things in $TEMP they are
escaped when put in 'backupskip'. So that $TEMP is taken literally.
That is in set_init_1(), around line 3000. Perhaps you can make a patch
for that?
NOTES
Maybe this behaviour can also be fixed for ')' as first character of a
directory, as it will raise the same behaviour in VIM.
As I am new to vim-dev, who usually submits this to the repository? Can
anyone make a cvs/svn/whateveryouuse-account?
You can send patches to me.
--
What is the difference between a professional and an amateur?
The ark was built by an amateur; professionals gave us the Titanic.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: gvim, Windows NAS share of a unix file system, hard links
Nathan Coulter wrote: bug report == version: VIM - Vi IMproved 7.0 (2006 May 7, compiled May 7 2006 16:23:43) MS-Windows 32 bit GUI version with OLE support problem: Writing to a file on a windows share where the underlying filesystem supports hard links, modifying a file using gvim (w command) causes the file to acquire a new inode. Contrast with the behavior of notepad.exe (file - save), which respects the hard link, keeping the inode intact. What is the 'backupcopy' option set to? It should be auto, then Vim should be able to recognize hard links on NTFS filesystems. -- A computer program does what you tell it to do, not what you want it to do. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: BUG: nested syntax regions and tranparent
Doug Kearns wrote:
In the following sample string:
{pre{contained}post}
the right brace after contained is not highlighted when using these
syntax commands.
syn region foo1 matchgroup=foo2 start={ end=} contains=foo3
syn region foo3 start={ end=} transparent contained
hi def link foo1 Constant
hi def link foo2 Delimiter
Vim 6 seems to exhibit the correct behaviour.
I can reproduce it. One more for the todo list...
--
% cat /usr/include/sys/errno.h
#define EPERM 1 /* Operation not permitted */
#define ENOENT 2 /* No such file or directory */
#define ESRCH 3 /* No such process */
[...]
#define EMACS 666 /* Too many macros */
%
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: .xht and .xhtml file extensions for xhtml filetype detection
Christian J. Robinson wrote: On Sun, 25 Feb 2007, Sylvain Bertrand wrote: Hi, Is this possible to add .xht and .xhtml file extensions for xhtml filetype detection? Yes, see :help new-filetype. I think this should be added to the Vim distribution, and often wonder how it got left out of Vim7. Apparently nobody noticed them. Are *.xht and *.xhtml widely used for XHTML? -- Some of the well know MS-Windows errors: ESLEEP Operator fell asleep ENOERR No error yet EDOLLAR OS too expensive EWINDOWSMS-Windows loaded, system in danger /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: .xht and .xhtml file extensions for xhtml filetype detection
On 2/25/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Christian J. Robinson wrote: On Sun, 25 Feb 2007, Sylvain Bertrand wrote: Hi, Is this possible to add .xht and .xhtml file extensions for xhtml filetype detection? Yes, see :help new-filetype. I think this should be added to the Vim distribution, and often wonder how it got left out of Vim7. Apparently nobody noticed them. Are *.xht and *.xhtml widely used for XHTML? I have never seen either. .xht is perhaps even more of an abomination than .htm is/was. nikolai
Re: .xht and .xhtml file extensions for xhtml filetype detection
Hi, For infos: If I open file.html (with xhtml content) using firefox 2.0.0.2, the document will have the text/html mime type which is wrong following the guidelines of the following document: http://www.w3.org/TR/xhtml-media-types/ If I open file.xhtml, the document will have the text/xhtml+xml mime type. The latter w3c document reference an ietf document dealing with the text/xhtml+xml mime type in which there is a section specific to file extensions. There, you will find those .xht and .xhtml file extensions defined: http://www.rfc-editor.org/rfc/rfc3236.txt I could also use the .xml extension with xhtml content. Firefox will give the text/xml mime type to the document. But vim will load all its xml candies leaving out the xhtml ones. Sylvain 2007/2/25, Nikolai Weibull [EMAIL PROTECTED]: On 2/25/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Christian J. Robinson wrote: On Sun, 25 Feb 2007, Sylvain Bertrand wrote: Hi, Is this possible to add .xht and .xhtml file extensions for xhtml filetype detection? Yes, see :help new-filetype. I think this should be added to the Vim distribution, and often wonder how it got left out of Vim7. Apparently nobody noticed them. Are *.xht and *.xhtml widely used for XHTML? I have never seen either. .xht is perhaps even more of an abomination than .htm is/was. nikolai
Re: .xht and .xhtml file extensions for xhtml filetype detection
Dnia poniedziałek 26 luty 2007, Bram Moolenaar napisał: Apparently nobody noticed them. Are *.xht and *.xhtml widely used for XHTML? Spotted .xhtml several times, never saw .xht . m.
