file format/encoding "tag" on status line?

[Jose Koiller]

Hello All,

Good evening.

I was wondering if there would be an easy way to set up the "custom
info" space in the WinEdt status line to show the encoding format for
the current file being edited.

For example, while editing a UTF-8-encoded file, the tag "UTF-8" (or
some such thing) would show up in that space. When editing a
CP-1252-encoded file, a tag like "1252", "ansinew", or simply "ANSI"
would appear. To check this info now, I have to go the "document" menu
-> "document settings" -> "format" tab (or to click on the 4th space
of the status line after the "?" space, and then the "format" tab).

Some context, in case anyone is interested: When exchanging .tex files
with collaborators, file encoding can be an issue. For example, I was
editing a UTF-8-encoded main .tex file, using
\usepackage[utf8]{inputenx}. When I received another file from a
collaborator to \input{...}, I ran into trouble with my TeX engine,
because that file was CP-1252-encoded, and had some accented
characters. (This collaborator was using an older, non-unicode
compliant version of WinEdt, I think.) WinEdt opens and displays files
with different encodings within the same project without any errors or
warnings, but the TeX engine isn't so graceful... It took me a little
while to figure out what was going on...

I think it would be nice to quickly check the encoding format of new
files I open, just by glancing at the status line...

Thanks a lot, and regards,

Jose

[WinEdt Team]

Jose,

Post by Jose Koiller
I was wondering if there would be an easy way to set up the "custom
info" space in the WinEdt status line to show the encoding format
for the current file being edited.

This is currently not possible because there is no macro function
that would return current document encoding (you can only see or
change it in documents settings dialog). Even if there was one, it
would be bit complicated because you would have to add custom code
"SetInfo(...);" to Activate Document Event handler...

Since this information could indeed be of some interest under
certain circumstances I will consider adding a new panel for this
purpose and you will be able to enable its visibility...

WinEdt (by default) tries to load document in UTF-8 but if a
document contains illegal characters it changes its encoding to
your default ANSI code page without making a fuss (as long as no
characters are lost). I'll think about an optional extra panel for
the next version...

Best regards,

alex

[Ulrike Fischer]

I'll think about an optional extra panel for the next version...

Well if you think about extending/changing the status line:

Could there be an option to rearrange the fields? Or to even to get
a two line status line? I often resize winedt so that it occupies
the left side of my monitor while on the right side is the document
I'm trying to convert. But then I can't see two (for me) important
fields of the status line: The main file information and the custom
field (where I stored the information about the active TeXsystem and
the active pdf-viewer).

[WinEdt Team]

Ulrike,

Post by Ulrike Fischer

I'll think about an optional extra panel for the next version...

Could there be an option to rearrange the fields? Or to even to get
a two line status line? I often resize winedt so that it occupies
the left side of my monitor while on the right side is the document
I'm trying to convert. But then I can't see two (for me) important
fields of the status line: The main file information and the custom
field (where I stored the information about the active TeXsystem
and the active pdf-viewer).

Two-line status bar is out of question (I am just not going there)!

Perhaps I will completely revamp status line settings to alow
arbitrary order of panels with predefined meaning and allow more
custom panels with additional properties for extra info that some
users may appreciate.

Beside the arbitrary order (and a visible property for each panel)
I will also introduce an option to have a panel resized to fit its
caption if the caption is wider than the specified default string
(which is used for minimal width). This way you can size some
panels more reasonably and if, for example, the string withy many
submodes exceeds this width the panel will be extended as
necessary. One may not want to use this too often (as resizing of
panels may be an annoying distraction) but now and then (when an
average string is much smaller than an odd long one) it may be
useful...

PANEL property in [STATUS_BAR] will have to contain sub-properies
to make them customizable like this. The (visible) panels will
appear in the order that you list them. The caption and macro
response can be controlled by specification of these two properties
or (in their absence) by predefined values for standard panels...

The downfall of this extension: it will be impossible to make
automatic upgrade of your current status line settings. If you
customized [STATUS_BAR] section you'll have to do it again from
scratch (it should not take more than a minute to do so).

This should take care of completely customizable status line for a
while but it will take a few days to implement properly.

Best regards,

alex

[Jose Koiller]

Dear Alex,

Thank you very much for your feedback.

Post by WinEdt Team
Since this information could indeed be of some interest under
certain circumstances I will consider adding a new panel for this
purpose and you will be able to enable its visibility...

Thanks a lot. Checking the document settings dialog isn't a big deal,
but, again, it would be nice to be able to check this at a glance... I
understand that if I use WinEdt submodes, a string such as ":UTF-8" or
":CP1252" will show up in the document mode panel, which is sort of
what I'd like. The problem is that I may receive or download "random"
.tex files from different sources using different encodings, and with
no comment lines indicating modes and submodes for WinEdt...

Post by WinEdt Team
WinEdt (by default) tries to load document in UTF-8 but if a
document contains illegal characters it changes its encoding to
your default ANSI code page without making a fuss (as long as no
characters are lost).

As a side note, it's really interesting to have these
"behind-the-curtains" bits of information on how WinEdt works... I
didn't know much (or, really, anything) about different encodings
until this became an issue, and I had to do a little "research"
(mostly on Wikipedia...) about them. It's interesting to understand
how a knowledgeable developer such as yourself deals with this stuff
in practice.

Best regards,

Jose