Make File type public

[Timmmm]

Most of the functionality of Files (e.g. range_to_byte_span) actually operates on individual Files but for some reason that struct is private, and you can only use these methods through Files.

I think it makes sense to make File public and move those methods onto it (the Files ones can be kept as wrappers).

[brendanzab]

Similarly to my comment in #248, I'd probably recommend making a custom implementation of codespan_reporting::Files if you're running into these kinds of limitations. My long term plan is to deprecate support for codespan at some stage too, in favour of promoting the use of codespan_reporting on its own.

[Timmmm]

Hmm ok. To be honest the only feature of codespan I am using is range_to_byte_span (from codespan_lsp, it, in order to handle VSCode's incremental text updates for language servers. There's an example of that here.

So what I was going to do is make a custom implementation of codespan::Files, which is impossible because codespan::File is private. But since you are deprecating codespan in favour of codespan_reporting, which doesn't include the range_to_byte_span logic, does that mean that I may as well not use codespan or codespan_reporting at all?

What would you recommend if I don't want to have to deal with the hassle of implementing range_to_byte_span myself, but I also want a database where files are indexed by URI and removable?

[brendanzab]

ahhhh - yeah I'm not sure! One idea we had was to have an lsp backend for the codespan_reporting::Files trait: #227 - maybe this would be sort of what you are after?

[Timmmm]

Yeah I think so. I just want a trait that has a few things to make dealing with LSP changes easier - i.e. range_to_byte_span and so on, but the trait should be for a single file. I don't really understand why even in codespan_reporting all of these methods that really only operate on one file are actually defined on the Files database.

The Files trait should just have methods similar to those on HashMap. In fact, I don't think you should define a Files trait at all. Most people will be happy with HashMap.

I really just want a File trait with methods something like this:

trait File {
  byte_to_rowcol(&self, byte_index: usize) -> Option<(usize, usize)>;
  rowcol_to_byte(&self, rowcol: (usize, usize)) -> Option<usize>;
  replace_rowcol_range(&mut self, from: (usize, usize), to: (usize, usize), text: &str) -> bool;
  replace_byte_range(&mut self, from: usize, to: usize, text: &str) -> bool;
  source_rowcol_range(&self, from: (usize, usize), to: (usize, usize)) -> Option<&str>;
  source_byte_range(&self, from: usize, to: usize) -> Option<&str>;

  source(&self) -> &str;
  set_source(&mut self, source: &str);

  num_rows(&self) -> usize;
  num_cols(&self, row: usize) -> Option<usize>;
}

And then a default implementation of it. Maybe it's simpler if I just copy/paste the line handling code from codespan. :-)