new TextBuffer(); .setFile(...); .reload(); -> .emitDidChangeEvent missing

[ludwigkraatz]

new TextBuffer(); .setFile(...); .reload(); -> .emitDidChangeEvent missing

[rsese]

Sorry for the delay @ludwigkraatz - I'm not an engineer but chatted with another maintainer so wanted to share what I learned (at a high level); basically, workspace.open is really expecting to open a local file on disk. If that's the case, Atom should be able to handle the rest.

In your case, it looks like you have custom code because you want to work with data from a database - but since it's not just a plain file, it's expected that you would need to use custom code rather than relying directly on text-buffer.

I might not have explained things super well but if you want to talk more about your code the best place to go for help is the Atom Slack or the official message board. We'll close for now since it's not clear that this is a problem with text-buffer but can always reopen or create a new issue if there's a confirmed problem.

[ludwigkraatz]

hey robert, thanks for replying. sadly this does not really feel to be an answer that actually deals with my problem. I'm trying to describe it another way. When trying to use a custom File-Object, i have an issue with the launch process of the editor. There is exactly One place, that seems actually designed for that case: -textBuffer.setFile- Unfortunatly it is still experimental and therefore not handling changes of file-objects belonging to that buffer (over the lifetime of the owning Editor window) very well. Usecase 1: Local File that is encrypted. Will be loaded like every local file using atoms workspace.open() and then tracked by some helper identifying that it is actually an encrypted file. So it relocates the textBuffers File-Object to an encryption-aware one - but the "rerendering" of that action has to be triggered in a hacky way. Usecase 2: the one where the file object is entirely non-local, described in the initial issue message (same issue in regard to the rerendering). The point is - yes i use a custom file - but code is ment to be reusable. And from my dive into the atom+textBuffer repository, the best way to allow for custom code -like the usecases described above- to be integrated into atom, seems to be the textBuffer. It even has this -experimental- notice explaining that this is exactly what the setFile method should be dealing with - at least once it is not experimental/beta anymore and more stable for other usecases than the init of the textBuffer itself.. I'm simply lobbying for that to be considered - tweak up that textBuffer.setFile(), to handle reload appropriatly - which will widen the usecases in which to use the builtin atom modules - as well as provide a stable and therefore more robust framework on which to code customized functionality - for atom. I hope you can help me with that - by identifying engineers within your team and bring this to their attention so they can evaluate this - rather than explaining me why i supposedly should just code everything myself (which from my perspectice would be the conclusion so far; including a different workspace...). Currently i just have not the time on my hands / mind to create accounts for different message boards - or sending mails to get invites to be in some other communication channel.. I'm just trying to help you guys to fix an issue i identified in your code - and was trying to solve that together with people who actually understand the best way how to incorporate this into the current atom-codebase.. I sincerely hope this does not read like an offensive attack/reply. I'm rather disappointed of not being understood and taken seriously in that matter. If it is not possible to handle this (kind of issue) via github, I'm affraid my work on/with atom will be very limited - as this is the way im willing to participate when it comes to the quest of improving/dealing with openSource software. best regards, ludwig ps: i really like what atom has to offer so far - so honestly i'm hoping we get this github-issue communication to work - as i'd like to participate in regards to the actual code and mid-/longterm by enriching the atom-ecosphere. Von meinem iPhone gesendet

…

Am 11.05.2019 um 02:58 schrieb Robert Sese ***@***.***>: Closed #310. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[lee-dohm]

There are two scenarios that atom.workspace.open is currently designed to handle:

1. atom.workspace.open('filename.txt') -- Open a file that exists on disk, which instantiates a TextEditor object backed by a TextBuffer
2. atom.workspace.open('scheme://some-path') -- Find the opener that matches and was previously registered via addOpener, which instantiates its own view and model (for an example, see the implementation in markdown-preview)

It sounds like what you're describing is a hybrid of the two, where you want to open something that doesn't exist on disk but you want the standard TextEditor/TextBuffer objects to handle everything other than the data layer. If you want something like that to happen, then you'll have to register an opener and create the TextEditor, TextBuffer (backed by the custom File object), and whatever else you need by hand.

I hope that helps and let me know if I misunderstood anything.

[ludwigkraatz]

thanks for your reply! well, you seem to focus a lot on workspace.open, so i'm trying to explain the issue from up there: i want to call workspace.open(uri, {file: customFile}) as this would allow me to reduce my code on whats actually custom to my usecase. And as described in the other usecase: this also applies to local text files. The only thing thats different, is that i need a custom file object - that might do de/encrypt, juggling with a db instead/additionally to the local file, or yes, even skipping local file handling at all. as from my dive into the atom code, this (file option) is not implemented currently. so clearly this is quite the change for a very public api - as this might have consequences for how the registered openers would have to react on a present file option. thats why i disregarded that option entirely and tried to focus on what i can do with textbuffer/editor after the openers did their work. that this file-patching code could lie within an custom opener, triggered by uri-sheme:// - sure. but this is a detail, that so far wasnt pressing - as the actual issue is getting my custom file into a buffer: - i have to either deal with stuff i dont want/should not have to deal with, like TextBuffers LanguageMode or in general the whole initialization of it - which seems quite entangled to the textEditor. and anyways - its not like there is an workspace.open(uri, {buffer}) option - which would still have the same problematic implecations on registered openers - so i have to sneak the empty buffer after it was created by the editor and try to patch it with a custom/new file object - which leads to the described issue: if i change the foundation of the textBuffer - its file - it does not emit any kind of reload event upwards to the editor and due to a lack of available method (as far as i could see) i have to dirty-hack one. so from workspace.open (which is an inconvinience in API [to me] rather than an actual issue) -> i hacked my way down to textBuffer.setFile - which [to me] is an actual issue - as it blindly accepts me resetting the file without taking any action in regard to the implecation on the changed content. Although it is clearly ment to handle custom files - event thought marked as experimentL. so either the experimental api textBuffer.setFile should shout at me "stop doing that, i already have a file - you cant simply change that!" or at least give me a way to simply trigger a changedContent event of some kind - because of that "re-setting of its file" currently, it simply emits a "changed path" which is a usecase i understand - but its based on the assumption that when the buffer got initialized with a file, it already had the correct content - which might be the default case. but as 1. the textBuffer already is ment to emit content changes 2. there is no 'simple' way for me to pass a custom file down to the buffer, from up at workspace.open, 3. and in case of encryption, where the need for an actual different-than-default file object might get obvious just after the default file could read the content and some code decide, it was in need of a custom encryption-wrapping file obejct, the addition of a changed-content functionality to the setFile method seems quite the best solution -to me- i hope you understand my issue and aggree. if you, besides that, have other remarks on how to handle my custom File with workspace.open, in a cleaner way than mine - im defentily open for those as well. thanks very much for your help!

…

Am 14.05.2019 um 03:53 schrieb Lee Dohm ***@***.***>: There are two scenarios that atom.workspace.open is currently designed to handle: atom.workspace.open('filename.txt') -- Open a file that exists on disk, which instantiates a TextEditor object backed by a TextBuffer atom.workspace.open('scheme://some-path') -- Find the opener that matches and was previously registered via addOpener, which instantiates its own view and model (for an example, see the implementation in markdown-preview) It sounds like what you're describing is a hybrid of the two, where you want to open something that doesn't exist on disk but you want the standard TextEditor/TextBuffer objects to handle everything other than the data layer. If you want something like that to happen, then you'll have to register an opener and create the TextEditor, TextBuffer (backed by the custom File object), and whatever else you need by hand. I hope that helps and let me know if I misunderstood anything. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.