First, PLEASE PLEASE PLEASE - this is not a religious discussion about editors. I just want a How To sort of answer.
That said, in editors where the data is seen as a matrix (sometimes called Eastern Orthodox Editors, examples: SlickEdit, Xedit, E/PM and the switch+alt+A block mode in eclipse) rather than a long string broken into rows (Western Orthodox Editors) it is possible to have a function, usually called "ALL" that takes a search argument and shows only ALL the lines containing that search. So if you had a file like:
11 22 33 44 55
22 33 44 55 66
33 44 55 66 77
77 88 99 00 11
and issued an ALL for "11", you'd see only the lines with 11 in them:
11 22 33 44 55
77 88 99 00 11
The other lines would be hidden and, most importantly, any edits applied would only act on the visible lines, not on the hidden one(s).
So, it there a tool, add-on, built-in, whatever, that will do this for Eclipse? And for that matter MS/VS and NetBeans?
Thanks!
I don't know of such an editor function, but you can do a file search specifying the string and the search view will give you a list of the lines containing the string. It's just that the list is displayed as a tree and not a solid block of text.
Related
when i'm writing my markdown, very often VSCode changes whitespace to something else, e.g., # Example -> # Example. It looks the same, but it's not whitespace (eslint says no-irregular-whitespace which is how I was able to spot it, but in MD this doesn't show).
> `# Hello`.charCodeAt(0)
35
> `# Hello`.charCodeAt(1)
160
> `# Hello`.charCodeAt(2)
32
> `# Hello`.charCodeAt(3)
72
It causes a lot of trouble occasionally. Why does it do that?
I have a string in IDA
IDA string view
that I want to change to "Welcomd" just for a test. How can I overwrite the string. Changing the hex editor does not work for me.
Select the string, and then go to Edit -> Patch Program -> Change Byte
If you're changing "Welcomd" to "Welcome" should mean changing "57 65 6c 63 6f 6d 64 0d 0a" to "57 65 6c 63 6f 6d 65 0d 0a"
Can you be more specific about
Changing the text editor does not work for me
?
Use put_many_bytes function.
(I think its from idc but I'm not sure
Is there anyone who knows how to change the highlight color in the Macro Expansion popup in Eclipse CDT? The color is light grey, and it appears in Original and Fully Expanded view for those matches items.
I didn't find it in any preferences option :(
Code hover background can be changed:
Macro expansion background cannot be changed:
This color can be changed manually.
Go to Eclipse Installation Details -> Plugins tab.
Find plugin org.eclipse.cdt.ui and remember this version.
Go to eclipse installation directory and go to plugins.
Find org.eclipse.cdt.ui_VERSION.jar.
Open this file as archive and extract "org\eclipse\cdt\internal\ui\text\c\hover\CMacroCompareViewer.class".
Open file CMacroCompareViewer.class in any hex-editor.
Find sequence 11 00 D4 11 00 D4 11 00 D4
This bytecode pushes values {212,212,212} to stack before call RGB constructor. Single instruction 11 00 D4 means sipush D4. We need to change this color to more darker like {32,32,32}. So we replace value D4(212) to value 20(32), and sequence must be "11 00 20 11 00 20 11 00 20"
Copy modified file back to archive and done!
The highlight colours match your theme, so it may be that changing the hover background colour will help the clarity of the text.
Navigate through the menus:
Window, Preferences, C/C++, Editor, Appearance color options.
"Source hover background" is at the bottom of that list.
Disable 'System Default' to change the colour, or enable it to try the system default colour.
The source for my answer was here:
Eclipse, change popup text background color when hovering the mouse on a keyword
I simple wanted to know how many characters can be viewed without overflow (horizontal scrolling) on any GitHub source view page.
On OS X v10.9 (Mavericks):
Google Chrome: 125
Firefox: 122
Safari: 121
I attempted to simulate the font-family fall back with the web inspector
On Ubuntu:
Firefox: 126
Opera 12.16: 126
Chromium: 113
I was just testing this again https://github.com/aizatto/character-length
Testing on macOS Sierra 10.12.6 (16G29):
For both:
Safari Version 11.0 (12604.1.38.1.7)
Chrome Version 60.0.3112.113 (Official Build) (64-bit):
When:
Viewing a file (Fixed Length): 117 chars
Viewing a diff (Scales):
920px width - Half of MBPr 15"; Usable but requires scrolling: 58 chars
1280px width - 3/4s of MBPr 5"; 1/2 of 2880px; Decent: 78 chars
1706px width - 3/4s of 2560px: 115 chars
1920px width - MBPr 15": 120 chars
2560px width: 164 chars
With the new GitHub design, 160 characters are visible for me on Ubuntu - Chrome or Firefox.
1280×1024 users will initially see 158 characters if they have a vertical scrollbar, though by scrolling a little horizontally they can still view 160 characters with up to 4 digits of line numbers.
So basically 160 characters is now fairly safe for desktop users. Mobile users are pretty much a lost cause - 37 characters for devices 360 CSS pixels wide.
Thanks to #aizatto for the link to https://github.com/aizatto/character-length.
I'm running the indigo release on Windows Vista.
I have set both the print margin in General -> Editors -> Text Editors and the maximum line width in Java -> Code Style -> Formatter to 100 characters, yet it is still determined to wrap my comments at column 80.
For example, when this is typed at the top of my file:
(longest lines are 90 and 94 characters respectively)
// This comment is over 80 characters long, but it is in no way over 100 characters long.
/*
* The same problem occurs in block comments as well. True, neither problem is code breaking,
* but it certainly is annoying all the same.
*/
It is formatted to:
(lines are 73 and 79 characters respectively)
// This comment is over 80 characters long, but it is in no way over 100
// characters long.
/*
* The same problem occurs in block comments as well. True, neither problem is
* code breaking,
* but it certainly is annoying all the same.
*/
I have tried restarting Java and have hit every "apply" button I can find, but to no avail. It does not appear to be listed as a known issue in the release notes. Is there something I'm missing? Something simple perhaps?
At least on Eclipse Helios (3.6), there's a separate "Comments"-tab on the Formatter-settings, which has its own "Maximum line width for comments"-setting.