Cool trick and tip of the day:

For those of you who fondly remember the days when there was an IBM 3270 terminal on your desk ... run the Citadel client locally on your machine and put "status_line=1" in your .citadelrc

You'll get an adorable status line on the screen that shows the host, room, etc. you're in, along with encryption status and the number of new emails you have. And for that authentic IBM flavor, you'll notice that on the right side there's a little "X" icon that appears when the client has a transaction in progress with the server.

(Yes, on a real 3270 it was a clock, but text-mode 3270 emulators always used an X instead)

Try it on a slow connection for that authentic "I'm waiting for the machinee" effect.

Cool. Thank you. BTW: I was searching for the config file... then I
realized it's called `citadel.rc`

You can copy citadel.rc to a file called ".citadelrc" in your home directory.
When this is found by the client it will be used instead of the global citadel.rc file. This gives you the option to customize it for just yourself and not everyone else on the same computer.

A couple of small changes to the text client are coming soon:

1. No more "localhost" wholist entries.
The text client will be smart enough to show the actual location of the user, even when it's running on the localhost and connects to 127.0.0.1 instead of the local socket.

2. A little experiment where we warn users about using '<E>nter Message' when they should be using '<R>eply'. Initially, this is only going to happen in rooms whose default view is "Blog". Today, a site like Uncensored can't have world-writable Blog rooms because many text client users still habitually use <E>nter when they should use <R>eply, and that creates a top-level Blog post instead of a comment. We'll experiment with this and see where it goes.

(Uncoincidentally, this is the same reason we can't easily do a topics-and-threads view ... but it could be argued that this would be somewhat un-Citadelian anyway.)

I'm not sure when Uncensored will receive the new software. I have to upgrade us to 64-bit Linux, which involves a time consuming database conversion. I might just do it at the same time.

Suggestion - add an option in .<E>nter <C>onfiguration to allow users to bypass warnings - this assumes that the warnings will display initially and the user is basically acknowledging that they prefer to do things the "Citadel way".

Another alternative would be to remove <E>nter message for these rooms and require text client users to .<E>nter <N>ew message or .<E>nter <R>eply. This bears in mind that the intent behind the text client is to keep the workflow of the associated user experience as simple as possible.

Just my $0.02 on something I use exclusively since it is so much easier to work with accessibility tools in order to read and navigate.

Whatever you do, don't make it more inconvenient for regular people to use the client for the sake of making it safer for dumb users :-)

Suggestion - add an option in .<E>nter <C>onfiguration to allow users

to bypass warnings - this assumes that the warnings will display

Well, we do have the "expert mode" setting for that.

The problem is that many of the "experts" have been using Citadel for 30+ years and aren't aware of threading semantics, so they just whack "<E>nter-message" when a "read-<N>ew-messages" operation exits to the room prompt. You (winzlo) did exactly that in the message I am replying to now. This is understandable when you're living inside a user interface that doesn't display the threads.

I've experimented with threaded views, but it doesn't work right when many users are starting new threads every time they hit <E>nter instead of <R>eply, and I can't even blame them; they don't understand the problem and we've given them no reason to. If we moved the text client to a threaded view, there would (quite justifiably) be an uproar.

Blog rooms are a different animal. In a blog room, we *need* the threads maintained, to properly associate comments with their respective blog posts.
Initially, we made it so that only the blog owner can make a top-level post; all others can only reply. This is easy to enforce in the text client, since it simply displays a message explaining why you're only allowed to reply if you try to do "<E>nter-message". And that's why the experiment is targeting blog rooms only, at the beginning. At the very least, we might be able to build blogs that anyone can post new entries to, without making a big mess.

2020-05-25 10:32 from darknetuser
Whatever you do, don't make it more inconvenient for regular people to

use the client for the sake of making it safer for dumb users :-)

Damn, that rules me out then. B^P

Off-the-wall suggestion...

Leveraging something like [n]curses, could certain rooms have a flag set to use a sort/select view and others be left thread-lesss? I know this would segregate Citadel-client loyalists into only using unthreaded rooms, but would at least offer the feature.

We've had a curses-integrated client before ... it became unwieldy and gave people a lot of build problems. As you know, we're trying hard to reduce build problems :)

My other thought was that perhaps we can make two different types of rooms, "linear" and "threaded" which will give the user different prompts as they navigate through. Perhaps the only difference in the text client would be that it gives the nag prompt when someone hits "<E>nter". And/or in WebCit it could present in a more traditional "web forum" view, where the first screen shows a summary of all active threads. <shrug>

Not happening yet, there's too much to do. I've got webcit-ng to finish first :)

Upon login today, I just realized something that differs a tad from "classic Citadel". During the login sequence, the point where it notifies the user that there is a new mail message shows up before the onslaught of the Lobby's conversation, not just prior to the prompt.

The <G>oto -> <N>ew flow ends up putting the user into the Mail> room anyway, but I thought it would be nice for the user to see this a little more obviously since there is a lot of screen scroll on busy Lobby> rooms.

I've got to admit, I read the entire room, then typically <E>nter my response, especially in the text client, and it is out of habit.

That's the original flow as it was built nearly 40 years ago, and all old-school Citadel afficionados are used to it. You land in a room, read everything new, and then whack the <E>nter key and decide what to say. I don't blame anyone for wanting to do that ... after all, the classic view is *built* for that ... it simply doesn't map well to other views.

Citadel's classic view simply wasn't built for "topics" and "threads". It was built for free-flowing conversation, and it still does that amazingly well. To force the use of "topics" and "threads" everywhere would certainly turn it into "not Citadel". The task at hand, then, is to figure out how -- and more importantly, *where* -- to compromise.

It's easy when rendering a web view, because the presentation gives the user a visual cue on how to interact with it. A room that displays as a blog is going to have comment boxes attached to each blog entry, and the "Enter message" button at the top has been replaced by "New blog post". A room that displays as a normal message board, on the other hand, has "Reply" and "ReplyQuoted" buttons next to each message, so they're used some of the time. Someone whose first and only experience with Citadel is on WebCit might use those buttons more than someone coming over from the text client ... but the "Enter message" button is still there on the top of the screen, so it could go either way.

I think the compromise will eventually be to offer two types of message board rooms. One would be the existing "linear" view that we all know and love, because again, it is excellent for free-flowing conversations. The other would be a "threaded" view, which would be appropriate for rooms like Citadel Support where you have threads whose conversations are tightly related to a specific topic. Here at Uncensored we'd stick with the "linear" view for most rooms. In a "threaded" room, a text client user who hits "<E>nter message" would then get the warning that they're in a special kind of room and they'd be starting a new topic, and do they really want to do that.

So that's my current thinking. Comments/suggestions?

"Good morning, Mr. Tyler. Going down?" Hahahaha.

Actually I agree with IG on the prompting when in a special room. Making all rooms in a floor threaded or not would be more confining for systems that have either too few rooms to bother with floors, or too many rooms and thus having to manage at what could be interepreted as a secondary configuration.


What would be interesting is an option for floors to set the default room type when new rooms are created. Perhaps I'm still in the compromise mindset with ParanoidDelusions's response.

;<E>nter <C>configuration would be the logical place for such an option, as well as offering to provide information about the floor.

I am forever a text client user, it is quite a significant burdon to try and navigate WebCit using accessibility tools - much as it is for any other messaging-based website. The flow is, as IG said, still valid and works very well. Getting these "Citadel Plus" features into the text client is always going tob e a hurdle due to the fundamental purpose of this client.

I like the direction being proposed, so long as the default option when pressing the spacebar is to not create a new thread, but return to the previous prompt for further user direction.

kinda cool when you're one of the most acccessible forums out there, due to sheer retro-ness.

kinda cool when you're one of the most acccessible forums out there,

due to sheer retro-ness.

The biggest reason why I miss BBS's to begin with. I was one of the lucky ones to be at the University of Minnesota when Gopher was created - precursor to the web. Still 100% text, so it was accessible, but had message boards, chat rooms, information, etc, all from a menu-driven curses-based environment.

Now, I'm a techno-dinosaur who gets his nostalgia fix from the UNIX command line and Uncensored.

To be sure, Citadel's split personality is both a blessing and a curse. There is no doubt, the text client focuses almost exclusively on the BBS use case, and will continue to do so for the foreseeable future. But it's also a really convenient way to read mail, go through RSS feeds, etc.

I've been struggling w ith this one for years. Certain users post messagesa, and I will see special characters like "TA" with oomlauts(sp) at every hard line break or paragraph. While I still cannot determine if the issue is the editor being used, or Citadel's inability to either strip the characters (which are invisable to non-macOS users), or to convert them into what they really are (most likely, \r, \n, null or any combination.)

I was able to circumvent this issue by hunting down a special font set called "Fira Code" that I am now using in my ZSH development environments for its ability to properly translate these characters. However, expecting all macOS users to manually install this font just to see messages in their intended format seems illogical.

IG, you remember this conversation? I think I sent you a mail with screen shots, which would give you the identity of one of the posters that is producing this issue.

In response to this information, I have uncovered the necessary combination of configuration options for the text client output to display properly on a macOS terminal session.

While I did go the extra mile and downloaded/installed the "Fira Code" font into my font library, I did this in order to support Ligatures (combinging symbols in order to create more visually appealing things such as borders and arrows, plus certain types of specialized symbols such as the Apple logo).

The real key appears to be in the text encoding portion of whichever terminal emulation program being used (macOS Terminal, iTerm, etc.) By default, these are set to Western (ISO Latin 1). The only combination in which I was able to get accurate display of the text client's intended output was to set the text encoding to Unicode (UTF-8).

This is quite a ways outside my technical knowledge, so please excuse these questions:

1. Was this done intentionally in order to support the global potential audience that a Citadel system could have?

2. Could this be altered on a per-server or per-client basis in order to better support the native terminal environment of the given operating system?

At leaset I have worked out what I needed to do. I would not be surprised if there are others that just disregard the visual anomolies and focus on the valid content. (FWIW, screen reading softweare does not know what to do when these characters are encountered, so I get all sorts of weird attempts to verbalize what it things it is "seeing". :) )