Re: [Nano-devel] switching to an existing buffer when file is already open

[Benno Schulenberg]

Op  3-08-2017 om 21:19 schreef Rishabh Dave:
> there were 2 methods to do that. First one I thought
> was to check the i node number and second was to compare absolute path
> names. While both (I tried both) I never found any document saying
> that i node number stays with a file for life time.

It should.  In 'info ls' it says: "This number uniquely identifies each file
within a particular file system".  And in 'info ln': "it is not incorrect to
say that the inode _is_ the file".  But never mind, current nano already just
compares full paths to see whether a file has been opened before when using
position history, so let's continue with that.

> So, current patch
> is the one that compares absolute path names.

Good.

> By the way, patches attached aren't well tested. Recently I couldn't
> find time. Just let me know if they are okay.

Hm...  No, they are not okay.  I've been looking just at the last one,
and this cfn_for_buffer() function is weird.  First: it lacks braces.
Only the indentation shows what your intention is.  It seems to work,
but it isn't certain that all compilers will do the same thing.
Second: what is wrong with simply using get_full_path()?  Third:
your function breaks down when the user uses a tilde in the path name.

For example, type:

  cd  &&  yournano newfile

Then type ^R M-F ~/newfile <Enter>
Your nano will still open a second buffer with the name "newfile".

When looking at the first patch, 0001... you should have merged
the second one into it.  Now I have to mentally replace the wrong
switch_to_next_buffer_void() with something else.

Four details.  One: don't use incomprehensible names like "cfn_...".
Second: use the faster openfile->filename[0] != '\0' instead of
!strcmp(openfile->filename, "").  Third: if (new_buffer == TRUE)
is silly -- just use: if (new_buffer).  Fourth: replace the message
with a simple: "Already open" -- no distracting filename.

Benno