Talk:Text file

message: I agree that this should be merged with plain text.  I think the result should be named "plain text",
but the contents should mostly or completely  come from this page text file.  --NealMcB 17:30, 25 April 2006 (UTC)
replies: text: I disagree. These two terms completely differ, a text file being a file comprised of text alone, and plain text being a snippet of usually unformatted text (that can come inside any type of document, e.g. a presentation or a data sheet). Obviously, their differences should be clarified by correcting their definitions in their respective pages. PaF 21:41, 13 May 2006 (UTC)
replies: text: Yes 'plain text' and 'text file' are not synonymous, but that doesn't mean they shouldn't be merged. The material of this article should be fitted into plain text, and 'text file' should be a sub-section thereof which simply says something like: 'a text file is simply a file that contains text data without any binary data.' If someone searches for 'text file', they should be directed to plain text. --Apantomimehorse 01:23, 5 July 2006 (UTC)

text: I also disagree. 70.58.81.57 22:47, 4 July 2006 (UTC)

text: I object, because just now I have trouble classifying text with my program that uses file (Unix). Structured text, such as XML has a lot of non-textual tags, while plain text (per definition) hasn't. Otherwise, I agree with PaF, Apantomimehorse, 70.58.81.57, Dread Lord CyberSkull, Alex Peppe and Nil0lab. Said: Rursus ☺ ★ 17:19, 25 June 2007 (UTC)
thread_title: Merge with [[plain text]]

message: Text files → Text file – {use singular form as per std}
:Add *Support or *Oppose followed by an optional one-sentence explanation, then sign your vote with ~~~~
*Support Singular is more encyclopedic, I feel. UrbaneLegend 23:01, 17 February 2006 (UTC)
thread_title: Requested move

message: ===Confusing!!===
The article defines text files as approximately plain text, but this is essentially wrong. A text file contains text that is intended for human information transfer as opposed to binary or data files that for most parts will remain unknown for the ordinary user. This means that 
* MS Word produces text files. 
* A yet more confusing example is HTML-files, who cannot be called plain text, but who use to be regarded as text files.
The article must be enhanced to treat structured text beside plain/flat text. Said: Rursus ☺ ★ 19:50, 25 June 2007 (UTC)
replies: text: Besides, having MIME in the article contradicts the intro. MIME is a somewhat structured text. Said: Rursus ☺ ★ 20:10, 25 June 2007 (UTC)
replies: text: MS Word doesn't produce text files, since doesn't produce files that are human-readable without special software (unless you want to look through all the binary blobs for the occassional bit of your text.) Happysmileman (talk) 19:32, 6 December 2007 (UTC)

text: A text file (or plain text file) is a computer file which contains only ordinary textual characters with essentially no formatting.  The term 'text file' is typically used in contrast with the term 'binary file', even though any file is fundamentally a sequence of arbitrary bits, and many computer components (for example, all hard disk circuitry and most system software) make no distinction between file types.  However, a large percentage of application programs can understand and use text files in some way, but few programs can typically understand and use the contents of any particular binary file. Hence the distinction can be useful to computer users.  Said: Rursus ☺ ★ 20:05, 25 June 2007 (UTC)
thread_title: Disputed

message: The article defines text files as approximately plain text, but this is essentially wrong. A text file contains text that is intended for human information transfer as opposed to binary or data files that for most parts will remain unknown for the ordinary user. This means that 
* MS Word produces text files. 
* A yet more confusing example is HTML-files, who cannot be called plain text, but who use to be regarded as text files.
The article must be enhanced to treat structured text beside plain/flat text. Said: Rursus ☺ ★ 19:50, 25 June 2007 (UTC)
replies: text: Besides, having MIME in the article contradicts the intro. MIME is a somewhat structured text. Said: Rursus ☺ ★ 20:10, 25 June 2007 (UTC)
replies: text: MS Word doesn't produce text files, since doesn't produce files that are human-readable without special software (unless you want to look through all the binary blobs for the occassional bit of your text.) Happysmileman (talk) 19:32, 6 December 2007 (UTC)
thread_title: Confusing!!

message: :A text file (or plain text file) is a computer file which contains only ordinary textual characters with essentially no formatting.  The term 'text file' is typically used in contrast with the term 'binary file', even though any file is fundamentally a sequence of arbitrary bits, and many computer components (for example, all hard disk circuitry and most system software) make no distinction between file types.  However, a large percentage of application programs can understand and use text files in some way, but few programs can typically understand and use the contents of any particular binary file. Hence the distinction can be useful to computer users.  Said: Rursus ☺ ★ 20:05, 25 June 2007 (UTC)
thread_title: Analysis of intro

message: Yihiheee!! (Giggering evilly, twirling the moustaches)! I simply rewrote the intro to refer to human text information files. I know there's a conflict between three different interpretations of text files:
# text file = plain text file - doesn't contain control characters, but may contain newline characters,
# text file - is intended for humans to read, 
# text file - is readable by any unspecialized text editor, and may be compiled or interpreted by a programming language.
So in essence my change was too drastic, and if also the original meaning is reinserted beside mine, I will be happy too. Said: Rursus ☺ ★ 20:59, 25 June 2007 (UTC)
thread_title: Evil rewrite made

message: Please add everything you find here (!):
*  - source: tertiary (3), confusion on def'on'usage and on def'on'tech-criteria;
*  - source: primary? (1?), only uses def'on'tech-criteria, and another, for me unknown, meaning;
*  - source: tertiary (3), very vaguely distinguishes between files containing text, and files only using ASCII (obsolete, but generalize to any character encoding);
*  - source: secondary (2), only uses the "contains only alphanumeric characters" definition (which benevolently must also be interpreted to include space, parentheses and interpunction);
*  - source: tertiary (3), uses a defn declaring only ASCII to be used, including "formatting instructions";
*  - source: primary (1), says that text files don't contain "invisible" control characters; contrasts with rich text, binary file, flat file. 
Sample usages:
 
Kidisk 
//musikk  —Preceding unsigned comment added by 88.91.88.113 (talk) 21:05, 17 July 2010 (UTC)
thread_title: Sources of variable quality

message: I was distracted by the criticism in the document, eg. citation needed, vague... I'm lazy right now, maybe when I get home I will fix the criticisms.
--146.145.210.126 12:55, 20 July 2007 (UTC)
thread_title:  the criticism is distracting 

message: The current image accompanying this article should be replaced with something non-stupid.
—Preceding unsigned comment added by Radishes (talk • contribs) 2007-08-03 20:59:26
:Cool. Fire up your favorite SVG editor and create a better one, if the image is so bad this should be a piece of cake. dr.ef.tymac 02:25, 4 August 2007 (UTC)
thread_title:  Stupid image 

message: Sourced or not, this is nonsense:
"text files are intended to be viewed or interpreted by application software, whereas binary files are executable by the operating system."
Just to prove my point: Blender .blend files, MS Word DOC files, JPG, PNG, GIF, TIFF, OGG, MP3, WAV, AIFF, etc are all examples of "binary files" which are "intended to be viewed or interpreted by application software". 
Meanwhile, MS-DOS .bat files, Unix shell scripts, and programs written in Perl, Python, BASIC, and other interpreted languages are examples of "text files" which are "executable by the operating system". The footnote about "source code" doesn't alter this fact: compilation or interpretation often happens in RAM and often no binary file is created in the process.
So, this is a totally wrong distinction to make.
Also, note [4] is NOT a source for this statement, it's an explanatory footnote.
What distinguishes "text files" from "binary files" is that the byte stream in a text file has a simple, unambiguous mapping to a sequence of characters which may be rendered as human-readable glyphs, arranged in a simple human-readable form.
We do use application software to do this rendering, but that is equally true of many binary files, so it is not a distinctive property of text files. The definition of text file is also tightly linked with the concept of a "text editor", which is an application specifically designed to manipulate text files. Indeed, a good definition of a text file is "a file which may be easily processed using a text editor".
"Plain text", though it probably has more than one distinct meaning (and probably therefore deserves a disambiguation?), in this context, means a text file which furthermore does not contain special formatting instructions (unlike XML or HTML, for example), usually called "markup". Thus, "plain text" contains little or no structure (this is fuzzy because paragraph breaks, newline characters, and setting headings off by empty lines can all be thought of as exceptions).
The term "text file" actually dates from a time when it was essentially synonymous with "ASCII encoded file", but the rise of other encodings, and particularly Unicode has stretched the meaning by making what we think of as "text files" more complex and less unambiguous. But even so, there is a clear distinction between a straightforward representation of text and a rich-text or page-description language which contains complex formatting information.
Digitante (talk) 14:32, 11 February 2008 (UTC)
replies: text: I agree that statement was very misleading. It couldn't be allowed to stand, so I removed it.  The intro needs to be enlarged now, I'd guess, but I'm not prepared to do that; feel free.  Note that there are plain text, plaintext, etc. articles existant.  -R. S. Shaw (talk) 21:32, 11 February 2008 (UTC)
thread_title:  Highly questionable wording in intro 

message: The article says:
"The end of a text file is often denoted by placing one or more special characters, known as an end-of-file marker, after the last line in a text file."
This is incorrect information supported by a [weasel word]. Most file systems don't use the concept of "end-of-file" marker, and most systems definitely don't use a special marker for the last character in a text file.
It is arguable, on the other hand, wheter the last line of a text file is or isn't ended by a newline marker (whichever it is, CRLF, CR or LF). But the newline marker is definitely not a marker for the end of the file.
-- Rgiusti (talk) 15:19, 9 August 2012 (UTC)
thread_title:  End-of-file marker? 

message: I happened to notice today a peculiar dogma or "double-standard" that is being implicitly asserted in this article with regard to textual/string representations.  On the one hand, a "modern" OS is said to no longer require end-of-file markers, seemingly equating progress to this feature.  However, on the other hand, lines themselves are still typically ended with new line character(s), so it would seem that this "anachronism" survives at the line level of detail.  To my knowledge, this would be due to the difference in the abstractions themselves.  File lengths, being the domain of the OS, are apparently more "modern" than the file formats, which are effectively invisible to the OS.
All in all, to me, this seems to presume a bit of glibness within the article in recognizing the trifling optimization at the OS-level, while ignoring the bigger potential optimization at the line-level.  I'm not sure what to make of this, except that I find this observation interesting, and would prefer that the article not be so dogmatic.  75.139.254.117 (talk) 04:22, 20 November 2016 (UTC)
replies: text: Well, end-of-file markers are redundant because the information about file size is otherwise stored in file metadata, and this information is required there because of different properties of modern file systems. File metadata does not store the information about individual lines within a file, mostly because there is no good use for such information outside text file editing/displaying, in which case significant portions of the file would be read anyway. Of course such metadata could be store in some file system, but then associated data structures would end up taking more space then single LF byte, which is hardly an optimization. So basically the article is right in recognising deprecation of explicit EOF markers but not of explicit EOL markers. — Dmitrij D. Czarkoff (talk•track) 18:02, 27 June 2017 (UTC)
replies: text: Translation: EOF information is not necessary because start of file (or the current segment of the file) as well as its size (or location of its end, which is equivalent) is available external to the file. While a line may consist of zero, one or 100 thousand characters. For instance, Microsoft Notepad doesn't insert line breaks in lines that 'run off' the screen. That is quite appropriate, usually. The only way to know where a displayed line will (or should) break is to know both the details of the display device and the details of the font to be used to display it. Neither is generally available to the file.72.16.99.93 (talk) 08:25, 25 November 2018 (UTC)
thread_title:  Curious observation 

message: There is a move discussion in progress on Talk:CTXT (media) which affects this page. Please participate on that page and not in this talk page section. Thank you.  —RMCD bot 10:45, 13 May 2018 (UTC)
thread_title:  Move discussion in progress 

message: I have serious issues with the article. It generally assumes that a text file is intended for display. That's just not true. Text files are used for a variety of reasons, even when the information is NOT intended for display (or printing). The article claims the file "is" composed of characters. Not really, the file is composed of binary (virtually always) data which "should be" interpreted as computer characters. (Where computer characters include letters (graphemes), digits, punctuation marks, and control characters - what the Unicode Consortium calls 'code points'.) Text files are used generally because they can be easily understood by humans, not because they will be. That is, they might be used to encode information to ensure the quality of the information, or may be used because the interpretation of the contents is straightforward, simple, and (assuming the reader is literate in the underlying language) direct (should that ever be necessary). The fact that most browsers and word processors can easily display the contents of a text file (due to historical precedent) is another reason, but we have to keep in mind that even the simplest display requires a whole lot of computer code to take the binary bits on a magnetic film or charges on a silicon chip and create dots of light on a computer monitor from them. Is that task substantially easier than interpreting a binary file? Not necessarily, in fact interpretation of a binary file may be easier and faster for the computer/electronics than display of a text file. The article is written as if the author believes that these characters actually exist in the file. While a simple way to look at it, and if the audience is composed of middle-school students, it might be an optimum way, perhaps some acknowledgement of the reality wouldn't be too difficult to keep in mind.72.16.99.93 (talk) 08:16, 25 November 2018 (UTC)
thread_title:  Wrong on many levels. 

message: Some people here are trying to define what a "text file" actually is, but they struggle because they don't acknowledge that a single file can be more than one thing.  I have a certain file on my computer: 
* It is a text file,
* It is an XML file,
* It is a Scalable Vector Graphics (SVG) file, and
* It is an Inkscape document.
When I say that it is a "text file," What I mean is, it makes sense, under some circumstances, to open the file in a "plain text" editor (a.k.a., "programmer's editor"). The Inkscape document format is defined as annotated SVG, SVG is defined as an XML application, and XML is defined as plain text that obeys certain syntax rules. That's four distinct levels of abstraction, and that's without even broaching the subject of what the document looks like when rendered as SVG.
I also have an .xhtml file. That's even more fun to describe because it is text on more than one level: It's text, represented as XHTML, which is a form of XML, which is represented as plain text. 173.75.33.51 (talk) 19:30, 31 August 2020 (UTC)
thread_title:  Article fails to acknowledge levels of abstraction.