Re: Feature suggestion: option for letting spaces match newlines in search
On 24/02/11 8:49 PM, Ulf Magnusson wrote:
Hi,
One problem with searching for phrases in files that contain wrapped
text (LaTeX source files, e-mails, source code comments, etc.) is that
you never know whether two words will be separated by a space or a
newline. Therefore, it would be handy to have an option that makes
spaces match newlines in searches.
I've looked at http://vim.wikia.com/wiki/Search_across_multiple_lines,
but those solutions have the disadvantage of either forcing you to use
an awkward pattern or not supporting incremental searching.
A solution to a more general class of problems would be to allow the
search pattern to be automatically rewritten (e.g. by a substitution
or a function) prior to being used. That way you could automatically
rewrite spaces to \_s or do other neat things like having foo bar
match foo {\it bar} in LaTeX documents.
I'm not experienced enough with vimscript to be able to tell how such
a feature could interact badly with other things, but perhaps it
wouldn't be as bad if you limited it to searches initiated with /.
Thanks for making Vim!
/Ulf
Since nobody has replied to this that I've seen, I'd just like to add a
+1 for something like this. It would be very handy for quickly searching
for a phrase you remember in prose that is hard-wrapped.
Ben.
--
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
Re: Gvim File/Close menu does not close tabs
Hello, Please open a file1. Open a file file2 in a new tab. Use the File/Close menu to close file2 tab. The tab is not closed, instead an empty buffer with name No Name replaces file2. So the File/Close menu is not a synonym for :close. Is it a feature or a bug ? I think it's a bug. Here's the fix: diff --git a/runtime/menu.vim b/runtime/menu.vim --- a/runtime/menu.vim +++ b/runtime/menu.vim @@ -101,7 +101,7 @@ an 10.320 File.Open\ Tab\.\.\.Tab:tabnew:browse tabnewCR an 10.325 File.NewTab:enew :confirm enewCR an silent 10.330 File.CloseTab:close - \ :if winheight(2) 0 Bar + \ :if winheight(2) 0 tabpagewinnr(2) == 0 Bar \ confirm enew Bar \ else Bar \ confirm close Bar OK to include, Bram? Ben. -- 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
Re: search hit BOTTOM, continuing at TOP not displayed in insert mode
Zero reaction on this thread. Any idea what was in it? Nothing was quoted. Please think of desperate EasyVim users who never see search hit BOTTOM, continuing at TOP when using the menu Edit/find then Next. Please think of busy mailing list subscribers who don't find it easy to go back through mail archives to look up conversation context. ;-) Smiles, Ben. -- 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
Re: 'wildmenu with problems
On 10/03/11 9:20 AM, John Little wrote: On Mar 9, 8:31 pm, Axelaxel.ben...@cip-kommunal.de wrote: Entering :echow[tab] in 7.3 138 is giving me - instead of the first option starting with w - the following wildmenu expansion: [1] [No Name] 7.3.135, I get warn, which I imagine you should be. Also works for me in 7.3.125 and 7.3.138. Maybe a plugin is causing this? Ben. -- 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
Re: :version erroneous
On 9/03/11 6:39 PM, Christian J. Robinson wrote: On Tue, 8 Mar 2011, Axel wrote: Addendum: The same happens for :set all The OS is Windows XP. Does it still happen if you do :set nolazyredraw? A recent patch to fix something else seems to have introduced this problem with 'lazyredraw'. Hopefully Bram will have a fix out soon. I see the problem in console Vim on Mac OS X, only with lazyredraw set, and it only affects the Press Enter prompt, not the More prompt. Ben. -- 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
Re: Proposed patch: NL in sub-replace-expression('\=')
I would like to propose a patch which suppresses the conversion of
NL toCR when evaluaation ('\=') is used inside substitute()
function.
Simply this patch is what makes x == y true in the following code.
let x = substitute('a', '.', \n, )
let y = substitute('a', '.', '\=\n', )
Regardless of whether the functionality change of the patch is accepted,
I think there should be a change to :help sub-replace-expression to
explain what is done when \= is used within substitute().
Ben.
--
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
Re: GVim accessibility
On 9/03/11 1:00 AM, Sebastian Humenda wrote: Hello, I would like to make a suggestion for the graphical Vim. When using Orca, a screenreader for the graphical desktop, I can't use GVim. Since the menu's and button's are written in GTK+, there are perfectly usable, but not the main text body. This is quite logical: GTK+ has built-in the ATK library to report information about the program directly to AT-SPI - Orca. As my understanding is, it would be only necessary, that GVim reports the kind and the content of the text body (the actual opened file) to AT-SPI, using the AT-SPI library. There has just to be someone who has some experience with GTK and wants to help out. There are several blind and visual impaired people who have suggested this, since they are forced to work on the command line (and the terminal is no real alternative with Orca). Actually, the missing accessibility in GVim is the reason for me to work on the console instead of working at the graphical desktop. I'd be really glad if someone could look into it. Thanks Sebastian I'm not sure this is all that easy. Some similar issues were discussed with relation to MacVim on the vim_mac list, though. Search for posts by yvonne thomson on that list and you might find something relevant (you might not too). Ben. -- 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
Re: Yank to + also yanks to * when suppressing a in guioptions in unix
Dear Patrick, Your comment is not clear to me. Help says: a options results in a word selected using Visual is automatically yanked to the selection register (*). It works. With a suppressed, a Visual selected word is no longer yanked to the selection buffer (*). It works. Now, I see no reason why, with a suppressed, yanking a word to the Unix Clipboard (+) using +yw (no selection) should also yank it to the selection register. But it is what it does. Yes, I think like you, Jean, that it is a bug. Nothing at :help 'guiopions', :help 'clipboard', :help quotestar or :help x11-selection suggests this strange behaviour should occur. I do seem to remember reading something about it somewhere, but I can't find it now. So, I could be imagining things, or it was an old bug report I remember, or it is intended and documented somewhere Ben. -- 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
Re: Supporting more key modifiers
On 18/03/11 8:38 PM, Philippe Vaucher wrote: As long as the two triplets of keypresses I suggested originally can all be represented uniquely, and without reference to timing information in the Escape vs Alt+ case, then I'm happy with whatever internal implementation makes it happen. The two triplets in question being Tab Ctrl-I Ctrl-Shift-I Escape C Alt+C é Yes I am aware that on current byte-driven terminals there is no way without using timing information to distinguish all these three cases in the latter triplet here. This should not stop GUI systems from distinguishing them however. Can someone (Bram?) tell us if Bram's proposed solution would allow us to map those triplets independently as wanted? Of course it does. Bram wouldn't have suggested it if it wouldn't work at all I'm not familiar enough about vim's byte queue system to tell if the modifier byte really answers our needs here. I don't think we need to keep the same byte-stream representation as we currently have, and I don't think that's what Bram meant. I think we can change it. As long as it remains a byte-stream representation. And I don't think it will be possible to do what we need without at least extending it. At the moment, keys are a fixed length of 3 bytes (one of which is the 'escape byte' 0x80, and the other two of which have restricted values). There simply isn't enough value-space to do what we need, and it's possibly not very future-proof even if we can squeeze it in. It's also a bit of a mess, IIRC. It would be better to give it an overhaul. And it probably needs to use variable-length sequences. A thought occurred to me a couple of days ago: would it be appropriate to actually use CSI as the byte-stream representation? Or something like it. It is a byte-stream representation, right? And it's extensible, right, so it is less likely to need a big overhaul in future? Does it allow for 'private use' stuff? Because Vim needs a way to represent a bunch of other events as keystrokes (mouse clicks, scroll wheel, its magic script-local meta-character thing, representing the CSI escape character itself, etc.). Also, is it easy to skip over CSI sequences if necessary with simple logic? I think there are some nice/helpful things that could be done design-wise though. For example, Vim is often used with enc=utf-8 these days. I think it would be wise to, if possible, ensure all key sequence representations are invalid UTF-8 in their entirety. Then they could be put in buffers and yanked back into registers without ambiguity (hopefully), i.e. there wouldn't be the ambiguity of whether the escape character was part of a key sequence that should be yanked as such, or part of the buffer text which should be escaped upon yanking. See, Vim already deals with the CSI character in its byte-stream code, and escapes it, so some aspects of this are already somewhat accounted for. But I wonder when precisely it is escaped, and whether at times it is escaped when it shouldn't be, or not when it should be. It would be good to design to avoid this problem. (I happened to be hacking on some Vim code recently where this came into play, so I noted it with interest.) Ben. -- 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
Re: Color Support for :! and :Shell system command execution
On 23/03/11 3:21 AM, Kevin wrote: Wanted to suggest adding support for terminal colors to gvim. I want this, too, and it's on my to-do list to investigate implementing some time. That certainly shouldn't stop anyone else jumping in and doing it, though. No idea when I might have enough time to look into it. But it's something I care enough about that I'll probably eventually look at it. Ben. -- 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
Re: vim v7.3.125 crashes when running a macro with a count in the thousands
On 31/03/11 3:51 PM, Mun wrote: Hi, My OS: Red Hat Enterprise Linux 5.6 My configure command: configure --with-features=huge --enable-perlinterp --enable-pythoninterp --enable-gui I must apologize that I don't have too much to go on with this issue, but I'll provide what I have and I will try to get more data if requested. Obviously Vim's reporting something related to X. Were you using Vim's GUI at the time, or just console Vim? Did your macros make use of the system/X clipboard at all, or does your 'guioptions' or 'clipboard' setting mean that it would have been used for Vim's unnamed register? Just a couple more pieces of data that might be helpful, though I have no idea what's going on. Ben. I had a simple macro that would take a line and reformat it by adding strings to the beginning and ending of the line. Nothing tricky or complex. The file I was operating on had roughly 11,000 lines. If I executed the macro with a count of about 2,000 vim crashes on me. When I use the following vim command: % vim --nopluginfilename I get the following lines outut to the terminal when vim crashes: -- Delimiter BEGIN BadRequest (invalid request code or no such operation) Vim: Got X error Vim: preserving files... Vim: Finished. 44;0MBadRequest (invalid request code or no such operation) Vim: Got X error Vim: Finished. 44;0M --- Delimiter END - And when I use the following vim command: % vim -u NONE -U NONE --nopluginfilename My terminal window fills up with the following repeating lines: -- Delimiter BEGIN Vim: Got X error BadRequest (invalid request code or no such operation) Vim: Got X error BadRequest (invalid request code or no such operation) Vim: Got X error BadRequest (invalid request code or no such operation) Vim: Got X error BadRequest (invalid request code or no such operation) Vim: Got X error BadRequest (invalid request code or no such operation) Vim: Got X error BadRequest (invalid request code or no such operation) Vim: Got X error Vim: Caught deadly signal SEGV --- Delimiter END - One last piece of data: I compiled the same vim source files on a Red Hat Enterprise Linux 4 system and used my same plugins and rc files and ran the same macro in the same way and it ran without issue; even with a count of 11,000 . See below for the complete :ver information from both systems. A core file wasn't written; thus, I can't provide a backtrace. Regards, -- 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
Re: How to nowrap echo or echohl?
Rather than reinventing the wheel, have you tried using the :options command? I don't think he meant *Vim* options. He's just wanting to present the user with a menu of sorts, I think. Ben. -- 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
Re: Suggestion: change how [count]@{register} executes
So, what about executing 1000@@ as @@999@@ (where in turn 999@@ is executed as @@998@@ and so on ... and 2@@ as @@1@@ and 1@@ as @@ )? I like the idea. Hadn't thought of using recursion when I wrote about the issue earlier, but yes, of course, that's an obvious and simple way to implement it. Putting together a patch would only take a couple of minutes. What do you think, Bram? I don't think anything could really meaningfully make use of the current behaviour, so even though technically it would break backward compatibility it wouldn't break anything useful. Ben. -- 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
Re: Suggestion: change how [count]@{register} executes
So, what about executing 1000@@ as @@999@@ (where in turn 999@@ is executed as @@998@@ and so on ... and 2@@ as @@1@@ and 1@@ as @@ )? I like the idea. Hadn't thought of using recursion when I wrote about the issue earlier, but yes, of course, that's an obvious and simple way to implement it. Putting together a patch would only take a couple of minutes. What do you think, Bram? I don't think anything could really meaningfully make use of the current behaviour, so even though technically it would break backward compatibility it wouldn't break anything useful. You can't rely on the register not changing in the first @@, thus the following 999@@ may do something completely different. Won't work. Well, yes, but you could make 1000@a stuff @a999@a into the buffer and avoid that problem. If you mean the contents of the register changing, that was the point of the suggestion. The contention is that if a macro changes the register in which it is stored, it is expected that the change will take effect immediately after that run of the macro, not after a counted number of runs have completed. I think that's fair enough, because it's strange to think @a@a should work differently to 2@a and hard to imagine where the current behaviour would be useful (i.e. having only the 'last' change of the register take effect). Ben. -- 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
Re: Suggestion: change how [count]@{register} executes
On 10/04/11 11:51 PM, Ernie Rael wrote: Could that change affect undo chunking? I don't think so, but I could be wrong. Ben. -- 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
Re: Modified keypresses
On 16/04/11 12:45 AM, Paul LeoNerd Evans wrote: Having recently dredged this topic up again - what is the current state of plan? Are we happy we have a working model of how things will work and are just awaiting time to write some code, or are there still questions lingering about? I think we've been making some good progress, but there is still plenty that needs to be discussed. Some of my thoughts: - It sounds like changing the internal Vim byte-stream representation for keypresses to actually be CSI could be a good idea. By making careful use of the private area we could ensure Vim can represent everything it needs to, plus almost by definition it can represent all the keys/modifiers required, plus it is somewhat future-proof. Does anyone have any objection to this? - I have one possible objection: I'm interested in how close to losslessly we can convert between registers (which can hold keypresses) and buffers (which cannot). In many encodings, it cannot be done losslessly, but in UTF-8, which is very common these days, perhaps it can. I suspect perhaps CSI was designed with this in mind. Does anyone know if CSI sequences are ever valid UTF-8 or are designed not to be? If they are not ever valid UTF-8 we have the nice situation that there isn't an ambiguity between keypresses and characters. If not, perhaps designing something with that property would be wise, rather than using CSI. - Whatever byte-stream representation we land on, though, we would need a more careful survey of what internal Vim things are needed, and a sensible design for using the private area. That shouldn't be too hard and probably doesn't need to involve the community too much. - More importantly, though, we need some unambiguous specification of when to use the rich key representation and when not to use it. I think this needs a fair amount of further discussion. E.g. when Vim receives ^M from a terminal, should it leave it as ^M or should it convert it to a CSI sequence? What about in the GUI? What about when keys are stuffed into the input buffer? What about when storing the LHS and RHS of a mapping? - Finally, we need to finish discussing how mappings will be triggered. - My initial thoughts on this: Vim should use generic non-CSI codes when ambiguity exists: That includes when it receives codes from a terminal which are not CSI, so e.g., when receiving ^M which could be Enter or Ctrl-M, it should just store it as ^M. However, when it receives a key in the GUI or via CSI and it knows specifically it was produced by Enter or Ctrl-M it should store it specifically using CSI. For backward compatibility reasons, existing -notation should be considered ambiguous, but we should come up with an extension of this notation to be considered specific. Perhaps just adding an extra character after the opening ''--for instance !Enter could mean Enter, specifically. When interpreting keypresses, specific keypresses would trigger specific mappings, or ambiguous mappings if no corresponding specific one exists; ambiguous keypresses would never trigger a specific mapping. This means you could map Enter and it would work in dumb terminals and the GUI, and existing plugins would keep working in both, too, including when you actually press Ctrl-M. However, in the GUI/smart terminal, you could override that default/ambiguous map, by mapping !C-M which would take precedence, but only be active when we are sure Ctrl-M was pressed and not Enter. Do others think this approach would work? Ben. -- 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
Re: Modified keypresses
Q1. Need to change the input queue structure? A1. Changing this requires many other changes, and it's not clear that there's a whole lot to be gained for doing (very) much work. The current queue isn't so terrible, it's just not a nicely-packaged struct. Q2. Can current queue structure encode everything we want to encode? A2. Sounded like a tentative yes[1]. It definitely needs some amount of redesign. How much is strictly necessary, I'm not sure, but it seems to me it would benefit from more consistency even if not strictly necessary, so changing the internal representation to CSI or something very similar, could be worthwhile. What it doesn't need, and really can't have, for reasons of efficiency, is actually changing to use 16 or 32-bit 'characters' or structs. It must remain a byte-stream representation. Q3. Backwards compatibility - can we change the way keys are specified, either through (i) a special modifier key? (ii) an option? A3. (i) Sounds like a horrible idea to me, but no one responded when I asked about it[2]. (ii) Sounded like a definite no[3], which seems unreasonable to me (see same response-less email). Personally, A3 seems like a showstopper. Fixing this set of hysterical-raisin C-x = ASCII control character and all the related key-mapping disabilities seems like a clear case of *desirable* breakage of backwards compatibility. Yeah, this might be worth further discussion/campaigning/diplomacy. My initial thoughts in my previous email took an approach similar to the 'special modifier key' approach, but was actually an 'alternative -notation' approach. I'm not sure if it's good enough, but maybe it will be a suitable compromise. Maybe it is a bit better if current -notation is considered specific if it couldn't be detected before at all, e.g. C-S-M could not be detected at all, so could be considered specific, but C-M and Enter must be considered ambiguous. Not sure. I found your post [2] quite confusing, I'm afraid. Perhaps see what you think of my ideas in my previous post and respond to those, and/or see if you can do a simplified version of your thoughts in [2] that might be a bit easier for us to digest and respond to? If A3's not a showstopper, though, maybe the best next step would be to start a test suite, to ensure things are working the way they're supposed to work. Plus it gives a spec to shoot for. Things to include would definitely be these sets: Tab Ctrl-I Ctrl-Shift-I ^I C-m Enter ^M C-[ Esc ^[ M-i é Alt-d Escape-d Not a bad idea. Also specification of how all of these should behave/be represented in buffers, registers, input queue, etc. would be worthwhile. It'd need to include those sets both as entered literally and in key notation in the various places in which they could appear. Ben Schmidt laid out several of those places in his response[4]. Actually, the specific paragraph you referenced in [4] is not a good one. That was part of an argument I was building against a specific proposal that would've really messed things up which I think we have got past now. A better list can be found in the same post, the paragraph beginning This would be easier. Smiles, Ben. [1] http://groups.google.com/group/vim_dev/browse_thread/thread/d9ba7d51d7d9eb73/dd1ebb0f65445322#dd1ebb0f65445322 [2] http://groups.google.com/group/vim_dev/browse_thread/thread/d9ba7d51d7d9eb73/0eb955217669f6bb#0eb955217669f6bb [3] http://groups.google.com/group/vim_dev/browse_thread/thread/d9ba7d51d7d9eb73/e05cf3068cfce300#e05cf3068cfce300 (Some things that are no[t] acceptable: - Have a setting to enable 'the new way') [4] http://groups.google.com/group/vim_dev/browse_thread/thread/d9ba7d51d7d9eb73/39ebcaf32a84f1b0#39ebcaf32a84f1b0 (ś starting: So this [ed: a new struct-based input queue] would be a backwards-incompatible change.) -- 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
Re: Modified keypresses
For backward compatibility reasons, existing -notation should be considered ambiguous, but we should come up with an extension of this notation to be considered specific. Perhaps just adding an extra character after the opening ''--for instance !Enter could mean Enter, specifically. When interpreting keypresses, specific keypresses would trigger specific mappings, or ambiguous mappings if no corresponding specific one exists; ambiguous keypresses would never trigger a specific mapping. This means you could map Enter and it would work in dumb terminals and the GUI, and existing plugins would keep working in both, too, including when you actually press Ctrl-M. However, in the GUI/smart terminal, you could override that default/ambiguous map, by mapping !C-M which would take precedence, but only be active when we are sure Ctrl-M was pressed and not Enter. Do others think this approach would work? Possibly better: the LHS of a mapping if using -notation could map it both specifically and ambiguously, and when used for stuffing keys into the buffer (including RHS of mappings), -notation could always be specific. This would mean if you mapped both C-M and Enter, each specific key would trigger the appropriate mapping, but ambiguous keys would still trigger whichever mapping was defined last. So old stuff would continue to work as expected, but new stuff would work somewhat as expected, too. The !Whatever notation, or perhaps some mapping modifier like specific could be used to indicate that only the specific LHS should be mapped, not ambiguous, giving a way of avoiding accidentally affecting Enter when mapping C-M. Ben. -- 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
Re: Modified keypresses
- It sounds like changing the internal Vim byte-stream representation for keypresses to actually be CSI could be a good idea. By making careful use of the private area we could ensure Vim can represent everything it needs to, plus almost by definition it can represent all the keys/modifiers required, plus it is somewhat future-proof. Does anyone have any objection to this? That sounds reasonable to me. I use rxvt-unicode, though, which is (apparently) the only major holdout from the xterm-keycodes monoculture. So, I have a particular interest in making sure the conversion to/from CSI works right. (Volunteering services, here. Not complaining.) Sounds good. Err, if you're using the 7-bit Control Sequence Introducer (\e[ = Esc + [ = \033 \133), then CSI sequences are virtually always valid UTF-8. The 8-bit single-character variant does avoid UTF-8, though. In a properly formed stream of bytes, 0x9b is never the first character of a UTF-8 sequence, since it has the appearance of a continuation byte. OK, great. It's internal and so completely under our control, so we can use 0x9b always. Part of the input handling code would be to convert known sequences beginning with \e[ to 0x9b. We then can ensure we never accidentally interpret valid UTF-8 as keystrokes, as keystrokes will always be invalid UTF-8. There is a potential gotcha here. If you put a macro with special keys into your .vimrc, it becomes invalid UTF-8, so the next time you open it, it may be converted from latin1 or something like that, because Vim falls back to the next encoding in fencs. The conversion would result in valid UTF-8, and so the keystrokes would no longer be interpreted as keystrokes. This is currently a gotcha anyway, though, so I don't think it is a problem. I presume even if Vim would ordinarily fall back, :scriptencoding forces its interpretation even if invalid UTF-8 is encountered, so there should be no problem when actually sourcing scripts. Single-byte encodings are a different story. IIRC, currently Vim takes special care to avoid interpreting CSI in a buffer as keystrokes, but interprets code point 0x80 in single-byte encodings as beginning a keystroke. This would change if we used CSI, as CSI would be interpreted as a keystroke, and 0x80 would not. I don't think this is actually a problem. It only makes a difference if you play back a macro you've yanked anyway (or something like that). A minor backwards incompatibility. Out of interest, what is Unicode code point 0x80? Something else to think about, though: What about users who set termcap options which include CSI in their vimrc. Will they continue to work? Will it continue to be easy to set termcap options by using CTRL-V + press-the-key-that-is-giving-you-problems? It is almost certainly going to be impossible to do this 100% backwards compatibly, but it's an issue we should think about. My initial thoughts are that it would probably work just as well (or badly) as it always has, but that the added input filtering may make it a bit less transparent, and perhaps we should have a mechanism for doing it more reliably. I'll get to the rest later. As far as this part goes, though, I don't think there are any compelling reasons not to use CSI for the internal byte-stream representation. There are just a couple of minor incompatibilities and rough edges to handle with care. Any other issues anyone knows about that should be considered on this front? Ben. -- 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
Re: Modified keypresses
APPROACH 2: - -notation LHS defines specific and ambiguous maps - C-M defines ^M and CSI-Ctrl-M - Enter defines ^M and CSI-Enter APPROACH 3: - Ambiguous LHS defines ambiguous and specific maps - ^M defines ^M, CSI-Ctrl-M and CSI-Enter - -notation LHS defines specific and ambiguous maps - C-M defines ^M and CSI-Ctrl-M - Enter defines ^M and CSI-Enter Note that because these approaches define multiple mappings for a single piece of -notation, the number of mappings to be defined grows exponentially with the number of -notation keys in the mapping. So we need to view these specifications as conceptual, not actually as implementation approaches. AFAICT, this should be easy enough to overcome (just alter the mapping lookup mechanism and LHS storage mechanism, which truly doesn't affect anything else), and has no bearing on the previously-listed benefits and drawbacks (enumeration difficulties and inefficiencies just happen at a different point for approach 3, and approach 2 barely suffers). Ben. -- 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
Re: Modified keypresses
If A3's not a showstopper, though, maybe the best next step would be to start a test suite, to ensure things are working the way they're supposed to work. Plus it gives a spec to shoot for. Things to include would definitely be these sets: Tab Ctrl-I Ctrl-Shift-I ^I C-m Enter ^M C-[ Esc ^[ M-i é Alt-d Escape-d I'm not entirely sure what you mean by these sets, with regard to the caret notation at the end. What do you mean byCtrl-I vs ^I ? I'm happy that this ought to be considered againstTab andCtrl-Shift-I however. I think Ben was drawing the distinction between receiving an 0x09 byte (^I) and receiving something that was known to be Ctrl-I via CSI. Judging from your earlier mails, the problem is not between ^I and Ctrl-I, though, but between ^I and Tab, which even newer terminals represent the same way, right? Nevertheless, we still have two things to test here: the situation where Vim gets ^I and doesn't know whether it's Ctrl-I, and the situation where Vim gets ^I and knows it can't be Ctrl-I, because it knows Ctrl-I would have been represented by that terminal as CSI. Ben. -- 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
Re: Modified keypresses
- Whatever byte-stream representation we land on, though, we would need a more careful survey of what internal Vim things are needed, and a sensible design for using the private area. That shouldn't be too hard and probably doesn't need to involve the community too much. What things did you have in mind that would even need the private use area? Would these be non-keypress events? The CSI model is able to represent any of the keypresses already, so I'm not sure what's left to consider. You're spot on. Vim currently uses its internal keypress representation also to represent mouse clicks, mouse scroll wheel, 'script specificity' (i.e. SID used to access s: functions from mappings), representing the CSI 'character' and possibly more that I've forgotten, so if we change Vim's internal representation to be CSI, we would need to integrate these kinds of things (or have two 'escape mechanisms', but that seems like a very dumb idea to me). The way libtermkey handles this is that it has a set of translations, better names for some sequences. It renames 0x08 as Backspace, 0x09 as Tab, 0x0d as Enter and 0x1b as Escape. Any of the other C0s take their Ctrl-[letter] interpretation. This can be disabled by a flag. I guess the puzzle for Vim will be knowing when to turn that flag on and off. I guess it should be fairly simple to figure out from $TERM and/or somehow querying the terminal. This is important for terminals to still match users' expectations with regards to the keys they press to get various termios handling. termios can only store a single byte value for the various events, so, for example, EOF has to be 0x04, the single-byte representation of Ctrl-D. Mmm. Most importantly Ctrl-C for interrupt, I suppose. Others, like stop and continue and status, are not really used in Vim, so don't really concern us. O, I guess suspend is used, too. I suppose Vim deals with both of these by intercepting signals rather than parsing the keys though. But maybe not. So, I would say, there are 4 keys which tend to go by different names: Ctrl-H = Backspace Ctrl-I = Tab Ctrl-M = Enter Ctrl-[ = Escape The others are relatively uncontentious and can be left as-is. So, are you saying that these four keys are ambiguous? Surely not! Are you saying that these four keys, when actually generated with Ctrl use CSI, and when not generated with Ctrl use a single byte, but other Ctrl letters always use a single byte, since they can't be generated without Ctrl anyway? I guess it doesn't really matter, as long as Vim knows what's going on, so can correctly identify the key from the bytes it receives. Though does that still handle such cases as the physical keys Ctrl-C vs Ctrl-Shift-C? Can I ask to map !Ctrl-C to mean only the lowercase, without the (implied) uppercase including shift? I think that's a good idea. I guess in the end we aim for consistency, so it could depend how things like meta and accented keys work whether it's truly a good idea or not. I would prefer it if case didn't matter, though. Ben. -- 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
Re: Modified keypresses
On 19/04/11 12:43 AM, Paul LeoNerd Evans wrote: On Mon, Apr 18, 2011 at 12:11:01PM +1000, Ben Schmidt wrote: - Ambiguous key triggers ambiguous map - ^M triggers ^M - Specific key triggers specific map, or ambiguous if none - CSI-Ctrl-M triggers CSI-Ctrl-M or ^M - CSI-Enter triggers CSI-Enter or ^M No terminal would ever be sending Enter as a CSI, because if it did so no real program now would recognise it. Understood. The terminal wouldn't be expected to, though. As detailed in an earlier mail, any non-ambiguous special key would be turned into some kind of CSI representation by Vim at input time. So if Vim knows a particular terminal only sends ^M for Enter (because it uses CSI for Ctrl-M et al.), and therefore, for that terminal, ^M is specific, Vim would represent it as CSI internally. At mapping lookup time, then, it would encounter CSI for Enter, if and only if it was unambiguously known that Enter was pressed (or the Enter was generated by code in Vim such as another mapping or feedkeys() using -notation). On receipt of the single 0x0d byte we cannot tell whether this is an Enter key, or a user of a legacy (i.e. non CSI-sending) terminal pressing Ctrl-M. It should know by $TERM or somehow, though, or be able to find out using a callback or something, that the terminal supports or is in 'CSI mode' where it will use CSI for Ctrl-M, though, right, and therefore deduce that ^M is definitely Enter for that terminal? APPROACH 2: ... - Old stuff only breaks where -notation is involved; in this case, the intent of the notation is clear, so breakages should not be unexpected (except by gurus who were exploiting the ambiguity anyway) I foresee one major problem here - I suspect Bram himself is in this camp, so is likely to raise significant objections if it involves him. :( Not wanting to put words in his mouth, but Bram's pretty reasonable, and I'm sure like all of us will gravitate towards the best solution, when the others have significant flaws/drawbacks (which I think they do). And this is a very minor break in compatibility. It only occurs when you have clashing uses of -notation. C-M would previously override an Enter map, and vice versa, but with this approach it wouldn't. But without such a clash, i.e. if you just used C-M or just used Enter, it would behave just the same way as it does now (a map of one kind would be triggered by the other key). So it's only really if you had a couple of clashing plugins loading in a certain order to do what you want, or you have some plugin that is inconsistent in how it refers to a given key, that you have problems. Both these situations should be very rare. - Drawbacks - Specific stuff will never work in an ambiguous terminal, so more work for users to support both terminal types You hit upon this here ;) No terminal would be set that way, so this is a non-starter. It doesn't require the terminal to be set any special way, partly because of Vim converting to CSI at input time as I mentioned above. But it does require more work by the user to support both old and new terminals, and that would be a real pain. Approach 2 looks like a clear winner to me so far. I think it would be better with the specific map modifier than with !-notation, though that would possibly cause problems if you want an LHS with some specific and some possibly-ambiguous stuff; I doubt this would be a problem in practice, though, and there is a workaround (use intermediate mappings). Is it possible to update approach 2, in light of the fact there are no non-ambiguous terminals, as such? I.e. that we can never tell if we received an Enter on a CSI-sending terminal, vs. Enter or Ctrl-M on a legacy one..., etc etc.. I think a good part of this is already catered for by the stuff I mentioned above, i.e. Vim converting 'ambiguous' to 'specific' at input time, because it knows that for the particular terminal in use it is specific. However, perhaps it is better to do things a bit differently so that ^M prioritises Enter, since that is its 'more normal' meaning. APPROACH 4 - Ambiguous LHS defines high priority (P1) ambiguous map - ^M defines ^M-P1 - -notation LHS defines specific and ambiguous maps; priority of ambiguous map is related to how 'simple' the key is--more modifier keys mean a lower priority--keys that would usually be represented without CSI have P1, so they replace mappings from ambiguous LHS - Enter defines ^M-P1 and CSI-Enter - C-M defines ^M-P2 and CSI-Ctrl-M - C-S-M defines ^M-P3 and CSI-Ctrl-Shift-M - !-notation LHS defines specific map only - !Enter defines CSI-Enter - !C-M defines CSI-Ctrl-M - !C-S-M defines CSI-Ctrl-Shift-M - (variation: :map specific instead of !...) - -notation (or !-notation) on RHS is specific - Enter generates CSI-Enter - C-M generates CSI-Ctrl-M - C-S-M generates CSI-Ctrl-Shift-M - Ambiguous key triggers highest priority
Re: no error raised for :let list[out-of-range] = value
On 21/04/11 10:10 AM, Ben Fritz wrote: On Apr 19, 4:40 am, Yukihiro Nakadairayukihiro.nakada...@gmail.com wrote: When assigning or deleting list item no error raised for out-of-range index. :let list = [] :let list[0] = 0 :echo list [] :let list = [] :unlet list[0] I expected E684: list index out of range: 0 or similar error. This one is a feature. It lets you easily grow a list. How? Ben. -- 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
Re: vim.org is down
Jason wrote: There is no A record for the domain name vim.org. That is, this link shouldn't work: http://vim.org/ That's correct, actually. Not only doesn't it work, but it shouldn't work. It is a shame people have abused DNS and expect it to work. Marc wrote: There have been lot's of discussion about this on the mailinglist. That this topic is being written about again and again is a reason to change it. IMHO. To some extent, I agree. It'd be nice to 'fix' this, just to silence the noise on the mailing list. But how? We can't CNAME it; it would be against spec, and would break things. We can't add an A record, because sourceforge might change it under us and/or we don't know what magic they might be doing with load balancing, etc. that we would irresponsibly bypass if we did that. Perhaps the simplest thing is to get some cheap 'DNS hosting' that offers a 'redirect' function. Basically the function just has a server listen on port 80 for requests and return a 3xx (preferably 301 in our case) redirect (to http://www.vim.org/ in our case) whenever it gets one. No smart URL rewriting or anything. We might already have it (it commonly is included with domain names in my experience) and just need to set it up. If not, in my experience, it's very cheap, something like a year's worth of hosting for the price of a glass of fruit juice. Because it's actually a webserver, not done in DNS, it bypasses the DNS-related difficulties, and because it's such a simple task and it should be low-traffic anyway, loading isn't an issue. Ben. -- 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
Re: vim.org is down
Perhaps the simplest thing is to get some cheap 'DNS hosting' that offers a 'redirect' function. Basically the function just has a server listen on port 80 for requests and return a 3xx (preferably 301 in our case) redirect (to http://www.vim.org/ in our case) whenever it gets one. I've taken the liberty of doing just this for vim.org on my own webhost. (I have ten domain names included in my plan, and I'm only using eight). If an 'A' record for vim.org were created with the value 64.130.10.15 (www5.pairlite.com = benizi.com), this would work instantly. I did what I outlined in my post[1] from the last time this came up, but even more simply: www5$ cat vim.org/.htaccess Redirect permanent / http://www.vim.org/ Verified; this is working. Ben. -- 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
Re: vim.org is down
On 23/04/11 2:33 PM, Ben Schmidt wrote: Perhaps the simplest thing is to get some cheap 'DNS hosting' that offers a 'redirect' function. Basically the function just has a server listen on port 80 for requests and return a 3xx (preferably 301 in our case) redirect (to http://www.vim.org/ in our case) whenever it gets one. I've taken the liberty of doing just this for vim.org on my own webhost. (I have ten domain names included in my plan, and I'm only using eight). If an 'A' record for vim.org were created with the value 64.130.10.15 (www5.pairlite.com = benizi.com), this would work instantly. I did what I outlined in my post[1] from the last time this came up, but even more simply: www5$ cat vim.org/.htaccess Redirect permanent / http://www.vim.org/ Verified; this is working. Just to clarify, I don't mean that it's working for end users; I just mean it looks to me like the server is responding correctly, so if our DNS admin agrees to make the change outlined above, things should go smoothly. Ben. -- 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
Re: vim.org is down
http://groups.google.com/group/vim_dev/browse_thread/thread/36b81acf60548c20 I pointed out that it is a simple DNS issue, and gave some examples of Sourceforge sites that have chosen to add an A record for the domain (vim.org for us) in their DNS. ... 216.34.181.97 vim.org Turns out you're right, John, though I couldn't find any actual evidence in your mail or the thread you cited to prove it. :-) However, this page does prove it: http://sourceforge.net/apps/trac/sourceforge/wiki/Custom%20VHOSTs Since SF recommend it, putting an A record for the bare domain must be OK and not mess up their load balancing or anything (though without checking their docs, we couldn't have known that; another project's doing it doesn't make it right). IMHO, it would be wise to update our config so that it matches SF's recommendation. I agree with the DNS admin that people *should* use www. I don't really think people should use Chrome either, which is where the problem rears its head because Chrome doesn't automatically add the www for you if it has a failure. But that doesn't necessarily mean we shouldn't support it. In fact, IMHO, I have an opinion is a pretty poor reason not to do something, and other good reasons not to do this seem to be vanishing. Might as well take a few seconds to update the config and help these guys out. Ben. -- 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
Re: vim.org is down
On 23/04/11 6:29 PM, John Beckett wrote: Ben Schmidt wrote: Turns out you're right, John, though I couldn't find any actual evidence in your mail or the thread you cited to prove it. :-) However, this page does prove it: http://sourceforge.net/apps/trac/sourceforge/wiki/Custom%20VHOSTs Interesting docs, thanks. BTW while in general defining an A record for vim.org would not be sufficient when several websites are hosted at the one IP address, the fact that putting the entry that I showed in your hosts file works does prove that adding the DNS A record would work (although of course it is ideal to know that Sourceforge support that, and it will work in the future). O, I never said it wouldn't *work*. It just might not be reliable or responsible. If SF changed things, it would break, and if they were doing load balancing or geotargetting with DNS, we'd be bypassing it by hard-coding in a static IP, so could screw things up for them. I suggest you try Bram, and see if he wants to ask for the change. I'm still in let sleeping dogs lie camp. Well, I've given my opinion: I think it would be a nice thing to do for those who want it, it is technically feasible, wouldn't hurt anything, and I can see no good reason not to do it. But I don't actually care about it, and it doesn't affect me. So, if anyone's going to actually push for it, or put in extra work to convince Bram/our DNS admin (sorry I don't know his name!)/anyone else relevant to make the change, it won't be me. Smiles, Ben. -- 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
Re: Can't reproduce - 'lines' is 25 and 'scrolloff' is 12
On 3/05/11 1:04 PM, sc wrote: On Monday, May 02, 2011 20:02:03 Jean-Rene David wrote: Can someone reproduce this item from the todo list: When 'lines' is 25 and 'scrolloff' is 12, j scrolls zero or two lines instead of one. (Constantin Pan, 2010 Sep 10) I can't. And I didn't find a message on either mailing lists on that subject around that date. i confirm this: for me j moves one line in the above circumstance Me too. That's another one that's been fixed but not removed, then, it seems. Ben. -- 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
Re: Patch to detect linewise selections from X clipboard
Well, what if I yank (in Firefox, say, or in Thunderbird) a multiline sentence
from the middle of a paragraph? As in the example below, I mean? With this
newfangled system, I won't be able to insert it in the middle of a different
paragraph in Vim, except by calling setreg('+', '', 'ac') to force it to
characterwise.
That is the thing I find frustrating, too. I find it easier to whack my cursor at
the beginning of a line or open a new line than split a line, paste linewise, then
join lines again.
Someone did note a workaround for this, though: going into insert mode and using
Ctrl-R + to paste. This perhaps allows the best of both worlds (once the people
who, like me, prefer characterwise clipboard pasting, put together some mappings
to do it that way).
Cheers,
Ben.
P.S. Tony, I think you just won the award for the worst quote trimming ever. ;-)
--
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
Re: Logo / Icon contribution
I love vim, but must admit to not being so fond of the fairly old looking icon. I recently created a new logo for my own use, and would be more than happy if you'd like to use it for an actual app icon or logo. I quite like the icon, too. I agree the old one (which in recent times, I've only seen in Windows), looks a bit dated if nothing else. Another icon to look at/consider/etc. is the MacVim icon which, likewise, tried to modernise the old Vim icon somewhat, and I think did quite well. Can't remember when it was done, who did it, or anything. But it has been rendered at multiple sizes, and there are scripts that also create document icons with the MacVim badge and file extension printed on them for different file types. AFAIK, pretty much everything needed for this is in the MacVim git repository. The icon format is Mac-specific, I think, but it could probably be converted if other platforms would like to use it. I'm sure people are free to. Ben. -- 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
Re: Can't reproduce - 'lines' is 25 and 'scrolloff' is 12
On 4/05/11 12:11 AM, Jean-Rene David wrote: * Lech Lorens [2011.05.03 10:00]: On 03-May-2011 Jean-Rene Davidjrdavid...@magma.ca wrote: Can someone reproduce this item from the todo list: When 'lines' is 25 and 'scrolloff' is 12, j scrolls zero or two lines instead of one. (Constantin Pan, 2010 Sep 10) I can't. And I didn't find a message on either mailing lists on that subject around that date. I can reproduce it. However, I need to set 'ls' to 0 for the problem to show. Still no luck for me, even with 'ls' set to 0. What version of vim are you using? I see the behaviour now, with 7.3.161. Ben. -- 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
Re: [BUG] compiled with python, but has('python') returns 0
Here is the version information:
...
+python/dyn +python3/dyn +quickfix +reltime +rightleft -ruby +scrollbind +signs
...
However, :echo has('python') returns 0.
Does the :python command work? If not, perhaps it can't find the python
library at runtime, as it's only dynamically linked.
Have you tried has('python/dyn') as well?
IMHO, though, has('python') should work.
Ben.
--
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
Re: [BUG] compiled with python, but has('python') returns 0
:python command doesn't work. It gives the following message:
OK. So you need to install Python where Vim can find it. :-)
See :help python-dynamic
Once Python is properly installed, Vim should find it on startup, and
:python should start working and has('python') should return 1.
Also note that the :python3 command is different to the :python command.
If you only have Python 3 installed, only Vim's has('python3') and
:python3 commands will work, not the ones above, which are for Python 2.
Cheers,
Ben.
--
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
Re: Why is 'foldtext' local to window instead of buffer?
I've recently been trying to write a 'foldtext' setting that is specific to LaTeX and would include useful information like for a example the caption information for a folded environment. But then I discovered that the 'foldtext' setting is local to a window and not to a buffer, making filetype-specific foldtexts pretty much impossible. So if I were to for example edit my LaTeX file and a C file that I'm writing about in the same window I can't have foldtexts that are tuned for those files, respectively. Are you sure this is a problem? Have you tried it? :help local-options explains how window-local settings are kept per-buffer so when you reuse a window to edit a buffer you've edited before, the options for that buffer+window combination are used, or if the buffer wasn't edited in that window before, the options from the last window used for that buffer. Window-local doesn't actually mean window-local irrespective of buffer; it somewhat means window-and-buffer-local. Ben. -- 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
Re: Syntax engine - 'extend' broken
I've tried to look into the code to find the source of this behavior,
but eventually decided that trying to understand what it does would
take me too much time so I gave up.
I had a quick look, too, and haven't spotted the bug yet.
Note that your second example is a red herring:
a[aaa]a
is highlighted correctly. :syn match rules cannot nest (or overlap), so
the brackets correctly extend the match that originally spanned
characters 1-7 to span characters 1-9.
Your other two examples demonstrate the strange behaviour. Here's an
even simpler case:
sy clear
sy region braces
\ matchgroup=Type start=/{/ end=/}/
\ contains=parens keepend
sy region parens
\ matchgroup=Statement start=/(/ end=/)/
\ contains=parens extend
hi link braces Comment
hi link parens PreProc
finish
{a(a(a(a)a)a)a}
I just have it in a single file and use :sou % to (re)load it.
Ben.
--
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
Re: Syntax engine - 'extend' broken
On 14/05/11 10:27 PM, Ben Schmidt wrote:
I've tried to look into the code to find the source of this behavior,
but eventually decided that trying to understand what it does would
take me too much time so I gave up.
I had a quick look, too, and haven't spotted the bug yet.
I have tracked it down now. The problem is that when an extend syntax
group ends, check_state_ends() calls syn_update_ends() which then calls
check_state_ends() again. However, that first call happens before
check_state_ends() has finished its current iteration which updates the
location where end-checking should continue. Thus the end-checking
commences too early, and a syntax group higher up the stack can end,
though it shouldn't.
As there is only one call to syn_update_ends() with startofline being
false, and that is from check_state_ends() which will continue its work
after the call, this one-line change can fix it:
diff --git a/src/syntax.c b/src/syntax.c
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -1064,7 +1064,7 @@
}
}
check_keepend();
-check_state_ends();
+if (startofline) check_state_ends();
}
/
However, I am a bit concerned this makes the code (even) less readable.
A comment in the middle of the function does draw attention to the fact
that startofline==0 when an extend item has just been removed. As I
mentioned above, this is the only time this is the case. It turns out
that there is also only one call when startofline is true, and this is,
funnily enough, when starting a line. The two situations are pretty
different, and even though some similar updating is necessary there are
plenty of differences, and the function is, though short, littered with
checks of startofline. I think it might be better to create two versions
of the code (corresponding to startofline being true and false), and
either put them in two functions, or even at the locations of the two
existing calls (I don't deem the functions too large for this). What do
you think, Bram? I would be happy to make such a patch.
While investigating the issue, I found an inefficiency, too; more
checking is done than necessary because had_extend in check_state_ends()
is only initialised at function start, not each iteration of the loop.
This fixes it:
diff --git a/src/syntax.c b/src/syntax.c
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -2533,7 +2533,7 @@
check_state_ends()
{
stateitem_T*cur_si;
-inthad_extend = FALSE;
+inthad_extend;
cur_si = CUR_STATE(current_state.ga_len - 1);
for (;;)
@@ -2583,8 +2583,7 @@
/* When the ended item has extend, another item with
* keepend now needs to check for its end. */
-if (cur_si-si_flags HL_EXTEND)
-had_extend = TRUE;
+ had_extend = (cur_si-si_flags HL_EXTEND);
pop_current_state();
Cheers,
Ben.
--
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
Re: Patch 7.3.188
On 15/05/11 9:07 PM, H Xu wrote: On 05/10/2011 11:22 PM, Bram Moolenaar wrote: [snips entire patch description including 150+ lines of patches] Hello Bram, [...] Another winner for the worst quote trimming ever. I have no idea what you even wrote in your other messages, because I couldn't easily find your reply amongst the patches. Could you/others please trim quotes to the relevant portions when replying? It would make following much easier. Cheers, Ben. -- 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
Re: Syntax engine - bug in 'containedin'
On 18/05/11 1:50 AM, Radek wrote: Another strange behavior of syntax engine. Though it occurs only when there's at least one syntax group with 'containedin=' attribute, it affects even completely unrelated syntax items. As before, I feel that an example will explain it best. Found it. Not sure if my fix is correct yet though. Stay tuned. Ben. -- 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
Re: How about in-built camelcase movement support?
The other question is whether a sizeable population works on camelcase code and would like to have this solved :). I would like to see a camelcase and/or underscore-seperation movement commands. But I think if done, it has to be done really carefully so it doesn't end up using obscure keys or mashes, or hideously complicated options, or we turn Vim into Emacs Ben. -- 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
Re: Syntax engine - bug in 'containedin'
On 18/05/11 1:50 AM, Radek wrote: Another strange behavior of syntax engine. Though it occurs only when there's at least one syntax group with 'containedin=' attribute, it affects even completely unrelated syntax items. As before, I feel that an example will explain it best. The patch below fixes it. I think the comment pretty much says it all. That it worked before/in other cases was a bit of an 'accident' really, due to the order in which various things were done. Bram, I'm still awaiting your comments on the last syntax engine patch I sent through, to know whether I should rework it as I proposed or not. I'd like to have these discussed, finalised and included sooner rather than later if possible, as I may not remember many details if too much time passes. Cheers, Ben. diff --git a/src/syntax.c b/src/syntax.c --- a/src/syntax.c +++ b/src/syntax.c @@ -2566,6 +2566,9 @@ #endif update_si_attr(current_state.ga_len - 1); + /* nextgroup= should not match in the end pattern */ + current_next_list = NULL; + /* what matches next may be different now, clear it */ next_match_idx = 0; next_match_col = MAXCOL; -- 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
Re: Compiling Vim with X on Mac
[redirected from vim_use to vim_dev] Good idea! OK, I got confused. I think in vim.h FEAT_GUI should be defined even when NO_X11_INCLUDES is defined. If there is some place where FEAT_GUI causes trouble then add a check for NO_X11_INCLUDES there. That should be a lot cleaner an avoids unexpected side effects. NO_X11_INCLUDES suggests only the includes are skipped, nothing else. I agree. It is a much bigger and more complicated patch, though, as not including those files has a lot of side-effects in terms of which structures can be defined. I've done what I think is most sensible in the attached patch. What do you think? Phew, that's a mess. I didn't expect so many dependencies. Can we think of another solution? Perhaps we can split os_macosx.c into a part that conflicts with the X11 headers and doesn't contain any GUI stuff and a part with the rest, that may use GUI stuff? Or is there code that both uses the GUI and conflicts with X11 headers? I think that is essentially already the situation. The trouble is more that once you don't include the X11 headers, a bunch of structures, which aren't particularly GUI-related (i.e. they exist in console Vim), such as Vim windows, syntax groups, etc., can't be defined, as they contain GUI-related members. And even if they are unused in the .c file being compiled, as they are defined in the header files, of which Vim has few, they are somewhat inavoidable. Without adding an extra layer of indirection to all these structures (to go via a pointer rather than use the GUI members directly, so at least the strctures can remain constant with or without the GUI/X11 datatypes defined), or splitting Vim's header files up a lot more (so it is more modular and we can pull in what, and only what we want/need in any given source file), we are a bit stuck. I don't think the code that conflicts with X11 headers actually does much, or uses many structures, so either of those approaches above could potentially work (well, indirection will always work, and modularisation could work or mostly work, and just fall back to indirection where necessary). But both are quite a bit of work, for little gain, IMHO. The current code, of course, is a bit dangerous--just turning off the GUI features when compiling certain source files means a whole bunch of structures are defined really very differently for just those files. If any are allocated or members past where the two versions match are used, things could go horribly wrong, and in a hard-to-find way. With the new patch I forwarded, there is at least only one such structure (which I reordered so that the one member that needs to be included/excluded is at the end, so it's as safe as possible). So at least it's better. Still not pretty, though. All depends which risks you prefer, really, as I, like you, don't think we should spend too much time on this. Ben. -- 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
Fwd: Re: Keyboard left in a strange mode after ZZ
Below is a message from vim_use where we've partially identified the cause of some bug. Maybe there's a Windows dev here who has some more ideas, or could reproduce it and track it down? I'm afraid I'm pretty useless from here. Smiles, Ben. On Thu, May 26, 2011 at 5:00 PM, Ben Schmidt mail_ben_schm...@yahoo.com.au mailto:mail_ben_schm...@yahoo.com.au wrote: On 27/05/11 1:02 AM, Richard Guse wrote: I'm using Vim 7.3 7/20/2010 under Windows 7. I usually start gvim from the command-line but sometimes from Windows Explorer. After I start, do my work then use ZZ to save/exit, it leaves the keyboard in a strange state relating only to the window which was used to start gvim: before: abc123 after: ABC!@# after (shift key): ABC!@# after (caps lock): abc!@# There seem to be two ways to fix it... 1. exit and restart the window 2. in a bad window, re-start vim then type any command...even typing : and exiting the window with the mouse works. Just starting it then closing the window doesn't fix it - something must be typed. This doesn't happen with vim. This doesn't happen with gvim if exited with :wq or :x. I haven't noticed this behavior with any other application. I've noticed several tips and messages relating to mapping caps lock to escape but I don't map default keys. I'm hoping someone here has seen this before as its driving me nuts. It is incredibly difficult to retrain myself to :wq or :x rather than ZZ. I even tried mapping ZZ to :x and it still happens. Hmm. I guess it happens because Gvim does something keyboard-related when it exits, but when you use ZZ, at that point the shift key is depressed. To test the theory try doing :noremap ZZ 2gsZZ That will put in a 2 second delay before exiting, which should be more than enough time for you to release the shift key. See if that helps. If it does, check you can reproduce the bad behaviour by continuting to hold the shift key until after the 2 second delay passes and Vim exits. That's it exactly! I can now re-produce it not only by the above method but also by typing :q!enter but not lift the shift key when pressing enter. Curiously, some capital letter must be pressed as :xenter while shift is pressed does not do it. Explains why maping ZZ to :x doesn't fix the problem. I reduced it to 1 second :normap ZZ gsZZ which appears to be plenty. The delay is slightly annoying but much less annoying than funky caps lock. :noremap ZZ :sleep 300CRZZ works even better. :) Still can't re-produce it in any other application. It must be unique to vim and my environment. Thanks. -- 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
Re: [?] echoe acts like an exception inside :catch and :finally blocks
On 3/06/11 9:45 AM, Tony Mechelynck wrote: On 02/06/11 23:27, Bram Moolenaar wrote: ZyX wrote: Is this expected: try throw 'Throw' catch echoe 'Echoe' echom 'Echom' endtry will show only 'Echoe', but not 'Echom'? I though that «When used inside a try conditional» refers only to the first section of `:try...' block, not to `:catch' or `:finally' sections. This indeed looks wrong. :echoerr generates an error (which, inside a try block, is handled as an exception). Depending on where the error happens, it may cause an abort of whatever it is that it is wrapped in. In the present case, the Echoe exception is not caught, so it will propagate outside the try block we see here, to be caught by an outside try block if any, or if there isn't, it may (I suppose) propagate as an error, causing an abort of some script or function around this try block. Vimscripts do not normally terminate on errors, and that is the problem here; it does, when it shouldn't. There is no mapping to terminate, no function, no surrounding try/catch block into which to propagate the error. It should just be ignored and the script continue, just as if you issued the echoe followed the the echom on the commandline. Ben. -- 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
Re: HOME variable in cmd.exe for vim compiled in an UNIX-like environment
On 8/06/11 2:38 PM, Bram Moolenaar wrote: fabian greffrath wrote: Am 07.06.2011 05:40, schrieb Bram Moolenaar: This tries to expand a file pattern starting with ~/, which won't work when $HOME isn't set. However, it should not crash. You say the shell chokes on the command, but how does that make Vim crash? I don't know. Maybe it's just Windows that for some reason *believes* that vim has crashed [1]. However, I have just tried out with another shell, i.e. the sh.exe from UnxUtils (which is a zsh) and it works even if both PATH and HOME are unset! - Fabian [1] These are the debug messages that Windows presents to me (in German, sorry): Problemsignatur: Problemereignisname:APPCRASH Anwendungsname: conhost.exe Anwendungsversion: 6.1.7601.17514 Anwendungszeitstempel: 4ce79a18 Fehlermodulname:conhost.exe Fehlermodulversion: 6.1.7601.17514 Fehlermodulzeitstempel: 4ce79a18 Ausnahmecode: c005 Ausnahmeoffset: 1e65 Betriebsystemversion: 6.1.7601.2.1.0.256.4 Gebietsschema-ID: 1031 Zusatzinformation 1:f7b2 Zusatzinformation 2:f7b24610852830221d2f973252451319 Zusatzinformation 3:1131 Zusatzinformation 4:11317911aee4606a99ac6986df83c9f2 Lesen Sie unsere Datenschutzbestimmungen online: http://go.microsoft.com/fwlink/?linkid=104288clcid=0x0407 Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline: C:\Windows\system32\de-DE\erofflps.txt I guess what happens is that the shell dies, and takes Vim with it. I don't think it is up to Vim to set $HOME just to avoid the shell from dying. You could try running that conhost.exe without $HOME in another context, see what happens. Can it be reproduced without Vim? If so, a bug can be filed against the shell. If not, perhaps we haven't fully understood it yet? Ben. -- 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
Re: Fwd: Numbered registers
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Mar 22 2011 13:03:19) MS-Windows 32-bit GUI version with OLE support Included patches: 1-142 Vim maintains the numbered registers 0-9. These are maintained automatically by Vim. I had a request for the YankRing plugin to also manage these registers and make sure the top 10 most recently used entries in the YankRing are in those registers. In attempting to implement this, I see Vim has it's own design on these. So even as I write to them: let @2 = 'blah' This will be overwritten with something else. You can read about the numbered registers here: :h quote_number Though I am seeing some behaviour with the #2 register that I can't really explain. I was hoping someone familiar with the code could have a quick look at tell me what Vim is putting in this register. I have not been able to determine when or why this one is updated with the text it receives. Is there any Vim option to turn off the management of the numbered registers? I don't get it (which is why I didn't reply on vim_use :-)). Numbered registers generally behave as I expect them to, including when I set them, except for @ (which works as documented, but just isn't convenient always!). Can you spell out more specifically what the problem is? What specific steps show what happens and what would you prefer to happen? Ben. -- 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
Re: ALT_C and ã
On 19/06/11 3:52 AM, Ian Liu Rodrigues wrote: Dear list, When I press ALT_C in GVim, it generates the character ã (a tilde). This is problematic since I can't create an imap to ALT_C, for typing ã will also trigger the mapping. I'm interested in fixing this bug and providing a patch, but I've never looked in Vim's code, so if someone could give me an entry point, I would appreciate. Yeah, this is a known limitation. We have planned out a roadmap to fix it, but it is quite a large job, and I don't think anybody is actually working on it yet. There are plenty of people interested in having it fixed, though, so I'm sure as soon as one of them has some spare time, it will happen! Ben. -- 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
Re: ALT_C and ã
On 21/06/11 12:13 AM, Paul LeoNerd Evans wrote: On Sun, Jun 19, 2011 at 09:16:00PM +1000, Ben Schmidt wrote: Yeah, this is a known limitation. We have planned out a roadmap to fix it, but it is quite a large job, and I don't think anybody is actually working on it yet. There are plenty of people interested in having it fixed, though, so I'm sure as soon as one of them has some spare time, it will happen! _Do_ we actually have a roadmap.. really? I recall various discussions going back and forth, but no real concrete specifics, nor did anyone step up and say I will write some code. Do we actually have either of these things? Oops! I think you're right. I must've been thinking of another feature where we got further (bidi text or smoother scrolling or something). I think as far as we got is a 'model' for how mappings should work. Approach 4 built on all our discussions and clearly set out how mappings should conceptually work. There were a number of other raised but unresolved issues, too. We should gather them together into a neat list, resolve them (or agree not to resolve them) and then make some kind of roadmap/implementation plan. Ben. -- 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
Re: ALT_C and ã
On 22/06/11 9:37 PM, Paul LeoNerd Evans wrote: On Tue, Jun 21, 2011 at 10:45:57AM +1000, Ben Schmidt wrote: I think as far as we got is a 'model' for how mappings should work. Approach 4 built on all our discussions and clearly set out how mappings should conceptually work. There were a number of other raised but unresolved issues, too. We should gather them together into a neat list, resolve them (or agree not to resolve them) and then make some kind of roadmap/implementation plan. This sounds like a good idea. Do you want to take charge of that bit? I seem to recall we were heading in about the right direction, with just a few minor questions here and there around the edges. I'll see how I go. I might be able to do some work on it next week, but if not, it'll be about a month before I get a chance. So if you want to have a go yourself, just jump in. Cheers, Ben. -- 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
Re: [BUG] `verbose set sw?' is not working in help buffer
On 26/06/11 11:15 AM, ZyX wrote: Reply to message «Re: [BUG] `verbose set sw?' is not working in help buffer», sent 04:12:57 26 June 2011, Sunday by Bram Moolenaar: In help files the option values are set to sane values. Option values set in the program don't have a verbose location. If I set 'sw' to 100 it will remain set to 100 in a help buffer. It does not look like a `sane' value. And it is not a value defined by Vim itself, so it is a bug. The local option is set from the global option, not from a file, so has no verbose location. :verbose setglobal sw? will show you whence the global option was set. I wouldn't call it a bug. But it could be a helpful enhancement to, when setting a local option from a global option, also set the verbose location. Ben. -- 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
Re: a problem with syntax highlighting in regexp.c
I extracted a couple of lines from regexp.c (143,144): (vim 7.3.244) #define BRANCH 3 /* node Match this alternative, or the * next... */ and put them in a file junk.c. Then vim -u NONE -N --noplugin junk.c :syn on shows the comment-ending pair of characters, */, in error highlighting. No problem for me with Vim 7.3.219 and an updated syntax/c.vim which hasn't made it into the official runtimes yet. FYI: I found this due to my looking at line 2045, (2044,2045) No problems around that area for me either. So, if it's a bug, it's a new one! Ben. -- 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
Re: Patch 7.3.258
Does this have some documentation with it? How will anybody find out about it
if not?
Ben.
On 21/07/11 1:27 AM, Bram Moolenaar wrote:
Patch 7.3.258
Problem:MS-Windows: The edit with existing vim context menu entries can be
unwanted.
Solution: Let a registry entry disable them. (Jerome Vuarand)
Files: src/GvimExt/gvimext.cpp
*** ../vim-7.3.257/src/GvimExt/gvimext.cpp 2010-08-15 21:57:29.0
+0200
--- src/GvimExt/gvimext.cpp 2011-07-20 16:48:09.0 +0200
***
*** 586,593
// Initialize m_cntOfHWnd to 0
m_cntOfHWnd = 0;
! // Retrieve all the vim instances
! EnumWindows(EnumWindowsProc, (LPARAM)this);
if (cbFiles 1)
{
--- 586,608
// Initialize m_cntOfHWnd to 0
m_cntOfHWnd = 0;
!
! HKEY keyhandle;
! bool showExisting = true;
!
! // Check whether Edit with existing Vim entries are disabled.
! if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, Software\\Vim\\Gvim, 0,
! KEY_READ,keyhandle) == ERROR_SUCCESS)
! {
! if (RegQueryValueEx(keyhandle, DisableEditWithExisting, 0, NULL,
!NULL, NULL) == ERROR_SUCCESS)
! showExisting = false;
! RegCloseKey(keyhandle);
! }
!
! // Retrieve all the vim instances, unless disabled.
! if (showExisting)
! EnumWindows(EnumWindowsProc, (LPARAM)this);
if (cbFiles 1)
{
*** ../vim-7.3.257/src/version.c2011-07-20 16:36:35.0 +0200
--- src/version.c 2011-07-20 16:54:34.0 +0200
***
*** 711,712
--- 711,714
{ /* Add new patch number below this line */
+ /**/
+ 258,
/**/
--
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
Re: [patch] move to next error
On 3/08/11 6:30 AM, Bram Moolenaar wrote: Christian Brabandt wrote: this patch fixes this issue from the todo list: , | 8 Add a command to jump to the next character highlighted with | Error. ` It implements the [e and ]e movement commands, which move to the previous or next error. And while I was at it, I also made [t ]t move to the previous/next item that is highlighted with TODO highlighting. Thanks, I'll put it on the todo list. We are running out of command characters, taking two more from the ] and [ list makes me wonder how many users will use them. Perhaps we should have one move to highlight command with an argument to specify what kind of highlighting? That would be more future safe. I think something more future-proof and flexible would be better, too. Maybe it needs to be an Ex command that a user can map if desired to access in normal mode. Ben. -- 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
Re: A few questions(accessing the Vim code in VimL)
Spencer Collyer wrote:
On Sun, 8 Feb 2009 20:40:09 -0800, Garrett Whelan wrote:
... Oh, also what is this declaration structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043 list_hashtable_vars(current_funccal-l_vars.dv_hashtab,
2044 (char_u *)l:, FALSE, first);
2045 }
I've never seen that in C before. Declaring variables after the
arguments but before the body?
That is the original style of function declaration in C, from back in
the KR first edition days.
Yes. Note, though, they are not variables being defined (or even
declared), but the types of the function arguments being declared. You
can't just define variables there, it is the place to declare the
arguments' types, though.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Feature request: Add a Diff option upon open when Found a swap file...
Adding the ability to easily diff the recovered buffer against the on-disk file (the action recommended to the user) is a valid request. I'm not proposing the following as a solution, but I will mention that there is a related tip: http://vim.wikia.com/wiki/Swap_file_%22...%22already_exists!_-_so_diff_it And the 'Comment' at the end of the tip, IMHO, is the most useful part. Here's what I usually do. When I'm confronted with the 'Swap file exists' message, I choose 'Recover' and then immediately issue :DiffOrig (:help :DiffOrig). Once I've considered the changes, I either (1) close the Scratch buffer that is the original file, to keep the recovered file, and delete the old swap file, or (2) I edit the file again and choose 'Delete' when confronted with the 'Swap file exists' message. Now, perhaps a good solution is to have (1) a 'Recover and diff' option that basically does 'Recover' and :DiffOrig in one step and (2) a :KeepThis command that you can run in the buffer you're interested in keeping, that writes the buffer you're editing to disk (you may have even edited it, e.g. to incorporate *some* changes from a recovered version), deletes all the stale swap files, closes any other buffers that were editing that file (to avoid 'Buffer already editing that file' issues, etc.), and re-edits the file so that its current swap file is .swp not .swo and thus easily recoverable in future. It would need a little support from Vim--i.e. a reliable way to determine what the swap files are, both current ones for buffers being edited, and stale ones, i.e. ones from which recovery was done. That is probably easy to add. But apart from that, it could be Vimscripted, I think. So, two big questions about it. (1) Would my suggestion be an appropriate interface? and (2) Would Bram be willing to have those small additions to Vim? Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: variable tabstops feature branch in vim_extended.git
Hi, Matthew, Have you managed to do any work on this to bring it up to date? If not, I'll volunteer, as I love this functionality, and have noted a couple of areas which need fixing/improving since the last patch I have. Either way, could you send me the latest version of the patch? Or should I get it from vim_extended? Ben. On 14/03/09 5:54 AM, Matthew Winn wrote: On Thu, 12 Mar 2009 23:38:44 +0100, Markus Heidelberg markus.heidelb...@web.de wrote: patch 7.2.137 has rewritten half of the function shift_block() in src/ops.c. This is the part, which was heavily modified by the variable tabstops patch, so that I ended up with a merge conflict. I will at first remove the feature from the branch, so that I can update the master branch. If someone who actually uses this feature or Matthew himself would update the patch, I would be eager to include it again. I've been meaning to work on the patch but ill health has intervened. I'll see if I can find the time to bring the patch up to date. -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Missing redraw when changing 'ff'
Hi, Bram,
I'm getting back into doing some Vim coding, and mailing list
interaction and so on, and have come across this old patch (attached;
originally on vim_use).
The changes to ex_cmds.c are obsoleted by patch 7.2.082, but the change
to option.c is still relevant.
The problem is that when 'ff' is changed, the screen is not redrawn, so
any ^J or ^M in the buffer are incorrectly displayed until you scroll or
redraw.
Ben.
--
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.phpdiff -r 11ae7ca1e672 src/ex_cmds.c
--- a/src/ex_cmds.c Sat Dec 06 10:45:15 2008 +1100
+++ b/src/ex_cmds.c Sun Dec 28 19:13:21 2008 +1100
@@ -49,6 +49,7 @@
exarg_T *eap;
{
int c;
+char_u *transc;
char buf1[20];
char buf2[20];
char_u buf3[7];
@@ -92,9 +93,12 @@
else
#endif
buf2[0] = NUL;
+ transc = transchar(c);
+ if (c == CAR get_fileformat(curbuf) == EOL_MAC)
+ c = NL; /* we use CR in place of NL in this case */
vim_snprintf((char *)IObuff, IOSIZE,
_(%s%s%s %d, Hex %02x, Octal %03o),
- transchar(c), buf1, buf2, c, c, c);
+ transc, buf1, buf2, c, c, c);
#ifdef FEAT_MBYTE
if (enc_utf8)
c = cc[ci++];
diff -r 11ae7ca1e672 src/option.c
--- a/src/option.c Sat Dec 06 10:45:15 2008 +1100
+++ b/src/option.c Sun Dec 28 19:13:21 2008 +1100
@@ -1056,7 +1056,7 @@
{(char_u *)0L, (char_u *)0L}
#endif
},
-{fileformat, ff, P_STRING|P_ALLOCED|P_VI_DEF|P_RSTAT|P_NO_MKRC,
+{fileformat, ff, P_STRING|P_ALLOCED|P_VI_DEF|P_RSTAT|P_RBUF|P_NO_MKRC,
(char_u *)p_ff, PV_FF,
{(char_u *)DFLT_FF, (char_u *)0L}},
{fileformats, ffs, P_STRING|P_VIM|P_COMMA|P_NODUP,
Re: Top of file not reached using ctrl-f + ctrl-b
FOUND IT!
Correct behaviour relies on a long overflowing, which it does on 32 bit
machines, but not on 64 bit machines.
From onepage(...) in move.c:
long n;
...
while (n = curwin-w_height loff.lnum = 1)
{
topline_back(loff);
n += loff.height;
}
if (n = curwin-w_height) /* at begin of file */
...
From topline_back(...) in move.c:
if (lp-lnum 1)
lp-height = MAXCOL;
From vim.h:
#if SIZEOF_INT = 4
# ifdef __MVS__
# define MAXCOL (0x3fffL) /* maximum column number, 30 bits */
# else
# define MAXCOL (0x7fffL) /* maximum column number, 31 bits */
# endif
#else
In the usual, non __MVS__ case, on 32 or 64 bit machines, we have
MAXCOL=0x7fffL. On at least most 32 bit machines,
sizeof(int)==sizeof(long), so n overflows and becomes negative at
n += loff.height when we reach top-of-file, and the if is entered. On at
least some 64 bit machines, sizeof(int)sizeof(long) (4 vs. 8, it
seems), and so n does not overflow but just gets huge.
The code is clearly wrong, but I'm not 100% sure what the intentions
are.
Perhaps the if should be
if (loff.lnum 1) /* at begin of file */
?
I don't have time right now to try it, and my build environment isn't
quite set up right yet and not worth the trouble to do so as I'm
thinking of doing an OS reinstallation in a day or two. Can someone else
review the change / test it / suggest something else if it's wrong?
I don't have a 64bit machine to try it on, but wouldn't it be simpler
just to change the declaration of n from long to int?
I thought of that, but suspect it would mess up 16 bit machines. Not
sure if anyone cares about that anymore.
It also wouldn't fix the __MVS__ case which will suffer from the same
problem for a different reason.
And to cross all the ts, the behaviour of overflow with signed integers
is undefined in the C language. But while it can be described as a dodgy
piece of code, for most hardware platforms there shouldn't be a problem.
I doubt this is the only place relying on undefined language behaviour.
I doubt it too. But surely it would be better to have a more sane test
than relying on platform-specific ill-defined oddities.
To really be picky, probably MAXCOL is not a good choice of value for
height in the 'above first line' case. Something like LONG_MAX (does
that macro exist?--and on which platforms?) would be more appropriate.
It would return us to relying on the overflow, though, which IMHO isn't
really the best solution.
Bram probably will have a preferred way of fixing this, I suppose. Now
the problem has been pinpointed it should be pretty trivial for him to
decide on a fix. Probably more helpful for him if someone can test a
proposed fix, though.
Ben.
--
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
Re: Building GUI Vim on MacOS
On 11/7/20 2:36 am, Tony Mechelynck wrote: On Fri, Jul 10, 2020 at 5:00 PM Yegappan Lakshmanan wrote: Hi Tony, On Fri, Jul 10, 2020 at 7:37 AM Tony Mechelynck wrote: On Fri, Jul 10, 2020 at 3:41 AM Yegappan Lakshmanan wrote: Hi all, Is anyone able to successfully build GUI Vim on MacOS? I am not able to build Vim with GUI enabled on MacOS. I tried athena and carbon. I think the build instructions in src/INSTALLmac.txt file should be updated. Note that I am able to successfully build MacVim (https://github.com/macvim-dev/macvim) with GUI support. Thanks, Yegappan IIUC MacVim is _the_ version of Vim with "native Mac" GUI support. It /may/ be possible to build other versions of gvim for OSX _with X11_ which is not the default; but AFAIK such versions have received little or no testing ever since MacVim came into being, their GUI may or may not still be usable. OTOH the procedure for building Vim without GUI should be the same, or very similar, on OSX and on other Unix-like platforms. Thanks for the reply. I do regularly build and use the TUI version of Vim on MacOS (this is the system I use for Vim development). If nobody is able to build or use the GUI version on Mac, then we should remove that code (CarbonGUI). Regards, Yegappan I don't use the Mac myself, I'm on Linux; so all I know about Vim on Mac is hearsay, which I got mostly by following the vim_mac newsgroup in addition to vim_use and vim_dev; but you aren't the first one who tried to build a non-MacVim gvim on Mac and failed. Did you get an executable? If you did, have you tried to run it after starting an X11 server? I'm adding a few CC of people who "might" know the Mac better than I do. Best regards, Tony. Yeah, wow, that stuff is ancient. I didn't even know there was ever a working Carbon-based GUI for Vim. There is vim-cocoa which was an alternative to MacVim, but I believe it was poorly maintained, so although Cocoa is still supported by macOS, you'd have trouble building and running vim-cocoa. Carbon, being officially discontinued by Apple now (after being deprecated for a number of years), will be even harder to build and run. I guess if there's an Athena-based GUI, it would require X-Windows/X11/XQuartz, but I'm not aware of that ever running on the Mac. Indeed, as far as I'm aware, MacVim is currently the only viable GUI on the Mac. My suggestion would be to remove the others unless anyone is out there building recent versions of Vim for legacy OS versions (which is probably futile, so I doubt it; building an older version of Vim for an older OS would be a smoother road). Smiles, Ben -- -- 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 subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/b3f412e2-c795-28ca-a0c1-91e9d81f4fbc%40gmail.com.
