Can we set a line length limit in QScinitilla editor so that after crossing this limit text will be moved to next line?
Scintilla's documentations explains the line wrap at Window width and not after specific length.
Checked on Scintilla's documentations and I was expecting it will have a method to set the line limit.
Related
Question
When buffer contents have changed how do I know if a line, having say a line no of 100, has shifted to line no 104?
Note: Content of the line may change so can't track the line using search patterns.
Hacky Solution
I was thinking using the TextChanged* events along with the current cursor position and change in the total number of lines will help. But this seems like it could lead to an incorrect answer.
Context
I'm trying to create a plugin as a wrapper around vim's tags functionality.
The issue is: if a tag was inserted at line 100 and 4 lines were added above it, the tag points to an incorrect location, i.e. line 100, whereas it should be 104.
How do I calculate this difference of 4?
Solutions that apply to both vim and neovim would be appreciated.
Documentation for IDWriteTextFormat1::SetLastLineWrapping() is insufficient:
Sets the wrapping mode of the last line. If [the single BOOL parameter is] set to FALSE, the last line is not wrapped. If set to TRUE, the last line is wrapped.
For IDWriteTextLayout2::SetLastLineWrapping() it is equally terse:
Set whether or not the last word on the last line is wrapped.
Some details lacking that I want to know:
Which one is the last line? In my tests, sometimes it is the last visible line that gets the extra word, but sometimes it is the next one, and then more lines follow. (Is it a bug in DirectWrite? In my code?) Here "visible" means (for horizontal lines, in the vertical direction) completely inside the layout rectangle.
How does it interact with IDWriteTextFormat::SetTrimming()? Some tests suggest that behaviour is different when trimming is set. (With SetTrimming(&DWRITE_TRIMMING{DWRITE_TRIMMING_GRANULARITY_CHARACTER,0,0}, nullptr);.)
It was intended for rectangular tiles where the last word of the application name would otherwise be hidden because it got wrapped to the next line. By default, this would yield:
"here is an example of a long application name" ->
<----------->.
here is an /|\
example of a |
long \|/
application
name
So if the tile height was short (say only 3 lines), then only none of the word "application" would be visible, but it's more useful to also show at least part of the next word.
<----------->.
here is an /|\
example of a |
long applica\|/
name
In conjunction with ellipsis character trimming, it looks like:
It always means the last visible line whether trimming is enabled or not, but when trimming is enabled, any partial lines are trimmed out, making the last "visible" the last untrimmed line. So that's the difference you're seeing.
I use Sublime Text (3) for my default Git commit message editor. I try to follow Git conventions using a hard limit on the number of characters per line (50 for the first line and 72 for the rest). I currently have guides set up at those intervals for visual reference, however rather than manually having to put a line return at the end of 72 characters, I would love to have ST automatically insert a line return for me. Essentially, I want to be able to write without line returns, but have actual returns put in for wrapping instead of just visually wrapping in the editor. Is there a reasonable way to do this?
There is a useful plugin for this (that I somehow missed in prior searches) called AutoWrap. AutoWrap does exactly what I wanted and automatically wraps the line after a certain number of characters with a line return, and the settings for activating it and the number of characters can be set by syntax type. Here is my associated Git Commit Message.sublime-settings file (from Packages/User):
{
"rulers": [50, 70],
"spell_check": true,
"auto_wrap": true,
"auto_wrap_width": 70
}
The auto_wrap and auto_wrap_width lines work perfectly with the plugin and I can keep or remove the rulers as need be.
In my .vimrc file I have textwidth=80 and a white line indicating 80 characters per line limit. Now, as I am also using folds, is there any way to cut fold lines to 80 characters.
Right now a fragment of C file in my setup looks like this:
The display of folded lines can be customized by the foldtext setting. In your case you likely want to restrict the width of the text so you would need to write a custom function that does this. As an example consider my CustomFoldText() function (simply specify a maximum width via the g:custom_foldtext_max_width variable.)
I have a text file with special characters as well as normal characters. I am trying to read this file line by line. I have used
string[] lines = System.IO.File.ReadAllLines("Trial.txt");
To read it.
I used a break point and tried to find out the values stored in those lines. It broke some of the lines in between without finishing reading it and stored the rest in a new next line. When I checked the records, I found that the breaking occurs only at the point where there are special characters even though it doesn't happen with a particular special character. If the file has a total of 10 lines and if there is 1 line which has this problem, it reads a total of 11 lines. Can any of you guys pleas help me out with this? The text file is in UTF-8 format.
The File.ReadAllLines method splits the file on carriage return ('\r'), new line ('\n'), or a carriage return followed by a new line (taken from here: http://msdn.microsoft.com/en-us/library/s2tte0y1.aspx).
Check if the line that is not supposed to be split has either of those characters (judging from your reply to Luke Wyatt you probably have a new line ('\n') on that line at the point where it splits).