Change the length of selected text lines sublime text 3? - sublimetext3

Is there a way to split selected long text into multiple shorter lines?
For example: from this
French President Emmanuel Macron said France will not accept text that does not mention the historic Paris accord.
"If we don't talk about the Paris agreement and if we don't get an agreement on it among the 20 members in the room, we are no longer capable of defending our climate change goals and France will not be part of this," he said on Wednesday.
France was one of the main drivers behind the Paris accord and the French parliament is now debating an energy bill that targets net zero greenhouse gas emissions by 2050.
"Negotiations on the topic of climate will be especially difficult this time," a German government official said.
to something like this
French President Emmanuel Macron said France will not accept text that does not
mention the historic Paris accord.
"If we don't talk about the Paris agreement and if we don't get an agreement on
it among the 20 members in the room, we are no longer capable of defending our
climate change goals and France will not be part of this," he said on
Wednesday.
France was one of the main drivers behind the Paris accord and the French
parliament is now debating an energy bill that targets net zero greenhouse gas
emissions by 2050.
"Negotiations on the topic of climate will be especially difficult this time,"
a German government official said.

There are two ways to do something like this, depending on whether you want to leave the text alone and be able to read long lines or if you want to physically modify the file.
Soft Wrapping
If you just want to view the text but leave it physically the same, then what you want is Word Wrapping. You can toggle the state of View > Word Wrap to turn wrapping on and off, and the options in View > Word Wrap Column specify where the wrapping will occur. Automatic chooses the edge of the window, or you can specify a specific column for the data to wrap on.
This is Soft Wrapping; you'll notice that the lines in the gutter do not correspond 1:1 with the actual lines because there is one physical line but several logical lines (Here the wrap setting is set to Automatic):
The word wrap state is controlled by the word_wrap setting in the default preferences; that determines what the default wrap state is. Changing the wrap from the menu will change it only for the file that you're currently editing, so if you want to change the state permanently, you should change that setting.
Additionally, the wrap_width setting controls where the soft wrap happens, with 0 (the default) being the width of the window (i.e. the Automatic setting in the menu). The menu items under View > Word Wrap Column change the value of this setting to specific values, but you can set any value you like in your preferences.
Hard Wrapping
If you want to physically modify the text, then you want the options in the Edit > Wrap menu instead. Here you can select text to have all of it wrapped, or just put the cursor inside of a paragraph to have only that one paragraph wrapped.
You have the option of wrapping at specific columns or at the current ruler, which you can specify in View > Ruler.
When done in this manner, the content of the file is physically modified (Here I chose the option to wrap at column 70 and turned the soft wrapping from above off):
The position of the ruler (or rulers; you can have more than one) is controlled by the rulers setting, which by default is empty. The menu item above sets the ruler in the current file to the value shown in the menu item, but you can set the rulers setting to anything you want. As above, the defaults for the settings are in your Preferences file and the menu items only change the state for the current file, so you need to modify your preferences to set a permanent value.
It's also worth nothing that the menu items that wrap at specific columns use the wrap_lines command with a specified width argument, so if desired you can craft a custom key binding that would wrap at any position you want.

Related

Is there any way to set background color of lines in GoLand (JetBrains IDE)?

Is there any way to set the background color for certain lines in GoLand (JetBrains IDE) so I can sign what code I have read?
Is it possible to do this? Does not matter if it's an IDE function or via some plugin.
There are a few ways to mark some lines and add them to the "Reading" list:
Bookmarks. It is built-in functionality in IntelliJ-based IDEs. You can go to the line with Authenticator interface declaration and select Edit | Bookmarks | Toggle Bookmark in the main menu. All bookmarks are available in View | Tool Windows | Bookmarks.
3rd-party plugins. I'm aware of MultiHighlight plugin that supports selection of the piece of code.
Sticky selection can do that trick.
there is the brief intro about it:
you can mark a selection to be permanently highlighted, even when your caret moves away. Inspired by "Style token" of Notepad++.
You can define an arbitrary number of Paint Groups. Selecting the appropriate editor action (keystroke or context menu), the all occurrences of currently selected text will be added to the Paint Group and will be permanently highlighted (until you clear the selection with an other editor action). So you can have different text fragments to be selected with the same Paint Group. The Paint Groups are kept when IntelliJ is closed.
You can set different colours for each Paint Group
You can set a marker to be visible on the right side of the editor
You can add multiple selections to the same group
You can convert a Paint Group to multi caret selection (and thus edit, copy, delete, etc. it)
For convenience you can undo the last addition (until the document is edited)
You can cycle through each element in a given Paint Group or in all Paint Groups
Keymap actions are added dynamically for paint, clear and convert as you add more Paint Group

Sublime Text: How can I disable auto scrolling while I'm typing in the Find box?

I am currently trying to write a complex regex for a huge file. Every time I type in the find input box to make a small change, Sublime scrolls me either to the top of the document or to a semi-random location (from what I can remember, it doesn't always scroll to the first match), even when there are matches where I'm already scrolled to in the file. It makes for a pretty painful workflow: I write down the line number on a piece of paper, edit my regex, and then have to "go-to" back to the line I was already at. How can I prevent this, or at the very least, does anybody know why exactly this is happening in the first place?
This is controlled by the Highlight Matches button in the Find and Find and Replace panels, and causes Sublime to show you all of the matches, highlighting one of them and outlining the remainder in a region to show you where they are.
The visual appearance of the button is controlled by the theme you use, but it's always in this position in the panel (and it should have the same icon in all other find panels as well); it also has a tooltip that tells you the name.
When the search term is modified and this option is turned on, Sublime jumps to a match, though this doesn't occur if the panel opens with an existing search term already in it; in that case matches are highlighted but the view doesn't change.
The option also exists in Incremental Find panel as well, but turning it off there only stops other matches from being highlighted as by definition Incremental Find is for jumping to a search term incrementally as you modify it.

Set position of status message in SublimeText 3

There is sublime.View.set_status method which adds message to status bar.
Is there a way to set position of that message? E.g. I'd like to have it on the right, before count of misspelled words, not on the left where Sublime adds it.
There is (after a fashion) a method of being able to specify where in the user addressable portion of the status bar the items you add will fall, but the key part there is user addressable.
In particular, all items that can be added to the status bar by a plugin are always to the left of the standard status bar items such as Line 1, Column 1 and it's only in that left side area that it's possible to specify where the status item is added.
As such you can't place anything to the right of the standard position text or the spell checker's indication of how many words are misspelled.
Within the user addressable part, the status items that view.set_status() adds to the status bar are ordered according to the key value that you use when you set the key.
So for example view.set_status("AAAAA", "Something") will appear on the left and view.set_status("ZZZZZ", "Otherthing") will appear on the right.
This is only partial control since any plugin can add items to the status bar and it's impossible to know what other plugins might be adding items and what key they will use.
I would presume that the ordering is done this way so that even though it's not possible to know with certainty exactly where the item is added, it's still done in a way that's repeatable so that for the user certain items are always in the same relative position while they're working.
This may be why the status bar items for core features such as the count of misspelled words are always placed in known positions.

What is the best way to layout/design a long complex web form to collect user input

I need to design a web form which landlords can use to add rental listings. There are 8 mandatory text boxes and 2 optional text boxes, 11 drop-down lists, 12 checkboxes and one large text area. Any suggestions about how to arrange them in a way that is clean, and uncluttered? My concern is, if the form looks lengthy, they may not want to fill it. So far I have divided the elements on the page into sections, however the page still looks cluttered.
I would suggest that you use 2 pages instead of 1. On the first page, show the 8 mandatory text boxes and follow them with an additional checkbox which makes the 2 optional text boxes appear on being clicked. This means that the user will opt-in for the optional checkboxes making it more acceptable and natural to her. Next, place a submit button which would take the user to the second page.
Put all the 12 checkoxes and the text area on the second page. On page 2, tell the users very clearly that this is the last page they need to fill. They will be less disinclined now since all they need to do is to place a few more clicks.
You may want to split the process of getting all of this data from the user into multiple parts. Conventionally, that would be multiple pages of forms. The problem with that is that it's annoying for the user to have to watch their browser reload the whole page as they move through the form.
A more popular methodology now is to use AJAX to present the larger form in multiple pieces without having to reload the entire page.
In both cases you will need to keep state between each page load or AJAX request so that the back button behaves sanely and the user's previous input reappears as they move backwards (and forwards) through the form.
Unless you have some kind of nifty state-keeping mechanism already written that is generic enough to work for any given form set you may decide to use, welcome to the pain in the ass that is web development.
How about a wizard-style layout?
Break the sections out into separate pages, so components are submitted separately. Make it clear how many sections there are, and how far through the form the user is. Be careful to track the user's progress either in the session, or by keeping state in the form.
This approach makes giving error messages a bit less threatening to users (you never show them the error message "Please correct the following 34 errors").
Edit: Having seen the current form layout, I actually think what you've got at present is very clear, and nicely done.
Do submitters have account profiles that you can use to populate the contact details? If so, I would drop the contact details from the form for creating a listing, and add a review screen that shows all of the information, and gives links for specifying alternative contact details or amending other information. Users then see one screen, plus a review screen with a big "Publish This Listing" button. Amazon's order process uses a good review screen.
Breaking the input into multiple sections is a good idea.
I also like to make most of the input fields invisible, and make them visible as more information is entered. I start with the most important info to be entered first (e.g., name), and as each item is entered, I make further input fields visible. I also give focus to the next logical field that the user is expected to enter as he goes along.
You can use other tricks like highlighting the next field to enter (i.e., changing the background color or surrounding borders of the input field label) to make it even more obvious to the user.
Grouping related fields into separate boxes (with visible borders) may make the info seem less cluttered, too.
This approach makes it look less overwhelming to the user, and makes it more obvious to him what he needs to enter, from start to finish.
Frankly, 33 fields on a single page does not sound all that long for describing a rental listing, especially when 23 of the fields (checkboxes and dropdowns) can default to the most common values. With your current layout, the form almost all fits above the fold. That ain’t bad.
I’d be very cautious about splitting it into separate pages (e.g., as a wizard). First of all, that will take the user longer, because now you’re adding navigation and re-orientation time. Second of all, it will seem to take longer; the user will be like, “Geez, I have fill out a multi-page form?” Thirdly, users can’t tell how much work is expected of them when some of it is hidden on other pages (or by AJAX tricks). Some will not fill out the form at all assuming the worse. Others will abandon it part-way through because they either didn’t plan enough time for it, or just got tired of hitting Next indefinitely. You can mitigate this last problem by saying up front how many pages there are, and showing the user’s progress through them, but that just accentuates the fact that it’s multi-page, and therefore “long.”
IMO, all it needs is some lighter graphic design. I’d drop the “reverse video” section titles and the green background on alternating sections and make it all white. Use color and/or bold text for the section titles. You can combine the Property Description section label with the field label to reduce clutter and redundancy. Consider putting the Pets and Parking fields on the same line as Laundry then spreading the Unit Details fields out vertically so the mis-alignment of the fields is not so noticeable. Alternatively, size the Unit Detail fields so that they are better aligned. Maybe you can drop the “How do you want to be contacted?” field. I’d expect that if users don’t want to be contacted by one of the means, they simply don’t fill out that field.
Other than that, be sure your users understand the importance of these fields –why filling them out helps them find the right renters. Users don’t mind filling out a lot of fields if it’s clear that each benefits them. It’s when users feel like they're disclosing a lot of data to benefit you that they get resentful and reluctant. The importance of the fields you have seems self-evident to me, but maybe you should include a link that explains the purpose and value of the fields.
Finally, make sure there’s not too much clutter and competition from the “standard” page elements (e.g., sidebar menus, legal information).

Navigating with arrow keys

What are some generally accepted practices for navigating between irregularly placed and sized elements in a canvas (such as controls on a form) using the arrow keys?
For example, if the currently focused element is a tall element (A) whose height encompasses three shorter elements to the right of it (B, C and D):
####### #######
# # # B #
# # #######
# #
# # #######
# A # # C #
# # #######
# #
# # #######
# # # D #
####### #######
Which of these elements should be focused when the user presses the Right arrow? The top element (B)? The one in the center (C)?
What if D was focused before the use user moved focus to A by pressing Left? Should focus return to D when the user subsequently presses Right?
I'm wondering if there are some published guidelines for these scenarios.
I haven't looked into any specific guidelines or anything, but it seems that in the first case, when you're on A and you push Right, it should go to B.
If you're already on C or D when you push A, it probably makes sense to go back to that one. I'm less sure about this one, because the user might have gone to A from the bottom as a "shortcut" to get to B (This makes sense if there are a lot of elements in the right column, so instead of going (Up-Up-Up-Up-Up-Up you go Left-Right).
I think it's also important to note what element 'B' is that you're navigating to. Suppose B is a text box. If you go from A to B, will you assume the user wants to enter input and automatically focus their cursor in the text box? This would give a user immediate use of typing into the box, but immediate problems if he/she wanted to move to C or D instead.
I think it's more important to give the user feedback on which field he/she is in. Windows controls tend to suck for showing a well highlighted field, while in OS X, you get a distinctive highlight around the control that is selected (in most cases).
Just make it a point not to get in the way of the user if they want to go somewhere else. Don't lock down their keyboard after moving into A-D if they only want to move to another element.
In general, navigating through controls should follow the user's natural reading order. In Western cultures, that's left-to-right, top-to-bottom. This has been a usability standard at Microsoft going back to the excellent The Windows Interface Guidelines for Software Design and Microsoft Windows User Experience.
In your example, navigation through the controls should go A-B-C-D-A-...
If you're on A and you hit right, you should go to B.
If you're on D, and you hit Left, there are two options: "going left", which is A, or "going back", which would mean going to B. If you choose the second way, there's no place to get lost, although it can look a bit weird at first.
That said, if you choose the first way, I think the proper would be going to B: no need to remember where you were, just where you are, to know where you'll be. ("State is bad. Don't make the user think about it.")
Take a look at what Microsoft says for Vista applications.

Resources