PyDev Python Builder lowercase L in string - pydev

I just installed the latest Eclipse Neon, and latest PyDev on that. When opening a python file using the "Python Editor" provided, all lowercase "L"s are automatically displayed as uppercase whenever enclosed in quotes.
Opening the same file in another editor shows all L's as lowercase, so the issue in the Python Editor is purely visual, but it's certainly odd. I've tried turning off code completion and code analysis and it didn't help.
Has anyone else seen this weirdness and found a reason / fix?

Based on the screenshot, I'd say the issue isn't on the editor, but on the font you're using (the main difference from one case to the other is that by default, PyDev strings are italic and for some reason the font you've chosen shows lowercase l very close to L when italic -- although I think that the actual uppercase L is probably different from the lowercase l when italic too).
As for a solution, you can either not show the font as italic (in Preferences > PyDev > Editor > uncheck 'Italic' for Unicode and Bytes) or change the font you're using (in Preferences > General > Appearance > Colors and Fonts > Text Fond and Text Editor Block Selection Font).

Related

Fix issue With VS Code: yellow orange border box around characters

When I type a ا letter in the Arabic language it is surrounded with a colored border box in vscode.
Any solution to this problem?
Your specific case - a series of Arabic characters - might no longer be highlighted in vscode (even with the following settings enabled) as vscode is getting a little smarter about strings of characters it would otherwise highlight.
Contextual Unicode Highlighting
To report fewer false positives, ambiguous and invisible unicode
characters are no longer highlighted if the surrounding characters
visually indicate a non-ASCII script.
Thus, in trusted workspaces, only characters that are invisible or can
be confused with ASCII characters are highlighted, except those that
are contained in a word of non-ASCII characters where at least one
character cannot be confused with an ASCII character.
from v1.65 Release notes; contextual unicode highlighting
Try disabling one or more of these settings (set to false):
Editor > Unicode Highlight: Non Basic ASCII
Editor > Unicode Highlight: Ambiguous Characters
also see https://stackoverflow.com/a/70293571/836330 for more on the Unicode Highlighting options. And https://stackoverflow.com/a/70297896/836330 and https://github.com/microsoft/vscode/issues/138767.
There is also a way in vscode v1.64 to add another locale to your environment so that its characters will not be highlighted as questionable unicode characters.
New setting: Editor > Unicode Highlight: Allowed Locales
Use this when your display language is something other than the language you are using in your files, like French, Russian, Japanese, etc. that is causing the unwanted unicode warning highlights.
Download the language pack you need:
Search in the Extensions view for "language packs". I believe only the Microsoft language packs are supported in the Allowed Locales at this time. The picture above shows the French Language Pack. Install it.
Add its language code to the Allowed Locales setting.
To find the right "code", the easiest is to open your Command Palette after installing the language pack and search for Configure Display Language. You don't want to change your display language but it will show the available language codes:
We see we need fr as the code.
It will make a setting like this in your settings.json:
"editor.unicodeHighlight.allowedLocales": {
"fr": true
}
Before these changes:
After: In theory, with the default options for the other unicode highlight setting, the unicode highlighting should be gone.
[It still seems a little rough to me, you may have different results.]

Alignment of characters in Notepad++

I just wondered why my m-files from MATLAB look so different when I open them with Notepad++ instead of the built-in MATLAB Editor.
It seems that in the MATLAB Editor each character has the same width. Not so in Notepad++ (even I change the language to "M").
Here's a screenshot from a file opened in Notepad++ (left) and in the MATLAB Editor (right).
In the MATLAB Editor all the characters in column X are exactly one below the other. They aren't in Notepad++.
I just played a bit with the tab preferences, without any success.
Is there a way to get the alignment of columns in Notepad++ the same as in the MATLAB Editor ...at least for m-files?
It's because your MATLAB Editor is set to use a monospaced font such as Courier (i.e. a font where all the characters are designed to have exactly the same width), but your Notepad++ is not.
In Notepad++, you can set the font with the menu Settings -> Style Configurator. Select "MATLAB" from the language list (or in fact you may like to select "Global Styles", to do this for all languages), and set the font to a monospaced font such as Courier.
Alternatively, you may like to download a more modern programming font such as Consolas, ProFont, Monofur, Proggy, or Inconsolata. These are all monospaced, and nicer than Courier. You can use the in both Notepad++ and the MATLAB Editor.
It's possible that another issue might be that you have tab characters in your code, which are displaying with a variable width in Notepad++. You can make sure that MATLAB replaces tab characters with spaces in the MATLAB preferences (MATLAB->Editor/Debugger/Tab). To check whether you have tab characters, open the file in Notepad++ and select View->Show Symbol->Show All Characters. Tab characters will display as a short arrow, and space characters will display as a little dot. If you need to change all the tabs to spaces in an existing file, Notepad++ can do this with Edit->Blank Operations->Tab to Space.
Hope that helps!
To add to Sam's answer, choosing a monospaced font specific to your environment's language is recommended. For instance, Courier New on Japanese language may not have the desired result. Choose MS Gothic (for Windows) or Osaka (for Mac) instead.

How to customize Eclipse's text editor code formatting

How can I set my Eclipse's code formatter to allow code rows longer than 80 characters. I know that very long lines is hard to read but in my opinion 80 characters per line is very small value for wide screen monitors.
In Preferences, go to Java > Code Style > Formatter and edit/create the formatter and go to tab Line Wrapping. There in you can set the Maximum line width.
Further on you can in General > Editors > Text Editors also set the Print margin column which should shift up that margin (a 1px wide vertical line in the right side of your code) to the desired position. This however doesn't affect the formatter, only the human eye.
This answer was a bit old, and the path have changed with new versions of Eclipse.
To set the Maximum line width, go to Project > Properties. In the Properties window, go to Java Code Style > Formatter. Select your Active Profile (let the one which is already selected, this is the one you are currently using) and click on Edit. In the tab Line Wrapping, you can set the Maximum line width (80 by default). You can also go to the tab Comments and uncheck Enable Line Comment Formatting if you want your comments not to be formatted on multiple lines with Ctrl+Shift+F.
Don't forget to change the name of the Profile Name; if you don't change it, you won't be able to save your changes (provided the one you are editing is Built-In
Also, you can set the Print margin column in Window > Preferences > General > Editors > Text Editors.
Regarding the "small" value (80), this has just changed (in August 2014).
See "Eclipse is not a terminal anymore – Default line size of Java code formatter is now 120"
(By Lars Vogel)
Project > Properties, Java Code Style > Formatter.
Edit tab Line Wrapping
A three-years old issue is finally addressed:
bug 356851: Default line size of Java code formatter should be increased to 120
It is not mentioned in the Eclipse Project 4.5 (Mars) M1 - New and Noteworthy, but it is still "Verified for 4.5 M1 using I20140804-2000 build".

How can I clean source code files of invisible characters?

I have a bizarre problem: Somewhere in my HTML/PHP code there's a hidden, invisible character that I can't seem to get rid of. By copying it from Firebug and converting it I identified it as  or 'Zero width no-break space'. It shows up as non-empty text node in my website and is causing a serious layout problem.
The problem is, I can't get rid of it. I can't see it in my files even when turning Invisibles on (duh). I can't seem to find it, no search tool seems to pick up on it. I rewrote my code around where it could be, but it seems to be somewhere deeper in one of the framework files.
How can I find characters by charcode across files or something like that? I'm open to different tools, but they have to work on Mac OS X.
You don't get the character in the editor, because you can't find it in text editors. #FEFF or #FFFE are so-called byte-order marks. They are a Microsoft invention to tell in a Unicode file, in which order multi-byte characters are stored.
To get rid of it, tell your editor to save the file either as ANSI/ISO-8859 or as Unicode without BOM. If your editor can't do so, you'll either have to switch editors (sadly) or use some kind of truncation tool like, e.g., a hex editor that allows you to see how the file really looks.
On googling, it seems, that TextWrangler has a "UTF-8, no BOM" mode. Otherwise, if you're comfortable with the terminal, you can use Vim:
:set nobomb
and save the file. Presto!
The characters are always the very first in a text file. Editors with support for the BOM will not, as I mentioned, show it to you at all.
If you are using Textmate and the problem is in a UTF-8 file:
Open the file
File > Re-open with encoding > ISO-8859-1 (Latin1)
You should be able to see and remove the first character in file
File > Save
File > Re-open with encoding > UTF8
File > Save
It works for me every time.
It's a byte-order mark. Under Mac OS X: open terminal window, go to your sources and type:
grep -rn $'\xFEFF' *
It will show you the line numbers and filenames containing BOM.
In Notepad++, there is an option to show all characters. From the top menu:
View -> Show Symbol -> Show All Characters
I'm not a Mac user, but my general advice would be: when all else fails, use a hex editor. Very useful in such cases.
See "Comparison of hex editors" in WikiPedia.
I know it is a little late to answer to this question, but I am adding how to change encoding in Visual Studio, hope it will be helpfull for someone who will be reading this sometime:
Go to File -> Save (your filename) as...
And in File Explorer window, select small arrow next to the Save button -> click Save with Encoding...
Click Yes (on Do you want to replace existing file dialog)
And finally select e.g. Unicode (UTF-8 without signature) - that removes BOM

Double click text selection in CFEclipse

In CFEclipse, I do a lot of double-clicking to select text. The standard behavior is to select all text within the nearest word boundaries. This is problematic when editing code where the original editor didn't use camel-case; for example, they wrote "myObject" as "my_object".
Is there a way to change the double-click selection behavior to include '_' as a valid word character?
In the latest version of CFEclipse, there is now the option to define what characters are considered word boundaries when double-clicking, and also the option to use different characters when using alt or shift keys.
In Preferences, goto CFEclipse > Editor > Text Selection to update this:
(source: bpsite.net)
CFEclipse does not recognize either the underscore or a period as a character for selecting text with a double-click. There is no way that I know of other than rolling your sleeves up and hacking the editor code to change it. I doubt that this will be changed any time soon with the impending release of Bolt from Adobe.
On eclipse 3.4.1 Ganymede, it seems to select the nearest boundaries including the '_' (at least in the java file I am using)
What eclipse version are you using ?
This blog even reports that eclipse3.3 does select word as you are expecting it...
vs.