If I open a text file with one and don’t save changes before I open another text file without specifying which editor I want to use. the newest open file overlays the current one in progress, wiping it out. Apparently no recovery. If I have two open, I cannot open a third without destroying data. This began occurring a month or two ago. I would rather not take on learning VIM or other high end editors for simple tasks that don’t require any of those features.
You better check what your openSUSE version is. Leap 42.1 is current, Leap 42.2 is in Alpha test.
KWrite should open a new window for every file you open in the file manager.
Kate (which is probably your default text editor) opens a new tab in the same window with the new file, that’s probably what you mean with “the newest open file overlays the current one”.
The previous one is not “wiped out” though.
You can switch between the open documents, just click on the tab’s title like you would do in a web browser.
You can also click on “Documents” on the left to open the “Documents” side bar that shows all open documents.
The previous file’s contents will also reappear if you close the current one (the tab/document, not the window).
What also may happen is that there’s not enough space to show all tabs if you open a new one. In that case the “Quick open” icon in the top right of the window will show a “+1” or similar, clicking on it will also show all open documents.
If you don’t like Kate’s tabbed behavior, just set Kwrite as default application for text files in “Configure Desktop”. Or uninstall Kate, that should also make Kwrite the default.
As mentioned, Kwrite will open a new window for each document.
Oh, and btw, Leap 43.2 will not be released earlier than in about 3 years. I have no idea how kwrite and kate will look and behave then… 
Due to my poor eyesight, I often cannot see what I just typed, so it often comes our wrong. All are 42.1.
Also, there is no mention of tabbing being added when your just do default updates.
Where should it be mentioned?
And this tabbing has not been added by any (recent) updates.
That was already the case in KDE4’s kate (i.e. since years), but this one didn’t even show tabs.
Maybe you didn’t have kate installed before, but something pulled it in?
I normally did not use Kate until I had problems running two separate incarnations of Kwrite. So now I could dispose of Kate and just do tabbed multiple files. And that prevents viewing them all at once, and makes copies of things from one to the other more difficult.
Also with Kate, the search and replace is now all screwed up. There is no exit token in the display so the only exit is by closing the file. It then reappears on the next open with Kate. And some of the options have the text obscured. I assume that that is due to the screen height and the font size. I have to have a minimum 14 fort so that is out of the question.
Guess I’ll have to use nano!
They need to provide something to say what was fixed/changed prior to running the update!
I don’t think what you expect should be supported.
Unless you save the file, you can’t lock in changes.
Until you save your changes, the changes you make are stored in a temporary file which of course is deleted or purged when you save.
Unless the alternate (or even a new window using the same app) application can read that temporary file, there is no way unsaved changes should be seen in another app, and even then because it’s not likely that apps update dynamically from that temporary file it will mean that if you continue to switch back and forth between the apps, you will lose data.
In other words, unless you use an app which <very specifically> supports dynamic updates in multiple application instances (like Google Docs or Piratepad), it’s probably bad practice to open the same document and edit in multiple applications or application instances.
One way to do what you’re describing is to use a versioning file system like git or svn. A versioning file allows multiple versions of a file to exist which can later be merged if desired.
TSU
One or more files can be opened in Kate. Then the viewing window can be split into multiple panes or more windows can be opened for the same Kate session. If an edit it is made in one pane, the changes are simultaneously reflected in any other pane that is displaying (e.g. a different part of) the same file. This is really useful when editing code or long legal documents, and is separate to the use of a versioning system.
Yes, running multiple panes <in the same application instance> should be a supported and recommended use.
Only thing to doublecheck for any app (not just Kate) is whether the pane automatically refreshes when it has focus (ie selecting the pane), or if needs to be manually refreshed. But, the underlying idea is that you only have one application reading the temporary file holding the changes so the displayed content can be managed properly.
TSU
There should be absolutely no problem running two (or more) separate incarnations of Kwrite.
It works fine here.
Can you please explain in more detail what the problem is?
Have you tried to right-click on (a) file(s) and choose “Open with”->“Kwrite” to make sure it is actually opened in Kwrite?
Have you tried to set KWrite as default application for text files in “Configure Desktop”->“File Associations”?
Guess I’ll have to use nano!
There are others as well, like Emacs or gnome-edit.
Or Kwrite.
They need to provide something to say what was fixed/changed prior to running the update!
Who are “they”, and what changes in updates are you talking about?
Every official openSUSE update has a description of the changes, there are package changelogs, and the changes are mentioned in the upstream release announcements normally.
But kate behaves this way since at least 13 years!
And there have been no changes to Kwrite in this regards, there hasn’t even been an update recently…
PS:
That’s not completely true either.
Yes, there is no “exit token” or close symbol.
But if you click again on the “Search and Replace” button (where you clicked to open it in the first place), it will disappear.
You can also show/hide the “Search and Replace” tool view in Kate’s menu: View->Tool Views
And again, this is how Kate works since years.
And it’s standard KDE behavior too.
To understand what has to happen is to understand why things might or might work.
The basic thing to know is that the mentioned text editors store changes to the file in a temporary file until the file is saved.
So, if the file and unsaved changes are to remain consistent (maintain integrity) any application that opens the file with intent to make further changes needs to access and use both the original file and the file that holds the temporary changes. This means that multiple panes, and even in <most> cases multiple instances of the same app should be able to do this without a problem. If another, different app (eg Kate and Kwrite) were to open the same file simultaneously, it still comes down to the fundamental concept just described, ie When the second app opens the same file, do you see all the unsaved changes?
But, there is also an additional important concept, whether changes are automatically updated in <all> apps which are accessing the same file. Typically, unless an app was designed to open a file which has also been opened elsewhere, there will not be an auto update feature, and this is where you will cause problems. Without an auto update feature, the User has to constantly hit the Refresh or Reload constantly to be sure the file being edited hasn’t been “saved” by another application or otherwise been significantly modified.
So, for example the following using even just 2 instances of the same app…
Open a new file in Kate.
Write some text “This is some basic text”
Do not save, and leave the file open.
Open a new instance of Kate and open this same file.
You should see the unsaved “This is some basic text” in this second Kate because both Kate instances can read the same original file plus the file holding the unsaved text.
Now, in one of the Kates, type some additional text “This is some added text” and save.
In the <other> Kate which is still displaying only “This is some basic text” type something that’s brand new like “This is going to cause a headache” and now try to save.
The above is likely what happened in the OP’s original post when he described his scenario using 3 app instances.
This illustrates the basic versioning issue in all shared file systems (multiple simultaneous access with editing permissions).
It’s why Windows file systems lock files when accessed by applications, on Linux those file locks don’t exist by default so are sometimes implemented by the application, else the system needs to implement some kind of merge resolution. Besides CMS apps, you can also implement file versioning systems like Git and SVN to avoid these scenarios which affect file integrity.
This is also why I endorsed the idea of using 2 panes over using multiple application instances, at least there is the <possibility> that within the same app the pane might auto-update (but needs checking).
TSU
Welcome to UNIX® and everything that looks or smells like UNIX® (*NIX): Linux; Android; Apple OS; BSD; AIX; HP-UX; Ultrix; . . .
[HR][/HR]A basic property of the way in which UNIX® and similar systems handle files (“Everything is a file.”) is that:
- Everything
(meaning also Anything) which has any particular file open (notice the “Everything” – more than one instance of anything can open any particular file – usually [more in a moment]), can write to that file and, everything else which has that particular file open is signalled that the file’s content has changed.
For example:
I create a text file in Dolphin and then open it with Kate and type some content and save the changes without closing Kate.
Then I also open that same text file with KWrite and, make some additional changes which I save without closing KWrite: the Kate instance indicates that some changes have been and asks if I wish to update the displayed text content, plus some other options.
Then, from a CLI session I begin a VIM session to make further changes to that text file’s content and, write the changes without closing the VIM session: both the Kate and KWrite sessions inform me of the change and ask what shall be done.
Unfortunately I haven’t set my VIM to track changes in the opened file: it only notices that the file has been changed by something else and asks if I wish to overwrite the file – which it does Action for me: check how to make VIM refresh it’s buffers.]
[HR][/HR]This is all part of the UNIX® (and Linux) system library function which programmers use to open files – the function open().And, as with all programming calls to system library functions there are (many) options, including options which define the way in which the file shall be opened and the mechanism by which changes to the file shall be indicated to the user’s process.
Unfortunately, almost no user applications offer settings which change the file open behaviour for that application.
That’s not really true.
Applications have to monitor files for changes themselves.
There’s nothing in the system that does that automatically, and in particular not open(), which does just that, open a file (it does not monitor the file for changes, and it does not notify the applications of changes, which would not even be possible technically).
The kernel does provide functionality to get notified of file changes, but applications have to explicitly use them.
Libraries like KDE Frameworks e.g. make that easier for applications.
Unrelated to the original problem in this thread though, I’d say.