Markup: Include file-content as part of markdown.
It would be great if we could include certain lines from another file to be showed inside a mardown file.
For example something like:
{5:12}(code/example.java)
Would result in including the specified java file, lines 5 to 12
05.
06. public static void main(String[] args) {
07.
08. system.out.println("Hello World!");
09.
10.
11.
12. }
kanuku
All 139 comments
How would this work if the contents of the file changed? For example, if code/example.java no longer existed on master?
gjtorikian
on 17 Aug 2014
Thanks for the suggestion. See https://github.com/github/markup/issues/172#issuecomment-33241601.
bkeepers
on 3 Sep 2014
This would be a very useful feature...
anthony-cros
on 9 Sep 2016
+1
wvangeit
on 7 Nov 2016
Would be great for boilerplate or site/sub-section wide announcements or sections.
mwpowellhtx
on 31 Jan 2017
+1
MarcinMoskala
on 10 Feb 2017
+1
GJRTimmer
on 17 Feb 2017
+1
sschaetz
on 27 Feb 2017
+1
seanwendt
on 1 Mar 2017
+1
pcejrowski
on 20 Mar 2017
+100000
mghiumiusliu
on 21 Mar 2017
+1
smeggingsmegger
on 29 Mar 2017
+1
NicolaiSchmid
on 31 Mar 2017
+1
scinfu
on 31 Mar 2017
+1
igorrmotta
on 3 Apr 2017
+1
(and it would be great to select language for syntax highlighting for the contents as well)
slayoo
on 4 Apr 2017
+1
brry
on 6 Apr 2017
+1
roblu
on 7 Apr 2017
+1
jgebal
on 22 Apr 2017
+1
chipironcin
on 28 Apr 2017
+1
fab2s
on 6 May 2017
+1
mpires
on 8 May 2017
+1
zanderwar
on 12 May 2017
+1
irusri
on 13 May 2017
+1
Sixdd6
on 2 Jun 2017
+1
angeloocana
on 19 Jun 2017
+1
Instead of using from-line to-line, this could be inspired on how RestructuredText addresses it:
In RestructuredText you can do something like:
.. code-block:: python
:startinline: true
:linenos: true
:linenos_offset: true
:include: somesourcefile.py
:start-after: # begining-regular-expression
:end-before: # ending-regular-expression
Where :start-after: and :end-before: take a regular expression. That makes the snipet resiliant to changes in the code. Same approach could be used here.
bitelxux
on 28 Jun 2017
Instead of defining the range in the markdown document you could mark a section in the code and refer to it via a reference. This way code changes won't affect the markdown (create invalid links, wrong line numbers etc)
elektronikworkshop
on 9 Jul 2017
+1
ronenhamias
on 22 Jul 2017
馃憤
cphoover
on 27 Jul 2017
Any update on whether or not this is being considered?
ranguli
on 28 Jul 2017
Note sphinx has a prolog and epilog
http://www.sphinx-doc.org/en/stable/config.html#confval-rst_epilog
This is starting to get implemented in other tools such as linters
https://github.com/twolfson/restructuredtext-lint/issues/39
jayvdb
on 28 Jul 2017
+1
stopsopa
on 1 Aug 2017
+1
SimonDesautels
on 3 Aug 2017
+1
k0nze
on 5 Aug 2017
+1
cederom
on 6 Aug 2017
+1
Similarly, it would be awesome to reference the contents of a section from another markdown file. This would allow to easy cross reference any overlapping documentation (without needing to duplicate contents) from different markdown files within the same repo
rigelrozanski
on 7 Aug 2017
+1
doughgle
on 18 Aug 2017
+1
gabsn
on 18 Aug 2017
+1
memoryhole
on 26 Aug 2017
+1
yahya-abou-imran
on 29 Aug 2017
+1
UweZiegenhagen
on 30 Aug 2017
+1
Foxh0und
on 31 Aug 2017
+1
adamday2
on 11 Sep 2017
+1
tmlayton
on 13 Sep 2017
+1
MJCD
on 17 Sep 2017
+1
winf-hsos
on 21 Sep 2017
+1
jkiddo-dxc
on 29 Sep 2017
+1
jloveric
on 29 Sep 2017
For what it's worth I was giving this some consideration the other day and I think the only realistic way to implement such a thing is probably to have the resources be fetched as CLIENT SIDE includes.
The server would not pre-parse these 'extensions'. A page could opt into resolving them if it was in their best interest as a 'feature' with a small client side javascript.
For security this could be limited either strictly to same origins or with CORS/CSP outside of the libraries control.
MJCD
on 30 Sep 2017
+1
Patola
on 2 Oct 2017
+1
iilyak
on 24 Oct 2017
I'd love any feedback on my proposal for a client-side extensions lib that would provide this
MJCD
on 28 Oct 2017
I have a simple use case. I have a file version.txt which contains the current version of my project. I want to be able to pull that version number into my markdown eg. so I can reference a particular version of my code in GitHub by its label in my README.md.
mcarans
on 31 Oct 2017
Thanks for your feedback - every bit will hopefully push this agenda along a bit!
MJCD
on 31 Oct 2017
+1 I would love to pull in my .env.example file
SeanCannon
on 8 Nov 2017
+1
proudcommerce
on 17 Nov 2017
+1
pgallir
on 24 Nov 2017
+1
teddyrendahl
on 2 Dec 2017
+1
gabriel-v
on 4 Dec 2017
+1
juliami
on 4 Dec 2017
+1
chiefbiiko
on 10 Dec 2017
+1
naveenkumarmarri
on 17 Dec 2017
+1
webia1
on 20 Dec 2017
Bump
MJCD
on 20 Dec 2017
+1
Artistan
on 22 Dec 2017
+1
debianmaster
on 26 Dec 2017
+1
atherdon
on 27 Dec 2017
+1
dustinstansbury
on 30 Dec 2017
+1
willxy
on 6 Jan 2018
To me the main benefit of not having WYSIWYG is being able to call in external files easily. I think if more markdown flavors included this it would be super helpful.
pdeffebach
on 6 Jan 2018
+1
DDBdrift
on 8 Jan 2018
+1
srayevskyy
on 10 Jan 2018
+1
katia-e
on 15 Jan 2018
+1
sarxos
on 17 Jan 2018
+1
eavalenzuela
on 17 Jan 2018
+1
nielsabels
on 22 Jan 2018
+1
it will be usefull
AlexeiScherbakov
on 24 Jan 2018
+1
zappbrannigan34
on 30 Jan 2018
+42
TermanEmil
on 2 Feb 2018
This is clearly something they never intend to address or even provide response to - it's just a ghost thread headed to nowhere.
CHOO CHOO ALL ABOARD THE GHOST TRAIN
/unsubscribe
MJCD
on 5 Feb 2018
It seems noone is paying attention to this thread so I have opened a new issue referencing this one:
https://github.com/github/markup/issues/1159
mcarans
on 5 Feb 2018
+1
lucasrodes
on 10 Feb 2018
+1
Thoughtscript
on 4 Mar 2018
+1
ahsansher
on 9 Mar 2018
+1
coff
on 16 Mar 2018
+1
theyongdai
on 20 Mar 2018
+1
drmingdrmer
on 21 Mar 2018
+1
SamuelMarks
on 23 Mar 2018
+1
RoySRose
on 25 Mar 2018
+1
hrvojegolcic
on 26 Mar 2018
+1 :p
esperancaJS
on 26 Mar 2018
+1
vicsyl
on 5 Apr 2018
+1
gitburr
on 10 Apr 2018
+1
elamblin
on 11 Apr 2018
+1
verbruggenalex
on 13 Apr 2018
+1
pussinboots
on 16 Apr 2018
+1
dtgoitia
on 17 Apr 2018
+1
knlambert
on 20 Apr 2018
+1
LucaCappelletti94
on 22 Apr 2018
Would be nice. And this thread again makes me think why there's no user-voice-like "+1" voting system :man_shrugging:
Anyway: +1
JosXa
on 12 May 2018
+1
seantma
on 14 May 2018
+1
tkossak
on 15 May 2018
+1
Frodox
on 20 May 2018
Surprised this isn't already a feature for Github Markdown.
+1
NBurley93
on 30 May 2018
+1
jcytong
on 3 Jun 2018
+1
Would fix the exact problem I am having today.
LittleGreenViper
on 3 Jun 2018
+1
basilhariri
on 5 Jun 2018
+1
schulm
on 11 Jun 2018
+1
mrutkows
on 19 Jun 2018
+1
heathsnow
on 20 Jun 2018
+1
webia1
on 24 Jun 2018
+1
krzysg
on 27 Jun 2018
+1
Neuroboy23
on 27 Jun 2018
+1
Suffering56
on 28 Jun 2018
+1
pavelbozhko
on 28 Jun 2018
+1
josemariasola
on 28 Jun 2018
+1
hariel18
on 29 Jun 2018
+1
ismailhkose
on 1 Jul 2018
+1
Tarrke
on 2 Jul 2018
+1
ib4
on 2 Jul 2018
+1
codewithsk
on 3 Jul 2018
+1
dhaeb
on 3 Jul 2018
As this issue is closed, I raised a while back this one which is still open so perhaps has slightly more chance of being noticed by GitHub: https://github.com/github/markup/issues/1159
mcarans
on 3 Jul 2018
+1
phd
on 29 Jul 2018
+1
AppWerft
on 3 Aug 2018
+1
pvcraven
on 4 Aug 2018
+1
aniketgawade
on 13 Aug 2018
+1
grocid
on 13 Aug 2018
+1
hrvojegolcic
on 14 Aug 2018
+1
adahus
on 15 Aug 2018
+1
pascal8888
on 17 Aug 2018
+1
Bia3
on 19 Aug 2018
+1
eeliu
on 24 Aug 2018
+100
ahmubashshir
on 27 Aug 2018
+1
mrJeppard
on 28 Aug 2018
+1
Muldec
on 29 Aug 2018
An empty comment of "+1" adds nothing to any Github conversation.
If you would like to express gratitude for a comment, please use the 馃憤 feature created to avoid this exact issue.
<3 you all
lacymorrow
on 1 Sep 2018
I think the +1 is merely a way to spam the email of the maintainers to attract attention to a popular github feature request issue. If you just thumbs up someone's comment the maintainers do not receive a notification :) If the maintainers do not wish to pursue the request they can always lock the issue.
verbruggenalex
on 2 Sep 2018
Related issues
danieljabailey
路
4Comments
madikhan1
路
3Comments
Alhadis
路
6Comments
woodruffw
路
6Comments
atomoton
路
7Comments
Most helpful comment
+1