
Feature suggestions and discussion [READ THE FIRST POST]


. 














How about a change like
--- a/lib/philomena/versions.ex
+++ b/lib/philomena/versions.ex
@@ -48,7 +48,16 @@ defmodule Philomena.Versions do
end
defp difference(previous, nil), do: [eq: previous]
- defp difference(previous, next), do: String.myers_difference(previous, next)
+ defp difference(previous, next) do
+ List.myers_difference(String.split(previous), String.split(next))
+ |> Enum.map(fn {key, value} ->
+ adjust_whitespace({key, Enum.reduce(value, "", fn new, old ->
+ old <> " " <> new
+ end)})
+ end)
+ end
+ defp adjust_whitespace({:eq, str}), do: {:eq, " " <> str <> " "}
+ defp adjust_whitespace({op, str}), do: {op, String.trim(str)}
@doc """
Creates a version.
to turn gibberish like
into something readable
It’s certainly possible to pretty up the code a bit, but the comment history looks way nicer that way.
Background Pony #2A5F

. 














@byte[]
Or how about this:
Or how about this:
--- a/lib/philomena/versions.ex
+++ b/lib/philomena/versions.ex
@@ -48,7 +48,14 @@ defmodule Philomena.Versions do
end
defp difference(previous, nil), do: [eq: previous]
- defp difference(previous, next), do: String.myers_difference(previous, next)
+ defp difference(previous, next) do
+ List.myers_difference(split_with_whitespace(previous), split_with_whitespace(next))
+ |> Enum.map(
+ fn {key, value} ->
+ {key, List.foldl(value, "", fn x, acc -> acc <> x end)}
+ end)
+ end
+ defp split_with_whitespace(str), do: String.split(str, ~r{\s+}, include_captures: true)
@doc """
Creates a version.
This properly preserves newlines and such. I don’t think it matters when lines without changes are also included. Most posts don’t contain several pages worth of text and having context is indeed a good thing.
Background Pony #965A
@Background Pony #2A5F
Imo, git includes 3 lines of context because of traditional 80~140 symbols line limit, while natural plain texts may have lines of any size (aka paragraphs). So context from the changed paragraph alone usually should be enough.
Imo, git includes 3 lines of context because of traditional 80~140 symbols line limit, while natural plain texts may have lines of any size (aka paragraphs). So context from the changed paragraph alone usually should be enough.
Background Pony #0F89
@., @byte[], @Background Pony #2A5F
While we’re talking about this, the edit history page ought to also let you see the state of the post (or at least its code) at each state, without the diffs inserted, for easier readability - I have this inelegantly implemented in a userstyle that hides added text and unstyles removed text when I hover the block…
While we’re talking about this, the edit history page ought to also let you see the state of the post (or at least its code) at each state, without the diffs inserted, for easier readability - I have this inelegantly implemented in a userstyle that hides added text and unstyles removed text when I hover the block…
Background Pony #2A5F
@Luna
Not sure if line-wise diffs are optimal for this. Lines of regular text are longer than lines of code. Typically, a paragraph will be one line.
Not sure if line-wise diffs are optimal for this. Lines of regular text are longer than lines of code. Typically, a paragraph will be one line.

Luna 




















![A Perfectly Normal Pony - <meow> byte[] permission to suck your dick A Perfectly Normal Pony - <meow> byte[] permission to suck your dick](https://derpicdn.net/badges/2016/8/21/3347537b8cd4315817422b.svg)























Luna Best Pony~
@Background Pony #2A5F
They will also highlight differences in precise words. This diff is meant to be such that in extremely large posts or pages, where only 1 word changes, it’s possible to display just the snippet that changed with some context around it.
They will also highlight differences in precise words. This diff is meant to be such that in extremely large posts or pages, where only 1 word changes, it’s possible to display just the snippet that changed with some context around it.

Ciaran 












































Senior Moderator
君場森生きる
Feature Request: Ability to preview the contents of a gallery as images in a post or description
Problem (use case): Philomena displays images in sort order. Some artists and uploaders (henceforth: creators) upload sequential art. For example: ongoing comics. Artists often wish to provide an easy index to the story, or to provide links to the individual pages in the correct order. One workaround is to manually link pages in descriptions. This works well, but is inelegant and prone to failure if individual pages are replaced with new versions.
The most proper solution is most likely a way to ‘thread’ uploads. However, this may take a while to implement.
Instead, could Galleries be leveraged to achieve a similar result?
Proposed Fix:
- Permit previews of galleries to be shown in posts as ‘small’ thumbnails with links to the image.
- To prevent scaling issues of very large galleries, show only a preview of a few images along with the gallery title as a link. Allow the creator to indicate which images should be shown in the preview. Example choices:
• First (oldest) N images.
• Latest (newest) N images.
• Previous and Next images with the currently displayed image in the middle.
Proposed syntax:
- 
• GalleryIndex = Indicates this is a gallery index.
• gallery_name (string) = Name to display in link
• gallery_id (string) = unique identifier of a gallery on the site.
• display: = The type of display for gallery.
• display_type (enum) =first
|last
|centered
•first
= Displays first (oldest) N images in the gallery
•last
= Displays last (newest) N images in the gallery
•centered
= Displays 3 images in a table with the image_id of the current image ‘in the center’.
• count: (integer, optional) = Number of images to display. Not used when display_type iscentered
.
Use Case: If an upload is a part of a set - for example a page in a comic - this would allow artists/uploaders to upload a single boilerplate in the description that will show the correct sequence of the pages. The artist/uploader would then be able to add new images to the links for the series by adding new uploads to the gallery, and arranging them appropriately within the gallery.
Example of ‘First’ with 3 images:
Syntax:
Result:

Result:
Example of ‘Last’ with 5 images:
Syntax:
Result:

Result:
Example of ‘Centered’, using 3453704 as the ‘center’, or image_ID the description is on:
Syntax:
Result:

Result:
See more from WIP of Ciaran’s Rainbow Rocks 10th Image:
<- next you are here previous ->
With this, assuming they used the ‘centered’ format, creators could add each new upload to the gallery used in the links, add the gallery link to their descriptions, and then each image would have ‘next’ and ‘previous’ links and previews.
When they add new images, the links in the description would automagically update, and if they want to they can simply rearrange the sequence using the ‘rearrange’ feature of the gallery.
Although development would absolutely be required, I think this might help with some of the problems I’ve seen creators have threading their comics or other forms of sequential art together.
mdashlw 







Assistant
Site Developer
I’m not sure how feasible it is to implement but
filter:123
would be a very useful search term. E.g. filter:1
would only show images that pass filter 1, -filter:1
would only show images hidden by filter 1.Interested in advertising on Derpibooru? Click here for information!

Help fund the $15 daily operational cost of Derpibooru - support us financially!