LQ Suggestions & FeedbackDo you have a suggestion for this site or an idea that will make the site better? This forum is for you.
PLEASE READ THIS FORUM - Information and status updates will also be posted here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I want to suggest something related with the code tags.
The code tags do not break long lines, as this is usually expected.
In my opinion, there should be and option to pass it to break lines longer than 80 columns. Longer columns are not so easy to read. Further, the programs I write also have long lines in them, although my terminals width is usually 80. The longer lines can be things copied from terminal (like man pages), comments or source code (also depending on the language in use). The editors usually break the long lines to fit the terminal (or window).
[color] has options, so I imagine that it should be easy to add one (or a few) to [code]. I would like the default to be "break lines", or to have another tag for that. An option to other widths may exist (if more than one option in the some tag is not easy to do, let them be the actual value in the option).
The font tags exist, but they are too long to type. I wish the existence of [pre][/pre], just to set a different font (not exactly the same as HTML, which is like our [code]).
--------------
The problem: the code tags appear with extra empty lines after their text ended. I do not remember pointing this before, but the idea is not new for me.
In this thread, there are several examples of code tags. My tags are manually typed, and in separate lines (which I imagined that cause the problem, wrong). For me, it is much easier to type than a few clicks to set them. When quoting others' posts in that thread, I have seen the use of "normal" ones, created by the site (and all these tags are, IMHO, very ugly, due being upper-case).
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,680
Rep:
To me, at least, the point of the code tags is that there is no formatting so things can be read verbatim and, also, things can be pasted without the worry of "Did it wrap or not?".
I would suggest that should an output be posted which "had consistently over-long lines" it could be a symptom in and of itself.
Last edited by 273; 06-14-2017 at 03:04 PM.
Reason: Typo
when copy paste, I just go to the end of the line hit enter to chop it off giving it that end line hidden thingy whenever it doesn't do that after posting. this requires hitting the edit button and fixing it after posting.
@273:
Maybe you are wrong. I think that all formatting (or something close to that) we can do in the the posts, are also available inside the code tags: in the thread I pointed, I use color tags inside the code tags, there is no problem.
Pasting or writing source code with brackets there, may give unwanted effects (if they are not escaped), I think.
And you are wrong that long lines are a problem. There are many programs, languages and manual pages, among other things, I have seen in the code sections in the LQ fora, that have long lines that are formatted *only* we they are shown to us (in their original source).
@BW-userx:
Your first sentence, too long, is a bit hard to understand. I assume what it is with the second sentence, but I may be wrong. You seem to try to justify the lack of a feature, is that right?
Look at this post. It has a code section with several lines that do *not* exist in the forum code I wrote! It somehow makes them, it is a bug!
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,680
Rep:
Quote:
Originally Posted by dedec0
And you are wrong that long lines are a problem. There are many programs, languages and manual pages, among other things, I have seen in the code sections in the LQ fora, that have long lines that are formatted *only* we they are shown to us (in their original source).
You're misunderstanding -- that's actually my point. The code tags can be used to show the exact command give or its output.
If LQ arbitrarily wrapped at 80 columns things would look artificially wrapped to those reading on screens where the code block could have more than 80 columns.
Again, the main point of code blocks is that they can show commands and/or output without formatting.
@BW-userx:
Your first sentence, too long, is a bit hard to understand. I assume what it is with the second sentence, but I may be wrong. You seem to try to justify the lack of a feature, is that right?
Look at this post. It has a code section with several lines that do *not* exist in the forum code I wrote! It somehow makes them, it is a bug!
off the top of my head.
when copying and pasting one has to keep in mind that the hidden formatting within it is not carried over to that in which it is being pasted into, and some times it is. That all depends on the recipient of the text in how it deals with it.
It has been my experience that it all depends on the recipient in how it deals with it.
say for instance one writes something in LibreOffice, it has hidden formatting tags within it. If I write this out in LibreOffice first then copy and paste it into here using the code or quote tags what takes place?
When the hidden formatting codes (tags) or whatever it is that they are called to keep the formatting in the text are not there then it turns back into a flat file that has nothing to keep the formatting, so it is then one big line of text.
this is not a bug it is how the software was written to deal with copy paste as the programmer must have had in mind that one will type in what is needed between the code or quote tags.
the limitations are not because of the one that is using this software ie LQ . As LQ did not write this code to this "blog" forum.
I do not know what capabilities they have in order to modify the code to the formatting of text or how much actual work it will take to get it to work to your speciations.
I do know it is not a bug but a design issue. To have to write code that will check for the code or quote tags first then assign a 80 char rule to whatever is in between them. I am sure is not as easy as one may think.
yes it is a pain in the butt sometimes to post then look at it, only to find that what I or you or someone else did had not kept it formatting, only to have to go back in and fix it. but that is life. a pain in the butt.
going into what @273 said, too the code or quote tags which ar the same by a different name, allow the user to formate the text to how they want it to look within the complete text post. In order to get it to look like they want it to look like.
for instance in coding a certain format is apply for readability.
Code:
int main()
{
function(){
do something,
do some more
}
if [ something ]
then fo this
function(){
do something here
}
return 0
}
if it was to format everything at 80 then what could happen to that formatting you just read?
the tags provide a means to point out what is within it. to separate it from that other text within the post along with allowing it to be formatted like I just did, and for easier readability. as apposed to this.
int main()
{
function(data type, data type){
do something,
do some more
}
if [ something ]
then fo this
function(end-point, midpoint);
return 0
}
note when I am in edit mode it has the spaces just like that within the tags but loses the formatting when posting it.
I'm sure, as with every feature, there are potential bugs.
My experience with the use of the [code] tags in LQ are that:
When people don't use code tags and they paste code, sometimes the spacing gets screwed up where everything is all on the left margin. Perhaps they had tabs over spaces in their code.
When people use code tags, I do not believe I have ever seen something that looks like the spacing was unintentionally altered. Except by the original typist - single mistakes versus a global change.
Good description on the repeat with comments out showing. I just use <snip> on leaving out irreverent readouts and explain outside of code tags why the snip is there.
I picked that trick up when researching my own problems when learning how to drive and parallel park gnu/linux on my own.
Not sure if PS1 means play station one. Which I still own and use from time to time.
The coloring is just bells and whistles to me.
But then. I am shade tree linux user.
You guys tread in deeper waters while I am still in the kiddy pool.
But I have pimped out my urxvt a little on my own.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.