all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: John Darrington <john@darrington.wattle.id.au>
To: Alex Kost <alezost@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Cosmetical change: remove inconsistent "$file ends here"?
Date: Sun, 25 Sep 2016 11:32:04 +0200	[thread overview]
Message-ID: <20160925093203.GA2317@jocasta.intra> (raw)
In-Reply-To: <87a8ewl6tq.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

On Sun, Sep 25, 2016 at 11:30:41AM +0300, Alex Kost wrote:
     ng0 (2016-09-24 20:00 +0000) wrote:
     
     > We should either be consistent with this in all files or remove this
     > altogether in my opinion.
     >
     >> ng0@shadowwalker ~/src/guix/guix-no-changes$ egrep -nr "ends here"
     >> gnu/build/vm.scm:323:;;; vm.scm ends here
     ...
     > What do you think?
     
     I don't know what the original purpose of this convention is, it was
     probably invented in those ancient times when dinosaurs walked by
     streets, but I kinda like these "ends here" things :-)
     
     The only purpose I see in using them: you can be sure that there will
     not appear redundant newlines (introduced by untidy commits) in the end
     of files.
     
     Anyway, I vote for leaving them and adding the missing ones.
     

I have a better idea.  Let's remove these verbose messages, and write an API,
which is capable of opening and streaming files , we could call those functions - 
for example  - "fopen" and "fread".  But here comes the clever bit:   We also
provide a function - let's call it "feof".

This approach will have the advantage that we could use this API to write things
called "editors" which might display some user friendly string such as "End of buffer" 
when the end is encountered.

Once these tools are developed, we could inform the community that they no longer
need to put the string "file ends here" at the end of their files.

WDYT ?


-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  parent reply	other threads:[~2016-09-25  9:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-24 20:00 Cosmetical change: remove inconsistent "$file ends here"? ng0
2016-09-25  8:30 ` Alex Kost
2016-09-25  9:21   ` ng0
2016-09-26  8:32     ` Christopher Allan Webber
2016-09-26  8:45       ` Andy Wingo
2016-09-25  9:32   ` John Darrington [this message]
2016-09-25  9:38   ` Danny Milosavljevic
2016-09-25 17:45     ` Hartmut Goebel
2016-09-25 17:55       ` Vincent Legoll
2016-09-25 17:59         ` John Darrington
2016-09-28  8:38   ` Ludovic Courtès
2016-10-06 19:18     ` ng0

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160925093203.GA2317@jocasta.intra \
    --to=john@darrington.wattle.id.au \
    --cc=alezost@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.