|
On 2012-05-26, Gary Johnson wrote:
> On 2012-05-25, Chris Jones wrote: > > > There are things I find a little unclear regarding autocommands but > > assuming the file extension is something like ‘*.mkdwn’ shouldn't it be > > possible to achieve this automatically when creating the file by placing > > something like this in a file named ~/.vim/ftdetect/markdown.vim: > > > > | autocmd BufNewFile,BufRead *.mkdwn set filetype=markdown > > > > Wouldn't this cause ‘:w myfile.mkdwn’ to automatically enable the > > markdown foldexpr and create the folds in one pass? > > No. ... Never mind. It should. Regards, Gary -- You received this message from the "vim_use" 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 |
|
In reply to this post by Chris Jones-44
On May 26, 2012, at 6:32 PM, Chris Jones wrote: > >> On Sat, May 26, 2012 at 06:47:59AM EDT, Eric Weir wrote: >> >> I don't know when it became effective, but my understanding is that >> markdown support is built into Vim. > > I ran a quick test on a freshly-installed Vim 7.3 and highlighting > worked out of the box with a 20-line markdown sample I grabbed online. > > With Vim 7.3, $VIMRUNTIME/filetype.vim has the following lines: > > | " Markdown > | au BufNewFile,BufRead *.markdown,*.mdown,*.mkd,*.mkdn,README.md setf markdown > > As soon as I issued a ‘:w /tmp/sample.mdown’ to write the [No Name] > buffer to disk , the markdown was highlighted. Thanks, Chris. I did same with an ".mkd" extent and got the same result. I'm embarrassed to say this, but I think all this "sturm und drang" is going to turn out to have been occasioned by the fact that I mistakenly believed that ".md" was a markdown extent. > I would avoid ‘*.mmd’ & ‘*.md’ (not in the above list). Worse, per > filetype.vim, ‘*.md’ is something else: a modula2 file extension. No problem with ".md", but ".mmd" is the extent used by multimarkdown, an extension of markdown that adds some additional features, e.g., footnotes. It is used by Scrivener to convert Scrivener documents to LaTeX. Without the ".mmd" extent multimarkdown will not compile the file. > I proceeded to copy the folding script to ~/.vim/after/ftplugin/ under > ‘markdown.vim’ and ran the same test. Sure enough, immediately after > I wrote the buffer to disk (:w /tmp/sample2.mdown) my 20 lines became > one single big fold. Again, same result. > Please remove... The ‘au...’ command above does the same thing. But the > fact that in your case, highlighting does not work on file creation is > interesting. As if Vim was never notified of the BufNewFile event.. Will do. > Immediately after you create the file you could check that the folding > script is loaded : run ‘:scriptnames’ and look for a line that says > ~/.vim/after/ftplugin/markdown.vim (or the MacVim equivalent). > > You need to do this on a dedicated Vim session.. start Vim on an empty > buffer, enter some markdown, save the file, and run :scriptnames.. If > the folding script isn't even loaded, folding is not going to work. Safe to assume the script is loaded since I'm getting folding on recognized markdown files? > Then run ’:verbose set ft’ and ‘:verbose set syntax’ to see if they are > set to ‘markdown’ and then ‘:verbose set fdm’.. should say ‘expr’. All results are positive. I think this solves the problem. My apologies to everyone who was scratching their heads on this one when all along it was a stupid mistaken assumption on my part. Not that it wasn't educational, though. So also thanks for that. I owe responses to several others here, but at this point will get to that tomorrow. Sincerely, ------------------------------------------------------------------------------------------ Eric Weir Decatur, GA [hidden email] "Style is truth." - Ray Bradbury -- You received this message from the "vim_use" 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 |
|
In reply to this post by scott-268
On May 26, 2012, at 11:44 AM, sc wrote: >> On Sat, May 26, 2012 at 05:54:32AM -0400, Eric Weir wrote: >> >> [Is that a shortened version of the command you suggest?] > > no, :e is shorthand for :edit, which reloads the buffer and triggers > filetype detection along the way > > the bad news is you've just implied you don't know how to use vim's > extensive help system (or maybe you're intimidated by it?) > > :h :e > > would have answered that for you -- i recommend spending some time > familiarizing yourself with the help system -- learn about helpgrep, > and try it out with > > :helpgrep filetype detection > > there are about 24 hits on that specific string, and will take you to > many interesting places in Help as you :cn your way through them Thanks, sc. I do know how to use it---sorta. I know how to call up the files and navigate around in them. The problem is that I don't understand most of what's explained when I seek help from it. I don't avoid it. I often do check before asking for help. [Don't think I did so this time.] But usually end up having to ask for help anywat. On the other hand, I find the FAQs very helpful. That said, I will do as you suggest---after check the help on "help" versus "helpgrep." Sincerely, ------------------------------------------------------------------------------------------ Eric Weir Decatur, GA USA [hidden email] "Imagining the other is a powerful antidote to fanaticism and hatred." - Amos Oz -- You received this message from the "vim_use" 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 |
|
In reply to this post by Gary Johnson-4
On Sat, May 26, 2012 at 03:50:24PM EDT, Gary Johnson wrote:
> On 2012-05-25, Chris Jones wrote: > > > There are things I find a little unclear regarding autocommands but > > assuming the file extension is something like ‘*.mkdwn’ shouldn't it be > > possible to achieve this automatically when creating the file by placing > > something like this in a file named ~/.vim/ftdetect/markdown.vim: > > > > | autocmd BufNewFile,BufRead *.mkdwn set filetype=markdown > > > > Wouldn't this cause ‘:w myfile.mkdwn’ to automatically enable the > > markdown foldexpr and create the folds in one pass? > > No. BufNewFile will set the filetype to markdown when starting to > edit a new file with a name ending in .mkdwn; That's also how I understood it, yet.. I tested with a markdown file and BufNewFile and BufRead were the only two events defined to Vim. Non-customized Vim 7.3, no plugins, etc. This is what I see in filetype.vim: " Markdown au BufNewFile,BufRead *.markdown,*.mdown,*.mkd,*.mkdn,README.md setf markdown I started a Vim session by typing ‘vim’ at the prompt and I entered some markdown in the [No Name] buffer. At this point ‘set ft?’ said ‘filetype=’.. Now as soon as I had written the file to disk as ‘sample.mdown’ or .mkd.. .mkdn.. etc., ft was correctly set: ‘filetype=markdown’. so is it the BufNewFile or the BufRead event that causes the filetype to be set? Between the two, I would tend to think it is BufNewFile, not because the file is written to disk, but rather because the Vim buffer now has a name. I don't know if is meant to work this way (the doc would appear to suggest otherwise) but I suspect that the BufNewFile event is also triggered when you issue a ‘:w’ command against a scratch buffer. [Mind you, this is linux, not MacVim though I don't see why it would make any difference since this appears to be an event that is purely internal to Vim.] Anyway, this is what I understood the OP was doing: creating a scratch buffer, entering code, and saving the file via a ‘:w xxxxx.markdown’ command. But where I do agree, is that if it is acceptable for the OP to create his files by giving them a ‘xxxxx.markdown’ file name on the initial ‘:new’ (:vne.. :tabe.. etc.) command he will have the benefit of immediately having the Vim ‘filetype’ option automatically set and both syntax highlighting and automatic folding will be available as long as there exist corresponding definitions (syntax file with or without syntax folding, folding script.. etc.). In other words, as soon as he starts typing, keywords, headings, etc. will be recognized and highlighted accordingly. This obviously cannot happen as long as you are entering your code in a [No Name], (ft=) buffer. But I don't see how this is going to solve his problem if the BufNewFile event is not triggered in the first place. > BufRead will set it when opening an existing file whose name ends with > .mkdwn. To have ":w myfile.mkdwn" set the filetype, you would need to > use the BufWrite autocommand event. That's not normally done because > one usually wants any setting dependent on the file type executed when > starting to edit the file, not when the editing is finished. I didn't go into into it but that was my point: it is not ‘normally’ done and yet what the OP reports as not working does work everywhere else for similarly defined file types (if you look at filetype.vim). > The ways I usually set the filetype on new files is to open them by > name > > $ vim foo.c What I don't like all that much about this approach is that on a multi-user system especially, and since the file is not actually created in the file system, a file with the same name might be created before you actually write foo.c to disk. And then you get one of those confusing messages... > or > > :split foo.c > > or if I'm already in an empty buffer or the file doesn't have an > extension (e.g., a shell script), by executing > > :set ft=c I just did a quick test with ‘:tabe’ (no file name), obviously the filetype was ''. I entered some vimscript & as soon as I wrote the file under f.vim, syntax highlighting came on. To _Eric W._ What happens when you do as Gary suggests: start Vim via a ‘vim newfile.mkd’..? CJ -- AHH! The neurotic monkeys are after me! -- You received this message from the "vim_use" 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 |
|
In reply to this post by Eric Weir
On Sat, May 26, 2012 at 08:38:28PM EDT, Eric Weir wrote:
> > On May 26, 2012, at 6:32 PM, Chris Jones wrote: [..] > > As soon as I issued a ‘:w /tmp/sample.mdown’ to write the [No Name] > > buffer to disk , the markdown was highlighted. > Thanks, Chris. I did same with an ".mkd" extent and got the same > result. I'm embarrassed to say this, but I think all this "sturm und > drang" is going to turn out to have been occasioned by the fact that > I mistakenly believed that ".md" was a markdown extent. Not to worry.. That's one area of Vim I don't understand very well.. An opportunity to learn something.. > > I would avoid ‘*.mmd’ & ‘*.md’ (not in the above list). Worse, per > > filetype.vim, ‘*.md’ is something else: a modula2 file extension. > No problem with ".md", but ".mmd" is the extent used by multimarkdown, > an extension of markdown that adds some additional features, e.g., > footnotes. It is used by Scrivener to convert Scrivener documents to > LaTeX. Without the ".mmd" extent multimarkdown will not compile the > file. Ah, for syntax highlighting and presumably folding to work, you would need to create a custom autocommand (same as the one in filetype.vim) for this file extension to be recognized and stick it either in your .vimrc or possibly in your ftplugin/ or your after/ftplugin directory (untested). [..] > Safe to assume the script is loaded since I'm getting folding on > recognized markdown files? Absolutely. > > Then run ’:verbose set ft’ and ‘:verbose set syntax’ to see if they > > are set to ‘markdown’ and then ‘:verbose set fdm’.. should say > > ‘expr’. > > All results are positive. > > I think this solves the problem. My apologies to everyone who was > scratching their heads on this one when all along it was a stupid > mistaken assumption on my part. Where I'm concerned, no need to apologize.. thanks for the workout.. ;-) > Not that it wasn't educational, though. So also thanks for that. Talking of educational.. in reference to what you wrote elsewhere regarding Vim help, I thought I might mention that there are two distinct parts to Vim's help: the ‘user manual’ and the ‘reference manual’. Maybe the following illustrates the difference between the two: | :h cpo | :h user-manual The user manual provides structured overviews of pretty much every area of Vim without going into too much detail. Studying at my own pace, one chapter at a time helped find my bearings. Mind you, I mean studying.. not printing it and just reading through it.. splitting the screen and practising in a scratch buffer until you really know what's there. The good thing is there are links to the reference manual whenever you feel like digging.. Once you've worked through that, you will be able to find what you're looking for in the reference manual much more easily and what you find there will make better sense. CJ -- Mooo Canada!!!! -- You received this message from the "vim_use" 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 |
|
In reply to this post by Chris Jones-44
On May 26, 2012, at 9:32 PM, Chris Jones wrote: > To _Eric W._ > > What happens when you do as Gary suggests: start Vim via a ‘vim > newfile.mkd’..? I have never started vim from terminal. [Or, I believe, as you guys say, from "console."] Gary had other suggestions, though, e.g., setting filetype on an empty screen. When I do that markdown header highlighting and folding are recognized immediately. ------------------------------------------------------------------------------------------ Eric Weir 1111 Clairemont Avenue J3 ~ Decatur, GA 30030 404-636-6142 ~ [hidden email] -- You received this message from the "vim_use" 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 |
|
In reply to this post by Eric Weir
On May 26, 2012, at 8:44 PM, Eric Weir wrote: > >> On May 26, 2012, at 11:44 AM, sc wrote: >> >> the bad news is you've just implied you don't know how to use vim's >> extensive help system (or maybe you're intimidated by it?) >> >> :h :e >> >> would have answered that for you -- i recommend spending some time >> familiarizing yourself with the help system -- learn about helpgrep, >> and try it out with >> >> :helpgrep filetype detection >> >> there are about 24 hits on that specific string, and will take you to >> many interesting places in Help as you :cn your way through them > > Thanks, sc. I do know how to use it---sorta. I know how to call up the files and navigate around in them. The problem is that I don't understand most of what's explained when I seek help from it. I don't avoid it. I often do check before asking for help. [Don't think I did so this time.] But usually end up having to ask for help anywat. On the other hand, I find the FAQs very helpful. > > That said, I will do as you suggest---after check the help on "help" versus "helpgrep." Ok, I think I know the difference between help and helpgrep. Help takes you to [the first?] item tagged with the string entered with the command. Helpgrep makes a list of all instances in which the string occurs. [Suspect that's not quite right, but it's what I've taken from what I read.] The problem for me with the latter is that the instances seem to go on interminably, with no clear demarcation---at least that's evident to me---between the list of instances of the string and other help topics. But the initial instances are clear and I will study them. ------------------------------------------------------------------------------------------ Eric Weir 1111 Clairemont Avenue J3 ~ Decatur, GA 30030 404-636-6142 ~ [hidden email] -- You received this message from the "vim_use" 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 |
|
In reply to this post by Eric Weir
On 2012-05-22 15:14, Eric Weir wrote:
> Turns out I'm using Vlad Irnov's markdown folding script.https://gist.github.com/1035030 I'd completely forgotten about it, but it is what takes care of it for me. Try out Voom, which has a markdown mode <http://www.vim.org/scripts/script.php?script_id=2657> I never thought I'd like a two-pane outliner (and one written in Python too -- no offense but I came across Perl first! :-) but I use it all the time now. I use pandoc. <http://johnmacfarlane.net/pandoc/index.html> There's an excellent Vim plugin for its markdown dialect: <http://github.com/vim-pandoc/vim-pandoc> /bpj -- You received this message from the "vim_use" 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 |
|
In reply to this post by Chris Jones-44
On May 26, 2012, at 11:11 PM, Chris Jones wrote: > Talking of educational.. in reference to what you wrote elsewhere > regarding Vim help, I thought I might mention that there are two > distinct parts to Vim's help: the ‘user manual’ and the ‘reference > manual’. > > Maybe the following illustrates the difference between the two: > > | :h cpo > | :h user-manual > > The user manual provides structured overviews of pretty much every area > of Vim without going into too much detail. Studying at my own pace, one > chapter at a time helped find my bearings. Mind you, I mean studying.. > not printing it and just reading through it.. splitting the screen and > practising in a scratch buffer until you really know what's there. The > good thing is there are links to the reference manual whenever you feel > like digging.. > > Once you've worked through that, you will be able to find what you're > looking for in the reference manual much more easily and what you find > there will make better sense. Thanks, Chris. I was going to say I had no idea there was a user-manual---until I took a look at the pdf version. In fact, I had a hard copy of the book, but got rid of it because I couldn't understand it. I went looking for it but found that, alas, I have indeed gotten rid of it. May have get myself another copy. The pdf is too maddening to navigate around in. I take to heart what you say about studying, not just reading through. At this point I have a hard time imagining myself doing this with the entire thing, all at once. I can certainly imagine doing that with the chapters and sections that cover my current level of skill and introduce me to some new useful skills. And returning to it periodically to get myself onto a new level. Regards, ------------------------------------------------------------------------------------------ Eric Weir Program and Resource Development ~ Evaluation ~ Writing Education ~ The Environment ~ Community Development 1111 Clairemont Avenue J3 ~ Decatur, GA 30030 404-636-6142 ~ [hidden email] -- You received this message from the "vim_use" 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 |
|
In reply to this post by BPJ
On May 27, 2012, at 11:41 AM, BPJ wrote: > On 2012-05-22 15:14, Eric Weir wrote: >> Turns out I'm using Vlad Irnov's markdown folding script.https://gist.github.com/1035030 I'd completely forgotten about it, but it is what takes care of it for me. > > Try out Voom, which has a markdown mode > > <http://www.vim.org/scripts/script.php?script_id=2657> > > I never thought I'd like a two-pane outliner (and one > written in Python too -- no offense but I came across > Perl first! :-) but I use it all the time now. Thanks, BJP. I had it installed for a while, but didn't fully appreciate it's utility. I'm a committed vimwiki user, and another user recently recommended it to the user group. Currently I'm trying to figure out how to get vim-addon-manager to install it. [I want to rely on vam for managing my plugins.] > I use pandoc. <http://johnmacfarlane.net/pandoc/index.html> > There's an excellent Vim plugin for its markdown dialect: > > <http://github.com/vim-pandoc/vim-pandoc> I'm intrigued by pandoc. My reason for going with straight markdown at the moment is that I use Scrivener for larger writing projects and Scrivener relies on multimarkdown, and extension of markdown, to convert Scrivener documents to LaTGeX. ------------------------------------------------------------------------------------------ Eric Weir [hidden email] "Any assurance economists pretend to with regard to cause and effect is merely a pose." - Emanuel Derman -- You received this message from the "vim_use" 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 |
|
On Sun, May 27, 2012 at 8:10 AM, Eric Weir <[hidden email]> wrote:
> > > I'm intrigued by pandoc. My reason for going with straight markdown at the moment is that I use Scrivener for larger writing projects and Scrivener relies on multimarkdown, and extension of markdown, to convert Scrivener documents to LaTGeX. > The beauty of the Pandoc plugin (and the Pandoc converter) is that you can use it and still use only markdown or multimarkdown as your markup, but it gives you a bunch of additional features anyway. I work pretty much only in Markdown, but Pandoc plugin is a godsend. And if my needs go past what Markdown can do, I just keep using Pandoc and use features it supports beyond the Markdown syntax... c -- Chris Lott <[hidden email]> -- You received this message from the "vim_use" 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 |
|
In reply to this post by Eric Weir
On 2012-05-27 18:10, Eric Weir wrote:
>> Try out Voom, which has a markdown mode >> > >> > <http://www.vim.org/scripts/script.php?script_id=2657> >> > >> > I never thought I'd like a two-pane outliner (and one >> > written in Python too -- no offense but I came across >> > Perl first! :-) but I use it all the time now. > Thanks, BJP. I had it installed for a while, but didn't fully appreciate it's utility. > I'm a committed vimwiki user, and another user recently recommended it to the user group. > Currently I'm trying to figure out how to get vim-addon-manager to install it. > [I want to rely on vam for managing my plugins.] > I use pathogen and had no trouble installing anything so far. The good thing with pandoc is that its markdown is a superset of vanilla markdown, and it has a strict option to disable extended syntax. /bpj -- You received this message from the "vim_use" 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 |
|
In reply to this post by Chris Lott
On 2012-05-27 19:46, Chris Lott wrote:
> The beauty of the Pandoc plugin (and the Pandoc converter) is that you > can use it and still use only markdown or multimarkdown as your > markup, AFAIK pandoc does not yet support multimarkdown table syntax, but making it do so has been up on the pandoc discussion list and the developer, who is usually very responsive to reasonable user suggestions, was at least somewhat favorable, so I think it's going to be supported eventually. I've tried to write vim syntax highlighting which handles pandoc's table syntax and does not conflict with setext style headers, with slim success so far, mostly due to my inability to take in :h syntax effectively... /bpj -- You received this message from the "vim_use" 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 |
|
In reply to this post by Chris Jones-44
On 2012-05-26, Chris Jones wrote:
> On Sat, May 26, 2012 at 03:50:24PM EDT, Gary Johnson wrote: > > On 2012-05-25, Chris Jones wrote: > > > > > There are things I find a little unclear regarding autocommands but > > > assuming the file extension is something like ‘*.mkdwn’ shouldn't it be > > > possible to achieve this automatically when creating the file by placing > > > something like this in a file named ~/.vim/ftdetect/markdown.vim: > > > > > > | autocmd BufNewFile,BufRead *.mkdwn set filetype=markdown > > > > > > Wouldn't this cause ‘:w myfile.mkdwn’ to automatically enable the > > > markdown foldexpr and create the folds in one pass? > > > > No. BufNewFile will set the filetype to markdown when starting to > > edit a new file with a name ending in .mkdwn; > > That's also how I understood it, yet.. > > I tested with a markdown file and BufNewFile and BufRead were the only > two events defined to Vim. Non-customized Vim 7.3, no plugins, etc. > > This is what I see in filetype.vim: > > " Markdown > au BufNewFile,BufRead *.markdown,*.mdown,*.mkd,*.mkdn,README.md setf markdown > > I started a Vim session by typing ‘vim’ at the prompt and I entered some > markdown in the [No Name] buffer. > > At this point ‘set ft?’ said ‘filetype=’.. > > Now as soon as I had written the file to disk as ‘sample.mdown’ or > .mkd.. .mkdn.. etc., ft was correctly set: ‘filetype=markdown’. > > so is it the BufNewFile or the BufRead event that causes the filetype to > be set? Between the two, I would tend to think it is BufNewFile, not > because the file is written to disk, but rather because the Vim buffer > now has a name. > > I don't know if is meant to work this way (the doc would appear to > suggest otherwise) but I suspect that the BufNewFile event is also > triggered when you issue a ‘:w’ command against a scratch buffer. I don't know what to make of this at this point. After discovering that I was wrong in my understanding of what happens when you :write and unnamed buffer to a file, and after reading your posts, I did some experimenting, too. I started vim and enabled syntax highlighting and filetype detection, $ vim -N -u NONE :syntax enable entered a bit of markdown text into the buffer, then executed :set verbosefile=verbose.out :set verbose=9 and wrote the file: :w myfile.markdown As soon as I did that, the markdown headers in the buffer became highlighted, as we've seen before. Then I quit vim, :set verbose=0 :q and opened the verbose.out file. Here are the first 23 lines from that file. -------------------------------------------------------------------- chdir(/home/gary) fchdir() to previous dir chdir(/home/gary) fchdir() to previous dir Executing BufRead Auto commands for "*.markdown" autocommand setf markdown Executing FileType Auto commands for "*" autocommand exe "set syntax=" . expand("<amatch>") Executing Syntax Auto commands for "*" autocommand call s:SynSet() Searching for "syntax/markdown.vim syntax/markdown/*.vim" in "/home/gary/.vim,/usr/local/share/vim/vimfiles,/usr/local/share/vim/vim73,/usr/local/share/vim/vimfiles/after,/home/gary/.vim/after" Searching for "/home/gary/.vim/syntax/markdown.vim" Searching for "/home/gary/.vim/syntax/markdown/*.vim" Searching for "/usr/local/share/vim/vimfiles/syntax/markdown.vim" Searching for "/usr/local/share/vim/vimfiles/syntax/markdown/*.vim" Searching for "/usr/local/share/vim/vim73/syntax/markdown.vim" chdir(/usr/local/share/vim/vim73/syntax) ... -------------------------------------------------------------------- It appears that filetype detection was triggered by the BufRead autocommand! Why on Earth would the BufRead autocommand be triggered by a :write? I searched the source code and found the following in the do_write() function in ex_cmds.c: /* If 'filetype' was empty try detecting it now. */ if (*curbuf->b_p_ft == NUL) { if (au_has_group((char_u *)"filetypedetect")) (void)do_doautocmd((char_u *)"filetypedetect BufRead", TRUE); do_modelines(0); } So not all BufRead autocommands are triggered by a :write; only those in the filetypedetect group. That behavior still seems strange, but now we know. Regards, Gary -- You received this message from the "vim_use" 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 |
|
In reply to this post by Eric Weir
On Sun, May 27, 2012 at 11:59:36AM EDT, Eric Weir wrote:
> Thanks, Chris. I was going to say I had no idea there was > a user-manual---until I took a look at the pdf version. In fact, I had > a hard copy of the book, but got rid of it because I couldn't > understand it. I went looking for it but found that, alas, I have > indeed gotten rid of it. May have get myself another copy. The pdf is > too maddening to navigate around in. Ah, see.. you didn't even know it was there.. but not to worry, I used Vim for 2-3 years before I ran into it.. by accident. :-) The pdf version.. or worse a hard copy of the Vim help are IMHO useless because the Vim help was never meant to be read as a book in the first place.. for one thing, as you justly remarked.. you cannot navigate it.. I was not suggesting you sit down and read the entire user manual over a period of 10+ hours.. I set myself a fairly loose schedule.. like week one chapter one, etc. opened a tab and split the screen vertically with the manual displayed on the left and a playground scratch buffer on the right, read a couple of paragraphs.. practised what I read in the scratch buffer as well as the Vim command line.. tried to be creative or just curious and explored other possibilities.. followed some of the links to the reference manual.. googgled for answers when something was not entirely clear or I felt I could do with a second opinion.. etc. > I take to heart what you say about studying, not just reading through. > At this point I have a hard time imagining myself doing this with the > entire thing, all at once. I can certainly imagine doing that with the > chapters and sections that cover my current level of skill and > introduce me to some new useful skills. And returning to it > periodically to get myself onto a new level. Not all at once.. for me at least.. it's been a slow process. CJ -- AHH! The neurotic monkeys are after me! -- You received this message from the "vim_use" 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 |
|
In reply to this post by Gary Johnson-4
On Sun, May 27, 2012 at 04:10:43PM EDT, Gary Johnson wrote:
> On 2012-05-26, Chris Jones wrote: [..] > > so is it the BufNewFile or the BufRead event that causes the > > filetype to be set? Between the two, I would tend to think it is > > BufNewFile, not because the file is written to disk, but rather > > because the Vim buffer now has a name. > > > > I don't know if is meant to work this way (the doc would appear to > > suggest otherwise) but I suspect that the BufNewFile event is also > > triggered when you issue a ‘:w’ command against a scratch buffer. > I don't know what to make of this at this point. After discovering > that I was wrong in my understanding of what happens when you :write > and unnamed buffer to a file, and after reading your posts, I did > some experimenting, too. > > I started vim and enabled syntax highlighting and filetype detection, > > $ vim -N -u NONE > :syntax enable > > entered a bit of markdown text into the buffer, then executed > > :set verbosefile=verbose.out > :set verbose=9 [..] > and opened the verbose.out file. Here are the first 23 lines from > that file. [..] > | Executing BufRead Auto commands for "*.markdown" > | autocommand setf markdown [..] > It appears that filetype detection was triggered by the BufRead > autocommand! Why on Earth would the BufRead autocommand be triggered > by a :write? Surprise.. surprise.. :-) > I searched the source code and found the following in the do_write() > function in ex_cmds.c: > > | /* If 'filetype' was empty try detecting it now. */ > | if (*curbuf->b_p_ft == NUL) > | { > | if (au_has_group((char_u *)"filetypedetect")) > | (void)do_doautocmd((char_u *)"filetypedetect BufRead", > | TRUE); > | do_modelines(0); > | } > > So not all BufRead autocommands are triggered by a :write; only > those in the filetypedetect group. > > That behavior still seems strange, but now we know. Not all that much. I suspected BufNewFile, and I guessed wrong. It looks like the telltale bit in the name of these events is the ‘Buf’ prefix. It's really all about Vim's internal management of buffers, more than about the actual writing or loading of the file. And Vim does what's more convenient... from the point of view of Vim. In any case, thanks much for figuring this out and providing details re: verbose/verbosefile. Made a good note of this technique for future use. CJ -- WHAT YOU SAY?? -- You received this message from the "vim_use" 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 |
|
In reply to this post by Chris Jones-44
On May 27, 2012, at 7:45 PM, Chris Jones wrote: > Not all at once.. for me at least.. it's been a slow process., Thanks, Chris. I can go with what you describe, though I would probably go more slowly than you. Likewise with splitting the screen having the user manual in one window, trying things out in the other. I do wish now that I hadn't gotten rid of my hard copy. [I think I gave it to the Salvation Army!] I'd be interested in your opinion---or that of any others here--of "Hacking Vim 7.2" recommended here <http://iccf-holland.org/click5.html. FYI, I've been using vim about one year now. I don't code, though I can sometimes figure out how to tweak existing code to get a plugin to work or to get vim to work the way I want. [I stress "sometime."] Regards, ------------------------------------------------------------------------------------------ Eric Weir Decatur, GA USA [hidden email] "Hatred destroys. Love heals." - Eknath Easwaran -- You received this message from the "vim_use" 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 |
|
In reply to this post by BPJ
On May 27, 2012, at 2:45 PM, BPJ wrote: > On 2012-05-27 18:10, Eric Weir wrote: >>> Try out Voom, which has a markdown mode >>> > >>> > <http://www.vim.org/scripts/script.php?script_id=2657> >>> > >>> > I never thought I'd like a two-pane outliner (and one >>> > written in Python too -- no offense but I came across >>> > Perl first! :-) but I use it all the time now. >> Thanks, BJP. I had it installed for a while, but didn't fully appreciate it's utility. > > I'm a committed vimwiki user, and another user recently recommended it to the user group. > > Currently I'm trying to figure out how to get vim-addon-manager to install it. > > [I want to rely on vam for managing my plugins.] >> > > I use pathogen and had no trouble installing anything so far. Today I tried installing Voom using Vim-Addons-Manager again today, BPJ. This time the install went through without a hitch. Now I need start learning how to use it. [From a skim of the manual it looks sophisticated enough to merit a user group. Maybe there is one.] More later, ------------------------------------------------------------------------------------------ Eric Weir Decatur, GA USA [hidden email] "Imagining the other is a powerful antidote to fanaticism and hatred." - Amos Oz -- You received this message from the "vim_use" 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 |
|
In reply to this post by Eric Weir
On May 27, 2012, at 11:59 AM, Eric Weir wrote: > On May 26, 2012, at 11:11 PM, Chris Jones wrote: > >> Talking of educational.. in reference to what you wrote elsewhere >> regarding Vim help, I thought I might mention that there are two >> distinct parts to Vim's help: the ‘user manual’ and the ‘reference >> manual’. >> >> Maybe the following illustrates the difference between the two: >> >> | :h cpo >> | :h user-manual >> >> The user manual provides structured overviews of pretty much every area >> of Vim without going into too much detail. Studying at my own pace, one >> chapter at a time helped find my bearings. Mind you, I mean studying.. >> not printing it and just reading through it.. splitting the screen and >> practising in a scratch buffer until you really know what's there. The >> good thing is there are links to the reference manual whenever you feel >> like digging.. >> >> Once you've worked through that, you will be able to find what you're >> looking for in the reference manual much more easily and what you find >> there will make better sense. > > Thanks, Chris. I was going to say I had no idea there was a user-manual---until I took a look at the pdf version. In fact, I had a hard copy of the book, but got rid of it because I couldn't understand it. I went looking for it but found that, alas, I have indeed gotten rid of it. May have to get myself another copy. The pdf is too maddening to navigate around in. Just discovered I hadn't completely gotten rid of it. I'm into a serious "simplifying" jag. Stuff to the dumpster. Stuff in boxes to be taken to Salvation Army, etc. I reorganizing stuff in one box I found the book at the bottom of the box. Thumbing through it it doesn't strike me as incomprehenisible as it did before. Maybe I've learned something. Maybe now I can learn from the book. ------------------------------------------------------------------------------------------ Eric Weir Decatur, GA USA [hidden email] "Uncertainty is an uncomfortable position, but certainty is an absurd one." - Voltaire -- You received this message from the "vim_use" 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 |
|
In reply to this post by Eric Weir
On Jun 3, 10:27 am, Eric Weir <[hidden email]> wrote: > On May 27, 2012, at 2:45 PM, BPJ wrote: > > > On 2012-05-27 18:10, Eric Weir wrote: > >>> Try out Voom, which has a markdown mode > > >>> > <http://www.vim.org/scripts/script.php?script_id=2657> > > >>> > I never thought I'd like a two-pane outliner (and one > >>> > written in Python too -- no offense but I came across > >>> > Perl first! :-) but I use it all the time now. > >> Thanks, BJP. I had it installed for a while, but didn't fully appreciate it's utility. > > > I'm a committed vimwiki user, and another user recently recommended it to the user group. > > > Currently I'm trying to figure out how to get vim-addon-manager to install it. > > > [I want to rely on vam for managing my plugins.] > > > I use pathogen and had no trouble installing anything so far. > > Today I tried installing Voom using Vim-Addons-Manager again today, BPJ. This time the install went through without a hitch. > > Now I need start learning how to use it. [From a skim of the manual it looks sophisticated enough to merit a user group. Maybe there is one.] Hello Eric, your timing is perfect, I've just uploaded new VOoM version. There is no dedicated user group. You can post any questions and comments on the following GitHub issues page: https://github.com/vim-voom/vim-voom.github.com/issues . Regards, Vlad -- You received this message from the "vim_use" 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 |
| Powered by Nabble | Edit this page |
