Vanilla 1.1.1 is a product of Lussumo. More Information: Documentation, Community Support.
I don’t know if this has been brought up before, but it’d be nice to have Vim style search/replace in Intype.
Also, although not as important, it would be nice to have a way to run an init script at startup to load a custom configuration (ala .vimrc, but I guess it’d be in javascript.) I’d see this as a post file loading step that would override the settings saved in the itConfig files. This would come in handy to specify per filetype settings.
I not 100% sure, but I think the general idea is that per filetype config is done in the bundles and themes?
natix: I don’t know if this has been brought up before, but it’d be nice to have Vim style search/replace in Intype.
Do you mean like s/change/me/ ? I think the search/replace should be at least a little GUI oriented. But let’s keep it simple – no monster dialogs with oodles of checkboxes and menus please.
I see the bundles as a part of the application a casual user would not want to modify since upgrading to a newer version will possibly erase changes one would make to them; storing personal settings in a custom file that’s not overwritten by the installer seems like a more sensible approach. It would also make it easier to move your settings from computer to computer (I wouldn’t really do this on Windows, but I do this a lot with Vim on Linux servers; Someone running Windows servers might find this useful though.)
There will be a mirror location for the bundles/themes where you can store your own overrides. This will not be touched when upgrading.
There’s going to be support for overriding bundles with files from the user folder (Profiles/Application Data/Intype) in the future…
Edit: lol, clicked to reply ten minutes ago, got beat :)
Ah, so the equivalent of a .vimfiles directory, good deal.
svenax: Do you mean like s/change/me/ ? I think the search/replace should be at least a little GUI oriented. But let’s keep it simple – no monster dialogs with oodles of checkboxes and menus please.
A simple search/replace box would of course work, it’s just a matter of getting used not to type :%s/change/me/g everywhere I go. I guess I should blame Vim for this though; I keep typing <Esc>Vkd or :q! at least 10 times a day whenever I’m in an IM or witting an email on Windows.
On the other hand, I guess it would be pretty easy to implement a Vim compatibility mode (off by default) that would work like the Firefox search box (docked at the bottom of the windows), without any control in the panel except for a single text box. In even the simplest search/replace dialogs, you still have to use the mouse (*shudders*) to check Regex, Selected Files, etc… or tab your way through. I wonder which one would cause carpal tunnel syndrome first…
Selecting files. Thats what caused mine. J/K
Perhaps the requested Firefox style search/replace bar can do something similar? ;)
The problem with such a bar is that it’ll become very big very fast if you start incorporating lots of commands and modifiers to the search function (ie. Match Case, Regular Expression, etc…) If the search bar takes too much space on the screen, it’ll overlap the text and will make searching for text in different contexts harder if you need more of the context to work with. At least when you’re working with a dialog box, you can move it out of the way. The idea behind using Vim style search/replace is that it only hides a very small area of the display and doesn’t require the use of the mouse or the tab key.
What I was thinking was that you can actually type in vim-style commands into the search bar to have it do search/replace ;) Think of it as a vim command line. I would strongly disagree against populating the bar with tons of form controls that would be better located elsewhere (in a full dialog perhaps).
idyllrain: What I was thinking was that you can actually type in vim-style commands into the search bar to have it do search/replace ;) Think of it as a vim command line. I would strongly disagree against populating the bar with tons of form controls that would be better located elsewhere (in a full dialog perhaps).
My thought exactly!
Okay, bit of a nerd alert in this topic. What’s <esc>Vkd and :q! ? And is a Vim compatibility mode really a sane idea? There really should be just one big Intype mode in Intype. :) But of course, it could always be done as a plugin, I think, when that functionality arrives.
But, the simple “s/search/replace/gi” could be a nice asset. Though the Search/Replace bar should have a Search field and a Replace field by default. It could have options in a context menu to avoid clutter. And if you want to use the vim style regexp, you can do that, just enter it in the Search field. Maybe it could detect the syntax and automatically hide the Replace field.
That sounds great – a search bar which accepts PCRE (or POSIX, or VIm?) syntax, something like this, would be great.
The Next and Previous buttons aren’t really needed are they, you could just do Enter and Shift+Enter? And just have a Highlight All button if anything. Also, I really think there should be two fields by default, one Search and one Replace (that’s “dynamic” as I described above, if possible).
Yeah, the buttons aren’t strictly necessary, I just happen to have that firefox extension installed at home – but I’m not sure about the need for two boxes – if you’ve entered a replacement expression, then it would do a replace, if not just search?
That’s not good, there should be a simple way to do S&R in this little bar even without knowledge of the vim style regexp. One good solution, IMO, would be auto-hiding the Replace field, like I already mentioned.
Frederick: Okay, bit of a nerd alert in this topic. What’s <esc>Vkd and :q! ? And is a Vim compatibility mode really a sane idea? There really should be just one big Intype mode in Intype. :) But of course, it could always be done as a plugin, I think, when that functionality arrives.
<esc>Vkd would delete the current line and the last one while :q! closes the current buffer without saving even if there were changes made to the buffer.
I agree it could be done as a plugin, to avoid favoritism toward any other editor, I’m just thinking many programmers and system admin would find Vim syntax useful; It is after all the most widely available text editor. But then again, Emacs users might not agree.
Back to the Firefox-like search bar, I strongly believe that it should contain as little controls as possible, since the find/replace dialog would be available anyway. The search bar would be more like a convenient keyboard-only tool to increase productivity for those who know the keyboard shortcuts (Like the fullscreen mode in Photoshop.)
I really like the idea of making it contain only one textbox for search and make it detect Vim syntax to allow replace this way. “s/search/replace/gi” and “/search” syntax is easy to detect either way.
Why shouldn’t there be a dedicated Replace field, by default? If the Replace field is empty, you’re just searching. And a search regexp or string won’t usually take up that much space that it will be visually truncated because the Replace field is there too. And when you start typing a vim style regexp it would hide the Replace field.
You shouldn’t have to be aware of the vim style regexp thingie to be able to do S&R without opening a bigger dialog.
Hmm. Maybe we could have a checkbox for “Vim syntax” on the quicksearch bar. And when enabled, it shows only one search field that’s vimmy. Disabled means that two fields show, and then a search for a vim-RE would search literally for that string.
But… no. I’m discussing this with a friend right now and we both think it starts to look bloated when you mix everything up. You will be able to do quick S&R with the two fields (which is more visually clear and you don’t have to escape the forward slashes) and I, like my friend, get a bit of a bloat alert in the back of my head when you start duplicating functionality and having overlapping concepts like this in the same place. I don’t think we should do that.
The vim style regexp and other commands that we adopt/adapt from other editors could be interpreted by a sort of commandline that could be bound to an F-key or something. Vim has a commandline too… And this commandline could take Intype-ish Javascript commands too when scripting is implemented… And then there should be just this regular quicksearch bar with S&R fields that can take normal regexps.
I’m pretty convinced this is roughly the best solution for all kinds of users.
A tip for everyone: One Billion Buttons Please: Should we build features for experts or newbies?
Frederick: The vim style regexp and other commands that we adopt/adapt from other editors could be interpreted by a sort of commandline that could be bound to an F-key or something. Vim has a commandline too… And this commandline could take Intype-ish Javascript commands too when scripting is implemented… And then there should be just this regular quicksearch bar with S&R fields that can take normal regexps.
Voting +1 on this. If we go this way, I’d see the Vim commandline as a plugin while the 2 fields search bar would be built-in with very simple syntax. The Vim commandline plugin would simply map Vim commands to the Intype API. That would also open the way for an Emacs plugin to satisfy everyone.
Yeah… That might be the way to go.
Intype could have a Javascript commandline of its own though, that could be nice, and then those plugins would just add different “modes” to it (or just add a list of commands that could be recognized and that naturally were given precedence over any JS commands)...
Just a thought I had.
I’m thinking that if *vi * searching is so highly desired, that it should probably be an add-on.
I don’t think the casual user would really know, or want to learn, how to use a completely different search/replace method. They’d simply want to input “Search for ‘Y’, Replace with ‘X’”. I suppose the same could easily be said for Regex find/replace as well. I wonder which one is more standard…
Yes, it should definately be a plugin. Please read the discussion that took place earlier… In short, I think it’s best to just have a standard way of doing normal/regexp S&R, with either a dialog, or an unobtrusive bar in the bottom or top of the editor area. And we should definately not duplicate this functionality by default just to please vi/vim/emacs/whateverothereditor-users. When support for developing Intype plugins comes along, these things could be done as plugins. But I think it was a nice idea that I had, that Intype could have a JS commandline of its own, by default, and that any plugins then could just extend it with new commands/syntaxes…
I have read the above comments. :) I thought, for once, I was summarizing my thoughts and being short, precise, and more specific. :P
Yeah, it didn’t seem like shokk had read the discussion before he posted, though. You I basically agree with, and about general regexp S&R, I think the percentage of users who would see that as the natural way to go about more advanced S&R is a lot higher than the ones who know and use some editor-specific syntax… Intype’s target users especially, remember this is a (for now) Windows-only editor that targets kind of intermediate to advanced web developers and programmers… I’m really convinced that the editor-specific stuff should be done as a plugin for those who really want/need it.
And I hope its going to be a plugin that comes standard with Intype too! :P Let’s see about writing one when the plugin API gets released.
The other issue about integrating such a SR syntax is that it would introduce unnecessary complexity to the program interface, ie, it is not intuitive. Users won’t discover such a syntax by merely opening up the SR bar (of course, you can perhaps get around the problem by having some template samples present in the SR box, ready to be overwritten).
This would also apply to the Intype commandline idea, although I could argue that the commandline is a feature that is generally used only by powerusers (therefore complexity is acceptable) and that SR is a feature that has to cater for everyone: casual to powerusers.
1 to 27 of 27
